kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sun, 26 Jun 2011, Dick Hollenbeck wrote:

> Wayne has pointed out that MS VC++ has no int64_t stuff and that there is a wx
> equivalent to assist poor little Microsoft.  Maybe we should simply define
> int64_t, if MS VC++, so we can use a int standard type rather than the wxInt64
> (or whatever it is).    Unnecessary allegience to wx over pure C++ seems

Isn't long long int in the new standard C(++) ? Or (as usual) MS decided
to do it its way? There should be a cmake incantation to detect it,
anyway...

As for the 'dynamic range' issue, working in nm with 32 bits give
a useful size of >2m (signed) so for variables it shouldn't be an issue.
Intermediate computation *could* overflow (for example when scaling
using the x*a/b instead of the x/b*a form to preserve precision).

Given kicad's use of coordinates I think this could only occur during
scaling in display (plotting is done in floating point IIRC) and
analytics (intersections, distances and so on) that are probably done in
FP for a number of reasons. Also remember that FP rounds only when: 1)
exceeding it's significant figures (which for the IEE754 double is about
15 places) and 2) when *dividing*; there is a common understatement: FP
doesn't necessarily round; it rounds only when there is a lack of
dynamic range when adding (so that some digit falls off the significant
range) and when dividing (because of some arithetic stuff saying that
some numbers can't be expressed in base-2 in aperiodic form).
Multiplication only rounds when the combined significant figures exceeds
the mantissa size (i.e. a 8-figures by an 8-figures would round). But
that's anyway better than a long int.

> From a performance view today long long ints are slower than doubles in
non-64bit architectures (given a modern FPU obviously), and their size
is the same. Also most (maybe all) of the math routines are double only.

Given that I work all the day with 8-/16- bit MCUs (and mostly in
assembly) I'd confirm that tracking fixed point precision during
computation is a moderate PITA :D I'd propose to use long ints for
general use and double for computation where it's needed. Troublesome
rounding cases should be decided on the spot (as usual when doing
numerics...)

PS: in the new standard the are multiple precision integers (COBOL-like)
but I fear they would be slow as hell:P

--
Lorenzo Marcantonio
Logos Srl