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

@sideshow My advice:

1) Stop using round brackets to refer to the entries of the Matrices A[k]. Especially do NOT use them on the left hand side of assignment statements. Use square brackets. I replaced them all.

2) Your main (outer loop) has a bit at the end where it assigns into A[k+1]. But you forgot to make A[k+1] a Matrix before that happens. So you were just creating A[k+1] as a table, implicitly. I added a line to create A[k+1] as a Matrix (zeroed by default) in a place that seemed suitable.

3) You are relying on implicit multiplication, and it seemed to me that there was a muddle here and there, with either missing spaces or confusion with dot (for dot product). I suggest that you stop using 2D Input and switch over to 1D Maple Notation. See the preferences for the GUI, ie. using the menubar Tools->Options->Display and then change the first drop menu "Input display" from being your current "2-D Math Notation" to being "Maple Notation". Doing so will give you plaintext code mode in which you use * and . explicitly (and space is not allowed for multiplication).

4) I see a problem with the line on which you assign to u[j], where `u` is a Vector. You have it as,

     1/sqrt((1/2)*RSQ * A[k] * w[j]

but later on you treat u[j] as if it were a scalar when assigning to entries of Matrix A[k+1]. I believe that you need to fix that line of code, and suspect that you need to make u[j] a scalar. As you had thing it seems that the entries of `u` were becoming Matrices rather than scalar, and that this cascaded into the entries of Vector `z` and Matrix A[k+1]. If I have misunderstood your purpose then you'll likely have to explain your goal better if you want help with this aspect.

5) It was difficult to find the offending piece of 2D Input that gave you original parsing error. I suspect it was the line

     q := q + A[k][j, k]^2

but I'm not 100% sure because of the round-bracket and other issues. I believe you'd find that with 1D Maple Notation input mode the GUI would also (generally) do better with pointing you to the location of syntax errors.

Matexample_modif.mw

@sideshow Why are you still using round brackets to reference entries of A[k] ? Didn't you read or understand my earlier answer?

Why are you STILL trying to represent 2D Input by pasting here as text?

Why aren't you uploading a worksheet with your full code, or pasting here from valid input as text?

Have you tried using a Worksheet with 1D Maple Notation, since you're having trouble with 2D Input?

@gkokovidis 2D Input strikes again.

@terryma

1) Try to compute your (6) with,

int( simplify(f), s ) assuming real;

or,

simplify( int( simplify(f), s ) ) assuming real.

2) I don't understand what you are trying to say about your expression (5). Where did the x go?

@terryma If your followup comment you are wrong, in at least two cases.

The first case is that the exponent 0.5 is not the same as the exponent 1/2. Maple is capable of both floating-point and exact calculations. You're confusing the two.

((1/7)^2)^(0.5) <> 1/7;

                                       1
                       0.1428571429 <> -
                                       7

The above example makes the earlier results I showed from `is` and `simplify` seem suspect and overzealous. That's why I included the exact exponent 1/2 in my original response. Compare also with,

(x^0.5)^2;

                               1.0
                              x   

simplify(%);

                              1. x

which falls down on say,

sqrt(2)^(1.0);

                          1.414213562

1.0*sqrt(2);

                                (1/2)
                           1.0 2     

And what's a good rule without exceptions to exceptions to the rule?

exp(1)^(1.0);

                                  1.0
                          (exp(1))   

A second case now is that in your followup explanation you left out the earlier qualifier that x is positive (or even nonnegative). But I believe you are already aware of this, from before.

((-2.0)^2)^(0.5) <> -2.0;

                      2.000000000 <> -2.0

You should be very cautious about using a float exponent if you don't have to. So that's one thing for you to take away: power 0.5 is different from power 1/2.

Another thing to keep in mind is that it is the command `sqrt` which computes. You can call the `simplify` command on x^(1/2) , but otherwise raising to 1/2 will not do much of anything. Compare these results:

sqrt( x^2 ) assuming x>0;

                               x

( x^2 )^(1/2) assuming x>0;

                               (1/2)
                           / 2\     
                           \x /     

simplify( ( x^2 )^(1/2) ) assuming x>0;

                               x