# st: Re: binary-decimal precision

 From "Michael Blasnik" To Subject st: Re: binary-decimal precision Date Wed, 2 Feb 2005 17:59:29 -0500

You may want to make more frequent use of the float() function.

mod(float(0.3),float(0.1))

comes a lot closer to 0.

I do agree that it's far too easy to make a mistake than it ought to be, especially with functions such as mod and int. I would guess that internal changes to the default behavior of certain functions that are most likely to have problems may solve a lot more problems than they create.

Michael Blasnik
michael.blasnik@verizon.net

----- Original Message ----- From: "Chris Ruebeck" <ruebeckc@lafayette.edu>
To: <statalist@hsphsun2.harvard.edu>
Sent: Wednesday, February 02, 2005 3:28 PM
Subject: st: binary-decimal precision

<snip>
But I would like to understand the issue better. So, taking the
example in the last link to heart, I fired up Excel and entered
=mod(0.3,0.1) to find that Excel does not answer 0 either, but instead
-2.77556E-17. Yet this is much closer to zero than the 0.1 result that
Stata provides when told to -display mod(0.3,0.1)-. Note that -di
%21.18f mod(.3,.1)- produces 0.099999999999999978, which is still quite
far from zero (and leads to a standard output rounded to 0.1). Note,
too, that it seems a ROUND function might more consistently solve the
issue in Excel than in Stata. I leave it to others to draw potential
connections between Excel's treatment and the string solutions in
Stata.

It's certainly possible that there is a mistake in my analysis, I don't
mean that Excel should be our benchmark for statistics, and I apologize
for continuing to beat this old horse.

Chris

*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/