Re: [f-cpu] Re: Floating-Point?

[Patrick Pelgrims <patrick.pelgrims@pandora.be>]

Yann Guidon wrote:
> 
> hi,
> 
> just a quick answer.
> 
> Juergen Goeritz wrote:
> >
> > On Fri, 17 Aug 2001, Hans Summers wrote:
> > > Could someone explain to me why 128-bit FP is desireable? I am struggling
> > > here to think of an application which needs 30 decimal places of precision
> > > (or whatever it is). In fact I'd go as far as to suggest that in most cases
> > > 32-bit FP would be sufficient. Chip designers tend to dream of having a
> > > 128-bit or 256-bit processor etc., but without reference to the real world
> > > which doesn't need (actually can't make good use of) such high precision FP.
> > > Expanding the word size won't deliver a performance enhancement. My belief
> > > is the only way such large word sizes make any kind of sense is in the
> > > contect of SIMD, where the large word size is effectively a parrelisation.
> >
> > Ah, I have the same opinion about this theme. You don't really
> > need a higher precision than 64 bit. Maybe that will change for
> > galaxy navigation in the future but until now 32 bit are good
> > (and fast) for most cases. I would rather implement some 32 bit
> > pipelined floating point instructions than go for a dedicated
> > fpu anyway... ;-)
> 
> 32 bits is fine as long as
>  - your algorithm is correctly designed so numerical stability is ensured "by design"
>  - the precision of the measuraments is below the precision of the number
> 
> 64 bit can look as an overkill in a lot of applications.
> however, high precision is required when
>  - your equation/algorithm creates values that are concentrated in
>    one small fraction of the precision (and you don't know where, so you can't
>    optimize the equation)
>  - your algorithm has to run millions of loops over the same data without
>    rounding artifacts.
>  - your algorithm is HIGHLY NON LINEAR and a meaningless rounding error
>    can result in completely false errors.
> 
> examples of things that are ok for 32 bits FP :
>  spectrum analysis, filtering...
>  (sound/image processing, machine control...)
> 
> examples of things that need 64 bits :
>  3-body (or more) interaction, nuclear physics...
> 
> I have once seen a picture of a 3-D representation of Lorenz's attractor,
> computed by different machines. even though most machines were (claimed) IEEE,
> there are differences. the CRAY diagram differed most (non-IEEE).
> so yes : numerical stability and precision are coupled.
Indeed. The person who has written a program to calculate the number PI
has found
some bugs in the IEEE calculation unit !! Mr. Cray was very amazed !
> 
> > JG
> 
> Ekkehard Morgenstern wrote:
> > > Ah, I have the same opinion about this theme. You don't really
> > > need a higher precision than 64 bit. Maybe that will change for
> > > galaxy navigation in the future but until now 32 bit are good
> > > (and fast) for most cases.
> >
> > Actually, floating-point is too imprecise for ANY precision calculation.
> > There are lots of numbers that can't be encoded into floating-point values.
> >
> > The bits in the mantissa are encoded as follows, for example:
> > - bit 0: 1/2: 0.5
> > - bit 1: 1/4: 0.25
> > - bit 2: 1/8: 0.125
> > - bit 3: 1/16: 0.0625
> >
> > and so on. By setting the bits, you're adding up the fractions.
> >
> > So, for example with financial computing, floating-point is a big no-no,
> > otherwise you end up with respresentation and rounding errors.
> >
> > Any precision computing does not use floating-point. BCD string arithmetic
> > (as known from COBOL and FORTRAN) is most commonly used for these
> > tasks.
> >
> > So, it doesn't really matter how precise the FP is, but the finer the
> > better,
> > of course. It would extend the number of applications for the CPU, since
> > sometimes it's desirable to sacrifice the precision for the sake of speed.
> >
> > On mainframes, there are AFAIK some applications that use custom code
> > to do as much arithmetic in integer or FP as possible, and that use
> > fixed-point
> > or BCD otherwise.
> >
> > 32, 64 and 80 bit floating-point are standard nowadays, so these should be
> > supported to avoid software emulation (preferrably IEEE standard
> > compliant).
> 
> concerning precision : some weeks ago, we discussed about an arbitrary
> precision computation package. if extreme acuracy is required, it is one
> way to go.
> 
> multi-precision computation (with int operations) should be no problem
> on F-CPU.
> 
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

-- 
Patrick Pelgrims 
Cellular: +32 478 98 45 35
Fax: +32 2 340 10 21
Home: +32 15 24 58 53
Work: +32 2 340 10 20
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/