I agree wholeheartedly, Joe, that information such as this should be in the help system. But it's lacking.

I'd like to see new help-pages showing usage of the various types of procedure parameters. But it should not be the existing ?parameter_classes page, which like many help-pages reads as drily as a unix man-page. Those existing set of pages describing procedures are also much more about writing than actually using procedures.

There is the ?colondash help-page, but I can hardly bear to look at it, since it absurdly tries to explain away using indexed package[member] syntax when package:-member is so obviously more often superior.

I'd like to see a whole set of different new help-pages, for each class of parameter. And then each parameter in the calling sequence of each routine's help-page could itself be a link directly to the relevant usage page.

acer

I agree wholeheartedly, Joe, that information such as this should be in the help system. But it's lacking.

I'd like to see new help-pages showing usage of the various types of procedure parameters. But it should not be the existing ?parameter_classes page, which like many help-pages reads as drily as a unix man-page. Those existing set of pages describing procedures are also much more about writing than actually using procedures.

There is the ?colondash help-page, but I can hardly bear to look at it, since it absurdly tries to explain away using indexed package[member] syntax when package:-member is so obviously more often superior.

I'd like to see a whole set of different new help-pages, for each class of parameter. And then each parameter in the calling sequence of each routine's help-page could itself be a link directly to the relevant usage page.

acer

Look at the help-page for the DiscreteTransforms package ( ?DiscreteTransforms ) in your Maple 11.

I find it unhelpful that the Online Help pages do not mention the version in which the command or package was introduced (as do the individual online help pages of some other major comercial math products.) It is far more difficult than it ought to be to discover that DiscreteTransforms was introduced in Maple 9. See here.

acer

Look at the help-page for the DiscreteTransforms package ( ?DiscreteTransforms ) in your Maple 11.

I find it unhelpful that the Online Help pages do not mention the version in which the command or package was introduced (as do the individual online help pages of some other major comercial math products.) It is far more difficult than it ought to be to discover that DiscreteTransforms was introduced in Maple 9. See here.

acer

You don't have it quite right. Yes, the Mathworks' own symbolic toolbox now uses MuPAD as the engine. But Maplesoft's current Maple Toolbox for Matlab (MTM) is a drop-in replacement, and one can configure Matlab to use either as the symbolic engine.

I don't have proof, but I'd be surprised if the form & strength of the symbolic toolbox in Matlab did not change when the underlying default engine was switched. I'd be surprised if some users' worksheets didn't start producing new and slightly different results (which might be a problem...). Using the MTM as the symbolic engine might mitigate such differences (but I have no examples).

See here for more info, which mentions that MTM is being offered free for owners of current Maple.

acer

As fascinating as the topic of rationale for personal choice of Maple interface is, perhaps it could be started in a new blog or forum topic? I feel confident that other people might have things to add on that. But it doesn't really pertain to 1D vs 2D parsing.

cheers,
acer

Please keep in mind that one can set preferences in Standard so that all File->New sheets are opened as Worksheets instead of Documents, and with the input mode set to 1D Maple notation instead of 2D math.

So, the issue of Standard vs Classic is not really the same as the issue of 2D vs 1D input modes.

acer

Thanks, so it seem like the differences are either bugs, or implicit multiplication, or the following singleton,

restart:
# works differently in 1D and 2D
m!=n;

  "This is, as you observed, by design. When you enter != or
   paste it, it immediately turns into <>, so at least users
   are not misled into thinking it has a different meaning." (pchin)

Even better than turning this into m <> n would be to leave it as m! = n which was already a meaningful mathematical syntax in Maple for many releases. It's wrong to change it, on several different levels.

• It already meant something well understood mathematically, for many Maple releases.
• It's rather gratuitous clobbering of Maple 1D syntax with some non-universally understood (C...) syntax.
• It creates a difference between the parsers, which should be avoided unless it brings a really significant functionality improvement (which this does not). See Jacque's characterization in the link.
• It will incorrectly rewrite any piece of Maple code containing it, that anyone finds on the web or in course notes and pastes into Standard with its default 2D Math mode.

acer

Thanks. It might be interesting to see what makes the int@diff method fall down, compared to the double limit method in the OP's Mma code fragment (...taken from Mma's `Re` help-page).

acer

Thanks. It might be interesting to see what makes the int@diff method fall down, compared to the double limit method in the OP's Mma code fragment (...taken from Mma's `Re` help-page).

acer

I can explain a little more what I mean when I state that the following is a bug.

# valid in 2D but not in 1D
2.sin(x);

In 1D Maple notation, the decimal point has a greater precedence in parsing than does the infix `.` multiplication operator. So the above example is actually implicit multiplication by 2. the floating-point value. So, really, this is just another implicit multiplication example.

The system has anomalies. Precedence is not merely an operator issue (see ?operators,precedence ), but is also a parsing issue. Where can one see it documented that the decimal point has a "greater parsing precedence" than does infix `.`, but less than infix `..`?

# In either entry mode, this gives a range
2..sin(x);

At the very least, this is a missing documentation bug (much like this ). Why doesn't ?syntax mention 2D Math's implicit multiplication, or link to a 2D Math syntax page?

While I'm at it, the ?syntax help-page describes the ambiguity of a^b^c and the need for brackets, in 1D Maple notation where it makes sense. But the ?operators,precedence help-page has the same explanation in 2D Math notation, where it doesn't make any sense.

acer

Thanks, Axel.

There are quite a few different floating-point computational modes in Maple now. It would be interesting to test more than just Maple's "usual" interpreter.

There is the usual interpreter, the evalhf interpreter, the runtime provided by Compiler:-Compile, and the usual interpreter running inside a proc with `option hfloat`. Then there are modes, such as whether UseHardwareFloats=true/false, whether one uses usual floats (SFloats) or HFloats. And some of those situations can be mixed together. What else have I missed?

I'm deliberately not mentioning Maple's rounding modes. There are paranoia tests for rounding specifically, and obviously these would give different results for non-default Maple rounding mode. I'd probably only look at the default Maple rounding mode (at least, at first).

acer

Thanks, Axel.

There are quite a few different floating-point computational modes in Maple now. It would be interesting to test more than just Maple's "usual" interpreter.

There is the usual interpreter, the evalhf interpreter, the runtime provided by Compiler:-Compile, and the usual interpreter running inside a proc with `option hfloat`. Then there are modes, such as whether UseHardwareFloats=true/false, whether one uses usual floats (SFloats) or HFloats. And some of those situations can be mixed together. What else have I missed?

I'm deliberately not mentioning Maple's rounding modes. There are paranoia tests for rounding specifically, and obviously these would give different results for non-default Maple rounding mode. I'd probably only look at the default Maple rounding mode (at least, at first).

acer

The recursive version calls itself. Your original version (or Joe's amended version) does not call itself. That's the difference. One of them recurses on itself, and the others do not.

acer

The recursive version calls itself. Your original version (or Joe's amended version) does not call itself. That's the difference. One of them recurses on itself, and the others do not.

acer