@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

Vote up.

And if one wants to access the relations in that PolyhedralSet programmatically,

:-Relations(A);

     [-z <= 0, -y + z <= 0, -x + 2 y - z <= 0]

@vv 

But of course I was not saying that my formulas and approach were not parametric in that mathematical sense. In that sense, most all Maple's plotting capabilities involve some kind of parametrization. (I wouldn't bother using a term repeatedly if it made only vacuous distinctions.)

Rather, my use of the term "parametric" was in reference to the particular form of calling sequence of the plot3d command. Maple's Help documentation uses the term to make this distinction too.

The original formulas given by the OP for the sphere and ellipse were in cartesian coordinates, and one of my points is that smooth edged surfaces can be produced without re-parametrizing in another coordinate system.

There are two usual ways to get the smoothly edged surfaces that the MESH structure provides: using the plot3d's so-called parametric calling sequence, and using its variable-range syntax. You had shown the former of those, and I showed the latter.

Both of those are much faster and less memory intensive than is implicitplot3d, and the end result often smoother along edges and surface body.

Maple could benefit from some automated 3D constrained region-plotting that produced such better results. It's somewhat analogous to how plots:-inequal can sometimes get smoother results faster than can plots:-implicitplot. Under the hood several approaches and techniques might be leveraged. Mathematica has been ahead here, for some time.

@brian bovril One of my points was that the error you show occurs even if the line which compiles MinVal is removed or commented out. So I could be wrong but it seems to me that the problem might not be in the functionality of the Compiler at all, but elsewhere in the code.

The copy you had archived, do you still have it, without it being saved in Maple 2017? I'd be interested to know which version it was run successfully in (and last saved).

In older versions of Maple the Iterator package was not shipped with the product. It only got added in a bit later. I wonder whether it changed in some key way.

@rlopez My main gripe about the Typesetting:-RuleAssistant popup is that it neither stores the dot-derivatives settings in a Worksheet nor inserts explicit calls to the Typesetting:-Settings command.

The result is that the desired behavior is not subsequently attained if the Worksheet is closed and then reopened. If you reopen the Worksheet then the customized derivative formatting choices are lost upon re-execution.

But explicit calls to the Typesetting:-Settings command are easily re-executed. They can even be hidden in the Startup Region of the Worksheet/Document, so that they are re-executed up front and automatically.

@exality Just to be clear, when I wrote "tricky" I was thinking of how to get it to work in only/all the right places that output appears in the GUI (without unwanted interference in as-yet-unknown special circumstances), rather than the prefix/rescaling itself. But thanks, I'll check out your link.

@exality The call to set interface(displayprecision) must be in its own Document Block or Execution Group, and not in one that is preceded with a call to restart. The GUI is finicky/buggy that way.

Having such a call be part of the document allows it to override the users' own GUI preferences for display precision (as set under Tools->Options from the menubar) , which can sometimes be useful.

You can also put such a call to interface() inside the Startup Region of a worksheet or Document. Here is an example: displayprec.mw

I suggest that you do not decrease Digits as any kind of general way to control the display precision since, as you mentioned, that is just going to interfere with your computations (unless you decrease and increase Digits or fine-tune your evalf calls, all of which is the opposite of the convenience you're going for).

As for Maple dynamically adjusting the numeric formatting as well as the units prefix, together, that sounds tricky to accomplish now, without a change in how the GUI performs its Numeric Formatting. It's an interesting suggestion. (It might be possible to get some similar effect now, using a customing `print/*` procedure, but it could get tricky and maybe even hairy in some corner cases of printing unusual things. I might give it a whirl.)

@Alex Bowden You just wrote [italics mine], "If (x-1)(1+x) were inherently ambiguous, why would Maple output it to me on the previous line? "

That is, you have claimed that Maple's output had no space between the brackets pairs.

Please upload a document where Maple returned output with that purported (x-1)(1+x) in it, lacking any space between the two brackets subexpressions.

Maple prints the product of x-1 and 1+x with a space between the brackets, which denotes multiplication. In 2D Input mode you can even enter it in that very same way, and that's the default mode for new users.

You can copy and paste that pretty-printed output into both a 1D or a 2D input line and get the appropriate product.

It looks to me as if you simply failed to notice the space that does appear between the brackets pairs in the pretty-printed output, and then re-entered the expression wrongly.

If you really want you can set the GUI's default to Worksheet instead of Document, set GUI's default to 1D rather than 2D input mode, and then issue the command interface(prettyprint=0). Then you can get input and output both with explicit multiplication symbols for this example. I think that'd be overkill, but you have the choice.

As I mentioned, the default for new users is 2D Input and pretty-printed 2D Output. Personally I prefer 1D Input and 2D Output (though I reach for the lprint command now and then. But you can set each as you wish.

@Kitonum I usually also pass the option adaptive=false alongside the numpoints option, to force a precise number of independent data points.

@_Maxim_ Thank you. Can you show how you arrived at the form in your det3?

@Markiyan Hirnyk I got as far as this ("unsigned Stirling numbers of the first kind", using OEIS on the coeffs of the expanded numerator): https://oeis.org/A132393. In other words, coefficients in terms of Maple's Stirling1 command. The coefficients were at increasing offsets into that sequence, with the offset being simple. I got that even for a and b without values.

When you say an "explicit formula" of n+1 terms, what precisely do you mean? Are you hoping to disallow any other nesting of summation? What, if any, special function calls are allowed?

I have no constructive proof of this guess yet. When you write that it must be done with Maple, does that allow for even this kind of preliminary observation, say using the OEIS package downloadable for Maple 2017? I realize that you want a proof, not a guess.

I converted your Post to a Question. Please enter future queries as Questions rather than Posts.

The behavior is consistent with the renumbering that occurs when earlier labeled equations are deleted.

So I suspect that it is all deliberate design.

Whether you consider that behavior in itself to be a bug depends on whether you agree with the design.

Personally I have no issue with it, as described above and if working properly as such.