В сообщении от Понедельник 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 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. 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 > > 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. 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 (COBOL-like) > 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
