Re: IEEE Inf and NaN support for numbers.c

Re: IEEE Inf and NaN support for numbers.c

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> The following patch adds basic IEEE Inf and NaN support for guile.  This
> introduces two new predicates (inf? and nan?) and two new functions
> (inf and nan, which return IEEE Infinity and NaN values,
> respectively).

Nice, thanks.

>   guile> (/ 0)
>   Inf

This is not a good print syntax for the new "inf" value.  It looks
like a symbol, while it really is a number.  Likewise for "NaN".

What about using "1/0" for inf and "0/0" for NaN.  Does this fit with
the IEEE rules?

When this works, we don't need the 'inf' and 'nan' procedures.

Do we want to care about signalling versus quiet NaNs, and the extra
information in the mantissa of NaNs?  (I don't think so.)

Also, somewhat unrelated to your patch, Guile can not read the
(illegal) notation "#.#" that is produces for funny numbers.  It's
probably best to avoid outputting this notation altogether and just
find a way to cope with funny numbers more sanely.  (Like you just did
for infinity.)

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[John W. Eaton]

On 14-Mar-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
| 
| > The following patch adds basic IEEE Inf and NaN support for guile.  This
| > introduces two new predicates (inf? and nan?) and two new functions
| > (inf and nan, which return IEEE Infinity and NaN values,
| > respectively).
| 
| Nice, thanks.
| 
| >   guile> (/ 0)
| >   Inf
| 
| This is not a good print syntax for the new "inf" value.  It looks
| like a symbol, while it really is a number.  Likewise for "NaN".
| 
| What about using "1/0" for inf and "0/0" for NaN.  Does this fit with
| the IEEE rules?

I suppose it would work, but it is a bit misleading, because Inf and
NaN can be generated in ways other than just 1/0 and 0/0.

| When this works, we don't need the 'inf' and 'nan' procedures.

Sure, but perhaps it is nice to have a way to request a NaN or Inf
value without having to perform additional arithmetic operations?

Eventually, I'd like to be able to make it possible to control what
happens when Inf and NaN are generated.  For example, generate an
exception instead of simply continuing.  In that case, it might be
good to have another way to get at Inf and NaN without generating the
exception.

I'd also be happy to have these procedures only available if some
package/module/whatever is loaded, but I don't know how to do that
(yet).

| Do we want to care about signalling versus quiet NaNs, and the extra
| information in the mantissa of NaNs?  (I don't think so.)

Perhaps not yet, but it might be useful to have these things later.

| Also, somewhat unrelated to your patch, Guile can not read the
| (illegal) notation "#.#" that is produces for funny numbers.  It's
| probably best to avoid outputting this notation altogether and just
| find a way to cope with funny numbers more sanely.  (Like you just did
| for infinity.)

Right, I wasn't sure what to do with the #.# thing, so I tried to
leave it alone as much as possible.

BTW, would people object to reformatting numbers.c to follow the GNU
coding standards?

Thanks,

jwe

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Rob Browning]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> BTW, would people object to reformatting numbers.c to follow the GNU
> coding standards?

It wouldn't bother me, but I can't speak for everyone of course.

On a related note, I've been playing around here with replacing our
bignum support with gmp (and noticing some bugs that need fixing along
the way).  The integration seems fairly easy (I've converted a lot of
the code in an very experimental tree), but I was wondering if you had
any thoughts on that front.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> On a related note, I've been playing around here with replacing our
    Rob> bignum support with gmp (and noticing some bugs that need fixing along
    Rob> the way).  The integration seems fairly easy (I've converted a lot of
    Rob> the code in an very experimental tree), but I was wondering if you had
    Rob> any thoughts on that front.

Technical issues aside (where I don't know enough to comment), I
believe that using gmp has been the intended plan for a couple of
years.

There was a bit of a skirmish on the subject of mismatched licenses
(Guile vs. GMP), but I remember it turning out to be a non-issue.

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> | >   guile> (/ 0)
> | >   Inf
> | 
> | This is not a good print syntax for the new "inf" value.  It looks
> | like a symbol, while it really is a number.  Likewise for "NaN".
> | 
> | What about using "1/0" for inf and "0/0" for NaN.  Does this fit with
> | the IEEE rules?
> 
> I suppose it would work, but it is a bit misleading, because Inf and
> NaN can be generated in ways other than just 1/0 and 0/0.

Yes, it also touches on the issue of exactness. 1/0 would be an exact
infinity, while we can currently only produce inexact exceptional
values.  We would need to write #i1/0, which is not as elegant.

> | When this works, we don't need the 'inf' and 'nan' procedures.
> 
> Sure, but perhaps it is nice to have a way to request a NaN or Inf
> value without having to perform additional arithmetic operations?

The 1/0 construct would be specially recognized as meaning infinity.
In case you are not aware of it: x/y is Scheme syntax for literal
fractions.  (Guile does not have exact rationals, but it might in the
future.)  These fractions are 'evaluated' by the "read" function, not
as part of running the program.  The fraction "1/0" can be specially
recognized by "read" and converted to IEEE +infinity (just as "23" is
converted into the integer 23).

I'm only really concerned here about read/write consistency.  Say you
compute some list of numbers, write them to a file with "write", and
read them back in with "read".  The new list should contain the same
numbers, of course.  When you write something like

    (1 2 Inf 4)

and read this back in, you will get a list with two numbers, a symbol,
and another number.

Therefore, we need to find a way to represent infinity and the other
exceptional values that doesn't clash with the rest of Scheme syntax.

(I think you know all this, but I couldn't stop myself from exlaining
it anyway.)

The cleanest way that I can think of right now is to use the
hash-comma reader extension:

    #,(+inf)   #,(-inf)   #,(nan)   #,(nan 0.42345)  

Unfortunately, this mechanism is optional and currently only available
when (srfi srfi-10) has been loaded.  We would need to make it
mandatory, which is entirely reasonable, I'd say.

PLT Scheme uses

    +inf.0   -inf.0    +nan.0

which are not really numbers, syntaxwise, but I think its OK to make
this extension.  The PLT Scheme docs say specifically:

    The following are inexact numerical constants: +inf.0 (infinity),
    -inf.0 (negative infinity), +nan.0 (not a number), and -nan.0
    (same as +nan.0). These names can also be used within complex
    constants, as in -inf.0+inf.0i.

    The special inexact numbers +inf.0, -inf.0, and +nan.0 have no
    exact form. Dividing by an inexact zero returns +inf.0 or -inf.0,
    depending on the sign of the dividend. The infinities are
    integers, and they answer #t for both even? and odd?. The +nan.0
    value is not an integer and is not = to itself, but +nan.0 is eqv?
    to itself. Similarly, (= 0.0 -0.0) is #t, but (eqv? 0.0 -0.0) is
    #f.

Does this sound reasonable to you?  If yes, can you adapt your patch
accordingly?

> Eventually, I'd like to be able to make it possible to control what
> happens when Inf and NaN are generated.  For example, generate an
> exception instead of simply continuing.  In that case, it might be
> good to have another way to get at Inf and NaN without generating the
> exception.

Yes, there is no problem with having procedures that return Inf and
Nan, etc.  Sorry for giving the impression that I didn't want them.

> BTW, would people object to reformatting numbers.c to follow the GNU
> coding standards?

I wouldn't.  Please talk to Rob Browning <rlb@defaultvalue.org> before
doing this, however, since he's doing quite a rewrite of numbers
currently.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[John W. Eaton]

On 24-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:

| The cleanest way that I can think of right now is to use the
| hash-comma reader extension:
| 
|     #,(+inf)   #,(-inf)   #,(nan)   #,(nan 0.42345)  

I'm afraid I don't understand what

  #,(nan 0.42345)

means.

It is easy enough to fix the patch so that it will write out these
values any way you like.  But I don't know enough about guile to know
what to modify to make it read these forms.

| > BTW, would people object to reformatting numbers.c to follow the GNU
| > coding standards?
| 
| I wouldn't.  Please talk to Rob Browning <rlb@defaultvalue.org> before
| doing this, however, since he's doing quite a rewrite of numbers
| currently.

I think Rob already said it was OK with him.  I haven't heard from
anyone else.  Choosing an appropriate time to do it so that we don't
cause unnecessary trouble for anyone who might be working on numbers.c
is the the hard part, I think.

jwe

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> On 24-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:
> 
> | The cleanest way that I can think of right now is to use the
> | hash-comma reader extension:
> | 
> |     #,(+inf)   #,(-inf)   #,(nan)   #,(nan 0.42345)  
> 
> I'm afraid I don't understand what
> 
>   #,(nan 0.42345)
> 
> means.

That was meant to represent a NaN with additional information.  As far
as I know, there are some unused bits in the mantissa of a IEEE NaN
that can be used to further characterize the NaN.  I don't know of any
application of them, tho.

> It is easy enough to fix the patch so that it will write out these
> values any way you like.  But I don't know enough about guile to know
> what to modify to make it read these forms.

Ok.  I think we should follow PLT Scheme here.  I will apply your
patch and make the necessary changes.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Ok.  I think we should follow PLT Scheme here.  I will apply your
> patch and make the necessary changes.

Done.  Please play with it and tell me whether you like the changes I
made.

	numbers.c (mem2ureal): Recognize "inf.0" and "nan.xxx".
	(scm_even_p, scm_odd_p): Treat infinity as even and odd.
	(iflo2str): Don't output a '+' for negative numbers or for Inf and
	NaN.  They will provide their own sign.
	(scm_divide): Only allow divides by inexact zeros.  Dividing by
	exact zeros still signals an errors.

Here is the NEWS entry:

    ** There is support for Infinity and NaNs.

    Following PLT Scheme, Guile can now work with infinite numbers and
    'not-a-numbers'.

    There is new syntax for numbers: "+inf.0" (infinity), "-inf.0"
    (negative infinity), "+nan.0" (not-a-number), and "-nan.0" (same as
    "+nan.0").  These numbers are inexact and have no exact counterpart.

    Dividing by an inexact zero returns +inf.0 or -inf.0, depending on the
    sign of the dividend.  The infinities are integers, and they answer #t
    for both 'even?' and 'odd?'. The +nan.0 value is not an integer and is
    not '=' to itself, but '+nan.0' is 'eqv?' to itself.

    For example

        (/ 1 0.0)
        => +inf.0

        (/ 0 0.0)
        => +nan.0

        (/ 0)
        ERROR: Numerical overflow

PLT Scheme does also distinguish plus and minus zero:

    (= 0.0 -0.0)
    => #t

but

    (eqv? 0.0 -0.0)
    => #f

I think we should do this as well.  John, how would one test for the
sign of zero?

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[John W. Eaton]

On  7-May-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:

| Marius Vollmer <mvo@zagadka.ping.de> writes:
| 
| > Ok.  I think we should follow PLT Scheme here.  I will apply your
| > patch and make the necessary changes.
| 
| Done.  Please play with it and tell me whether you like the changes I
| made.

Sorry for the delay.  Now I have some time to play with it, but I
can't seem to make guile from CVS now.  I tried updating recently and
had some trouble.  I was busy so I gave up.  Now that I have time, I
tried again by checking out a fresh copy using the commands from
savannah:

  cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/guile login
  cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/guile co guile

This gives me lots of stuff, but I immediately ran into the following
problem when I went to the guile-core directory and tried to run
autogen.sh:

  segfault:276> ./autogen.sh 
  ./autogen.sh: /home/jwe/src/guile/workbook/../scripts/render-bugs: No such file or directory

For now at least, I don't care about having an up to date BUGS file,
so I commented out the command in autogen.sh that runs render-bugs.
That lets me get a little farther, but I still see the following
problem:

  segfault:278> ./autogen.sh 
  aclocal: guile-config/guile.m4: 108: duplicated macro `GUILE_FLAGS'

What am I missing?  I'm on a reasonably current Debian testing system
and have

  ii  autoconf     2.53-2         automatic configure script builder
  ii  automake     1.4-p4-1.1     A tool for generating GNU Standards-complian

Any clues would be most appreciated.

Thanks,

jwe

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> Any clues would be most appreciated.

Please try a "unstable" snapshot from

  ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshots/guile-core.unstable.tar.gz

It is a traditional configure/make tarball, no autmagic involved.

I will look into the problems you have reported.  Sorry for your
inconvenience.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: IEEE Inf and NaN support for numbers.c

[Rob Browning]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> I think Rob already said it was OK with him.  I haven't heard from
> anyone else.  Choosing an appropriate time to do it so that we don't
> cause unnecessary trouble for anyone who might be working on numbers.c
> is the the hard part, I think.

AFAIK I was the only one actively working on numbers.c, and I'm OK
with the reformatting -- I'm going to be merging my changes by hand
when I get to it anyhow.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel