@Carl Love Of course what you write is correct: there always being some example which will cause numeric problems for any given fixed precision environment.

AFAIK "machine precision" means something more like hardware double precision, and should be closer to about (just over) 15 decimal digits rather than 17.

In Maple the simplest way to get a hardware double precision computation for this example (which happens to be quite accurate for this particular example, off by just a few ulps) is to compute it within Maple's evalhf facility. Ie,

restart;
f:=x->(1+1/x)^x:

evalhf(f(31536000.0))
                      2.71828178130237097

That is done very quickly.

restart;
f:=x->(1+1/x)^x:

CodeTools:-Usage( evalhf(f(31536000.0)) );
memory used=0.98KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns, gc time=0ns

                      2.71828178130237097

And, for the OP, the final evalhf result can be easily re-evaluated to 10 digits,

restart;
f:=x->(1+1/x)^x:

evalf[10]( evalhf(f(31536000.0)) ); 

                          2.718281781

To the audience, see the ?evalhf help page for more details.

evalhf( DBL_MIN );
                                         -307
                   1.00000010000000008 10    
evalhf( DBL_MAX );
                                         307
                    9.9999999000000001 10   
evalhf( DBL_EPSILON );
                                         -16
                   2.22044604925031308 10   
evalhf( Digits );
                              15.

To be fair to Mathematica, it should be mentioned that it also offers a numeric computation model in which the working precision can adjust itself, per computation, using a proprietary significance arithmetic model (somewhat akin to interval arithmetic). In that scheme a specified precision on the inbound numeric quantities can be used to meet a target accurracy. In contrast, in Maple the `Digits` environment variable only promises a target accuracy for so-called atomic operations, and in compound operations such as the example at hand the numeric round-off error can accumulate. In general it is up to the user to find a `Digits` setting that produces an accurate result for floating-point evaluation of expressions involving compound computations. (I have a somewhat rough attempt at a user-friendly front end to `evalr` and `shake` which gives a more robust float evaluation of examples like this one, trying for target accuracy. Should I polish it up?)

solve( { not x<100 }, x)[1];

                                        100 <= x

Now, are you OK with the name being on the right hand side like that? If not you need it reversed then (since 'x>=100' automatically simplifies to 100<=x) you may need to use something like sprintf or nprintf to turn such offending beasts into something that prints with lhs and rhs reversed.

acer

@Carl Love I am not sure that you are right in thinking that the essential problem is something that has changed with respect to Matrix (rtable) evaluation.

Similar evaluation behavior can be recreated in Maple 2016 if one creates a Matrix using unevaluation quotes. Eg.

restart;

C11:=upsilon[21]:

P:=Matrix([['C11']]);
                                 P := [C11]

eval(P, [upsilon[21]=3.4]);
                                [upsilon[21]]

eval(copy(P), [upsilon[21]=3.4]);
                                    [3.4]

Q:=map(eval,P,1);
                             Q := [upsilon[21]]

eval(Q, [upsilon[21]=3.4]);
                                    [3.4]

eval(rtable_eval(P), [upsilon[21]=3.4]);
                                    [3.4]

kernelopts(version);
         Maple 2016.0, X86 64 WINDOWS, Feb 16 2016, Build ID 1113130

I suspect that the discussions of rtable eveluation is sometimes muddied a bit because elements are evaluated upon access individually (extraction) and by printing of the whole thing.

@vv The use of so-called 2-argument eval to get different instances of the Matrix (instantiated at each set of values of the parameters) is superior to repeated assignment of sets of values to the top-level parameter names, I would agree.

One partial reason that it does not work for the OP is that he has created his Matrix using the infernal Matrix palette in 2D Input, which through poor design includes (unnecessary and unfortunate) unevaluation around the parsed elements. (I have previously submitted a bug report against that...)

It is not strictly necessary to use rtable_eval in order to work around this. Mapping 1-level eval across C[iso] is also sufficient, and it need only be done once, with the result reassigned to name C[iso]. And after that the use of 2-argument eval to evaluate the Matrix at the list of points should work.

Of course, if the OP is dead-set on using the method of repeatedly re-assigning the parameter names (rather than use the 2-argument eval or subs to instantiate at a list/set of points) then the C[iso] Matrix would also have to be somehow copied each time since otherwise the re-assignments clobber each other. Here is a version of that approach, done with Maple 15. Forum_Question_alt.mw As Carl has demonstrated rtable_eval (combined even with 2-argument eval) may be another effective solution for the OP.

How was the file "transferred" across the network? 

There are some instances of things like webmail which turn XML files like Maple .mw into empty 0-length files. Often that can be avoided by transferring a zipped copy instead.

