@slowlai That specfunc(anything,min) part of that frontend invocation is there so that min() calls don't get frozen entirely (which would prevent convert/piecewise from being to see & operate on its contents). As used, that frontend invocation will freeze most else, including products such as x*lambda. The idea is to treat x*lambda as if it were a single name, by freezing it with frontend, so that convert/piecewise will function on it.

Another way could be to freeze just that subexpression x*lambda, "by hand",

expr:=min(x*lambda,0);
ice:=freeze(x*lambda);
convert(subs(x*lambda=ice,expr),piecewise,ice);
thaw(%);

@Will "We think this is the easiest and fastest way to get rich math onto the web; simply compose your post in Maple. Save the worksheet and upload it to Primes."

Except that is not easy at all. It's far too much effort, to fire up Standard, compose, save to a new file with a new name, then open (and find) and load that up into Primes, all just in order to submit a reply to a post.

The Editor's menubar's "Maple Math" button is thus the best (only!?) hope for a fast method, then, given what you say about the clipboard.

But the displayed math graphic due to using the "Maple Math" button ought then to be aesthetically acceptable, and so far members are all agreeing that what comes from using the "Maple Math" button is ugly. See Erik's post above, which shows such.

And I cannot stress how important 1D Math alt tags are for anything representing 2DMath input. Examples of code in posts which cannot be copied from Primes and inserted elsewhere (as 1D input at least) are very close to having no utility. I hope that the .mw translation you mentioned provides that throughout.

Let me try an example, using firefox 3.0.7 on Windows XP. The expression that I type into the Maple Math box is,

   BesselJ(0,x) - Theta(psi) - GAMMA(4*Xi/3)

Note the (valid and legal Maple syntax for both 1D and 2D input) spaces between subterms and minus signs. If I check the Evaluate expression box then the popup has an error message saying I have entered an invalid expression, which is a bug. So I uncheck that box. See below, to what gets produced. Of course, apart from the +-+ bug there is also the aesthetic problem that people have mentioned.

Now I'll try it without the (valid!) spaces. It's just not pretty. It does have 1D code alt tags, which is good.

That last one is an image. So the mapleprimes server could make a prettier image, yes? (Why not use a browser/font rendering solution, btw? Images seem anachronistic. How about STIX?)

@Will "We think this is the easiest and fastest way to get rich math onto the web; simply compose your post in Maple. Save the worksheet and upload it to Primes."

Except that is not easy at all. It's far too much effort, to fire up Standard, compose, save to a new file with a new name, then open (and find) and load that up into Primes, all just in order to submit a reply to a post.

The Editor's menubar's "Maple Math" button is thus the best (only!?) hope for a fast method, then, given what you say about the clipboard.

But the displayed math graphic due to using the "Maple Math" button ought then to be aesthetically acceptable, and so far members are all agreeing that what comes from using the "Maple Math" button is ugly. See Erik's post above, which shows such.

And I cannot stress how important 1D Math alt tags are for anything representing 2DMath input. Examples of code in posts which cannot be copied from Primes and inserted elsewhere (as 1D input at least) are very close to having no utility. I hope that the .mw translation you mentioned provides that throughout.

Let me try an example, using firefox 3.0.7 on Windows XP. The expression that I type into the Maple Math box is,

   BesselJ(0,x) - Theta(psi) - GAMMA(4*Xi/3)

Note the (valid and legal Maple syntax for both 1D and 2D input) spaces between subterms and minus signs. If I check the Evaluate expression box then the popup has an error message saying I have entered an invalid expression, which is a bug. So I uncheck that box. See below, to what gets produced. Of course, apart from the +-+ bug there is also the aesthetic problem that people have mentioned.

Now I'll try it without the (valid!) spaces. It's just not pretty. It does have 1D code alt tags, which is good.

That last one is an image. So the mapleprimes server could make a prettier image, yes? (Why not use a browser/font rendering solution, btw? Images seem anachronistic. How about STIX?)

@epostma "..not very useful". That's true, since it is not useful.

@epostma "..not very useful". That's true, since it is not useful.

Thanks Alec. I never noticed this old response, until I started reviewing posts to add tags. Sigh.

At the time, I figured just as you have done, that the problem is with Matrix type checks being wrongly evaluated (like Matrix constructor calls). But I don't see a reason why it can't be fixed inside CodeGeneration, as I'm not sure that fixing it would interfere with any part that's working properly at present.

The reason I want this,by the way, is that if working I'm pretty sure that I would be able to cobble together an extension to CodeGeneration[C] which "undertstood" large parts of the LinearAlgebra package for float[8] rtables, and which could emit C code with appropriate calls to the BLAS or CLAPACK equivalents. But I can't really begin properly, in light of this bug.

