@das1404 There's no difference between sin(s)^2 and (sin(s))^2. The latter simply has superfluous parentheses (which I personally find to be a significant annoyance when I'm trying to read code). There's no question of the latter form being "safer"; the former will only ever be interpreted as squaring the whole expression. I've done computer programming for 40 years, and I've studied a great many computer languages. I'm not aware of any language where f(x)^2 is interpreted (or could even possibly be interpreted) as f(x^2), although I suppose that that possibility exists if there's some language that let's you change the precedence of operators. (Is there any such language?) Nor am I aware of any standard or system for printing formulas for reading by humans where f(x)² is intended to be interpreted as f(x²).

If you consider the juxtaposition between f and (x) to be a binary infix operator (and you should consider it thus), then this operator has higher precedence than all the "normal" operators (all except || and :-) , such as ^. Its precedence relative to || and :- is a bit more complicated to state because it depends on which is on the left and which is on the right. The associativity of this juxtaposition operator is to the left. That is, f(x)(y) is equivalent to (f(x))(y).

In Maple's loathsome and hideous 2-D input (which you, David, don't have because it's newer than Maple 7), a distinction is made between f(x) and f (x): In the latter, the space is considered a multiplication operator. This is the source of a great many problems reported here on MaplePrimes. Using this, f (x)^2 would be interpretted as f*(x^2). This doesn't contradict what I said above because there's no function application at all.

@vv The way that it's done in much of Maple's library code is that there's a keyword option to specify in-place operation (the same as call by reference) with the default being call by value. Like this:

foo:= proc(REC::record, {inplace::truefalse:= false})
local rec:= `if`(inplace, REC, copy(REC));
   rec:-b:= 5;
   `if`(inplace, NULL, eval(rec))
end proc:

R:= Record(b=99):
R2:= foo(R);
                      R2 := Record(b = 5)
eval(R);
                         Record(b = 99)
foo(R, inplace);
eval(R);
                         Record(b = 5)

You can change  inplace to any name that you want.

@nm So, are you telling me that in Mathematica, if I have a procedure with a matrix argument that makes a change to the matrix's entries, and I pass it a 3000x3000 matrix, then the default behavior is to pass it by value so that the entire matrix needs to be copied? I'm a bit skeptical about that.

Records are not rtables. Where did you see that? Records are modules.

@Carl Love I now see why you had set those options to 0---you were trying to suppress the display of the output of the non-plotting commands in the loop. Here's a better way to do that: End the loop with a colon rather than a semicolon, and for any plots generated in the loop that you want see, put them inside a print command. If you want to also save those plots for later, do it like this:

PL:= plot(...);
print(PL);

If you want to see them but not save them, do

print(plot(...));

The above work for all plotting commands, not just plot itself.

Option verboseproc affects the display of the code of procedures; it has no affect on the display of values generated within procedures (unless those values are the code of procedures). Option prettyprint affects the format that output is displayed; it doesn't change whether it is displayed. The environment variable printlevel does affect the display of output from within loops (and procedures), but it's all or nothing---you either see all the output at a given level or none. It's use is best reserved for very crude ad hoc debugging. The command userinfo gives much finer control over the display of internal output (including plots), and its use is acceptable (even desirable) for finished publishable code.

@tomleslie

1. By your emphasis on display, I think that you may cause some confusion about the issue, even if you understand it yourself. Maple's sets are actually stored in the order that they display---it's not just a matter of display. This can be verified thus:

S1:= {z,y,x}:  S2:= {y,z,x}:
disassemble(addressof(S1))[2];
                      18446746039894322502
disassemble(addressof(S2))[2];
                      18446746039894322502
#Thus the "two" sets S1 and S2 are actually stored at the same
#address--they're actually one set.
disassemble(%);
        31, 18446746039791410366, 18446746039791419870, 18446746039791423582
pointto~([%][2..]);
                           [x, y, z]

