Robert's already explained why the original example is a bug: simplify should only return the input -- simplified or not -- for valid input. There is nothing technically invalid about an expression containing both a name and its indexed form.

But while not wrong per se, it's not a great idea to use both an indexed name and its base name in the same expression. Even if you don't intend to assign to the base name yourself , some other routine that you use might do an equivalently unfortunate action.

Consider,

> subs(x[1]=y,x+x[1]); # ok
                                    y + x

> subs(x=y,x+x[1]); # oops, it hits both
                                  y[1] + y

There are quite a few routines which will not handle such mixed expressions well. Another example,

> convert(x[1]+x^2,sqrfree,{x,x[1]});
Error, (in content/content) invalid arguments

That last one causes this,

> fsolve({x[1]+x+1,x[1]+x^2});
Error, (in content/content) invalid arguments

Now, some routines have been made clever in this regard. They might carefully substitute in other dummy names for all indexed names, up front, and then resubstitute at the end. Or whatever. But that safety is not universal. I''ve found that dsolve, simplify, and solve are sometimes better at it.

While on this topic: these names indexed by [] are usually called "indexed names". They are of type name(indexed). They are not subscripted except in 2D Math (input and output!). Not everyone uses 2D Math output. If you do, then perhaps that's why you have refered to indexed names as subscripted names. Atomic identifiers are another form of subscripted names in 2D Math.

The big difference between indexed names as subscripted names, and atomic identifiers, is that only in the former is the subscript readily changed. This is a contentious area. For DEs, people may not need the subscript to itself be mutable, in which case an atomic identifier may be more suitable. But atomic identifiers are awkward to use.

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

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