I was looking at the parent-reply which read, in its entirely,

"As sin(x*y)=1 excludes x=0 for y finite, x*sin(x*y)=x and sin(x*y)=1 are equivalent assuming y finite."

And that does not include the assumption that x<>0. I see now that you added that correction later. Thanks for making it explicit.

I was looking at the parent-reply which read, in its entirely,

"As sin(x*y)=1 excludes x=0 for y finite, x*sin(x*y)=x and sin(x*y)=1 are equivalent assuming y finite."

And that does not include the assumption that x<>0. I see now that you added that correction later. Thanks for making it explicit.

No, they are not equivalent in the usual "if and only if" sense of the term "equivalent". There is logical implication here in only one direction, given that y is finite.

(y finite and sin(x*y)=1) implies (x<>0 and x*sin(x*y)=x).

But {x*sin(x*y)=x and y finite} does not imply x<>0, and so sin(x*y)=1 does not follow.

No, they are not equivalent in the usual "if and only if" sense of the term "equivalent". There is logical implication here in only one direction, given that y is finite.

(y finite and sin(x*y)=1) implies (x<>0 and x*sin(x*y)=x).

But {x*sin(x*y)=x and y finite} does not imply x<>0, and so sin(x*y)=1 does not follow.

This type of investigation would be much more useful if there was mention of which Maple interface and which entry mode was being tested.

If the entry mode being tested were "2D Math" input mode, then this might constitute further evidence to the need for Typesetting to be moved from the interpreted Maple Library into a compiled component such as the kernel or GUI itself. There is much similar evidence readily available from other easy experiments involving programming in a Document with 2D Math. (This is one -- but by no means the only --  point in the argument against writing programs and procedures in 2D Math mode.)

