On Monday 01 June 2015 20:33:50 Dennis Lee Bieber wrote: > On Mon, 1 Jun 2015 09:49:35 -0400, Gene Heskett <ghesk...@wdtv.com> > > declaimed the following: > >But IMO, any language that does not have the ability to set an fp > > number to a fixed number of digits to the right of the separator > > regardless of which , or . is used, needs one written. > > That removes all modern hardware units using IEEE floating point > standard, and pretty much all languages since (including) the first > version of FORTRAN. > > Floating point numbers are x-significant digits (commonly x:7 for > single precision and x:15 for double precision) with an exponent. > > Ada supports float and fixed point, but fixed point most easily > visualized as an integer with a scaling factor. > > >The ability to guarantee that the output of a FIX(2) is zero to at > > least 17 significant digits so that a zero coomparison is not > > non-zero because theres a 1 15 digits out in a 2 digit money format, > > is an absolute requirement. > > Use COBOL then... One used to have to go out of their way to get a > "floating point" data type in COBOL... The common numeric type is > packed BCD. > > Even M$ "money" datatype uses four decimal places even if only two > are displayed to the user -- it allows for accumulation of fractions > of a cent over time. > That is a far more restrictive interpretation than I had in mind. What, in the case of g-code should be the result of looking at a double and seeing that rounding errors in incrementing a number origially set to zero adding 1.000 to it 21 times, have created say 21.00000001200873000. Then we do a
while [number gt 0.000000] number=number - 1.0000000 do stuff using that number endwhile But the loop then iterates an extra pass, because the 1200873000 is still there. The numbers are all double's, but weren't initialized to a sufficient number of digits to the right of the . or , This is of course our own fault, caused by sloppy coding. But specifying the value to 15 magnitudes more than the machine is capable of without spending weeks writing a screw compensation file to get that level of accuracy is counterproductive. Its severe overkill IMO. Any language ought to just throw away those rounding errors by filling the extra precision with NNNNN.nnnn000000000000000's. even if the original initialized value was only stated as 1.00000. > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> -- https://mail.python.org/mailman/listinfo/python-list
