Incorrect evaluation of 10^30

[JaredBarr]

Mathcad 14 incorrectly evaluates 10 to the power of 30 as (10^30)+(4*10^14). It also does this for all powers greater than 30. Is this a common error to all mathcad 14 versions or does my copy have a unique bug?

[IRstuff]

On 1/15/2010 4:24:19 PM, barr9451 wrote:
>Mathcad 14 incorrectly
>evaluates 10 to the power of
>30 as (10^30)+(4*10^14). It
>also does this for all powers
>greater than 30. Is this a
>common error to all mathcad 14
>versions or does my copy have
>a unique bug?

I don't see anything like that. Can you post your worksheet?

TTFN,
Eden

[JaredBarr]

I agree that the error is somewhat trivial when considering rounding. I was only aware of the error due to a specific application where I had to carry the digits out in decimal format. What is the FPU and how do I check it?

[rmix22-disabled]

AS to the 10^30 I see, that your result has been formatted to decimal and you left the number of decimal places at the default 3. Change that to 15 or more (17 being the max) and you get the correct results. Generally I think you expect too much precison from a 64-bit number.

Regards
RMix

BTW - FPU usually means Floating Point Unit. Otherwise I have no idea, what Jean was talking about.

[ptc-1368288]

On 1/16/2010 7:11:34 PM, barr9451 wrote:
>I agree that the error is
>somewhat trivial when
>considering rounding. I was
>only aware of the error due to
>a specific application where I
>had to carry the digits out in
>decimal format. What is the
>FPU and how do I check it?
_______________________________

1. I don't understand what you mean by ""rounding" your original 10^(integer) ?

2. If you have 10^(non integer), the approximation is the power function X^Y, the error will appear at much before the max exponent order, which for instance exp(35) from recollection.

3. FPU = Floating Point Unit.

jmG

[rmix22-disabled]

Why do you hide the link in an mathcad sheet and there in a png-file?
BTW - the link is not quite correct, you linked to the kalkulator but meant

http://www.wrotniak.net/works/testfpu

The good news are, that the FPU is not blown up or destroyed but that the author is talking about some particular background processes are able to affect the precision of the FPU outcome. The article and software mentioned are rather old, so it possible won't be a problem in 2010.

Concernig the 10^30 effect I would rather stick to Toms explanation.

According to floating point rounding and converting errors its also interesting and well known, that computer math does not follow the commutative law for summation for the reason of the set of numbers not being infinite. E.g. the order in which the sum of 1/k with k running from 1 to an arbitrary integer N>1 is evaluated affects the result. See accompanied sheet, if you are interrested.

Regards
RMix

[ptc-1368288]

You have comments about a 10 years old multiple collaboration between collabs that were and still are quite knowledgeable, especially A. W. Hard to tell about the display you have shown. You should pass to PTC, because no more 14 users (collabs) have responded. Does it indicates they don't have the same display or that your installation is sick ? You seem to indicate "perfect".

"Concerning the 10^30 effect I would rather stick to Tom's explanation".

==> then a 1/1 dispute to read.

jmG

[rmix22-disabled]

On 1/17/2010 11:22:21 AM, jmG wrote:
>You have comments about a 10
>years old multiple
>collaboration between collabs
>that were and still are quite
>knowledgeable, especially A.
>W. Hard to tell about the
>display you have shown.

No clue! Anybody able to translate that for me?


>should pass to PTC, because no
>more 14 users (collabs) have
>responded.

Ahhh, I see. Probably you are argueing about me sending my file in XML-format. Why don't you simply write it that way?
BTW - the name of this conference has the version number 14 explicit in its name, so I would expect seeing files in that format here.


> Does it indicates they don't have the same
>display or that your installation is sick ?

??? No sick installation here. Simply a demonstration of the well known fact that in computer algebra addition is not commutative. (If your reply refernces my summation example).


> You seem to indicate "perfect".

Translation, please!


