@spark1631 Are you invoking Engine? If so then isn't its first argument a string of options similar to those of the commandline interface? And if so then could you try passing the -T option?

You might also try that in combination with passing the -Xss option when invoking java itself.

Just some ideas.

The hard limit (above which kernelopts(stacklimit) cannot be raised) depends on the Maple version and the platform.

acer

@Alejandro Jakubi I would like to see the help pages for topic=$ and topic=seq clearly describe when the repetition (or expression production) occurs, and when any evaluation occurs.

The following four cases are the kind of thing I feel would be generally useful, if properly annotated. (I believe that I understand what's going on in each case, and that people using seq and $ would benefit from having the full explanation readily available in the help system proper.)

restart:
f:=proc() global count;
     if not count::numeric then count:=1;
     else count:=count+1;
     end if;
   end proc:
seq('f'(),i=1..4);
                       f(), f(), f(), f()
count;
                             count

restart:
f:=proc() global count;
     if not count::numeric then count:=1;
     else count:=count+1;
     end if;
   end proc:
seq(f(),i=1..4);
                           1, 2, 3, 4
count;
                               4

restart:
f:=proc() global count;
     if not count::numeric then count:=1;
     else count:=count+1;
     end if;
   end proc:
'f'()$4;
                           1, 2, 3, 4
count;
                               4

restart:
f:=proc() global count;
     if not count::numeric then count:=1;
     else count:=count+1;
     end if;
   end proc:
f()$4;
                           1, 1, 1, 1
count;
                               1

@Athar Kharal I've been working on a tool for this, but it does yet support extraction of every kind of input, output, and other object. Is your file a Document or a Worksheet? 1D or 2D input? Does it have Sections? Are any of the inputs within GUI Tables? Is there code to extract from code edit regions

@Carl Love Something quite close is possible in Maple 2015, using the new programmatic content functionality.

(I didn't try a custom light source... Can one of the lights be a reflection of a point light source? The surface looks a bit glossier in my Maple GUI itself, when reexecuted.)

>  restart: >  with(plottools): with(plots): >  p1:=hemisphere([0,0,0],1.5,capped=false): >  p2:=hemisphere([0,0,0],1.45,capped=false): >  p3:=display(sector([0,0],1.45..1.5,0..Pi),             sector([0,0],1.45..1.5,Pi..2*Pi)): >  p3:=extrude(p3,-0.001..0.001): >  P:=display(p1,p2,p3,scaling=constrained,style=surface,            axes=none,color="#cc8800",orientation=[22,47,-31],            glossiness=1.0,lightmodel=Light4): >  DocumentTools:-Tabulate([P],fillcolor="black",widthmode=pixels,width=400); >  with(DocumentTools:-Layout): >  xml:=Worksheet(Table(alignment=center,widthmode=pixels,width=380,                      Row(Cell(InlinePlot(P,scale=1.6,xtrans=2,ytrans=-3,                                          height=330,width=380),fillcolor="black")))): >  DocumentTools:-InsertContent(xml); >

Download tabfun.mw

@Denni I don't have access to 64bit Linux with that particular CPU, on which to try with 64bit Maple 15.01. The Xeon's I can access apear to be quite a bit older.

I'm not sure whether it is related to the combination of Maple 15.01 and that Xeon, or the combination of Maple 15.01 and that OS, or all three.

It might be related to the 64bit Linux version of Maple 15.01 (2011) only being officially supported for Ubuntu 10.04 and 10.10. Your "Ubuntu 3.13.0-49-generic" is Ubuntu 14.04 (trusty, 2014) I believe.

As far as I know Maple 2015 (the current major release) is the first to officially support Ubuntu 14.04 LTS and 14.10. The previous major release Maple 18 states official 64bit Ubuntu support for only 12.04 LTS and 13.10.

Your minimal working example might possibly have a workaround by raising Digits > evalhf(Digits) to avoid evalhf. I don't recall that a customized NumericEventHandler to sidestep division-by-zero would work in Maple 15 under evalhf. But I suspect that you'd be better off with a correct solution with full functionality and not just a (possibly slow) workaround.

What kind of machine is the server? I mean, chipset and OS? And what do the commands kernelopts(version) and system(processor) report on it?

acer

@Alejandro Jakubi I have submitted a bug report.

@Markiyan Hirnyk I respectfully leave searching the help for yet another example up to you.

@Markiyan Hirnyk There is an example in the Maple 18 help page accessed via topic solve,details as the 1D Maple notation code,

solve( {x^2*y^2 = 0, x - y = 1, x <> 0} );

                         {x = 1, y = 0}

When viewed in 2D Input mode, that help page shows that example like  rather than the 1D Maple notation x<>0. But that's just a different display of the same expression.

@Carl Love The issue is not equality of Matrices. It is, rather, one of relative equality of Vectors, which can be considered as rows (or columns) of a Matrix. In that context the rank of the Matrix (of Vector rows) is germane.

@Carl Love It is quite standard (not just in Maple) to use svd to determine the rank of a floating-point Matrix. There are some rank-revealing qr decompositions, but svd is quite robust. The corner cases can be difficult.

Thanks for exapanding on the mutability thing. (It's been discussed on this site many times before. I'd guess that Alejandro has some reference links at his fingertips...)

@Rouben Rostamian  It is because Vectors are mutable.

It's a quibble, but the original was a list, so returning a list seems to be what was asked. (And the `map` can also be made into an elementwise operation). Ie,

`<|>`~([convert~({eq[]}, list)[]]);

It doesn't matter for the given example, but the case may arise where there are float Vectors which are "close enough" but with nonzero difference. In such a case it may be that an SVD decomposition and (rank based) reconstruction might be used.

How many rows and columns of plots do you have in a Table?

Are they 2D or 3D plots?

Do you wish to avoid page-breaks between Table rows, in the printed export?

What's the smallest fraction of a page-width you'd want to see for any individual plot?

What version of Maple are you using?

Do you use plots:-display to show an Array of plots in a GUI Table?

Do you use the size option (for 2D plots)?

Do you use the legendstyle option to control the font size?

Please consider uploading an example, to give a better idea of the intended layout.

What (roughly) is the geometry of your Maple GUI window, in which you'd also like things to look reasonable? Can we suppose that obtaining nice layout in the printed export is the most important thing here?

acer

@Markiyan Hirnyk The problematic result that the OP showed may be reprodced with something like,

evalf( solve(convert(Eq1, rational, exact),diff(y1(t), t, t)) );

There is no fool-proof way to decide what is best, without complete knowledge of the particular floats present. Using convert(Eq1, rational) produces a solution to a slightly different problem, and is an approach that may or may not be better in general. It's important to note that it is solving a different problem, even if in this particular case it is clear (by manual observation of the floats in question) that it will deliver well.

For example, if the float .2916666667 in Eq1 had instead been 0.7071067812 then it might be more desirable to instead use convert(identify(Eq1), rational) which would recognize that as 1/sqrt(2). If that float had instead been 0.5432154321 then convert(Eq1,rational) works on a different problem with that float converted with an error of 1e-10, 1 ulp. Using isolate rather than solve works for the given problem without producing as many lengthy factors, but of course that approach may presuppose that the data is "accurate".

There is no perfect solution to such issues in general, which (by the way) is why symbolic dsolve offers several choices of float conversion mechanisms via options.

Perhaps another good suggestion for the OP would be to also try and introduce floats into symbolic equations as late as possible. This may not be possible in the case of measured data, of course.