Numerical Input to Computer

[khaled]

when we want to tell the computer "for example" to do

calculation like calculating the circle's area,

 

we may give the following instruction in different versions,

 

A: Result = [math]r^2{}[/math] * 3.14

B: Result = [math]r^2{}[/math] * 3.1416

C: Result = [math]r^2{}[/math] * 3.14159265

 

example, input: r = 100000

 

A: Result = 31400000000

B: Result = 31416000000

C: Result = 31415926500

 

but yet when we go with real numbers, it start to be worse ...

so the best solution would to be,

let the machine shows you the best it can do !

this means, let the computer do the division ...

 

and this would be my version of Circle Area Calc .. in C,

long double Circle_Area ( double r )
{
     double pi = (double)22.0/(double)7.0;

     long double Result =  r * r * pi;

     return Result;
}

[insane_alien]

when you're using 22/7 as an approximation of pi then there isn't much need to store the variable as a double.

 

most programming languages have some form of math library that will far exceed that apporximation.

 

alternatively, you could get the program to calculate pi to an arbitrary number of digits before performing the calculation, but a precomputed value for pi would be the most efficient.

[khaled]

also, let's not forget the possibility of inserting the pi value as fraction into the formula,

 

for example,

 

formula: (X + 2[math]X^2{}[/math]) = r

 

Result = [math]r^2{}[/math] * pi

 

A: r^2 * (22/7)

 

B: (X + 2 X^2) * (X + 2 X^2) * (22/7) = (X^2 + 4 X^3 + 4 X^4) * (22/7)

....... = (22 X^2 / 7) + (88 X^3 / 7) + (88 X^4 / 7)

 

i guess that such process can give better solutions to particular formula

[insane_alien]

22/7 is insufficient for most applications.

 

22/7 id only suitable if its fine to use 3.14 as pi. 3.14159 is a better approximation than 22/7

 

did you even read my post?

Edited April 22, 2010 by insane_alien
i is not one

[khaled]

i did read your post,

 

and if you really read my second post, you'd realize that i started a new idea ...

[insane_alien]

what substituteing another variable for r and not even explaining what it is?

 

and you're still using a horrible approximation for pi.

[the tree]

If, for no apparent reason you set [imath]r=x+2x^2[/imath].

 

Then between [imath][ r^2 \pi ][/imath] and [imath][ x^2 \pi + 4x^3 \pi + 4 x^4 \pi ][/imath], the latter is obviously going to have a larger loss of accuracy due to involving at least 10 more FLOPs not to mention the additional loss from calculating [imath]x[/imath] in the first place.

 

As i_a mentioned, you can use arbitrary precision for a result at least as accurate as your initial value for the radius and there's certainly no need to use such terrible approximations.

[khaled]

im not the one who suggest using terrible approximations .. i use general fraction

[insane_alien]

you may not have suggested it but it's what you're using and in your first post you definitely implied it was better than using say 3.14159265. despite it being significantly worse.

 

then you bring in some new X variable and fail to explain what it represents or even why it is useful.

[Bignose]

If you're going to insist on using a fractional representation (for whatever reason) why not use 335/113, it is accurate to 7 digits.

[hobz]

You'd be far better of defining pi as a constant at compile time. First of all you can get exact precision to the degree that 'double' (or long double if you prefer) offers.

Second, calculating a constant value every time the function is called, is just a waste of power. (Hopefully the compiler will fix this for you.)

[khaled]

i heared it's possible, given an expression, we can embed pi fraction 22/7,

i know if you write (22/7)(double) in C it will return 3.14.. approximation

but if you embed the fraction in a dynamic expression in a function,

it will give more flexibility ...

 

like this,

 

first version:: given X: return (22/7) * (1/X) * 100,000,000

X=3 .. = 3.14159 / 3 = 1.04719666 * 100,000,000

.. = 104,719,666

 

2nd version:: given X: return 22/(7 * X) * 100,000,000

X=3 .. = 22 / 7*3 = 22/21 = 1.04761904 * 100,000,000

.. = 104,761,904

 

difference = 42,238

 

if this was a Money Transfer, 42,238$ is gone because of a miscalculation!

[crashonly]

i heared it's possible, given an expression, we can embed pi fraction 22/7,

i know if you write (22/7)(double) in C it will return 3.14.. approximation

but if you embed the fraction in a dynamic expression in a function,

it will give more flexibility ...

 

You are right that using a fraction such as 22/7 dynamically inside your code can give you more felxibility and more accurate results. You are completely missing the point, however, which is that 22/7 is a very bad value for Pi. 22/7 = 3.14285... so you see it goes off at 4th decimal already. So if 22/7 was the value you wanted to use, you would be correct, but as you want to be using an accurate value of Pi, any use of 22/7 will screw you over.

 

first version:: given X: return (22/7) * (1/X) * 100,000,000

X=3 .. = 3.14159 / 3 = 1.04719666 * 100,000,000

.. = 104,719,666

 

This is simply wrong. 22/7 does not equate 3.14159, for some reason you seem to have replaced it with a 6 decimal approximation of Pi.

 

2nd version:: given X: return 22/(7 * X) * 100,000,000

X=3 .. = 22 / 7*3 = 22/21 = 1.04761904 * 100,000,000

.. = 104,761,904

 

This calculation is correct, and again it gives you a very bad answer, because you want to be using a more accurate approx of Pi than 22/7.

[the tree]

I think we're all focussing a bit too much on Khaled's terrible choice of approximation. There is a valid point to be found in the fact that given finite precision, the accuracy of a calculation does depend on the way that calculation is performed as well as the inputs themselves.

[hobz]

I think we're all focussing a bit too much on Khaled's terrible choice of approximation. There is a valid point to be found in the fact that given finite precision, the accuracy of a calculation does depend on the way that calculation is performed as well as the inputs themselves.

 

So the point is, if you can come up with an approximation that is accurate down to the precision of the computer, then it would be worth examining whether one calculation method would perform better than another.

[the tree]

Very much so.

 

Say you needed to calculate x(y-z) or xy-xz, then one method will give a more accurate answer than the other, especially if y and z are close by.

 

With x=1.111, y=1.533, z=1.521, and a given accuracy of 4 significant figures for every FLOP (yeah okay that's a little contrived, but anyway) then you'll get relative errors of about 0.02% and 2.5% respectively. One of many rules of thumb is to avoid subtracting numbers that are close by, as that always results in a significant loss of accuracy.

[hobz]

The opposite could result in overflow, if y and z are sufficiently far apart, and x is large enough.

I wonder if these rules of thumb are summarized somewhere?