For your convenience, here's the above code in a copy-and-pasteable format:

S1:= {z,y,x}:  S2:= {y,z,x}:
disassemble(addressof(S1))[2];
disassemble(addressof(S2))[2];
disassemble(%);
pointto~([%][2..]);

This issue of storage format vs. display format is in contrast to, for example, a symbolic integral: It may display in a 2-D format, but it's internally stored in a 1-D format. Or a Matrix with a non-standard indexing function may display in an order different than the order that it's stored in.

2. What you say about mathematical sets is of course true, but it's not true of Maple's sets, which is what Adam is referring to. Maple's sets are stored in a definite order with definite rules; it is not haphazard (unlike polynomials). It is by sorting the elements that Maple can detect the equality of two sets that are entered in different orders. This happens during automatic simplification. The ordering used may change from version to version, at MapleSoft's convenience, so there's not much point in documenting it. If you want to use Maple's set ordering as a total order for any other  purpose, such as with the sort command, then you can use ((x,y)-> {x,y}[1] = x) as the ordering procedure.

3. While I haven't worked out all the details yet, I foresee no difficulty in principle with defining a mathematical construct such as Adam wants and implementing it in Maple.

@mehdibaghaee It can be done like this:

DO:= 2: #differential order
Neq:= 2: #number of equations
C:= [<1,0;0,1>, <2,3;8,7>, <4,5;9,10>];
B:= <6,11>:
Tau:= <tau__||(1..Neq)(t)>;
add(C[k+1].map(diff, Tau, [t$DO-k]), k= 0..DO) =~ B;
convert(%, set);

@Adam Ledger 23*Pi is much too small for there to be a catastrophic cancellation.

You don't need 10000 digits to fix this. You just need the current value of Digits+1+ilog10(abs(N)) where N is the integer part returned by frac.

Yes, but it's not really a bug in frac or evalf.

@mlog In your summary of VV's Answer, your point (3) is "get the normalization coefficient with the use of simplify(convert(f, rational))". That's not correct. That command is what accomplishes your point (2). The command that VV used to get the normalization coefficient is denom, which extracts the denominator of an expression, which is not necessarily purely numeric. So the general case could possibly involve many more steps to get down to a number.

@Adam Ledger Those curly braces, in this context, mean the same thing as parentheses.

You must never numerically evaluate the expression inside the O as part of numerically evaluating the expression that contains the O. That's because the O is "hiding" a constant coefficient. Without knowing that coefficient, numeric evaluation is meaningless. And almost always when you see a formula like that, the author doesn't know the coefficient either.

You can sometimes do some experimental mathematics to estimate the coefficient. If you have a formula f(n) = g(n) + O(h(n)), and you have some way (perhaps expensive) to also compute f(n) exactly, then compute

abs(f(k) - g(k))/h(k)

for some large number of values of k. Some statistical analysis of that, perhaps just a scatterplot, may reveal an estimate of the coefficient. I suggest that you try this.

Here's a procedure to numerically evaluate that formula:

Cesaro_ithprime:= proc(k::posint)
description `An approximation to ithprime(k)`;
local L:= ln(k), L2:= ln(L);
   round(k*(L+L2-1+(L2-2)/L-(L2^2-6*L2+11)/2/L^2))
end proc:

This little code snippet (below) will tell you the largest rank k that ithprime has stored knowledge about. Calling ithprime(K) for K > > k will get unbearably slow due an idiosyncracy of Maple's handling of lists.

max(rhs~(op(op(4,eval(`ithprime/large`)))));
      22299999

I discussed and analyzed this extensively in another thread a few days ago. The Questioner was David Sycamore.

@Adam Ledger If you call frac(ex) where ex is some exact expression (no floats), you get back ex - M where M is some integer. This expression is what is passed to evalf; neither frac nor `evalf/frac` are involved anymore. As in well known, computing the decimal approximation of the difference of two large quantities of nearly equal magnitude requires a significant increase in Digits. I am working on a solution.

