division by 0

division by 0

[Bernard Urban]

Debian woody on i386.

$ guile
guile> (version)
"1.6.4"
guile> (/ 0)
+#.#
guile> (/ 1.0 0)
+#.#
guile> (/ 1 0.0)
+#.#
guile>(/ 1 0)
standard input:3:1: In procedure / in expression (/ 1 0):
standard input:3:1: Numerical overflow
ABORT: (numerical-overflow)

Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
guile>

Problem happens in numbers.c, function scm_divide(), where the test 
#line 3274 should not be made.
 
scm_divide() seems copied from scm_quotient(), where the above
behaviour is correct.

-- 

Bernard Urban


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: division by 0

[Marius Vollmer]

Bernard Urban <Bernard.Urban@meteo.fr> writes:

> Debian woody on i386.
>
> $ guile
> guile> (version)
> "1.6.4"
> guile> (/ 0)
> +#.#
> guile> (/ 1.0 0)
> +#.#
> guile> (/ 1 0.0)
> +#.#
> guile>(/ 1 0)
> standard input:3:1: In procedure / in expression (/ 1 0):
> standard input:3:1: Numerical overflow
> ABORT: (numerical-overflow)
>
> Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
> guile>
>
> Problem happens in numbers.c, function scm_divide(), where the test 
> #line 3274 should not be made.

The 1.7 series should be handling this more correctly.  From NEWS:

    ** 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

    Two new predicates 'inf?' and 'nan?' can be used to test for the
    special values.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: division by 0

[Bernard Urban]

Marius Vollmer <mvo@zagadka.de> writes:

> Bernard Urban <Bernard.Urban@meteo.fr> writes:
> 
> > Debian woody on i386.
> >
> > $ guile
> > guile> (version)
> > "1.6.4"
> > guile> (/ 0)
> > +#.#
> > guile> (/ 1.0 0)
> > +#.#
> > guile> (/ 1 0.0)
> > +#.#
> > guile>(/ 1 0)
> > standard input:3:1: In procedure / in expression (/ 1 0):
> > standard input:3:1: Numerical overflow
> > ABORT: (numerical-overflow)
> >
> > Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
> > guile>
> >
> > Problem happens in numbers.c, function scm_divide(), where the test 
> > #line 3274 should not be made.
> 
> The 1.7 series should be handling this more correctly.  From NEWS:
> 
>     ** 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

Is (/ 1 x)  always equal to (/ x) in 1.7 ?
This is actually my problem. It originates in the fact that hobbit
converts (/ x) to (/ 1 x), and for x = 0, it fails for 1.6.

Why would I want to divide by 0 ? To obtain... nan !
In the interpreter, you can have:
(define nan (- (/ 0) (/ 0)))
For hobbit, you must do:
(define nan (eval '(- (/ 0) (/ 0)) (interaction-environment)))

> 
>     Two new predicates 'inf?' and 'nan?' can be used to test for the
>     special values.

-- 

Bernard Urban


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: division by 0

[Kevin Ryde]

Bernard Urban <Bernard.Urban@meteo.fr> writes:
>
> Is (/ 1 x)  always equal to (/ x) in 1.7 ?
> This is actually my problem. It originates in the fact that hobbit
> converts (/ x) to (/ 1 x), and for x = 0, it fails for 1.6.

You need to be clearer about what you're trying to report.

If you're saying (/ 0) is not the same as (/ 1 0), then I see that's
the case.  My guess would be that's wrong, probably both ought to give
errors (on the basis there's no multiplicative inverse of an exact
zero).  This is the case in the cvs head, perhaps it should be made so
in the 1.6 series too.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: division by 0

[Bernard Urban]

Kevin Ryde <user42@zip.com.au> writes:

> Bernard Urban <Bernard.Urban@meteo.fr> writes:
>>
>> Is (/ 1 x)  always equal to (/ x) in 1.7 ?
>> This is actually my problem. It originates in the fact that hobbit
>> converts (/ x) to (/ 1 x), and for x = 0, it fails for 1.6.
>
> You need to be clearer about what you're trying to report.
>
> If you're saying (/ 0) is not the same as (/ 1 0), then I see that's
> the case.  My guess would be that's wrong, probably both ought to give
> errors (on the basis there's no multiplicative inverse of an exact

Page 20 of R5RS says: "This report recommends, but does not require, 
that the IEEE 32-bit and 64-bit floating point standards be followed..."

Sot it is fine for guile to follow the standard (actually IEEE-754), 
which implies treatment of infinity and NAN. 

> zero).  This is the case in the cvs head, perhaps it should be made so
> in the 1.6 series too.
>

My argument is one of coherence, and I always believed coherence
was in the spirit of scheme:

guile> (/ 3)
0.333333333333333
guile> (/ 3.0)
0.333333333333333
guile> (/ 1 3)
0.333333333333333
guile> (/ 1 3.0)
0.333333333333333
guile> (/ 0)
+#.#
guile> (/ 0.0)
+#.#
guile> (/ 1 0)
standard input:16:1: In procedure / in expression (/ 1 0):
standard input:16:1: Numerical overflow
ABORT: (numerical-overflow)
guile> (/ 1 0.0)
+#.#
guile> 

-- 

Bernard Urban


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: division by 0

[Bernard Urban]

Kevin Ryde <user42@zip.com.au> writes:

> Bernard Urban <Bernard.Urban@meteo.fr> writes:
>>
>> Is (/ 1 x)  always equal to (/ x) in 1.7 ?
>> This is actually my problem. It originates in the fact that hobbit
>> converts (/ x) to (/ 1 x), and for x = 0, it fails for 1.6.
>
> You need to be clearer about what you're trying to report.
>
> If you're saying (/ 0) is not the same as (/ 1 0), then I see that's
> the case.  My guess would be that's wrong, probably both ought to give
> errors (on the basis there's no multiplicative inverse of an exact

Page 20 of R5RS says: "This report recommends, but does not require, 
that the IEEE 32-bit and 64-bit floating point standards be followed..."

Sot it is fine for guile to follow the standard (actually IEEE-754), 
which implies treatment of infinity and NAN. 

> zero).  This is the case in the cvs head, perhaps it should be made so
> in the 1.6 series too.
>

My argument is one of coherence, and I always believed coherence
was in the spirit of scheme:

guile> (/ 3)
0.333333333333333
guile> (/ 3.0)
0.333333333333333
guile> (/ 1 3)
0.333333333333333
guile> (/ 1 3.0)
0.333333333333333
guile> (/ 0)
+#.#
guile> (/ 0.0)
+#.#
guile> (/ 1 0)
standard input:16:1: In procedure / in expression (/ 1 0):
standard input:16:1: Numerical overflow
ABORT: (numerical-overflow)
guile> (/ 1 0.0)
+#.#
guile> 

-- 

Bernard Urban


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: division by 0

[Marius Vollmer]

Bernard Urban <Bernard.Urban@meteo.fr> writes:

> Is (/ 1 x)  always equal to (/ x) in 1.7 ?

Yes, or at least it should.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile