Thread: Geometry test on NetBSD (was Re: [HACKERS] RC1?)
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote:
>> Presumably that was put in because it was correct on i86. How do you
>> feel about changing that entry to
>> geometry/i.86-.*-netbsd=geometry-positive-zeros
>> rather than deleting it?
> I was under the impression until now that it was geometry.out for i86 using
> the libm387 math library, and geometry-positive-zeros for everyone else, but
> this acorn32 box is also giving geometry.out, so I must be wrong, in fact
> I've just tried not using libm387 on an i386, and it gives geometry.out
> too, so we might as well delete it...
Hm. Another possibility is that the existing resultmap entry is correct
for some prior netbsd version, but is correct no longer.
AFAIK, all modern hardware claims compliance to the IEEE floating-point
arithmetic standard, so failure to print minus zero as minus zero is
very likely to be a software issue not hardware. That suggests strongly
that the issue is netbsd version (specifically libc version) and not the
hardware platform.
If we knew which netbsd version the behavior changed at, we could put in
some version-specific resultmap entries. But unless someone can provide
datapoints on that, I guess we'll just have to update resultmap to match
recent versions --- ie, take out the entry pointing to
geometry-positive-zeros.
Any objections out there?
regards, tom lane
Tom, can you clarify why -0 is valid. Is it for _small_ near zero values that are indeed negative? --------------------------------------------------------------------------- Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote: > >> Presumably that was put in because it was correct on i86. How do you > >> feel about changing that entry to > >> geometry/i.86-.*-netbsd=geometry-positive-zeros > >> rather than deleting it? > > > I was under the impression until now that it was geometry.out for i86 using > > the libm387 math library, and geometry-positive-zeros for everyone else, but > > this acorn32 box is also giving geometry.out, so I must be wrong, in fact > > I've just tried not using libm387 on an i386, and it gives geometry.out > > too, so we might as well delete it... > > Hm. Another possibility is that the existing resultmap entry is correct > for some prior netbsd version, but is correct no longer. > > AFAIK, all modern hardware claims compliance to the IEEE floating-point > arithmetic standard, so failure to print minus zero as minus zero is > very likely to be a software issue not hardware. That suggests strongly > that the issue is netbsd version (specifically libc version) and not the > hardware platform. > > If we knew which netbsd version the behavior changed at, we could put in > some version-specific resultmap entries. But unless someone can provide > datapoints on that, I guess we'll just have to update resultmap to match > recent versions --- ie, take out the entry pointing to > geometry-positive-zeros. > > Any objections out there? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, can you clarify why -0 is valid.
The IEEE spec absolutely thinks that -0 and +0 are distinct entities.
I don't remember why, at one in the morning ... but if you insist I'm
sure that plenty sufficient numerical-analysis reasons can be produced.
The guys who wrote that spec knew what they were doing (that's why it's
been adopted so universally).
regards, tom lane
Tom Lane writes: > AFAIK, all modern hardware claims compliance to the IEEE floating-point > arithmetic standard, so failure to print minus zero as minus zero is > very likely to be a software issue not hardware. That suggests strongly > that the issue is netbsd version (specifically libc version) and not the > hardware platform. I could confirm my initial suspicion: it's a *printf() library issue. The FreeBSD CVS log tells the tale: http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in shame, but I would assume it's the same issue. Not sure what HP-UX is doing about it. -- Peter Eisentraut peter_e@gmx.net
At 1:15 AM -0500 11/20/02, Tom Lane wrote: >Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Tom, can you clarify why -0 is valid. > >The IEEE spec absolutely thinks that -0 and +0 are distinct entities. >I don't remember why, at one in the morning ... but if you insist I'm >sure that plenty sufficient numerical-analysis reasons can be produced. >The guys who wrote that spec knew what they were doing (that's why it's >been adopted so universally). It's so that 1/(1/-infinity) == -infinity. There are probably other reasons as well. I'm just guessing here, but it's possible NetBSD acquired the bug by trying to be functional on non-IEEE hardware. I hope that whoever found the problem (I don't see that in this thread) filed a bug report with NetBSD. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> Right, the equivalent for NetBSD vfprintf.c is:
> revision 1.40
> date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4
> Since we're returned the sign of a floating-point number by __dtoa(),
> use that to decide whether to include a minus sign in the result.
> Fixes printing -0.0, and thus PR lib/3137.
> NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42
Ah-hah, so it is a version issue --- we could make the resultmap line
something like
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros
Would you confirm what config.guess prints on your box --- in
particular, is there a dot in the version number?
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not
> fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in
> shame, but I would assume it's the same issue. Not sure what HP-UX is
> doing about it.
HP has evidently fixed it in HPUX 11. I do not think they intend to
change the behavior of HPUX 10 anymore, so the existing resultmap
entries for geometry/hppa seem okay.
regards, tom lane
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote:
>> Ah-hah, so it is a version issue --- we could make the resultmap line
>> something like
>> geometry/.*-netbsd1.[0-5]=geometry-positive-zeros
> NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1)
> NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1)
Hm, is that "elf" always there? I'm a little uncomfortable with making
the pattern be
geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros
as this seems way too lax ...
regards, tom lane
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> !!!! Just realised: the answers I gave above were with the config.guess from
> automake 1.7a!
> % uname -srmp
> NetBSD 1.6K acorn32 arm
> % postgresql-7.3rc1/config/config.guess
> acorn32-unknown-netbsd1.6K
> % automake/lib/config.guess
> arm-unknown-netbsdelf1.6K
Mph. Okay, I guess we'd better expend two patterns on this:
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros
geometry/.*-netbsdelf1.[0-5]=geometry-positive-zeros
Will make it so.
regards, tom lane
At 1:51 PM -0500 11/20/02, Tom Lane wrote: >Patrick Welche <prlw1@newn.cam.ac.uk> writes: >> On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: >>> Ah-hah, so it is a version issue --- we could make the resultmap line >>> something like >>> geometry/.*-netbsd1.[0-5]=geometry-positive-zeros > >> NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) >> NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) > >Hm, is that "elf" always there? I'm a little uncomfortable with making >the pattern be > geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros >as this seems way too lax ... A version like 1.6[A-Z] is a -current, not a release version from in between 1.5.x and 1.6. Different NetBSD ports have converted to elf at different times and not all ports are using elf even with 1.6 released. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Wed, Nov 20, 2002 at 06:48:15PM +0100, Peter Eisentraut wrote: > Tom Lane writes: > > > AFAIK, all modern hardware claims compliance to the IEEE floating-point > > arithmetic standard, so failure to print minus zero as minus zero is > > very likely to be a software issue not hardware. That suggests strongly > > that the issue is netbsd version (specifically libc version) and not the > > hardware platform. > > I could confirm my initial suspicion: it's a *printf() library issue. The > FreeBSD CVS log tells the tale: > > http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c > > The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not > fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in > shame, but I would assume it's the same issue. Not sure what HP-UX is > doing about it. Right, the equivalent for NetBSD vfprintf.c is: revision 1.40 date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4 Since we're returned the sign of a floating-point number by __dtoa(), use that to decide whether to include a minus sign in the result. Fixes printing -0.0, and thus PR lib/3137. NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Well spotted, Patrick
On Wed, Nov 20, 2002 at 01:51:28PM -0500, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: > >> Ah-hah, so it is a version issue --- we could make the resultmap line > >> something like > >> geometry/.*-netbsd1.[0-5]=geometry-positive-zeros > > > NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) > > NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) > > Hm, is that "elf" always there? I'm a little uncomfortable with making > the pattern be > geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros > as this seems way too lax ... "elf" won't always be there - that acorn32 is a case in point: it became elf for 1.6. acorn26 has always been elf. I can't remember when i386 became elf.. (In fact the old config.guess that comes with NeTraMet44b8 says i386-unknown-netbsd1.6K - so maybe the config.guess cvs log may shed some light) !!!! Just realised: the answers I gave above were with the config.guess from automake 1.7a! % uname -srmp NetBSD 1.6K acorn32 arm % postgresql-7.3rc1/config/config.guess acorn32-unknown-netbsd1.6K % automake/lib/config.guess arm-unknown-netbsdelf1.6K Confusing.. Patrick
On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: ... > > NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 > > Ah-hah, so it is a version issue --- we could make the resultmap line > something like > geometry/.*-netbsd1.[0-5]=geometry-positive-zeros > > Would you confirm what config.guess prints on your box --- in > particular, is there a dot in the version number? Yes: NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) (several NetBSDs probably come up with arm-unknown..) Cheers, Patrick
Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > Tom, can you clarify why -0 is valid. Is it for _small_ near zero > values that are indeed negative? > "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit" W. Kahan; ch. 7 in _The State of the Art in Numerical Analysis_ ed. by M. Powell and A. Iserles 1987 Oxford. Explains how proper respect for -0 eases implementation of conformal maps of slitted domains arising in studies of flows around obstacles. Kahan was one of the most important people behind the floating point standard and won the 1989 Turing Award for his work in numerical computing. http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html