Re: Why do some math functions return -0

[KHMan <keinhong@...>]

On 9/20/2010 10:07 PM, Mike McGonagle wrote:
> On Mon, Sep 20, 2010 at 9:35 AM, KHMan wrote:
> > In libm, the software implementation of floor() seems normal enough. Looking
> > at i387 assembly code in libm, the rounding mode is indeed changed, but it
> > is restored, pretty standard stuff -- no one in the right mind would have
> > left it as changed.
> >
> > Since there is nothing amiss on Tony Finch's Mac OS version of Lua, I don't
> > think Mac OS or FreeBSD developers would have missed such a simple thing.
> >
> > I guess that the 'something' is likely to be found in additional libraries
> > or code that the OP is using, like a heavy maths library that can have its
> > floating point modes adjusted and assumes that it is king of its
> > environment.
>
> I don't think this could be it, as I don't have anything other than
> the base install for 5.1.4 running. I can only assume that this might
> stem from how the G4 (an IBM chip) as opposed to the Intel that the
> Mac now uses.

Thanks for the update, it is appreciated.

Mac_OSX_Numerics.pdf in the PowerPC section say the default is 
round-to-nearest. The rounding mode can be checked using 
fegetround() -- if it's round to -INF, then I suppose it would 
support the current hypothesis. Hard to see anything else whilst 
doing normal arithmetic would produce a -0.0 other than the change 
of rounding mode.

On PPC floor(), from:
http://www.opensource.apple.com/source/Libm/Libm-315/Source/PowerPC/ceilfloor.c
it does not look like floor() is going to change any of the 
processor's rounding flags. There is no native floor() but only a 
faster version in math.h in the same source tree.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia