While John's Answer is great...

In order to make float matrix-scalar multiplication fast it is done with precompiled external code at hardware double precision. That's a way for Maple to compete with Matlab in computation speed (if not for memory management speed) for such problems when the size is large.

During the MatrixScalarMultiply by 1000, the Matrix `a` is first converted to datatype=float[8] which is (binary 64 bit) hardware double precision. But all the entries of `a` are less than or equal to 1. So the entries of `a` are base 10 floating-point, and the values after conversion to float[8] will be base 2 floating-point. That introduces some error, as there is not always a perfect equivalent base 2 float for a given base 10 float (with non-zero digits on the rhs of the decimal point which is what all these entries have).

In this case, it is the float[8] value for HFloat(858/1000.) as mentioned by John which does not have an exact base 2 match for the "exact" base 10 0.858 value.

So the subsequent scalar multiplication by 1000 does not purely undo the earlier division by 1000 as some base conversion error was introduced between those two scaling actions.

Note that the accumulated error is not much more that 1e-16.

If Maple would simply ditch the base 10 representation altogether and go with pure base 2 for both representation and display of all floats then these issues might vanish.  ;)  In such a scenario, you wouldn't even be able to enter the base 10 number 0.858 exactly. Problem solved!

While John's Answer is great...

In order to make float matrix-scalar multiplication fast it is done with precompiled external code at hardware double precision. That's a way for Maple to compete with Matlab in computation speed (if not for memory management speed) for such problems when the size is large.

During the MatrixScalarMultiply by 1000, the Matrix `a` is first converted to datatype=float[8] which is (binary 64 bit) hardware double precision. But all the entries of `a` are less than or equal to 1. So the entries of `a` are base 10 floating-point, and the values after conversion to float[8] will be base 2 floating-point. That introduces some error, as there is not always a perfect equivalent base 2 float for a given base 10 float (with non-zero digits on the rhs of the decimal point which is what all these entries have).

In this case, it is the float[8] value for HFloat(858/1000.) as mentioned by John which does not have an exact base 2 match for the "exact" base 10 0.858 value.

So the subsequent scalar multiplication by 1000 does not purely undo the earlier division by 1000 as some base conversion error was introduced between those two scaling actions.

Note that the accumulated error is not much more that 1e-16.

If Maple would simply ditch the base 10 representation altogether and go with pure base 2 for both representation and display of all floats then these issues might vanish.  ;)  In such a scenario, you wouldn't even be able to enter the base 10 number 0.858 exactly. Problem solved!

For your more complicated example, there is a trick: load the old `student` package first!

Ie,

with(student):

evalf(expand(finaltest));

What happens is that loading that package causes the routine `expand/Int` to be replaced with one that can handle your problem.

For your more complicated example, there is a trick: load the old `student` package first!

Ie,

with(student):

evalf(expand(finaltest));

What happens is that loading that package causes the routine `expand/Int` to be replaced with one that can handle your problem.

@gotamo The Student:-Calculus1:-Roots command acts as a user-friendly entry-point to (eventually) the fsolve command with its 'avoid' option being used repeatedly.

You can see verbose evidence for that by either issuing trace(fsolve) prior to calling Student:-Calculus1:-Roots. Or you could see it by printing and following the source code. Basically, for your numeric problem Student:-Calculus1:-Roots calls Student:-Calculus1:-RootsNumeric which calls `minimize/fsolve` which calls fsolve with its avoid option.

Another reasonable user-friendly procedure (which you may enjoy writing for yourself) to find all real roots in a given range could be constructed to instead utilize RootFinding:-NextZero repeatedly.

@gotamo The Student:-Calculus1:-Roots command acts as a user-friendly entry-point to (eventually) the fsolve command with its 'avoid' option being used repeatedly.

You can see verbose evidence for that by either issuing trace(fsolve) prior to calling Student:-Calculus1:-Roots. Or you could see it by printing and following the source code. Basically, for your numeric problem Student:-Calculus1:-Roots calls Student:-Calculus1:-RootsNumeric which calls `minimize/fsolve` which calls fsolve with its avoid option.

