Very simple matrix, very wrong answer 4

[fbeltrao]

Try to find the determinant of the following 3x3 matrix:

[pre] | 2 3 4 |
M := | 1 -2 3 |
| 3 1 7 |[/pre]

MathCAD 15 returns me this:

[pre]|M| = 6.217*10^-15[/pre]

Which is obviously wrong. The answer is ZERO. Doing it manually:

[pre][2*(-2)*7 + 3*3*3 + 1*1*4] - [4*(-2)*3 + 3*1*7 + 3*1*2]
3 - 3
0[/pre]

Also, try in Wolfram, the answer is also ZERO: [pre]

https://www.wolframalpha.com/input/?i=determinant({2,3,4},{1,-2,3},{3,1,7})

[/pre]

Can someone explain me what went terrible wrong to MathCAD 15 give me that absurd answer? Did I make something wrong?

 

[GregLocock]

Yes, I'd just give up on it and throw MathCAD away if I were you. That's a numerical order of the same magnitude as a mistake in the distance to the moon of the order of 1/1000 of a millimetre. This is obviously completely unacceptable in a package that is designed for use by engineers.

Disgustingly Python makes the same mistake, but with greater precision, 6.2172489379008837e-15.

I strongly recommend you write to The Times of London to complain about this disgraceful state of affairs.



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[IDS]

Disgustingly Python makes the same mistake, but with greater precision, 6.2172489379008837e-15.

Use SciPy Greg, that gives -1.17961196366423E-16; over 50 times more accurate.

Bur seriously (in reply to the OP), if you do arithmetic calculations on a computer with numbers of the order of 1, than any result less than 1E-14 is zero.

Doug Jenkins
Interactive Design Services

http://newtonexcelbach.wordpress.com/

 

[fbeltrao]

@GregLocock

I'm a student, take it easy, I'm not a MathCAD expert or know how it makes arithmetic calculations internally, I understand that computers solve this kind of calculation in a different way we make by hand.

I'm not solving matrices alone in MathCAD, that matrix I used as an example is a single line of much larger worksheet, which contains parts with boolean operations to check if the determinant is zero or not, automatically decididing in which way the system should follow to solve the problem, and since everything is chained, an answer different from zero breaks the whole thing when it comes the part to solve the matrices.

Yes, I exagerated saying it's a "very wrong answer". I understand that a number of that magnitude is equal to zero, but MathCAD do not understand this way, I guess I'll have to make some changes at the boolean operations to assume a number of that magnitute equal to zero.

@IDS

Thanks for your answer.

 

[IRstuff]

MAthcad's symbolic engine returns 0. While I understand being a student and all that, you should not depend on the real world returning zeros for problems like this. Only in school are cases where numbers calculate to zero. I would suggest that you bulletproof your calculation chain against this like this; you might even get brownie points for being proactive.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529


Of course I can. I can do anything. I can do absolutely anything. I'm an expert!
There is a homework forum hosted by engineering.com:

http://www.engineering.com/AskForum/aff/32.aspx

 

[fbeltrao]

That's exaclty what I made, used the symbolic engine, makes eveything much easier without the need to implement undesirable workarounds. Now evething works as expected.

 

[jhardy1]

"That's a numerical order of the same magnitude as a mistake in the distance to the moon of the order of 1/1000 of a millimetre."

Yes, but if you were navigating to the Andromeda Galaxy (2.5 million light years away), you could miss the geometric centre of the galaxy by 150,000 km - errors of that magnitude might cause problems when we start travelling to other galaxies!

