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

[Yann Guidon <whygee@f-cpu.org>]

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.

> 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/