>"Concerning the 10^30 effect I
>would rather stick to Tom's
>explanation".
>
>==> then a 1/1 dispute to read.
Dont't think so - simply all said. It seems not to be a MC14 bug but rather a natural effect of the limited FPU precision. Why increasing the number of decimal places "solves" the "problem" still puzzles me.

Regards
RMix

[ptc-1368288]

"BTW - the name of this conference has the
version number 14 explicit in its name, so I
would expect seeing files in that format here".
_________________________

That's what I was saying: hope for Mathcaders 14 to see and report the same bug that you have illustrated. Post your work sheet [or the puzzle only] to PTC. I didn't read any comment from the webmaster as a recorded bug.

jmG

[ptc-1368288]

On 1/17/2010 1:25:36 PM, jmG wrote:
>"BTW - the name of this
>conference has the
>version number 14 explicit in
>its name, so I
>would expect seeing files in
>that format here".
>_________________________
>
>That's what I was saying: hope
>for Mathcaders 14 to see and
>report the same bug that you
>have illustrated. Post your
>work sheet [or the puzzle
>only] to PTC. I didn't read
>any comment from the webmaster
>as a recorded bug.
>
>jmG
__________________________

Cn't help more.
..................

I don't see anything like that [Eden]

"I was only aware of the error due to a specific application where I had to carry the digits out in decimal format." [mix]

==> If you carry digits, you don't carry the true representation of numbers which represented in fraction !!! [jmG]
That may be the source of your problem. [jmG]

"Concerning the 10^30 effect I would rather stick to Tom's explanation".

==> My explanation is probably the first source, I vote for .
==> But truthfully respect Tom number theory .


Comments and reflection:

At the machine precision 16, carried in floating point 20, the relative accuracy of the carried calculations can be visualized as 1/100 the diameter of an electron seating at the top of a tower 1 km height !!! About such huge digits you demand, it indicates some ultra scientific calculations. For which scientific calculations, very many functions have a limited number of decimals and many constants unknown past their listed limits. Maybe your stuff is not so savant ?

jmG

[ptc-1368288]

On 1/17/2010 12:21:39 PM, rmix22 wrote:
...
>Regards
>RMix
_______________________

Meditate this work sheet
There is more on that ...
If you have carried the digits display, as explained before, you have not carried the real valued result.

Collabs are now getting interested !

jmG

[StuartBruff]

On 1/17/2010 11:22:21 AM, jmG wrote:
>"Concerning the 10^30 effect I would rather stick to Tom's explanation".
==> then a 1/1 dispute to read.

2/1, old chap. It is a numeric representation issue. In M14 it also makes a difference if the number is input as 10³⁰ or 1E30, the latter being exact in M14.


Stuart

[TomGutman]

1e30 is not exact in MC14 (it cannot be, as that is a number not representable in IEEE 64 bit floating point). It gives the exact same result as 10^30 (showing how good the latter calculation is, possibly some optimization to avoid the general power routine). I suspect you have some of your regions set to display 15 or more decimal places. That does result in a display that appears to be exact, but which does not reflect the underlying reality (actual stored number).
__________________
� � � � Tom Gutman

[StuartBruff]

On 1/17/2010 2:33:36 PM, Tom_Gutman wrote:
== 1e30 is not exact in MC14 (it cannot be, as that is a number not representable in IEEE 64 bit floating point). It gives the exact same result as 10^30 (showing how good the latter calculation is, possibly some optimization to avoid the general power routine). I suspect you have some of your regions set to display 15 or more decimal places. That does result in a display that appears to be exact, but which does not reflect the underlying reality (actual stored number).

It's internal representation is indeed not exact. However, as shown in the previously attached worksheet, evaluating the expressions 1E30 and 10³⁰ does give different results in M14, the 1E30 result being exact.

The 'number of decimal places' is irrelevant as that setting doesn't affect the number of places before the decimal place.

Stuart

[TomGutman]

>>The 'number of decimal places' is irrelevant as that setting doesn't affect the number of places before the decimal place.<<

The number of decimal places should be irrelevant. But there's a bug in there, and it's not. A setting of 15 or higher results in a different display from lower ones. The displayed results for 10^30 and 1e30 are identical, if the setting are the same.
__________________
� � � � Tom Gutman

[StuartBruff]

On 1/17/2010 4:49:05 PM, Tom_Gutman wrote:
>>The 'number of decimal places' is irrelevant as that setting doesn't affect the number of places before the decimal place.<<
== The number of decimal places should be irrelevant. But there's a bug in there, and it's not. A setting of 15 or higher results in a different display from lower ones. The displayed results for 10^30 and 1e30 are identical, if the setting are the same.

Excuse me while I find a brick wall to bang my head against .... <sigh>

Stuart

[rmix22-disabled]

>The 'number of decimal places' is
>irrelevant as that setting doesn't
>affect the number of places before the
>decimal place.

At least this is as it should be an what I expected. What puzzled me was, that (at least in MC14) the number of decimal places _had_ an effect on the display of the result of 10^3, when I played around with the file of the original poster (barr9451).

Regards
RMix

[TomGutman]

FPU is the floating point unit. It is a part of your CPU and there is nothing to check. It can't go bad unless your CPU fails completely. jmG is just (as is common) blowing smoke.

Now I can see the "error". If the number of decimals is set at 15 or more, it doesn't show up, indicating that there is a problem with conversions for such values. A setting of 17 is supposed to show the best decimal approximation to the actual stored value, but does not seem to work properly.

IAC, it is just a matter of number representation. The internal representation of numbers is binary, not decimal. 10^30 simply cannot be expressed exactly in binary with 53 significant bits (the precision of IEEE 64 bit floats) and is rounded up a bit to get the closest number that can be represented. This is just what happens using fixed precision binary floating point.

If you want decimal floating point calculations, or different precisions, you can use the symbolic processor (which does not use the hardware floating point representation).
__________________
� � � � Tom Gutman

[ptc-1368288]

On 1/16/2010 9:35:36 PM, Tom_Gutman wrote:
>FPU is the floating point
>unit. It is a part of your
>CPU and there is nothing to
>check. It can't go bad unless
>your CPU fails completely.
>jmG is just (as is common)
>blowing smoke.
> .............................
>� � � � Tom Gutman
_______________________________

I'm not blowing smoke for the visitor..
As usual, if you would read the attachments you would discover more with link to reputable software designer, where I give reference to some software that blow the FPU. Usually, games destroy the FPU and many will not restore when leaving.

That's not smoke !

jmG

[ptc-1368288]

... the other point is about if you use Vista with 32 digits where the Mathcad digits display (then copiable) is max 15. The display you have shown is puzzling.

jmG

[ptc-1368288]

On 1/15/2010 4:24:19 PM, barr9451 wrote:
>Mathcad 14 incorrectly
>evaluates 10 to the power of
>30 as (10^30)+(4*10^14). It
>also does this for all powers
>greater than 30. Is this a
>common error to all mathcad 14
>versions or does my copy have
>a unique bug?
_______________________________

Check the FPU.
If you uninstall games, the FPU is probably destroyed. Some software or gadgets were known to destroy the FPU as well. Not to good an example,

10^30 = 1x10^30 = 1000000000000000000000000000000

jmG

[TomGutman]

What sort of evaluation are you doing that you get the result expressed as the sum of two values?

Actually, I'm surprised that I don't see the "error". 1e30 is well beyond the range of exactly expressible (in IEEE 64 bit format) numbers, and is not exactly representable. It has to be rounded. But I can't see the rounding, even though I would expect to be able to.
__________________
� � � � Tom Gutman

[ptc-1368288]

>1e30 is well beyond the range of exactly expressible (in IEEE 64 bit format) numbers, and is not exactly representable".
______________________________

That seems a technical point but in fact there is nothing to calculate as it simply converts a notation. What I mean is that noting is pushed to the arithmetic unit (the binary registers) and no calculation are demanded from the AU. In other words, no numerization is involved, i.e: no representation. The power function X^Y does not seem involved.

jmG