update: can you pass the SRFI-56 challenge? Alex Shinn (16 Aug 2005 03:06 UTC)
Re: update: can you pass the SRFI-56 challenge? Shiro Kawai (16 Aug 2005 06:20 UTC)
Re: update: can you pass the SRFI-56 challenge? Alex Shinn (17 Aug 2005 05:27 UTC)
Re: update: can you pass the SRFI-56 challenge? David Van Horn (16 Aug 2005 17:58 UTC)
Re: update: can you pass the SRFI-56 challenge? Matthias Radestock (18 Aug 2005 17:23 UTC)
Re: update: can you pass the SRFI-56 challenge? Alex Shinn (18 Aug 2005 23:27 UTC)
Re: update: can you pass the SRFI-56 challenge? Matthias Radestock (19 Aug 2005 07:25 UTC)

Re: update: can you pass the SRFI-56 challenge? Matthias Radestock 18 Aug 2005 17:23 UTC

Alex Shinn <xxxxxx@synthcode.com> writes:

> Implementations which can't complete the test suite:
> ...
> SISC 1.11.2: passes most until mid-float32 then hangs

Problem #1:

SISC comes with three different floating point implementations: single
precision, double precision and arbitrary precision. The default shipped
with the binary releases is the latter. For that type of floating point
number there are two configuration parameters controlling the
precision. See
  http://sisc.sourceforge.net/manual/html/ch02.html#config-parameters
for details. Unfortunately their default values actually result in quite
a low precision. Changing maxFloatPrecision to a much higher value, such
as 1000, is required for the tests to pass.

Problem #2:

SISC's character i/o is unicode-based. That makes the byte i/o
operations in the reference implementation behave incorrectly. SISC does
support binary i/o, and it is necessary (and possible, but not as easy
as it should be) to implement these operations in terms of that.

Problem #3:

The implementation of expt in SISC was suffering from a premature loss
of precision. This is fixed in CVS and will be in the next release.

Problem #4:

The implementation of round in SISC was misbehaving in some boundary
cases. This is fixed in CVS and will be in the next release.

With the above changes, all tests pass when using the double precision
or arbitrary precision fp implementations. When using the single
precision implementation, all tests pass until SISC hangs in the double
precision tests, which is expected.

I should note that an actual implementation of srfi 56 in SISC will use
Java's native APIs for most of the operations.

Here's what changes we will make to SISC over the next few weeks in
order to facilitate implementation of srfi-56:
* change default arbitrary fp precision to a much higher value
* change default floating point implementation to double precision
* provide a more convenient API for byte-based I/O
* implementation of the finalised srfi-56 using Java APIs

Matthias