chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] mathematical oddities


From: Shawn Rutledge
Subject: Re: [Chicken-users] mathematical oddities
Date: Thu, 15 Jul 2010 11:49:34 -0700

>>> (condition-case (/ 1 0) (exn (exn arithmetic) "doh!"))
>>
>> Can you detect the actual divide-by-zero error though as opposed to
>> just a general arithmetic error?
>>

On Thu, Jul 15, 2010 at 6:26 AM, Felix
<address@hidden> wrote:
> Currently this is the only arithmetic error that may be triggered. Do
> you think it would be good to add a condition type for this?

Well if you think it will always be only that arithmetic error, I
guess that's good enough for me to write a division operator which
returns infinity if I ever need to.  But it would be less efficient.
Do you have to detect the infinity in order to turn it into a
condition?  Maybe that behavior could be switched off, or expose a
lower-level division operation so that getting the infinite result is
just a matter of redefining the operator to make use of the other
division operation.

On Thu, Jul 15, 2010 at 5:40 AM, John Cowan <address@hidden> wrote:
> The reason to return +0.inf from (/ 3.0 0.0) is that 0.0 is not a
> mathematical zero: rather, it refers to any number r where -DBL_MIN <
> r < DBL_MIN (DBL_MIN is defined in the C header <float.h>).  Dividing by
> exact 0, on the other hand, clearly should throw an exception.

Sounds like a good reason.  For integer operations it would still have
to throw an exception, because there's no such thing as an "exact"
infinity in the numeric tower right?

On Thu, Jul 15, 2010 at 12:38 AM, Peter Bex <address@hidden> wrote:
> I don't think it's a bug to allow only integers in these operations when
> bignum support is enabled.  It is much more likely to be a mistake than
> intended behaviour to call these functions with flonum args.

I don't think I agree; if you do long division on paper you can get
remainders from decimals, after all.  I like that it works, and it
made possible this:

(define π (atan 0 -1))
(define 2π (* 2.0 π))

;; Return the absolute value of the acute difference between two
angles in radians.
(define (abs-angle- one other)
        (min (abs (- one other)) (abs (- (modulo one 2π) (modulo other 2π)))))

(which I'm not sure is the best way, I just wrote it late last night)
(and that was before I googled and discovered the Douglas-Peucker line
simplification algo, which is what I really want)

But flonums continue to exist after you do (use numbers) so why should
the behavior change suddenly?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]