I don't see where you've indicated that .mw worksheets which have not been so transferred could or could not be uploaded by you from the problem network. That would be a useful thing to rule out.

Some people have reported an inability to inline their uploaded worksheets here. But you may still be able to Insert Link even if you cannot Insert Worksheet (inline its contents) in the upload popup dialogue here. Another useful thing to rule out.

acer

@Carl Love I have run across that problem where the plot is lightened while highlighted, and I too think that its ridiculous behavior.

what is Besselj with lowercase j?  Is it supposed to be BesselJ? 

acer

@Bendesarts Do you mean something like this?

TrigEq3modif.mw

@tomleslie  A space between the 2 and the . (period) should also suffice. But nothing wrong with your suggestion of course.

I forgot to add that the Asker should not be loading LinearAlgebra[Modular] if that specialized subpackage is not what's wanted - it is not the same as the LinearAlgebra package.

@Bendesarts It's not clear to me whether you want to keep that "common" denominator.

TrigEq2.mw

Did you also wish to allow combining some of the trig terms?

Try changing those two instances of floating-point 2. to exact 2 instead. (It's possible that you intended the `.` for explicit multiplication, but forgot the spaces and hence input floats.)

acer

@Kitonum It may be worth noting that the optional second argument to `combine` may be useful in such cases, in order to restrict what kinds of combining are done if additional kinds of terms are present. Eg,

combine(y(x) = 1/3/2^x+_C1/(3^x)^2 + cos(x)*sin(x));   
    
                               x  (2 x)                   x      (2 x)   (-x)  (-2 x)
                y(x) = 1/6 (3 2  3      sin(2 x) + 6 _C1 2  + 2 3     ) 2     3

combine(y(x) = 1/3/2^x+_C1/(3^x)^2 + cos(x)*sin(x), power);

                                     (-x)
                                     2            (-2 x)
                              y(x) = ----- + _C1 3       + cos(x) sin(x)
                                       3

@samira moradi 

I suspect that the "rsquared" result may only be available when the target expression is linear in the parameters. Additional computed results and statistics may be obtained using the `solutionmodule` output (or, with a list of strings as the rhs of the `output` option). Also see the help page for the Statistics:-Fit command.

restart;

X := a * (-0.6356560300e-1*ln(Y+200.+17.54410643*Y^(2/3)+102.5985568*Y^(1/3))+
          0.6356560300e-1*ln(Y+200.)-.2201977080*arctan(.1974510146*Y^(1/3)
          -.5773502693)+.1096187623);

vx := <1500, 1340.00, 1135.00, 982.00, 884.15, 704.72, 520.00, 287.00, 70.00, 0.>:
vy := <0., 4.28, 7.77, 7.30, 9.00, 13.00, 25.85, 28.91, 38.48, 50.00>:

f:=Statistics:-Fit(X, vy, vx, Y, output=solutionmodule):

f:-Results("parametervalues");

f:-Results("leastsquaresfunction");

f:-Results("residualsumofsquares");

f:-Results("residualmeansquare");

f:-Results("rsquared");

f:-Results("rsquaredadjusted");

#f:-Results();

p1:=plot(vx,vy,style=point):
p2:=plot( [f:-Results("leastsquaresfunction"),Y,Y=0..50],color=red):
plots:-display(p1,p2);

@Traruh Synred Why not upload the xxx_MAS.bak file (or whatever) that is non-empty?  I mean, if it does not open properly, even after renaiming the file's extension from .bak to .mw say.

@Annonymouse I don't see a way to get the slightly larger asterisk that is tighter against the `y` (as Carl showed), without the subscript being set too far to the right. That leaves mostly the examples where the asterisk is slightly smaller and higher (as an exponent), but at least not too far right. It's tricky because the asterisk gets a higher baseline.

restart;
with(DEtools):
NLC := diff(y(t), t) = k*(Am-y(t));
Am := 20; k := .1;
ivs := [y(0) = 10, y(0) = 30, y(0) = 50];

DEplot(NLC, y(t), t = 0 .. 20, ivs,
       tickmarks = [default,
                    [10 = `y*__1`,
                     15 = `y*`[1],
                     20 = `#msubsup(mi("y"),mn("1"),mo("*"))`,
                     30 = y[1]^`*`,
                     40 = y[1]^`∗`,
                     50 = y[1]^`*` ]],
       font = [default, default, 15], view=7..50);

You could try using the entity lowast instead of ast, as I did above at tick y=40. But on my Linux that doesn't look pretty.

An additional wrinkle is that the y-view is not automatically expanded below to fit the y-tickmarks. So if your specified font makes the tick at y=10 too large then it may not get displayed unless you force a taller y-view.