kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Apr 29, 2013 at 09:03:32PM +0200, Tomasz Wlostowski wrote:
> My 0.001 cent - It's much simpler: just don't use floating point.

That what's we try to do when possible, to avoid rounding issues and
have better numerical stability (more or less... I'd like that stability
would be achieved only with that!). However there are three important
things that need to be done in floating point:

- Squaring (not completely sure about this, correct me if I'm wrong),
  since it exceeds the int dynamic range

- Square roots: to find distances and other geometrical stuff. There are
  integer based square root algorithms (altough not in libm) but the
  operand is usually the sum of two squares so it doesn't fit an int
  (see point above). In fact I think the most used libm function (beside
  the trigs) is hypot.

- Trig stuff, for rotation, circles and similar things. Mostly sin/cos
  and some atan2, too (there is an ArcTangente which works from int
  values and returns the results in decidegrees; I'm trying to convert
  the code to use it when possible)

I think that circles created with cos/sin should be usually rounded (I
don't see any reason to do otherwise), and most distances should, too.
Squares are only used as temporary values so they don't give problems
(they stay double).

So, no, we can't not use a double here... in fact this whole review
comes from the angular type becoming a double (before it was an int).

Unless you have some magic/clever way to fit these in an int (I don't
dare to propose computing distances with a 64 bit integer square root.
I've got enough insults for doing this review in the first place :D)

Oh well I *could* (the hypot stuff, not the trig one) but then they
probably would reject that as some kind of heresy... (also I would need
to check the accuracy of such int64 sqrt, many are approximations
created for speeding up DSPs)

-- 
Lorenzo Marcantonio
Logos Srl