Fraction vs Double

I have always wanted to have a set of astronomical software and have  
been busy programming it in some idle moments the last few days. I  
have been doing most of the calculations with rational values because  
I thought it would be more precise. I reserved Double for iterations  
because I thought it would be faster, and for trigonometrical  
calculations because the standard functions are not available to  
Fraction.

However today I made a Double version of one of my methods and found  
that it executed notably SLOWER than the Fraction version. I did have  
to add a few asRational´s to communicate with the Fraction methods,  
but I didn't think this would slow it down particularly, would it?

So now I am thinking of going all in for Fraction and even  
programming some trigonometrical functions myself. But since the  
system functions are primitives, they will perhaps be faster than  
anything I could come up with anyway, wouldn't they?

Perhaps a later version of the system ought to be considered for  
delivery with primitive Fraction trigonometrical functions?

LEF

Lars,

Note that asRational will not necessarily answer a fraction that
represents the true value of a floating point number.  An example of
this would be

0.85 asRational => 17/20

which, by the definition of floating point numbers in base 2, is
impossible.  I remember reading some documents that illustrated things
such as algorithms running slower on floats than on doubles because the
extra precision caused faster convergence.  Perhaps this is one of those
cases?

I find it very curious that fractions are faster than doubles.  Do you
have an example you can share?

Thanks,
Andres.


Lars Finsen wrote:

From: Lars Finsen [mailto:[hidden email]]
> However today I made a Double version of one of my methods and found  
> that it executed notably SLOWER than the Fraction version. I
> did have  
> to add a few asRational´s to communicate with the Fraction methods,  
> but I didn't think this would slow it down particularly, would it?

asRational is definitely something that can slow things down considerably.

That said, the real answer - as always - is to avoid premature optimization: write the code first with values in whatever form they are available in (e.g. read from some database as floats or integers), and use normal operations like division without worrying about whether it will answer a different type from its arguments. Since you're not dealing with financial information, or (I guess) needing to produce answers with a _specific_ accuracy, you probably don't need to worry too much about accuracy: choosing Double for your floating point input should suffice.

Only after the software is working, and has been found to be slow, should you worry about performance. The best way to improve performance is to correct the algorithms, not the types of values. If you are still left with performance problems, there's no need to guess - the most experienced programmers are the ones most ready to admit that their guesses about bottlenecks are often wrong. Instead, use the profilers in the AT Profiling UI parcel.

Over the lifetime of your application, the only things that can affect performance more than Moore's Law are the algorithms. The things that will affect how much benefit you gain from your application will probably not be its performance at a point in time, but its functionality and how well it can be adapted as you see new needs. To maximize functionality and the ability of the application to evolve, the most important factor is keep the code simple, small and readable.

...and this is me, preaching what I so often fail to practise!
Steve