@mbras On the help page for sum there is a clear Note about using add instead of sum for adding up up a finite number of terms.

On the help page for topic sum,details there is more mention of this, and a discussion in the later part of the Examples, titled "Comparing sum and add". That explains quite a bit of the differences, and what's going on.

Reading the help pages for a command with which you're having difficulty is often a good place to start.

@exality The inability to protect to the name sqrt happens regardless of whether Units:-Standard is loaded or not, ie. regardless of whether the name is bound to the package export name Units:-Standard:-sqrt or to the global :-sqrt .

Both of those are protected names, which is Maple's way of ensuring that you don't clobber the system names.

But as you now know, you can just apply sqrt~(...) and don't need to first make any assignment to the name.

In my 2nd usage example I used a custom, anonymous operator only because it let me utilize the pretty 2D radical symbol.

@rlopez 

The problem occurs because Component action code picks up current name bindings when executing. The key item here is that when `=` is rebound to Units:-Standard:-`=` then DocumentTools:-Do does not interpret a first argument like %Plot0=P as intended.

IMO the DocumentTools:-Do command is ill-designed, and people should always use DocumentTools:-SetProperty and DocumentTools:-SetProperty instead.

Here is a worksheet that exhibits the problem. It fails with DocumentTools:-Do when Units:-Standard is loaded, but works with DocumentTools:-SetProperty.   Do_equals.mw

I notice other problems in this and several other Task Templates. Their action code is generally not mint clean, in the sense that unprotected global names are used without proper protection against evaluation or misidentification as locals.

For example, color=red instead of 'color'=':-red'. If the global name red gets assigned a value then the code no longer works.  (Most plotting command optional keyword values can be supplied as strings, so 'color'="red" also works.)

Another misuse of global names is in referenced commands in the form Student[Precalculus][Distance] , which also suffers because that involves unprotected references to names (as if global, but not denoted as global). If the user assigns a value to the unprotected global name Precalculus then the code no longer works. More robust would be either Student[':-Precalculus'][':-Distance'] or Student:-Precalculus:-Distance . See the help page for topic colondash for more.

In the Bezier curve Task Template I see about a dozen instances of these issues.

As I mentioned, you haven't uploaded a Worksheet or Document that contains code to reproduce the problem, ie. code that constructs such a Matrix as well as the way the command is being called. Without that the best we can do is guess at the cause.

You can attach a worksheet to a response here using the green up-arrow in the Mapleprimes editor.

@vv It seems to be an undocumented kernel thing, only working for symbols (which it does not evaluate).

restart;
kernelopts(version);
        Maple 2017.3, X86 64 LINUX, Sep 27 2017, Build ID 1265877

T:=table([eleventeen=P]):
eleventeen:=37:

T['eleventeen'];
                              P

T[eleventeen];
                            T[37]

T:-eleventeen;
                              P

@MDD Try replacing simplex:-minimize by simplex[minimize] .

Adjustment to spacing (though not really more robust or general purpose...)

Download typeset_math_text_2.mw

Perhaps the problem is not so much that `eliminate/recursive` is allowed to call itself with the empty set {} as its first argument, but that in such a case it returns {} rather than a set of trivial identities/equalities involving the passed elimination variable(s).

For example, the following returns {} the empty list, whereas perhaps it could more usefully return something like {[{x[4] = x[4]}, {}]} . Or something like that.

`eliminate/recursive`({}, {x[4], x[5], x[6], x[7], x[5]*x[6]*x[7]+2*x[7]+1}, {x[4]});

I will test out this idea. It might involve just a couple of changes in lines 18-34 of `eliminate/recursive`. If things look good after testing I might even be able to post a FromInert/ToInert hotfix here as a comment...

showstat(`eliminate/recursive`,18..34);

@vv In Maple 13.01 and earlier I receive NULL for that.

The cause of this seems unrelated to the above bug in eliminate (but I could be wrong). It seems to be related to how solve (and/or SolveTools) is handling (or accidentally not carrying along) the restrictions it figures out.

We could probably write you a Maple procedure which could:
1) Take as argument the filename of your worksheet.
2) Rip it apart and put it back together using XMLTools, etc, such that all "top-level" Tables are sorted accordind to the first text string appearing in the first cell.
3) Write the result out to a new, supplied filename, or open in a new GUI tab.

Optionally, it'd probably be not much more difficult to have the new .mw file contain a Table of Contents with hyperlinks to the individual Tables.  (I've previously done this kind of thing for Sections in a Worksheet).

Is that the kind of thing that'd be useful to you?

I don't know how the GUI's print-export mechanism works, sorry. 

But suppose that you absolutely cannot get the ease of use you want from the combination of mouse-selection and the GUI's print-export, for printing the Tables individually. In that case it should still be possible to augment the sorted, new .mw file to also contain a ComboBox Component, such that selection of any Table's preamble string in that ComboBox would open only the named Table in a new GUI tab, which you could then print-export stand-alone.

@minhhieuh2003 It is a bug the the RealRange constructor always turns Open(infinity) into just infinity, which has the effect that you cannot easily pretty-print the open semi-infinite real-range.

I can think of a few workarounds to allow you to get what you want displayed. Some of them would be over-complicated for a new user, I think. And some would affect printing of all semi-infinite real-ranges. So for now I'll make the following suggestion, whose drawback is just that the displayed object is transient -- ie. it is for a single display only, and any subsequent evaluation of it would revert to the closed interval display.

Download RealRange_openinf.mw

@tomleslie Thanks, corrected now.

@mmcdara You might take a look at the Programming Manual (available either within your Maple's Help system or online).

The structures appearing in the output of the dismantle command have some description there, eg. see Appendix 1.

You might also have a look at section 7.4 of the Programming Manual (not directly viewable online, it seems), and its first subsection on the evalf command (which relates to some of the points I made above).

I could probably add these comments:
- Beware of remembered results (due to memoization) when doing comparisons in loops since you might need to call forget(evalf) and/or similar before each tested computation.
- Be aware that internal use of guard digits can sometimes make compound floatting-point computations attain a better accuracy than guaranteed.
- You could also compare with approaches like use of interval-arithmetic for compound float computations. See evalr and shake. Using those to attain targeted float accuracy needs some extra effort, though.

@mmcdara You are mistaken in your interpretation of the scope of the I SEE 754 spec as far as I can see here. The rule cited is about single operations, and your example is a compound operation.

Using sqrt(2.0)*sqrt(3.0) need not give the same accuracy as, say, sqrt(6.0) which you wrote without justification.

Maple strives for less than 0.6 ulp error for atomic (ie. non-compound) arithmetic and elementary floating-point computations. But once you compound the operations then any errors from the inner operations (which need not be infinite-precision-accurate) can propagate.

@minhhieuh2003 

If you want RealRange typeset as I had it then you'll need to have the typesetting level set to extended.

In Maple 2017 that is set by default. You did not tell us which Maple version you're using. In older versions you could issue a command to set that.

For example, using Maple 2016,

Download RealRange_M2016.mw

I see that you've since edited your followup Comment to indicate that you're using Maple 2015. Well, setting the typesetting level works in Maple 2015 too.

RealRange_M2015.mw