Another reasonable user-friendly procedure (which you may enjoy writing for yourself) to find all real roots in a given range could be constructed to instead utilize RootFinding:-NextZero repeatedly.

@JacquesC A few examples come to mind.

1) context-menus (as you mentioned) is one of the ::uneval examples. If the output is an unevaluated lowercase `int` call, then it'd be performance disaster if invoking the context-menu caused normal-evaluation-rules to bring about a repeated attempt by `int` to compute the integral.

2) Typesetting's parsing of 2D input, which occurs in large parts at the Library level, is another of the ::uneval examples.

3) The fact that Explore:-explore does not support lexical scoping, is an example of your lexical scoping shift. (The GUI crashes if the new worksheet opened by Explore is a shared kernel and not a new kernel. Hence names (in a complicated expression or proc body passed to Explore) which would normally get a value via scoping simply appear to be unassigned and the mechanism breaks. It can be very difficult to re-instantiate something like a proc body as a new copy in which all lexicals get replaced by their "values".

4) A different kind of example: Have you ever forgotten to place an evalf around an expression inside a proc, and then later wished you had? How about if that expression is an uppercase Int call? What about when you forget to place `evalf/int`'s optional arguments ('digits', 'epsilon') inside an Int call, because you didn't realize that you really wanted to call `evalf` rather than `value` on it. These are just some of a mountain of responsibility difficulties in using Int() and evalf(Int()) side by side.

5) Maybe related to 4) is the fact that the Expression palette only allows for insertion of `sum` and not `add` or `Sum`. (Similarly the palette provides `int` but not a functional `Int` with properly functioning tabbable markers.) And we know what happens when the new user attempts to utilize `sum` to reference the unknown kth entry of an rtable.

@Alejandro Jakubi 

In Maple 14.00,

> 0^0; # same as in Maple 13
                               1

> `^`(0,0); # returned 1 in Maple 13
                               0

@Alejandro Jakubi 

In Maple 14.00,

> 0^0; # same as in Maple 13
                               1

> `^`(0,0); # returned 1 in Maple 13
                               0

Could you explain in more detail how this task differs from what ImageTools:-Convolution does?

@Jolsa There may still be some confusion about whether you are refering to input or output.

Let's agree on terms. The term "accuracy" is usually used to refer to the degree of correctness in the computed output (see Robert's reply). The term "working precision" is usually used to refer to the numbers of digits used in the computational environment, aka Digits. And (more rare in maple, but common in applied science) there is the term "precision" on its own which can refer to the degree of certainty or significance in the digits of the input (the source of which may have been a physical measurement).

If you are talking about accuracy of output then see Robert's reply. If you are talking about the precision (in measurement) of input then see ScientificErrorAnalysis (or its rougher cousin Tolerances), but be aware that their use is by no means wholly integrated throughout the Maple system.

@Jolsa There may still be some confusion about whether you are refering to input or output.

Let's agree on terms. The term "accuracy" is usually used to refer to the degree of correctness in the computed output (see Robert's reply). The term "working precision" is usually used to refer to the numbers of digits used in the computational environment, aka Digits. And (more rare in maple, but common in applied science) there is the term "precision" on its own which can refer to the degree of certainty or significance in the digits of the input (the source of which may have been a physical measurement).

If you are talking about accuracy of output then see Robert's reply. If you are talking about the precision (in measurement) of input then see ScientificErrorAnalysis (or its rougher cousin Tolerances), but be aware that their use is by no means wholly integrated throughout the Maple system.

@hirnyk I made a guess, based more on the supplied example than the description. I usually veer that way, as I find that people more often show what they really want. Sometimes it's a tough call.

@hirnyk I made a guess, based more on the supplied example than the description. I usually veer that way, as I find that people more often show what they really want. Sometimes it's a tough call.

As mentioned, English is irregular. And not unexpectedly there is room for improvement here.

For example, your code and post report 11 syllables for, "That pierced the fearful hollow of thine ear." It actually has just 10 syllables. Perhaps it's going wrong on the word "pierced", in which case a further pattern adjustment may be helpful.