@Carl Love My code above doesn't handle every possible case of obtaining a decimal approximation of frac(x) where x is a symbolic real constant of large magnitude. It relies on the ability of frac to find the integer part. There are some extreme cases where frac returns unevaluated.

My code also doesn't the handle the two-argument derivative-of-frac case. It seems unlikely that that case would come up.

@acer You mentioned "special evaluation rules of evalf." Do you know what those rules are? There does seem to be something special, but my experiments so far haven't been able to nail it down.

@rahinui The exp= 1 trick works because explicit numbers can be used as procedures that return themselves. This doesn't apply to symbolic numbers like Pi.

@vv In that case I'll continue. But this material is still intended primarily for @nm.

In some library procedure, inplace can be specified as an option by using an index on the procedure's name. This is coded as

foo:= proc(REC::record)
local 
   inplace:= procname::'indexed' and ':-inplace' in {op(procname)}, 
   rec:= `if`(inplace, REC, copy(REC))
;
   rec:-b:= 5;
   `if`(inplace, NULL, eval(rec))
end proc:

And it's invoked as

foo(R)
or
foo[inplace](R)

@vv Oops, that Reply was not meant to be directed specifically at you. I forgot to take off the @vv.

@vv In the related thread, I just posted some `evalf/...` code to work around the frac problem.

@das1404 lprint shows you output in its most-basic one-dimensional plaintext format. It is useful for re-examining output that you can't otherwise understand. That is the context that I previously recommended it for. Setting interface(prettyprint= 0) is pretty much equivalent to putting all output into lprint form.

The command print(expr) means "evaluate expr and display it in whatever format it would've been displayed in had it been output at the top level." So, if expr is a plot, then it's displayed as a plot. I guess that that wasn't your intuition.

@Kitonum You said that "everything works with assuming." But the very thing that the OP wants, simplify(A*B), still doesn't work with assuming.

@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.