acer

32490 Reputation

29 Badges

20 years, 7 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

I considered that he was thinking of context-sensitive menus, where unfortunately the capitalization does not match that of the actual commands, and where the appearance of individual choices comes and goes depending on the "selection".

I've see it happen before, that somene thinks that clickable Maple is the primary form of using Maple. (...although, maybe that's not what's happened here. Package exports are another possibility.)

acer

You can add your own context menu item for 3D numeric Arrays.

acer

You can add your own context menu item for 3D numeric Arrays.

acer

Have you read the ?evalf,Sum help-page?

acer

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

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
The explanation is pretty much the same, as hopefully the last line shows.

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

First 468 469 470 471 472 473 474 Last Page 470 of 594