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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
