Mac Dude

1561 Reputation

17 Badges

12 years, 266 days

MaplePrimes Activity

These are replies submitted by Mac Dude

@Rouben Rostamian  Actually, in LaTeX you want to use eps anyway. Using graphicx, the file will be combined into the ps file that dvips puts out to the printer; or to the output file.


@Alejandro Jakubi I am just running it on Maple 12 and it hasn't gotten anywhere in 10 minutes CPU.

But Carl may have found the issue...



Something like this works:

f := (x*Unit('m'))^2+(y*Unit('m'))^2 = Unit('m')^2;


It even seems to work if the units on one side are expressed diferently than on the other side; although you then quickly realize that the units are not treated as units but merely as multiplier (you can end up with something like 1+x*Unit('m'), which does not make too much sense). In the above example the units are immediately simplified away by Maple.

But it really is not clear what it is you are trying to achieve using Units. To have a meaningful equation you need to have the same units on either side. One an construe cases with a dimensioned multiplier on one side to achieve this, but what is the point? It seems that not knowing the units a priori may indicate the problem is not well understood to begin with. You can often get rid of units by proper normalization of your values before attempting to solve.

The sign question is a bit different but again it isn't trivially obvious it is solvable in general when symbolic math is involved. As soon as you have a variable left in your solution (which you do in the simple example), what does "y>0" refer to for general x (even x > 0)? Make x big enough and y will go imaginary. How can this be solved in general?

