What is considered an "advanced" topic in Python?

Gene Heskett gheskett at wdtv.com
Mon Jun 1 23:30:36 EDT 2015



On Monday 01 June 2015 20:33:50 Dennis Lee Bieber wrote:
> On Mon, 1 Jun 2015 09:49:35 -0400, Gene Heskett <gheskett at 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
>     wlfraed at 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>



More information about the Python-list mailing list