From csr21 at cam.ac.uk  Tue Jun  8 13:06:29 2004
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 08 Jun 2004 14:06:29 +0100
Subject: [ieeefp-tests-devel] test (and welcome) take 5
Message-ID: <sqzn7e2o8a.fsf@cam.ac.uk>

Hello,

Feel free to check stuff in to cvs.  This mail is more of a test than
anything else.

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



From toy at rtp.ericsson.se  Tue Jun  8 17:51:21 2004
From: toy at rtp.ericsson.se (Raymond Toy)
Date: Tue, 08 Jun 2004 13:51:21 -0400
Subject: [ieeefp-tests-devel] Symbolic printing of well-known values
Message-ID: <sxd7jui3ply.fsf@edgedsp4.rtp.ericsson.se>


Here is a patch that replaces some of the numbers in the tests with
symbolic values so that it's easier to see what the tests are trying
to do.

I'm sure not all the well-known values have been converted, but this
is a start.

Ray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ieeefp-consts.diff
Type: text/x-patch
Size: 3890 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ieeefp-tests-devel/attachments/20040608/c2252459/attachment.bin>

From csr21 at cam.ac.uk  Tue Jun  8 20:05:10 2004
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 08 Jun 2004 21:05:10 +0100
Subject: [ieeefp-tests-devel] Symbolic printing of well-known values
In-Reply-To: <sxd7jui3ply.fsf@edgedsp4.rtp.ericsson.se> (Raymond Toy's
	message of "Tue, 08 Jun 2004 13:51:21 -0400")
References: <sxd7jui3ply.fsf@edgedsp4.rtp.ericsson.se>
Message-ID: <sqk6yhke89.fsf@cam.ac.uk>

Raymond Toy <toy at rtp.ericsson.se> writes:

> Here is a patch that replaces some of the numbers in the tests with
> symbolic values so that it's easier to see what the tests are trying
> to do.

I've got no objections to this (and indeed would encourage people,
while we're in the exploration and development phase of this project,
to make speculative commits without worrying too much.  I will scream
if you break stuff, but hey -- don't let that stop you ;-).

In the long term, I enviseage that this mechanism would be replaced by
two things: firstly, that the tests would be preceded by an
automatically generated comment (or would contain a docstring)
describing the test: maybe something like "(atanh 0.5d0) => f00d0" as
a quick summary, with obvious Inf and NaN notation; secondly that the
tests be automatically annotated with such notes (in the
Dietz-style-RT sense) as :argument-is-nan, :result-is-inf,
:rounding-mode-nonnearest, and so on, so that implementations which
aren't fully IEEE compliant can ignore those tests with notes
corresponding to unimplemented (or unimplementable) features.

(one other thing to bear in mind: my suspicion is that the act of
wanting to test ieee features will lead to a pseudo-compatibility
library for ieee functionality, living in ieee754-fooimpl.lisp; with
luck, we'll be able to find a nonhorrible API that can be written up
and submitted to whatever standardization body still exists by the
time we get there :-)

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



From toy at rtp.ericsson.se  Tue Jun  8 20:40:32 2004
From: toy at rtp.ericsson.se (Raymond Toy)
Date: Tue, 08 Jun 2004 16:40:32 -0400
Subject: [ieeefp-tests-devel] Symbolic printing of well-known values
In-Reply-To: <sqk6yhke89.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Tue, 08 Jun 2004 21:05:10 +0100")
References: <sxd7jui3ply.fsf@edgedsp4.rtp.ericsson.se>
	<sqk6yhke89.fsf@cam.ac.uk>
Message-ID: <sxd3c554wcf.fsf@edgedsp4.rtp.ericsson.se>

>>>>> "Christophe" == Christophe Rhodes <csr21 at cam.ac.uk> writes:

    Christophe> In the long term, I enviseage that this mechanism would be replaced by
    Christophe> two things: firstly, that the tests would be preceded by an
    Christophe> automatically generated comment (or would contain a docstring)
    Christophe> describing the test: maybe something like "(atanh 0.5d0) => f00d0" as
    Christophe> a quick summary, with obvious Inf and NaN notation; secondly that the

