kicaddevelopers team mailing list archive

kicaddevelopers team

Mailing list archive

Message #06548
Re: Converting KiCAD to metric units: The approach
В сообщении от Понедельник 27 июня 2011 10:38:17 автор Lorenzo Marcantonio
написал:
> 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...
It seems so, MS ignores new standards. But anyway doing this portable is not
so difficult. Typedefs are great in this.
>
> 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
Result of integer division is exact in terms of integers. :P
> 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 base2 in aperiodic form).
> Multiplication only rounds when the combined significant figures exceeds
> the mantissa size (i.e. a 8figures by an 8figures would round). But
> that's anyway better than a long int.
Which "long int" you're speaking about? 32, 40, 64 bits wide or some another?
;)
Anyway rounding in FP is much harder to control than in fixed point.
Spontaneous rounding may cause DRC to fail someday without obvious reason.
Main reason I started working on metric scale is exact DRC matching.
>
> >From a performance view today long long ints are slower than doubles in
>
> non64bit architectures (given a modern FPU obviously), and their size
> is the same. Also most (maybe all) of the math routines are double only.
Computing technologies are heading towards 64 bit. :) And there are lots of
math routines in fixed point.
>
> 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
Oh that's not so problematic for those who familiar with. :)
> 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 (COBOLlike)
> but I fear they would be slow as hell:P
It's up to the compiler. :)

 KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61
Follow ups
References