The so-called "character typing test" discussed in other recent mapleprimes threads could also be defined much more rigorously if the typing rate were quantified. Couldn`t you set the keyboard input rate, and then hold down a single key until the multiple-character action was triggered. Then everyone could be on the same page, and report results that might be compared properly.

There is no evidence that Maplesoft developers have not been aware of the importance of sophisticated coding techniques (program analysis, DSLs, and lots more) for a long time. The fact that such things do not appear in the product, or get described in detail in public, probably has much more to do with the fact that Maplesoft is a corporation.

As you yourself have pointed out before on this very forum, there is a natural difference in outlook between developers and management (a "dynamic tension" or similar I believe you called it, between wanting to do things "right" and wanting to make money or adhere to resource restrictions). Referring here to "Maplesoft" in a personified way as if it were all of a single mind, given your earlier statements, seems like a bit of a cheap shot (especially in the blog of a developer).

The e notation has a strange status in maple. The interface's parser may recognize it, but it does not act like most other infix operators.

The behaviour of the `e` used for e notation is not programmatic. By which I mean that it doesn't appear possible to use it symbolically or programmatically unless it parses immediately to a literal float. It appears that it can only be used as a literal input. It doesn't depend on any value assigned to the global e symbol. It must be preceded and followed by a literal integer or nothing.

Since the (1D) parser will not recognize e notation as valid if not preceded and followed by literal integers (or sometimes, nothing), then in such cases it does not survive parsing and so doesn't become anything that the interpreter would subsequently have to handle.

It does not appear to be listed on the ?operators,precedence page. (Is it's binding strength greater than that of even || and ::) It does not appear to be listed on the ?syntax page.

It is described on the ?float page, but not very thoroughly. There, you can see that the Float() constructor may be used programattically, as an alternative.

I haven't looked to see whether it always behaves identically w.r.t to the 2D Math and the 1D Maple notation parsers.

The term "software floating-point" is often used to distinguish between hardware floating-point numbers (such as the result of the HFloat constructor or the data in a datatype=float[8] Matrix) and the arbitrary precision floating-point numbers that Maple uses as first class objects.

I agree. It would be better if it also worked directly for Nx2 Arrays.

I really do not like the "details" help pages. What a poor idea, to split up very commonly used help pages, so that the more interesting bits are buried in another side page. Too many people may miss the underemphasized links to the details pages. And it's not merely advanced usage which is buried on the details pages, but often is quite useful alternative calling sequences.

It would be so much better if all the information for a given command were on a single help page which was written and organized/blocked well. If done well enough, the extra information need not be overwhelming, and the difficulties for new users would be much less than with the current knowledge-split. (For Online Help it should be even easier to set up, with the "details" appeaing in an initially collapsed section, which is what Wolfram does.)

I agree. It would be better if it also worked directly for Nx2 Arrays.

I really do not like the "details" help pages. What a poor idea, to split up very commonly used help pages, so that the more interesting bits are buried in another side page. Too many people may miss the underemphasized links to the details pages. And it's not merely advanced usage which is buried on the details pages, but often is quite useful alternative calling sequences.

It would be so much better if all the information for a given command were on a single help page which was written and organized/blocked well. If done well enough, the extra information need not be overwhelming, and the difficulties for new users would be much less than with the current knowledge-split. (For Online Help it should be even easier to set up, with the "details" appeaing in an initially collapsed section, which is what Wolfram does.)

Just a minor point. As the ?plot,details page shows in its extended calling-sequence, you can pass an Nx2 numeric Matrix straight to `plot`.

So in this case, if `pts` were a Matrix instead of an Array, then plot(pts) would work directly without having to split pts by columns.

Just a minor point. As the ?plot,details page shows in its extended calling-sequence, you can pass an Nx2 numeric Matrix straight to `plot`.

So in this case, if `pts` were a Matrix instead of an Array, then plot(pts) would work directly without having to split pts by columns.

Interestingly, this efficieny suggestion has come up about 3-4 times in the last few months.

Clearly it is better to have such a list be as small as possible a collection of covering supertypes (which validly fit the restriction at hand). Otherwise the list would be unnecessarily and redundantly cluttered with subtypes.

The help page for `map` would more accurately start off by stating the it will "apply a procedure to each operand or element of a non-atomic expression".

But since that is too verbose, it could instead state that it will map an action across an expression. It's better to use terms that can be subsequently defined than to inaccurately simplify the statement using only a proper subset of the correct techinical terms.

It is also inaccurate in that it specifies that it maps a "procedure". But in fact it can apply more types than that. Can it apply anythinf of type appliable [sic]?

Here's another fun example: an SDMPolynom object. It is not of type atomic. And `map` can do something somewhat reasonable to it. But it does not apply the action to each and every operand.

> restart:
> a := SDMPolynom(x^3+5*x^2+11*x*y-6*y+15, [x,y]):
> type(a,atomic);
                                     false
 
> a;
                           3      2
               SDMPolynom(x  + 5 x  + 11 x y - 6 y + 15, [x, y])
 
> b:=map(t->t^2,a); # OK
                           3       2
          b := SDMPolynom(x  + 25 x  + 121 x y + 36 y + 225, [x, y])
 
> op(a);
                1, 3, 0, 5, 2, 0, 11, 1, 1, -6, 0, 1, 15, 0, 0
 
> op(b);
               1, 3, 0, 25, 2, 0, 121, 1, 1, 36, 0, 1, 225, 0, 0

The only way that can make sense, with the current statements in ?map, is if the "elements" of an SDMPolynom structure are the coefficients of its represented polynomial. Which would be a real stretch.

Similarly, `map` acts on the coefficients (only) of the terms of a series (SERIES DAG), which are not its operands. And I doubt many people would call those coefficients the elements of the series either, as they are not even the terms.

By the way, I see no problem with `fraction` being left of of the list on ?type,atomic since 3/5 is indeed of type complex(extended_numeric).

Hi Patrick, I have one minor suggestion.

Could the getarrows procedure save the incoming warnlevel to a local, then restore it following execution? (Sometimes people put the following computational part inside a try..catch, so the the restoration of environment can be done reliably in a `finally` clause of the try..catch.)