acer

Thanks Alec. I never noticed this old response, until I started reviewing posts to add tags. Sigh.

At the time, I figured just as you have done, that the problem is with Matrix type checks being wrongly evaluated (like Matrix constructor calls). But I don't see a reason why it can't be fixed inside CodeGeneration, as I'm not sure that fixing it would interfere with any part that's working properly at present.

The reason I want this,by the way, is that if working I'm pretty sure that I would be able to cobble together an extension to CodeGeneration[C] which "undertstood" large parts of the LinearAlgebra package for float[8] rtables, and which could emit C code with appropriate calls to the BLAS or CLAPACK equivalents. But I can't really begin properly, in light of this bug.

acer

@Alec Mihailovs Thanks, Alec!

> m - (m-n+1) + 1;
                                       n

I guess I had it producing 2 more values than it had to. Still "correct"... but wasteful.

I almost missed seeing this response, sorry. I find it hard to not miss some responses, as the Recent page doesn't have results sorted by Last Action times.

@Alec Mihailovs Thanks, Alec!

> m - (m-n+1) + 1;
                                       n

I guess I had it producing 2 more values than it had to. Still "correct"... but wasteful.

I almost missed seeing this response, sorry. I find it hard to not miss some responses, as the Recent page doesn't have results sorted by Last Action times.

Hi Joe,

datatype=anything would be acceptable, if it is unsure about whether overflow might occur, although I think that I might prefer integer[4] and damn the torpedoes. Returning a float result looks plain wrong to me.

acer

Hi Joe,

datatype=anything would be acceptable, if it is unsure about whether overflow might occur, although I think that I might prefer integer[4] and damn the torpedoes. Returning a float result looks plain wrong to me.

acer

Two degrees of freedom are at work: the cumulative score, and the number of participants voting.

The nuclearphynance site shows both of those explicitly, which is fine and good.

The current mapleprimes scoring mechanism shows both as well, although both are implicit. But that's OK. Most of us can easily add the two numbers, up--votes and down-votes, to get the number of participants, and subtract them to get the cumulative score.

Any scheme in which a cumulative single score is shown, while the number of participant is not shown or deducible, is suboptimal.

The Application Center's ranking scheme falls into that last category.

I can't tell whether or not Jacques is suggesting merging the up- and down-votes and keeping or retaining implicit display of the number of participants. I'd be surprised if he were suggesting ditching any and all implicit display of the total number of voters.

acer