It is somewhat different for fsolve, where you end up with numbers and you can test for sign (but it is not general as far as parameters is concerned.

Occasionally you may be able to address this by e.g. squaring the equation and then solving. It leaves you with explicitly taking the root and then using only the branch you want to. This will limit the class of problems you can solve, though.


You ask "Why is y = -sqrt(-x^2+1) a solution?" The answer should be obvious if you square the equation.

Y^2 = 1-x^2 is certainly a solution. A square root has two branches, and Maple keeps track of these.

When it comes to units, you equate two quantities without unit to one quantity with a unit of m^2. This is clearly not right. I suppose if you either define x and y to have the right unit, or multiply them with Unit('m), you should get further along. But I am not an expert at all in the Maple way of keeping track of units.




@rodrigog You need to consider interpolation of (one or both of) the data arrays. Look up ArrayInterpolation in the help facility; also there is a file Interpolation_and_Smoothing.examples that shows ways to do this.

With interpolation you do accept a certain amount of noise added to your data.



@Alejandro Jakubi 

I just did a little test. I opened a 260 MB (twohundredsixty MegaBytes) buster, a run of a simulation. Took maybe half a minute. There is something like a dozen or more plots plus an endless number of arrays, each one at least 6000 elements long, many are 6000 by 5 or so. The file is about 55 screen-full 9incl. the plots at default size). The JVM grew to a little over 1 GB (this process is allowing for a max 1Gig heap using the mod I explained above). The Maple kernel actually reports something like 81 MB right after opening which means it must have done something to force an allocation since its normal initial state is about 1...2 MB usage. Likely this is from loading my packages and running the ModuleLoad procedure. This particular file will bloat the kernel to beyond 2 GB when run (and takes several hours). The saving grace here is that I use Worksheet mode (I don't think this prog would run in Document mode) and that I do not have many 3-d plots which tend to hog and sometimes crash the JVM.
All this, however, with Maple 15 on a PowerMac G5. This is a 32 bit environment. With Maple 17 in a 64 bit environment the limit is RAM: once it has eaten up all physical RAM the system becomes basically inaccessible due to excessive paging. It does keep running, though.

Some of the reasons this particular sheet is so bloated lies in sub-optimal (from a Maple perspective) coding and I am spending time on finding ways I can modify the code to reduce the memory space required (for the kernel; the GUI is beyond hope in this regard).

I guess my point here is that Maple is able to deal with significant amounts of memory and large worksheets even in 32 bit (and obviously much larger ones in 64 bit environments). It would be useful to hear what the OP is actually doing that causes his issues, as well what environment (s)he is running in.


On Mac OS X, you can increase the JVM memory space like this:

Find the Maple application. Right click on it and select Show Package Contents. Open the "Contents" folder. In there you find an info.plist file.

Hopefully you have the Developer Tools in which case info.plist opens into the Property List Editor. If no Developer Tools, you'll need to use a text editor and wade around in xml code. Be that as it may: fine the Java entry in the plist and open that (click the triangle in the plist editor). Find the item VMOptions which has the command-line options used when firing up the JVM. Prepend what is there with -Xmx1g. Case matters here! This option sets the maximum memory during execution to 1GB. Save and close the file. Restart Maple.

You may want to backup the plist file before you do this, esp. if you use an editor.

Sorry, I do not know how to do this in Windows or Linux.

Now; all of this is for nought if you do not have enough physical memory. E.g., if you have 1 GB only you will run into problems as the system gets memory starved and will page forever.

Having said all this; I am still suspicious that something else is going on. I have many files of low tens of MB in size and these certainly open, if slowly. Even in Maple 15 on an aging PPC Mac. On an Intel Mac with 14 GB RAM and Maple 17 they actually open reasonably quickly (maybe 10 sec., max). The biggest hog (in my case) is the graphics. Reams of output and/or working in Document mode (as opposed to worksheet mode) do not help either. I have not had such files not open although I have had them be unusable (every action would take forever).

I have had files getting corrupted, but only very rarely. Document mode with typeset-everything is more prone to that.





You can also use the Digits parameter to control how many digits Maple uses. If you increase Digits from its default value of 10 to, say, 100, your round-off error will be so much smaller.

Having said that, I do not recommend that for general use. If you have trouble at Digits=15 (which is what I happen to use because it is the hardware precision), you are likely up to no good anyway and need to review your algorithm(s).




diff(f(x),x) is the standard way to enter a differential quotient in Maple (specifically in  Worksheet mode, red prompt and red typewriter-style input). There is an operator D, which may have a notation closer to your liking. You can look that up in the help facility (?D).

In document mode the input looks closer to standard mathematical notation. You can use the Expressions pallette to enter things like differentials (and then fill in the placeholders).


@Kitonum ...but note, your examples only work because the value can be expressed in Maple in an exact way. Try cos(1). The point I am trying to make is that this has nothing to do with radians or degrees. sin and cos >always< work in rad. If the result can be expressed in an exact manner in Maple, they will evaluate. If not, they will not evaluate unless given a float as an argument.


Carl is correct. However, as far as I can tell these options only exist for 2-d plots. I recently wanted gridlines for 3-d plots and found that the grid-related options don't work for 3-d plots.


You did not mention the OS you run. On Mac OS X I can have several Java versions and pick which ones it uses at least by default (using Applications:Utilities:Java:J2SE :Java On Linux I would suspect the same can be done albeit using a different mechanism. On Windows? No clue.

Mac Dude.

@Carl Love Hmm, maybe I should test my package against Maple 18 (which I have access to but not routinely use). In this particular case it seems what works in 15...17, and it seems to me that there may actually be some improvement to report here; certainly to the uninitiated the use of double quotes is not at all intuitive (although, when the manual calls the "rule" for a type a handler one gets the idea that something may actually get evaluated, hence the occasional need to prevent that).  But then; the whole type facility is a bit arcane, what with structured types and so on (which I actually tried in my case as well, but which got get nowhere fast).

Needless to say I would not know about changes in Maple's kernel, but why not (as long as it is backward compatible)? I have run fairly sizeable worksheets developed with Maple 15...17 against Maple 18 and run into very few issues, mostly connected with plotting and/or packages (like Physics, which is just a newer version in 18).


@Carl Love This did the trick! I am slightly puzzled as I thought I tried double uneval quotes before; but maybe I enclosed the argument...

Be that as it may, thanks a lot to you & acer for your help.

FWIW, this appears to work in Maple 15 as well (I am moving back & forth between 15 and 17 depending on the machine I happen to use).

Mac Dude


@acer So here is my problem a little more in context:

I am loading a package "Lattice". In this package I have a ModuleLoad proc that amongst others adds a few types specific to the use of this package:


Note that the addition of ExpandedLine is commented out since it does not work.

If I now try to add ExpandedLine in a regular worksheet that uses Lattice; I get this:

restart;with(Lattice); # output not reproduced here
TypeTools:-AddType(ExpandedLine,'Vector(Element)'); # no output generated
Error, (in Vector) dimension parameter is required for this form of initializer

So something is interfering here. It seems that Vector is being evaluated despite the quotes. I get the same problem when I activate the AddType stmt. in ModuleLoad. Note that the type Element works as intended; and I also do not see any problem per se with Vector, which is used in the package in different routines.

Maple 17.02 (64 bit) on Mac OS X 10.6.8.

Any insight?


First 20 21 22 23 24 25 26 Last Page 22 of 42