But one does not "need to use" ~ to get the elementwise effect, on either a set or an old-style locarcase array. One can also use map, which was available prior to Maple 13 (and would have been a usual way, for dealing with the set).

For a lowercase array (when it was not deprecated) the evalm command would have been a popular way to distribute scalar multiplication (along with effecting other arithmetic at the same time). And that still works, as does using ~ or map. But of course, as mentioned, with an newstyle Array or Matrix it happens automatically.

acer

But one does not "need to use" ~ to get the elementwise effect, on either a set or an old-style locarcase array. One can also use map, which was available prior to Maple 13 (and would have been a usual way, for dealing with the set).

For a lowercase array (when it was not deprecated) the evalm command would have been a popular way to distribute scalar multiplication (along with effecting other arithmetic at the same time). And that still works, as does using ~ or map. But of course, as mentioned, with an newstyle Array or Matrix it happens automatically.

acer

A simple race between methods is a coarse (high level) and quite obvious  form of parallelization. There are several places in Maple that ideally could benefit from such an approach. By itself, it makes use only of as many threads as there are competing methods, which is why it becomes less attractive when the number of available threads/cores gets very high. A long term goal of parallelization should also include finer (low level) parallelization so as to try and use many more threads/cores.

Of course, a sophisticated parallelization model (eg, "Task", or other) might eventually be able to handle proper, automated resource distribution at both coarse and fine levels.

The bigger, immediate problems are that high level parallelization requires the Library components used by the competing methods to be entirely thread safe, and to have access to a garbage collection mechanism that is efficient under multithreading. It's easy to show that the garbage collection mechanism isn't yet ready for that. Also, high level, competing methods are usually high level in terms of the Maple Library, and so much, much more likely to run amok of the current great degree of Library thread nonsafeness.

Here's another, simpler example: ifactor. It's methods could also be put into a race. And (possibly with much less rewriting than for int or dsolve) those methods might be more easily rendered thread safe with respect to each other. But even here it might be tough to make the methods thread safe with respect to themselves. (eg. `ifactor/QuadraticSieve` which is a module using locals which may get treated "thread-globally" for storing state).

Let me put it another way. For the competing methods of int or dsolve to be put into a parallelized race they must all be made thread safe. And in turn every single other routine they each use must also be made thread safe. And so on, in a causal tree. Since the competing methods are so high level (in the Library sense) they make eventual use of large amounts of the Library. So the overall degree of Library thread unsafeness is a huge barrier here.

acer

Every instance of a() will produce a new call to the random generating proc that you assigned to `a`. So the instance of a() in the while-condition is not the same as the instance in the print. The generator gets called separately for those.

I've seen similar questions asked about this sort of thing:

> a:=rand(1..10):

> evalb(a()=a());
                                     false
 
> is(a()=a());
                                     false
 
> a()=a();
                                     4 = 6

acer

It's not really strange at all. `while` is part of the to-from-while-do-for statement group, and so ?while gets to that "Repetition Statement" help-page.

acer

It's not really strange at all. `while` is part of the to-from-while-do-for statement group, and so ?while gets to that "Repetition Statement" help-page.

acer

The search facility of MaplePrimes is broken. A simple query for the word rocket does not currently find this.

I usually do like Patrick suggests, and use google.

acer

You could assign them to something (as table entries, or whatever), then wait until the loop is finished, and then use the seq command.

Or if you wanted the results displayed as they get computed and in a single row then you could use printf (and omit the \n for newline after each entry, then printf a single newline when the loop finishes.)

acer

You could assign them to something (as table entries, or whatever), then wait until the loop is finished, and then use the seq command.

Or if you wanted the results displayed as they get computed and in a single row then you could use printf (and omit the \n for newline after each entry, then printf a single newline when the loop finishes.)

acer

It wasn't clear whether Alex meant that the floats would be of the form xxx.000... or not.

But if he did in fact mean that they are merely the floating-point representation of some integers then conversion of very many of them might be faster using the kernel builtin routine trunc than using round (or floor).

acer

It wasn't clear whether Alex meant that the floats would be of the form xxx.000... or not.

But if he did in fact mean that they are merely the floating-point representation of some integers then conversion of very many of them might be faster using the kernel builtin routine trunc than using round (or floor).

acer

It seems uninstructive to demand use of do-loops if the data is already in list or listlist form. The following may not be optimally efficient (versus using an Array initializer), but it might be more instructive.

> MyA := Array(1 .. 5):
> MyA[1]:=1:
> for i from 2 to 5 do
>   MyA[i]:=5*(i-1);
> end do:
> MyA;
                              [1, 5, 10, 15, 20]

> MyA := Array(1 .. 4, 1..4):
> for i from 1 to 4 do
>   for j from 1 to 4 do
>     MyA[i,j]:=i*3^(j-1);
>   end do:
> end do:
> MyA;
                            [1     3     9     27]
                            [                    ]
                            [2     6    18     54]
                            [                    ]
                            [3     9    27     81]
                            [                    ]
                            [4    12    36    108]

acer

It seems uninstructive to demand use of do-loops if the data is already in list or listlist form. The following may not be optimally efficient (versus using an Array initializer), but it might be more instructive.

> MyA := Array(1 .. 5):
> MyA[1]:=1:
> for i from 2 to 5 do
>   MyA[i]:=5*(i-1);
> end do:
> MyA;
                              [1, 5, 10, 15, 20]

> MyA := Array(1 .. 4, 1..4):
> for i from 1 to 4 do
>   for j from 1 to 4 do
>     MyA[i,j]:=i*3^(j-1);
>   end do:
> end do:
> MyA;
                            [1     3     9     27]
                            [                    ]
                            [2     6    18     54]
                            [                    ]
                            [3     9    27     81]
                            [                    ]
                            [4    12    36    108]

acer

To be able to save the worksheet with some stored results (rtables, plots, etc) likely entails the underlying kernel being in a safe state. And if the kernel had "gone away" while doing gc while swapped out or what have you, then that might not be possible as an immediate action.

A middle ground might be to forcibly and immediately kill the underlying kernel and to be prompted to save any worksheets (open and using that kernel instance) without their output and stored rtable or plot or other embedded data. What might be novel might be for this to be offered without having the entire application quit.

I can imagine that it gets tricky if the GUI is waiting on Typesetting before completing a partial redraw of 2D Math output. If the kernel is not safely finished doing gc or other stuff, while inside Typesetting...  And there could well be other tricky scenarios.

acer

When Maple's too tied up and busy to abort the current computation, I will usually close the whole application (corner button on Maple's main window). This usually results in being queried about saving the open worksheet. That's fine.

But, as you put it, why cannot Maple's GUI be told to forcibly kill the kernel and close that worksheet, without having to quit the entire application.

A stable GUI, that allows forced closure of worksheets individually (even when running unresponsive kernel instances), would be useful. That would allow us to keep the Standard GUI up longer. That would make Standard's launch time less important, and so alleviate a difference w.r.t Classic.

acer