Re: gEDA-user: 23.99mil instead of 24mil in PCB

[Karel Kulhavy <clock@xxxxxxxxxxxxx>]

On Sun, Apr 02, 2006 at 12:16:18PM -0400, DJ Delorie wrote:
> 
> > I set via size in GTK PCB 20060321 in signal style to 25, OK, then
> > opened again and set to 24. Then I made a via and Object Report says
> > it has 23.99mil.
> 
> This seems to be a bug in the GTK units conversion (it works in
> lesstif HID but fails in gtk HID).  Try changing src/hid/gtk/gui.h
> (src/gui.h in the old pcb) to use this definition of TO_PCB_UNITS:
> 
> #define TO_PCB_UNITS(v)         (Settings.grid_units_mm ? \
>                                 ((v) / 0.000254 + 0.5) : ((v) * 100.0 + 0.5))
> 
> Adding 0.5 after the conversion turns the "truncate" double->int
> conversion into a "round" conversion.  Since we're expecting whole
> numbers anyway, this has the effect of dealing with any off-by-epsilon
> bugs, which this appears to be.

This is still good. Once I hit a situation where

double a;
[...]
printf("%d\n",a);
printf("%d\n",a);

Yielded two different numbers (off by epsilon). After that I forgot
everything about logic I learned through my life and remained just
blankly staring into the wall.

Logic cannot be used to describe floating point numbers. We prove this by
contradiction. Let's suppose logic could be used to describe floating
point numbers. First we assume that the conversion algorithm from the
floating point number to the on-screen representation is deterministic,
this can be easily verified from the glibc source. From my experiment we
can then see that
a!=a
We also use an obvious tautology
a=a
and we got a contradiction. QED. [X]

Floating point numbers are like a remnant from the era of analog
computers with their ubiquitous noise - you write 1V into a sampling
amplifier and when you read once, you get 1V, second time you get 0.999V
etc.

I guess the name floating point numbers is derived from the fact that
the point on the number axis representing a variable value is constantly
moving up and down - like floating on a sea.

CL<
> 
> Also, by multiplying by 100 instead of dividing by 0.01, we may avoid
> other espilon bugs.