Maple has all these data structures, and they each have different properties. And you are doing the right thing, by asking yourself which is appropriate for the given task. The difficulty is that the answer depends on the aspects of the task (which you've also surmised, great) but that isn't currently documented so usefully.

Arrays, Vectors, and Matrices are mutable. You can change any value within them and Maple will not create a new object. This makes them very efficient. In contrast, a list is not mutable. Unfortunately, many years ago Maple was changed to allow one to change an entry of a list, as long as the list's length was not more than 100. For longer lists, trying that produces an error message. One can still use `subsop` to change an entry of a long list but doing so creates an entirely new object, which is expensive. If the original list was assigned to X, then X got the new list assigned to it automatically. This is the sort of behind-the-scenes user-friendly inefficiency that Maple really doesn't need.

There is also a table in Maple, which is another mutable object. Tables are growable and very useful. In fact, if you don't create your container objects in advance, doing something like X[12,g]:=blah will create X as a table automagically.

Closely related to mutability is the concept which I'll call identity. I won't call it uniquification because I don't want to get confused with duplicate-removal in set objects. You might call it "simpl'ing", if you have heard that Maple kernel term before. The basic idea is that some objects should only get represented once internally. It would be inefficient if Maple stored two copies of the list [1,2,3], even if each were separately assigned to different names x and y. For such objects, evalb(x=y) reports `true` when they are compared. In contrast, one can assign x:=Vector([1,2,3]) and y:=Vector([1,2,3]) and Maple will store two distinct objects. Here, evalb(x=y) will return false, even though they have the same entries. This is deliberate. It relates highly to mutability. One can consider that, since subsequent changes to the entries of Vector x won't affect Vector y, they should certainly be reported as distinct.

You mentioned growth. In Maple, a table is growable. A list is not. Matrices, Vectors, and Arrays were not growable when introduces in Maple 6, but they are in Maple 12 and onwards using their new round-bracket notation (see rtable_indexing and Maple12's programming news).

A Maple set has much the same properties as a list, in terms of mutability, growability, and identity. But the contents of a set get uniquified (duplicates removed) and re-ordered (by some scheme Maple deems appropriate).

A list of lists is another way to get a 2D structure, another way to get an indexable collection of indexable objects. But here the outer container as well as the inner parts are all not properly mutable, or growable, without inefficient object recreation and replacement. I very much doubt that this is right for your task.

There's more that could be written, but let's consider your task. If you are willing to create the storage for all 120 time instances right at the beginning, then you could use a 3x120 Matrix or a 2D 3x120 Array or a 1D Array of 120 3-Vectors, or even a table of 120 2-Vectors. And you can use a counter or a default value to denote whether they each have yet been initialized. If you don't want to allocate the storage for them all up front, then you could use a table or a 1D Array of Vectors.

Accessing individual Vectors is easy in all these cases, even if slightly different square-bracket syntax is used. But distinct from the action of entry read/write access is the action of referencing individual Vectors to be passed as arguments to some routine (which you presumably cannot control, since it is part of Maple proper). If you have to pass just a particular Vector then extracting it from say a Matrix will create a new 1D object each time. If you call foo(M[1..3,17]) then Maple has to create M[1..3,17] as a new object. This might method not scale well in performance, or your task might be simple enough that it doesn't matter.

Are you feeling overwhelmed yet?

acer

Maple has all these data structures, and they each have different properties. And you are doing the right thing, by asking yourself which is appropriate for the given task. The difficulty is that the answer depends on the aspects of the task (which you've also surmised, great) but that isn't currently documented so usefully.

Arrays, Vectors, and Matrices are mutable. You can change any value within them and Maple will not create a new object. This makes them very efficient. In contrast, a list is not mutable. Unfortunately, many years ago Maple was changed to allow one to change an entry of a list, as long as the list's length was not more than 100. For longer lists, trying that produces an error message. One can still use `subsop` to change an entry of a long list but doing so creates an entirely new object, which is expensive. If the original list was assigned to X, then X got the new list assigned to it automatically. This is the sort of behind-the-scenes user-friendly inefficiency that Maple really doesn't need.

There is also a table in Maple, which is another mutable object. Tables are growable and very useful. In fact, if you don't create your container objects in advance, doing something like X[12,g]:=blah will create X as a table automagically.

Closely related to mutability is the concept which I'll call identity. I won't call it uniquification because I don't want to get confused with duplicate-removal in set objects. You might call it "simpl'ing", if you have heard that Maple kernel term before. The basic idea is that some objects should only get represented once internally. It would be inefficient if Maple stored two copies of the list [1,2,3], even if each were separately assigned to different names x and y. For such objects, evalb(x=y) reports `true` when they are compared. In contrast, one can assign x:=Vector([1,2,3]) and y:=Vector([1,2,3]) and Maple will store two distinct objects. Here, evalb(x=y) will return false, even though they have the same entries. This is deliberate. It relates highly to mutability. One can consider that, since subsequent changes to the entries of Vector x won't affect Vector y, they should certainly be reported as distinct.

You mentioned growth. In Maple, a table is growable. A list is not. Matrices, Vectors, and Arrays were not growable when introduces in Maple 6, but they are in Maple 12 and onwards using their new round-bracket notation (see rtable_indexing and Maple12's programming news).

A Maple set has much the same properties as a list, in terms of mutability, growability, and identity. But the contents of a set get uniquified (duplicates removed) and re-ordered (by some scheme Maple deems appropriate).

A list of lists is another way to get a 2D structure, another way to get an indexable collection of indexable objects. But here the outer container as well as the inner parts are all not properly mutable, or growable, without inefficient object recreation and replacement. I very much doubt that this is right for your task.

There's more that could be written, but let's consider your task. If you are willing to create the storage for all 120 time instances right at the beginning, then you could use a 3x120 Matrix or a 2D 3x120 Array or a 1D Array of 120 3-Vectors, or even a table of 120 2-Vectors. And you can use a counter or a default value to denote whether they each have yet been initialized. If you don't want to allocate the storage for them all up front, then you could use a table or a 1D Array of Vectors.

Accessing individual Vectors is easy in all these cases, even if slightly different square-bracket syntax is used. But distinct from the action of entry read/write access is the action of referencing individual Vectors to be passed as arguments to some routine (which you presumably cannot control, since it is part of Maple proper). If you have to pass just a particular Vector then extracting it from say a Matrix will create a new 1D object each time. If you call foo(M[1..3,17]) then Maple has to create M[1..3,17] as a new object. This might method not scale well in performance, or your task might be simple enough that it doesn't matter.

Are you feeling overwhelmed yet?

acer

I smile that Robert was clearly writing this while I composed my own message below. They appear to have much in common.

acer