[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: [Off-Topic] pcb grid improvements... status of patch?



On Wed, 13 Jul 2011 22:04:42 +0200
Gabriel Paubert <paubert@xxxxxxx> wrote:

> On Wed, Jul 13, 2011 at 11:27:48AM -0700, Colin D Bennett wrote:
> > On Wed, 13 Jul 2011 11:05:56 -0700
> > Colin D Bennett <colin@xxxxxxxxxxx> wrote:
> > 
> > > On Wed, 13 Jul 2011 19:55:02 +0200
> > > Gabriel Paubert <paubert@xxxxxxx> wrote:
> > > 
> > > > Great. As an astronomer, I really need to be able to define
> > > > my PCB in astronomical units and parsecs :-) 
> > > 
> > > You'll have to wait for 64-bit internal unit storage...
> > > (when metric internals [nm units] is implemented)
> > 
> > Correcting myself:
> > 2**64 nm â 0.123 AU
> > 2**128 nm â (2.3Ã10**18) AU
> > 
> > I guess 64-bit numbers won't do it for you!
> 
> The dynamic range of values you need for some modelling code
> in astronomy is, well, astronomical.
> 
> 25 years ago, I had to move some scientific code from an IBM 
> 370 mainframe to a VAX. The dynamic range of single and double 
> precision on the nefarious IBM hexadecimal floating point was 
> roughly 10^+/-76 (16^+/-64). The VAX could only reach 10^+/-38 
> (2^+/-128) in both single and double precision at the time (later 
> they added the so called G-float format with an 11 bit exponent 
> like IEEE). It turned out that I had to be very careful and scale
> several variables because otherwise I triggered overflows and 
> underflows on the VAX.
> 
> I must admit that I've never run into problems with IEEE double 
> precision (10^+/-308).

Dynamic range problems?  Maybe not.  However, I have problems even with
IEEE double precision floating point... due to the floating point
nature (which no number of bits thrown at it will completely fix).  The
biggest problem is that the absolute precision varies inversely with the
magnitude of the number. For instance, suppose you create a 1:1 3D
model of an atom, at the origin. Then you translate this atom into
outer space by simply adding a 3D vector to each point. Oops! The atom
has now been altered and potentially looks nothing like an atom anymore.
(The solution is to store translations separate from the model, rather
than altering the coordinates of each point in the model...)

Regards,
Colin


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user