@perr7 I am looking at trying to improve your example. It is slow because I am very busy right now with other things, sorry.

@Axel Vogt Thank's Axel.

I should be more polite and tell the questioner this:

.tar.gz is a Unix/Linux/OSX thing. It means that the file or files were bundled together with the `tar` untility and then compressed with the `gzip` utility (well, `tar` can do both nowadays).

It just means that the files were bundled and compressed, producing something similar to a .zip archive.

It's not a Maple thing. It's just an general operating system question. You just need a utility for Windows that understands .tar.gz compressed archives. There are several such things on the internet, most of which can handle .tar.gz as well as zip archives, etc. Axel has named one. Another is Winzip. Some are free.

@Carl Love I suspect what he wants (in 2D Math parlance), is more like (1)=~0 where (1) is probably an equation label reference.

Of course he could also assign it to some name, first...

@Markiyan Hirnyk How does your example "p:=(x-1)*(x-2), q:=(x-2)*(x-3), and r:= (x-1)*(x-3)" relate to what was given by you originally?

The text in your post is garbled. (Did you try to paste it in from 2D Input or something?)

Also, what do you mean by xe, x2, and y2?

Anyway, this works for me in Maple 2015,

plots:-densityplot(x*exp(1)-x^2-y^2,x=-2..2,y=-2..2,
                   colorscheme=["Blue","Green","Orange"],style=surface);

acer

@perr7 Thanks. Knowing the version number helps. Not sure of your OS, but in any case even without Classic availability we can likely get a command line script that exports the gif or frames more efficiently. The speed of the frame (all the plots) can likely be made better still.

The sign vs signum thing I mentioned gets an expected improvement. Thete can be several such bottlenecks or things to tweak in order to attain closer to optimal performance. But as mentioned, it is the holiday season for some, so you may have to wait for me to chip in fully.

@perr7 I'll try to find time to speed it up and post.

Which version of Maple are you using? Depending on the version it may be the using operator form for the plot3d calls' first arguments, and utilizing a wrapping call to evalhf with that, might speed up the generation of the surface plots.

Do you really feel that grid=[150,150] gives that much better look? That's about ten times as expensive to generate and to store.

In several places you used the uneval-quoted 'sign(-x)' and you might try the unquoted signum(-x) instead.

The data structures produced by `spacecurve` and `transform` are less efficient listlist rather than float[8] rtable. It is just possible that intermediary conversion (correction) in this regard might alleviate some of the strain on the GUI.

If we can speed up the generation enough then you might want to save without output, after restart, so as to get a very small source file that reopens quickly.

More later -- but it's the holiday season for me...

@Preben Alsholm I do not advocate that workaround Edgardo  gave to that kernel bug you mention. My suggestion continues to be that best is to await a proper kernel fix that is run through all quality assurance tests. I do admire the ingenuity of Edgardo's idea, though, and have noted that the later revision you quote is nicer than an earlier one. [We should give a url link here I think...]

@tazatel Your f is not (yet) an operator.

Try it as 

f :=unapply( NonlinearFit(....) , x );

In Maple 2015 see the menu item View->Group and Block Management->Expand Document Block, as one way to edit the input that is currently hidden.

You may have to select the portion of the worksheet that contained the offending Document Block (see its output, or toggle on D.B. markers) or do that for the whole Document. You can undo this later.

The idea is this. A Document Block is comprised of two Execution Groups. Normally the first has its output hidden, and the second has its input hidden. The hidden aspects  are properties of execution groups that one cannot normally alter separately from within the GUI (unless they are in a Table, which provides the property of having all input within it be hidden). This pair of Execution Groups act together -- the second displays the output of the first. When expanded one of them will show a "print redirected" bit.

When you "expand" the Document Block you reveal both, with the input beside a red cursor prompt. You can edit the input of the first one, and then collapse the whole thing once more.

It's hard to say more without the Document in question, which you have not uploaded here at this time.

acer

@nm It's not a button. It's  a code edit region. Right click and select the item to execute its code in the menu that pops up.

I suggest that you provide a clear example of what you want to do.

acer

@John Dolese One of the fastest and easiest ways to get an integer from a float is to use the `trunc` command. It is a built-in kernel function and very fast. If you don't like the way it rounds (for a mix of negative and positive values, say) then you can use `floor` or `ceil`. These are not mysterious, or rare.

Using the MTM package is relatively rare, on the other hand. It may have been designed for Matlab runtime interaction or emulation, but it is not especially fast. Several of the functions include a thin but not inexpensive layer of Library side interpretative code, with the main "benefit" being to emulate a particular coding style. The MTM package is not close to the top of my list of places to look when I want an efficient floating-point code solution.

The computations you've been doing with colorspaces are naturally purely floating-point. That is not, historically, typical Maple usage. Maple started out as a computer algebra system (CAS), and its abilities to do high performance floating-point computations came considerably later in its long history. I've lost track of the number of times I've read people write things with the sentiment: Why isn't this general purpose thing geared primarily for MY kind of task?

If you want to do intensive floating-point computations in Maple in a fast and efficient way then make use of the several mechanisms available for doing so. I've suggested doing so to you in other places. Perhaps read this or this to see how much improvement is possible.

I mentioned evalhf and datatype=float[8] to you once before and you replied that (after an apparently over-simple direct attempt at drop-in use of one of those) it did not improve your code's performance. I was not kidding when I wrote earlier than I suspect the kinds of computations that is now taking your code minutes if not hours could likely be done in seconds in modern Maple. But you'd need to refactor the code; there isn't a silver bullet for every coding style. Start off with float[8] data structures, procedures which are vectorized (same operation, applied across entries), inplace operations, etc. Then when the style is naturally efficient you'd be in a better place to run it under specialized acceleration methods.

Regarding you other question, and again using Maple 13.01,

restart;

# Since we know this...
simplify( convert( (exp(2*a)-1)/(exp(2*a)+1) - tanh(a), exp) );

                                      0

# We can construct a rule like this...
tanhrule := (exp(2*a::anything)-1)/(exp(2*a::anything)+1) = tanh(a):

expr := V0*(exp(2*t/T)-1)/(exp(2*t/T)+1):

applyrule( tanhrule, expr );

                                     /t\   
                                 tanh|-| V0
                                     \T/   

@upslol Why not split the original (by comma, say) and then deal with each separately? Building up `others` by iterated concatenation seems unnecessarily costly (and problematic). Perhaps build three tables of the separate results, and then convert to list or concatenate each of the three (just once) only when finished processing.