(Of course, there's a super-massive black hole at the heart of the Andromeda Galaxy, and the event horizon is billions of km across, so I think your fate would be pretty much the same even if you "missed" your target by 150,000 km! )

http://julianh72.blogspot.com

 

[IDS]

fbeltrao - you will meet this sort of problem all the time when programming numerical work. In general you need to create a tolerance constant of an appropriate magnitude and check that the absolute value of a result is less than the tolerance, rather than exactly zero. Also if you want to make it bullet proof you need to normalise the value being checked in some way, depending on the magnitude of the input values.

Doug Jenkins
Interactive Design Services

http://newtonexcelbach.wordpress.com/

 

[zdas04]

Double click on the answer and output it in Decimal. Answer shows up as an integer zero.

David Simpson, PE
MuleShoe Engineering

In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual. Galileo Galilei, Italian Physicist

 

[excognito]

No, you didn't do anything wrong but, as others have pointed out, this is due to Mathcad calculating the determinant using a numerical algorithm to calculate the answer you got.

Mathcad is effectively two processors working on a single worksheet: the Numeric Processor and the Symbolic Processor, with the Numeric Processor being the default (at least as far as user perception and many of Mathcad's functions are concerned).

---------------------------------------------

The Numeric Processor stores numbers as 64-bit IEEE 754 format floating-point numbers; of these 64 bits, 53 give the (binary, normalized) precision of the number and the remaining bits give the (binary power) scaling of the number. It's quite an interesting (ie, complex) subject and it is well worth reading around it to understand how computers deal with limited-width, floating-point numbers. Of note is that 53-bits means the difference between 2 numbers is of the order of 2^-16 ... in other words, about the size of ther result you are seeing.

A key point to grasp, however, is that whilst 53 bits is normally good enough for accurate calculations, there are many algorithms where the relative scales of numbers means that a difference of 2^-16 has a noticeable effect on the result; this is particularly evident where divisions occur, as often there is no exact binary 53-bit representation of the result (eg, 1/3 = 3.33333333.. which means that the floating-point representation can't accurately represent 1/3 as it misses off an infinite number of '3's! (The situation is slightly more complicated than that, because Mathcad uses the IEEE 754 80-bit format for actually doing the calculations, which does improve things slightly .. but the principle remains the same.)

Another key point to take onboard is that This problem is not unique to Mathcad. You will get near enough the same result if you try the same calculation in Matlab or Excel or any other application that uses standard floating point numbers.

---------------------------------------------

However, the good news is that Mathcad also has a symbolic processor, and that can handle numbers of arbitrary precision making it capable of exactly dealing with rational numbers. It can also simplify symbolic expressions.

If, instead of typing "=" when you evaluate your determinant, you type control-fullstop (ctl-.), you will find that Mathcad gives you the exact 0 that you expect. This is also why Wolfram Alpha gave an exact answer, because it uses a symbolic processor as standard.

You may be wondering why the Numeric Processor is the default, if the Symbolic Processor can give more accurate results? The reason is simply down to performance. Many numerical algorithms run substantially quicker than their symbolic counterparts and most processors have built-in hardware for doing floating-point arithmetic.

Hope that helps.

 

[PNachtwey]

I thought the problem was obvious.
Mathcad must use a Gauss Elimination method that involves scaling and then adding or subtract rows from each other so the lower left is all zeros. This can result in round off errors.
The error free way is to multiply diagonals and then add or subtract the products. There is no scaling or division required.
see the section on 3x3 matrices

http://en.wikipedia.org/wiki/Determinant

Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[Angre]

Fbeltrao,
The way a computer sees a number is very different from the way we "see" it.
Iam a structural engineer, and we are beware of such results in pathological cases.And they arise often enough, believe me.
How do we judge whether a case is pathological?, it just boils down to a hunch about what the solution would like,
in an approximate sense of course, even before we hit the "enter" key.
In some sense I dont fully trust results even from my calculator, unless and until I have broad outline of what Iam going to get.
As an example sin(63) should be ....greater than 0.7...if I get -0.3....time to check the mode ....deg or radians.
Hope you get my point.

 

[fel3]

Try 100.00-99.99-0.01

All eleven of my HP calculators give the correct answer of exactly zero.

However, every computer program I have tried over the years except two (including various versions of Mathcad, Excel, SuperCalc, etc.) have returned an answer of 5.1156995306556E-15 (give or take). The only programs that ever got it right were Word for Windows 2.0 and Q&A 4.0, the reason being (IIRC) that they limited the precision of the final answer to eight decimal places.

While 5E-15 is close enough to zero for many applications, it is not if you are testing for zero. in fact, that's how I first encountered this problem. I had given a client a large Q&A 4.0 data base to enter assessment district payments into, but there way no way to lock the assessment amounts I had calculated in SuperCalc 5.0 for transfer to the database. So, when I pulled his data from Q&A 4.0 back to SuperCalc 5.0, I added an error check column to my spreadsheet. Exactly one of the 653 assessments returned a non-zero amount. Not all problems of the type I started this message with return a non-zero result, but many do.

The short-term solution is to include rounding at strategic points in your calculation. The long-term solution is to add the tests for arithmetic reasonableness to the IEEE floating point standard…an opinion for which I was once savagely flamed on the HPMuseum forums by some electrical engineers. The other solution (as I am told) would be use binary coded decimal arithmetic, but I doubt that will ever happen.

So, what are the tests for reasonableness? They are this:
[ul]For addition and subtraction, the number of decimal places in the result cannot exceed the number of decimal places in the operand with the most decimal places.[/ul]
[ul]For multiplication, the number of decimal places in the result cannot exceed the sum of the number of decimal places in the two operands.[/ul]
[ul]For division, you are on your own.[/ul]

Fred

==========
"Is it the only lesson of history that mankind is unteachable?"
--Winston S. Churchill

 

[jhardy1]

When I learnt computer programming back in my youth, I was taught that when you test for zero in floating point maths, you don't test for absolute equality:

IF ( X == 0 ) THEN ...

Rather, you perform a "rounded" test such as:

IF ( ABS(X) < 1E-10 ) THEN ...

Whether you use E-10 or E-15 or whatever depends on the nature of the computations you are undertaking, and whether you are using single or double or extended precision, etc. (E.g. if you are comparing wavelengths of gamma radiation, you would need to use a test that is much less than 1E-10 metres!)

If you know the order of magnitude of the numbers you expect to see, and can define a sensible "smallest non-zero number", you can factor that into your test:

IF ( ABS(X) / SMALLEST_NON_ZERO < 1E-3 ) THEN ...

http://julianh72.blogspot.com

 

[IRstuff]

"All eleven of my HP calculators give the correct answer of exactly zero.

That's because most calculators use binary coded decimal (BCD), which is probably an outcome of the fact that modern calculators came from adding machines used to calculate monetary quantities, which require exact decimal representations. Users for such calculators still expect to be able to calculate money amounts, and still require BCD.

http://speleotrove.com/decimal/decifaq3.html#calcs

TTFN
I can do absolutely anything. I'm an expert!
homework forum: //

http://www.engineering.com/AskForum/aff/32.aspx

faq731-376 forum1529

 

[jghrist]

Choose Format|Result|Tolerance and set the Zero threshold to 14.
Now 100-99.99-.01 = 0

 

[PNachtwey]

wxMaxima returns exactly 0 even if I enter all the numbers as floating point numbers.

/* [wxMaxima: input start ] */
M:matrix([2,3,4],[1,-2,3],[3,1,7]);
determinant(M);
/* [wxMaxima: input end ] */

wxMaxima is superior to Mathcad when solving symbolic problems.


Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[IRstuff]

That could just be that the zero tolerance in Maxima is set higher than in Mathcad.

TTFN
I can do absolutely anything. I'm an expert!
homework forum: //

http://www.engineering.com/AskForum/aff/32.aspx

faq731-376 forum1529

 

[excognito]

PNachtwey (Electrical) 1 Oct 15 16:15

wxMaxima returns exactly 0 even if I enter all the numbers as floating point numbers.

/* [wxMaxima: input start ] */
M:matrix([2,3,4],[1,-2,3],[3,1,7]);
determinant(M);
/* [wxMaxima: input end ] */

Interestingly, Mathcad 15 M040 (the latest release) also gives exactly 0 for both integer and floating-point and for both numeric and symbolic processors.

wxMaxima is superior to Mathcad when solving symbolic problems.

Yes. But Mathcad is adequate for many cases. It would be better if they ditched the limited version of Matlab's symbolic processor (originally MuPad) and went for their own (eg, a branch of Maxima or one of the other open source symbolic libraries that permit commercial licencing)

 

[DBull]

You can also force it to round down to the closes chosen decimal point by using Floor().
Format|Result|Tolerance will only hide the leftover values. But using floor actually will define it as a new number to be used later (Same as in excel)

Floor(0.99,0.1) will f.ex return 0.9

In your case:
[New variable]:Floor(|M|,10^-14)=0

This is of course cheating. But is quick, easy and works.

I encountered a similar problem while adding units to a value.
Did you know that 100mm+200mm=300.00000000000006mm?
The peeps at the PTCcommunity gave me a wall of info on the subject

https://www.ptcusercommunity.com/message/406124