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

This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: comparison operators and *typos*From*: bear <bear@xxxxxxxxx>*Date*: Thu, 7 Jul 2005 08:34:59 -0700 (PDT)*Cc*: schlie@xxxxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050707031950.459A31B77B4@xxxxxxxxxxxxxxxx>*References*: <BEF1935C.ABC6%schlie@xxxxxxxxxxx> <20050707031950.459A31B77B4@xxxxxxxxxxxxxxxx>

On Wed, 6 Jul 2005, Aubrey Jaffer wrote: > | Thereby hypothetically: (presuming sufficient numerical precision) > | > | (tan pi/2) => 0 > >An exact zero? That is just wrong. No, actually it's more right than we expect computation to get. If pi/2 can be an exact number in the representation used by the scheme system, an exact zero is precisely the correct response to (tan pi/2). That said, tan isn't one of the functions that is required to return an exact result given exact arguments, so even if pi/2 is exact in the number representation, we still aren't *required* to return the exact zero, even though it's true. In the usual case, where the numeric representation does not allow pi/2 to be expressed as an exact number, then we have an operation on an inexact number and we *must* return an inexact result. Bear

**References**:**Re: comparison operators and *typos***From:*Paul Schlie

**Re: comparison operators and *typos***From:*Aubrey Jaffer

- Prev by Date:
**Re: comparison operators and *typos** - Next by Date:
**Re: Nitpick with FLOOR etc.** - Previous by thread:
**Re: limit function** - Next by thread:
**infinity notations** - Index(es):