@rahinui Thanks. I can download and easily work with that file. I'll be posting an Answer to your Question in a few minutes.

Also, I can confirm now that the .maple file extension is meant to apply to workbooks, which are a kind of superset of worksheets.

@Markiyan Hirnyk The question remains for me for all of these plots (including your very strange initial plot): Is it just the line b = 4*p? I haven't yet tried to prove/disprove that. I would need to simplify to get around a divide-by-zero.

@Adam Ledger Functions that appear inside O(...) or o(...) (and the related order/asymptotic symbols) should be:

1. in some sense simpler, or at least simpler to compute, than the function being approximated;
2. eventually positive;
3. eventually strictly monotonic;
4. eventually analytic;
5. have no coefficient (or perhaps we should say that the coefficient is 1 or -1).

(Those are my own criteria; I haven't read all those rules anywhere.) Rule 2 is required by the definitions of the Bachmann-Landau symbols. Usually having of 3 and 4 imply 1. Violating Rule 5 would make your writing look ridiculous to anyone who understands O, etc. We could violate the rules (other than 2) and still satisfy the definitions. But is there ever a good reason to do so? I think not. If we can satisfy 2, 3, 4, and 5, then I'm willing to call it a "generic" function. Good/common candidates are n^p, ln(n)^p, n! (or GAMMA), n^n, e^n (for any real constant p) or any products of those. That's by no means a complete list.

Sometimes those are given with a small range of values for the p. In those cases, one can often publish a paper if one can simply narrow the range. I've seen publishable results that narrow the range in the 7th decimal place!^[1] In the linked paper, the author reduces the asymptotic time complexity of a matrix-multiplication algotithm for two n x n matrices from O(n^2.3728642) to O(n^2.3728639). See the Wikipedia article "Coppersmith-Winograd algorithm".

You should also read the Wikipedia articles "big O notation" and "Computational complexity of mathematical operations".

[1] Le Gall, François (2014), "Powers of tensors and fast matrix multiplication", Proceedings of the 39th International Symposium on Symbolic and Algebraic Computation (ISSAC 2014), arXiv:1401.7714

@Markiyan Hirnyk Here is my understanding of VV's Answer. Of course, we must ask if it is possible to obtain his parameterization somewhat automatically with Maple.

#This is the lhs of your plotted equation:
F:= unapply(sqrt(b)*sqrt(1-4*p/b)-2*arctan(sqrt((9*p/b-22201/10000)/(9/4-9*p/b))), (b,p)):
#This is VV's parameterization:
P:=5625*t^2*tan((1/2)*t)^2*(1/299)+22201*t^2*(1/1196): # 0 < t < Pi
#By plotting P vs. 4*P+t^2, he's implicitly claiming that 
#F(4*P+t^2, P) = 0 assuming 0 < t, t < Pi
#Let's verify that.

#I needed to restrict to t < Pi/2 to make progress:
zero:= simplify(F(4*P+t^2, P)) assuming 0 < t, t < Pi/2;
                           /              (1/2)\    
                           |/       2    \     |    
                           |\-cos(t)  + 1/     |    
            zero := -arctan|-------------------| + t
                           \      cos(t)       /    
simplify(convert(zero, tan)) assuming 0 < t, t < Pi/2;
                               0
#For t in the 2nd quadrant, it appears to be not true: 
simplify(convert(zero, tan)) assuming Pi/2 < t, t < Pi;
                             /sin(t)\    
                      -arctan|------| + t
                             \cos(t)/    
#A good pre-calculus student should be able to simplify the above
#to Pi, but Maple can't!
plot(%, t= Pi/2+0.01..Pi);

@vv add has special evaluation rules; sum has the same evaluation as the vast, vast majority of Maple commands: evaluate first, then pass. It's just that that seems "special" for sum because it's usually add's evaluation rules that are desired.