I agree.  This is important.  I think the constants should still
remain since it still makes it easier to read the test.

    Christophe> (one other thing to bear in mind: my suspicion is that the act of
    Christophe> wanting to test ieee features will lead to a pseudo-compatibility
    Christophe> library for ieee functionality, living in ieee754-fooimpl.lisp; with
    Christophe> luck, we'll be able to find a nonhorrible API that can be written up

I'm more willing to blame the libm vendor and/or chip for problems.
I'm not really keen on implementing a compliant cosh implementation,
for example.

Ray




From csr21 at cam.ac.uk  Tue Jun  8 20:59:30 2004
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 08 Jun 2004 21:59:30 +0100
Subject: [ieeefp-tests-devel] Symbolic printing of well-known values
In-Reply-To: <sxd3c554wcf.fsf@edgedsp4.rtp.ericsson.se> (Raymond Toy's
	message of "Tue, 08 Jun 2004 16:40:32 -0400")
References: <sxd7jui3ply.fsf@edgedsp4.rtp.ericsson.se>
	<sqk6yhke89.fsf@cam.ac.uk> <sxd3c554wcf.fsf@edgedsp4.rtp.ericsson.se>
Message-ID: <sqfz95kbpp.fsf@cam.ac.uk>

Raymond Toy <toy at rtp.ericsson.se> writes:

> > (one other thing to bear in mind: my suspicion is that the act of
> > wanting to test ieee features will lead to a pseudo-compatibility
> > library for ieee functionality, living in ieee754-fooimpl.lisp; with
> > luck, we'll be able to find a nonhorrible API that can be written up
>
> I'm more willing to blame the libm vendor and/or chip for problems.
> I'm not really keen on implementing a compliant cosh implementation,
> for example.

Ah, sorry, that's not what I meant.  I meant tools such as for
inspecting the accrued exceptions, setting the rounding mode,
examining the operands of a trapping instruction, getting the
sign/mantissa/exponent of a float, examining the nonsignificant bits
of a NaN, unordered comparison operations, and so on.  Operations that
are specified in ieee754 as "would be nice".

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



From toy at rtp.ericsson.se  Tue Jun  8 21:12:00 2004
From: toy at rtp.ericsson.se (Raymond Toy)
Date: Tue, 08 Jun 2004 17:12:00 -0400
Subject: [ieeefp-tests-devel] Symbolic printing of well-known values
In-Reply-To: <sqfz95kbpp.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Tue, 08 Jun 2004 21:59:30 +0100")
References: <sxd7jui3ply.fsf@edgedsp4.rtp.ericsson.se>
	<sqk6yhke89.fsf@cam.ac.uk> <sxd3c554wcf.fsf@edgedsp4.rtp.ericsson.se>
	<sqfz95kbpp.fsf@cam.ac.uk>
Message-ID: <sxdy8mx3gbj.fsf@edgedsp4.rtp.ericsson.se>

>>>>> "Christophe" == Christophe Rhodes <csr21 at cam.ac.uk> writes:

    Christophe> Raymond Toy <toy at rtp.ericsson.se> writes:
    >> > (one other thing to bear in mind: my suspicion is that the act of
    >> > wanting to test ieee features will lead to a pseudo-compatibility
    >> > library for ieee functionality, living in ieee754-fooimpl.lisp; with
    >> > luck, we'll be able to find a nonhorrible API that can be written up
    >> 
    >> I'm more willing to blame the libm vendor and/or chip for problems.
    >> I'm not really keen on implementing a compliant cosh implementation,
    >> for example.

    Christophe> Ah, sorry, that's not what I meant.  I meant tools such as for
    Christophe> inspecting the accrued exceptions, setting the rounding mode,
    Christophe> examining the operands of a trapping instruction, getting the
    Christophe> sign/mantissa/exponent of a float, examining the nonsignificant bits
    Christophe> of a NaN, unordered comparison operations, and so on.  Operations that
    Christophe> are specified in ieee754 as "would be nice".

Oh, that's much better.  This is more interesting and more useful.

I guess the first order of business is to implement nextafter, which I
don't think any Lisp has implemented.

Ray




From toy at rtp.ericsson.se  Tue Jun  8 21:15:33 2004
From: toy at rtp.ericsson.se (Raymond Toy)
Date: Tue, 08 Jun 2004 17:15:33 -0400
Subject: [ieeefp-tests-devel] C results
Message-ID: <sxdu0xl3g5m.fsf@edgedsp4.rtp.ericsson.se>


Apologies for the long post.

I decided it would be useful to see how the C version of the
ieeefp-tests works.  I've appended the double-float output file
generated via GCC on a sparc/solaris8 box.

There are some surprises there.  CMUCL/sparc has failures on cosh and
sin.  The C version shows no such errors, but does shows errors on
atan2, which doesn't happen on CMUCL/sparc.  

More study needed, I think.

Ray

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: clib_DP.output
URL: <https://mailman.common-lisp.net/pipermail/ieeefp-tests-devel/attachments/20040608/e552a6d5/attachment.ksh>

From csr21 at cam.ac.uk  Tue Jun  8 21:24:36 2004
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 08 Jun 2004 22:24:36 +0100
Subject: [ieeefp-tests-devel] C results
In-Reply-To: <sxdu0xl3g5m.fsf@edgedsp4.rtp.ericsson.se> (Raymond Toy's
	message of "Tue, 08 Jun 2004 17:15:33 -0400")
References: <sxdu0xl3g5m.fsf@edgedsp4.rtp.ericsson.se>
Message-ID: <sqbrjtkajv.fsf@cam.ac.uk>

Raymond Toy <toy at rtp.ericsson.se> writes:

> There are some surprises there.  CMUCL/sparc has failures on cosh and
> sin.  The C version shows no such errors, but does shows errors on
> atan2, which doesn't happen on CMUCL/sparc.  

atan2 is currently untested in lisp, I think.

> More study needed, I think.

Definitely :-)

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



From toy at rtp.ericsson.se  Thu Jun 10 17:16:56 2004
From: toy at rtp.ericsson.se (Raymond Toy)
Date: Thu, 10 Jun 2004 13:16:56 -0400
Subject: [ieeefp-tests-devel] C results
In-Reply-To: <sxdu0xl3g5m.fsf@edgedsp4.rtp.ericsson.se> (Raymond Toy's
	message of "Tue, 08 Jun 2004 17:15:33 -0400")
References: <sxdu0xl3g5m.fsf@edgedsp4.rtp.ericsson.se>
Message-ID: <sxdfz931gfr.fsf@edgedsp4.rtp.ericsson.se>

>>>>> "Raymond" == Raymond Toy <toy at rtp.ericsson.se> writes:

    Raymond> Apologies for the long post.

    Raymond> I decided it would be useful to see how the C version of the
    Raymond> ieeefp-tests works.  I've appended the double-float output file
    Raymond> generated via GCC on a sparc/solaris8 box.

[snip]

    Raymond> Total   68 tests:  pass   68,  flags err    0,  value err   0,     coshd

So all coshd tests pass.  But the Lisp version says not.  In
particular double-cosh-value.10 fails.  The expected result is
most-positive-double-float, but we return infinity.  Calling
kernel:%cosh returns infinity too.

A simple C test program for sparc confirms that cosh does indeed
return infinity.  So either the C test is messed up or my simple test
is.

Aargh.

Ray

#include <stdio.h>
#include <math.h>
#include <ieeefp.h>

union dnum 
{
  long words[2];
  double fl;
};

int
main()
{
  union dnum x;
  union dnum y;
  
  x.words[0] = 0xC08633CE;
  x.words[1] = 0x8FB9F87E;

  printf("x = %lg\n", x.fl);

  fpsetround(FP_RM);
  
  y.fl = cosh(x.fl);

  printf("y = 0x%08lx%08lx = %lg\n", y.words[0], y.words[1], y.fl);

  return 0;
}

Output:

x = -710.476
y = 0x7ff0000000000000 = Inf




From csr21 at cam.ac.uk  Tue Jun 15 22:50:02 2004
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 15 Jun 2004 23:50:02 +0100
Subject: [ieeefp-tests-devel] Re: [ieeefp-tests-cvs] CVS update:
	ieeefp-tests/ieeefp-tests.lisp
In-Reply-To: <E1BaML3-0004yv-00@common-lisp.net> (Raymond Toy's message of
	"Tue, 15 Jun 2004 15:23:29 -0700")
References: <E1BaML3-0004yv-00@common-lisp.net>
Message-ID: <sqwu2877xh.fsf@cam.ac.uk>

Raymond Toy <rtoy at common-lisp.net> writes:

> o Add support for hypot.  This is used to test Lisp's ABS function on
>   complex values.

Cool.  I have ucblib-style input files for trunc()/FTRUNCATE in single
and double precision.  Do you think they should go into ucb/ucblib/,
or should we treat that as pristine and place additions somewhere
else?

Having trunc(), we are most of the way towards getting input files for
rint(), which is basically ceil() in rounding mode p, floor() in
rounding mode m, trunc() in rounding mode z; it's only complicated in
rounding mode n.

There does remain a point for discussion, though: what Lisp function,
if any, corresponds to rint()?  The natural choice would be FROUND,
but a case could be made for FROUND to be round-to-nearest always much
as FTRUNCATE is round-to-zero always.

Perhaps this allows me to bring up a couple of ideas for things which
should live in the IEEE754 package?  Ideas:
  * specialised condition types: IEEE754:DIVISION-BY-ZERO and
    friends.  The standard document says that it would be nice for
    programs to be able to find the faulting instruction and the
    operands from the handler; it would be nice to attempt to support
    this, at least for the IEEE-specified operations (+, -, *, /, sqrt
    and round-to-integer);

  * functions to get at the individual bits in the fields:
    IEEE:DOUBLE-FLOAT-EXPONENT and friends.  (I'm aware that the
    exponent field is biased; that makes design interesting)

  * (maybe) implementations of functions which don't have any
    corresponding analogue in CL: IEEE754:LOG10?  IEEE754:HYPOT?
    Maybe inspiration could be drawn from the C99 and C0X standards in
    this regard.

Anything else?

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



From toy at rtp.ericsson.se  Tue Jun 15 23:14:23 2004
From: toy at rtp.ericsson.se (Raymond Toy)
Date: Tue, 15 Jun 2004 19:14:23 -0400
Subject: [ieeefp-tests-devel] Re: [ieeefp-tests-cvs] CVS update:
	ieeefp-tests/ieeefp-tests.lisp
In-Reply-To: <sqwu2877xh.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Tue, 15 Jun 2004 23:50:02 +0100")
References: <E1BaML3-0004yv-00@common-lisp.net> <sqwu2877xh.fsf@cam.ac.uk>
Message-ID: <sxdwu28wh0w.fsf@edgedsp4.rtp.ericsson.se>

>>>>> "Christophe" == Christophe Rhodes <csr21 at cam.ac.uk> writes:

    Christophe> Raymond Toy <rtoy at common-lisp.net> writes:
    >> o Add support for hypot.  This is used to test Lisp's ABS function on
    >> complex values.

    Christophe> Cool.  I have ucblib-style input files for trunc()/FTRUNCATE in single
    Christophe> and double precision.  Do you think they should go into ucb/ucblib/,
    Christophe> or should we treat that as pristine and place additions somewhere
    Christophe> else?

My preference is to keep ucblib pristine.  But if you don't that's ok.

    Christophe> Perhaps this allows me to bring up a couple of ideas for things which
    Christophe> should live in the IEEE754 package?  Ideas:
    Christophe>   * specialised condition types: IEEE754:DIVISION-BY-ZERO and
    Christophe>     friends.  The standard document says that it would be nice for
    Christophe>     programs to be able to find the faulting instruction and the
    Christophe>     operands from the handler; it would be nice to attempt to support
    Christophe>     this, at least for the IEEE-specified operations (+, -, *, /, sqrt
    Christophe>     and round-to-integer);

This is a good idea.  CMUCL/sparc already supports this, I think, but
doesn't give the address of the faulting instruction, although it
could.

It's a problem with x86 since the exceptions happen at the NEXT FP
instruction, so the operands could have been destroyed before then.  I
think I tried to implement this for x86 long ago, but it didn't seem
to work very well for some reason that I can't recall.

    Christophe>   * functions to get at the individual bits in the fields:
    Christophe>     IEEE:DOUBLE-FLOAT-EXPONENT and friends.  (I'm aware that the
    Christophe>     exponent field is biased; that makes design interesting)

Provide both, perhaps?  I note that cmucl's idea of the bias value is
off by one from the bias value I see in most documents about IEEE754.

    Christophe>   * (maybe) implementations of functions which don't have any
    Christophe>     corresponding analogue in CL: IEEE754:LOG10?  IEEE754:HYPOT?
    Christophe>     Maybe inspiration could be drawn from the C99 and C0X standards in
    Christophe>     this regard.

Yes.  From a peek at glibc's log10, it looks reasonably
straight-forward.  I think hypot could be done using complex-sqrt
that's already in cmucl/sbcl.  At least the hypot tests all pass, and
we use complex-sqrt for abs of a complex number.

Should we provide for nextafter and copysign?  Well, copysign is the
same as Lisp's float-sign, with the args in the opposite order.
There's also scalb (basically scale-float) and log2.  We should
provide those as well, I guess.

Ray