PureBasic Forums - English

Posted: **Tue Mar 04, 2008 8:50 am**

I don't understand this at all.

n=1
q=n/3
Debug Pow(10,q) ; 1.0

Debug Pow(10,(n/3)) ; 2.1544346900318838

Posted: **Tue Mar 04, 2008 9:38 am**

Mistrel wrote:I don't understand this at all.
Code: Select all
n=1
q=n/3
Debug Pow(10,q) ; 1.0

Debug Pow(10,(n/3)) ; 2.1544346900318838

Because the compiler will promote the expression in the second one to a float or double you will get 10^0.3333.... You have already performed the n/3 calculation and stored it in the long variable in the first case and x^0=1.

Posted: **Tue Mar 04, 2008 3:59 pm**

But can you explain this instead:

n=1
q.f=n/3
Debug Pow(10,q) ; 1.0

Debug Pow(10,(n/3)) ; 2.1544346900318838

I get:

2.1544347393126988
2.1544346900318838

Is it simply truncated in q.f or ???

I see the anwers to the 7th decimal place are the same. That is indeed enough accuracy for anyone in the aerospace industry.

Hmmm let me throw a few more debugs in.

Posted: **Tue Mar 04, 2008 4:01 pm**

What do you mean? Do you wonder why it isn't 1.0 or why the numbers aren't equal?

Code: Select all

n=1 
q.d=n/3 
debug q
Debug Pow(10,q) ; 2.1544346900318838 

Debug Pow(10,(n/3)) ; 2.1544346900318838

Posted: **Tue Mar 04, 2008 4:02 pm**

Why the numbers are not more equal.

Posted: **Tue Mar 04, 2008 4:05 pm**

Code: Select all

n=1 
q.d=n/3 
Debug q
Debug Pow(10,q) ; 1.0 

Debug Pow(10,(n/3)) ; 2.1544346900318838

q.d, NOT q.f... .f has limitations (Silly me!)

Posted: **Tue Mar 04, 2008 6:35 pm**

Removed.

Posted: **Tue Mar 04, 2008 11:48 pm**

OK I will give you that in standard precision they were indeed equal, but they were not exact.

Posted: **Wed Mar 05, 2008 12:24 am**

a Float and even a Double almost never give an exact value.
or more precise:
for each value that can be stored 100% exactly, there are thousands of values that cannot.
that is immanent to the nature of floating-point storage.

Prof.Kahan wrote:13 Prevalent Misconceptions about Floating-Point Arithmetic :
1• Floating–point numbers are all at least slightly uncertain.
2• In floating–point arithmetic, every number is a “ Stand–In ” for all numbers that differ from it in
digits beyond the last digit stored, so “ 3 ” and “ 3.0 E0 ” and “ 3.0 D0 ” are all slightly different.
3• Arithmetic much more precise than the data it operates upon is needless, and wasteful.
4• In floating–point arithmetic nothing is ever exactly 0 ; but if it is, no useful purpose is served by
distinguishing +0 from -0 . ( We have already seen on pp. 13 - 15 why this might be wrong.)
5• Subtractive cancellation always causes numerical inaccuracy, or is the only cause of it.
6• A singularity always degrades accuracy when data approach it, so “ Ill–Conditioned ” data or problems
deserve inaccurate results.
7• Classical formulas taught in school and found in handbooks and software must have passed the
Test of Time, not merely withstood it.
8• Progress is inevitable: When better formulas are found, they supplant the worse.
9• Modern “ Backward Error-Analysis ” explains all error, or excuses it.
10• Algorithms known to be “ Numerically Unstable ” should never be used.
11• Bad results are the fault of bad data or bad programmers, never bad programming language design.
12• Most features of IEEE Floating-Point Standard 754 are too arcane to matter to most programmers.
13• “ ‘ Beauty is truth, truth beauty.’ — that is all ye know on earth, and all ye need to know.” ... from
Keats’ Ode on a Grecian Urn . ( In other words, you needn’t sweat over ugly details.)

Posted: **Wed Mar 05, 2008 1:04 am**

I forgot that I was casting to an integer. Oops!

PureBasic Forums - English

Why does this evaluate differently?

Why does this evaluate differently?

Re: Why does this evaluate differently?