Numeric inaccuracy - bug? (MC15 and Prime)

[Werner_E]

This is a real strange effect. I know that the conversion from decimal to binary and back can result in numeric inaccuracy. Especially as numbers like 0.7 or 0.1 have a periodic binary representation which has to be cutted somewhere. But usually there should be enough reserves to cope with that effect in case of a simple multiplication of two numbers. I was not able to reproduce that effect with other numbers than 0.7*11. So I hesitate to call it a bug.

The effect shows in Prime, too, but only in the symbolic eval. In Prime we cannot set the number of decimals to anything higher than 15 (17 in Mathcad 15), but in MC15 the effect shows already with 15 decimals whereas in Prime even with 15 decimals set I see the exact 7.7. Nevertheless the symbolic eval shows in Prime too, that the value in x is not exact.

Another effect which is somewhat beyond my understanding is, why the symbolic eval does not show the inaccuracy if a unit is added!!??

When in MC a calculation is stored to a variable, there are two things stored: the numeric value, which is used for subsequent numeric calculations and the "history", how the result should be derived (I guess that thats not really stored to the variable but that for symbolics the original assignment is referenced instead of the stored numeric value). Thats the reason why z:=0.7*11 folowed by z --> would show the correct symbolically evaluated 7.7.

If the assignment is followed by a numeric inline evalulation, only the rightmost expression is stored and thats the (inaccurate) numeric eval. Thats the reason why x is shown inexact even when evaluated symbolically - the "history" (=multiplication 0f the two numbers) is not stored anymore.

This seems to be different when a unit (an unknown variable to the Symbolic) is added. I would have guessed that, because of the inline eval, 7.699999999993 * m would be referenced for the symbolic, but it looks like this time the real history (=the two factors 0.7 m and 11) is taken - why?

Even writing y:=(0.7*11)*m doesn*t change anything.

But then we have

So the symbolics take the unit from the rightmost eval but the factors from the first assignment?????

[ValeryOchkov]

[Werner_E]

So what? Mathcads numeric precision is 16 decimals, so your second number with 17 decimals gets rounded to 16. That has not much to do with the subject here.

[StuartBruff]

Hmm. Interesting. I'll have to have a think about it. It seems to make a difference if the calculations are array based. FYI, neither Excel nor SMath give the same kind of discrepancy.

Stuart

NB. The attached file writes (and reads) a temporary text file to ensure that the symbolic processor picks up the correct "erroneous" product indices after a certain calculation.

[Werner_E]

Thanks for your iterest.

FYI, neither Excel nor SMath give the same kind of discrepancy.

Yes, and every simple pocket calculator uses some extra, not shown decimals and uses them, rounding displayed results to camouflage that kind conversion (Dec->Bin->Dec) errors (at least its my best guess that thats what we see here).

You seem to try hard to get the symbolic evaluation to show the discrepancy, too. I don't think that there is a difference if the calculations are array based. To my experience the symbolics will always give correct results if its doing the multiplication itself, which is does in case of variable a below. But if a variable is assigned the erroneous result of the numeric evaluation (via inline evaluation), the symbolics will show that discrepancy too, as the multiplication is no longer performed by the symbolics processor.

So if you add a numeric evaluation at the end of the definition of your matrix z (z:=matrix(...)=...) you get the wrong results with symbolic eval too. The reason you get it for individual multiplications is because you had used inline evaluations in the definitions of x above. That way the symbolics doesn't "see" the multiplication anympore biut only the erroneous result of the numeric evaluation.

At least thats what I thought so far until I added a unit:

I don't understand why the symbolic eval now shows the correct result for c and d compared with b. Also the last line confuses me as the symbolics seems to take the unit m (an undefined variable to the symboics) from the (erroneous) numeric eval at the end of the definition of d, but it looks like it doesn't take the numeric result as with b but calculates the product itself (like with a).

There also is a descrepancy between the display of numeric values and their representation with num2str(). "Precisions seems to be one decimal less:

[StuartBruff]

Ah! It's been so long since I've used Mathcad that I'd forgotten that the inline "=" assigned the (displayed) evaluated result to the variable, hence allowing such statements as

r:=rnd(3)=0.11111 (say)

3*r->0.33333

rather than

r:=rnd(3)

r=0.11111

r->rnd(3)

Interestingly,

r:=rnd(3).m=0.11111 (say)

produces

3*r->0.33333.m

But, if I've finally got your point, the symbolic processor appears to be correctly evaluating 0.7*11.m rather than picking up the "erroneous" value that the numeric processor assigns to the variable?

Stuart

[Werner_E]

In fact there are two things:

1) One would not expect a math program to "fail" on a simple calculation like 0.7*11. Here the problem seems to be that Mathcad reserves to few extra (if any at all) decimals to deal with those kind of conversion (?) errors. Or said the other way around, it allows us to show to many decimals. Thats different in Prime. While in MC the effect still shows up with 15 displayed decimals its doesn't in Prime. And in Prime we can't ask for more than 15 decimals. So I guess we can call it irritating but not necessarily a bug. Its simply that we can't demand a precision to 16 digits and demanding to show 15 to 17 digits may result in Mathcads results showing their real face. Strange that Harvey is reporting that with MC15 M020 he doesn encounter those effects (I am an M030).

2) Next thing is the symbolic eval of those numericlly calculated results. I thought I understood the difference between adding an inline evaluation and not doing it, but it looks like I didn't. What really puzzles me is the different behaviour of the symbolic evalualtion whether we use units or not. Despite the use of an inline assignment the symbolics evals correctly if we use units.

[HarveyHensley]

I don't have the problem with MC 15 020 or with Prime 3. I am on Win 7, i5 processor

[Werner_E]

HARVEY HENSLEY wrote:

I don't have the problem with MC 15 020 or with Prime 3. I am on Win 7, i5 processor

Really!? So you don't see that discrepancy with 0.7*11= if you set the number of displayed decimals to its max (17)?

Yet another bug which was introduced with the current maintenance release of Mathcad 15??

But then I experience a similar effect with Prime 3, too, and we all use F000 (I'm still on Win XP, though).

I am not able to show any discrepancy with numeric evaluations as we can only set up tp 15 decimals in Prime, but if I assign the numeric result to a variable and evaluate that variable symbolically, the described effect is seen.

I attach a small worksheet and a screenshot of what you are supposed to see.

BTW, the effect was encountered in another forum working on a sheet which uses symbolic "excplicit" to document the calcuations.

[HarveyHensley]

You are right. I was using the default display settings. Changing to the max digits gives your results. The problem does not ocurr with 14 decimal precision.

[Werner_E]

OK, so its not a newly introduced effect. Its exactly what I experience. A round off which is seen when displaying the result with 15 or more decimals (in Prime 15 decimals still look OK).