[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*: bear <bear@xxxxxxxxx>*Subject*: Re: My suggestions to the R6RS committee about numerics*From*: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>*Date*: Thu, 2 Jun 2005 14:46:26 -0400*Cc*: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <Pine.LNX.4.58.0506020833510.19932@xxxxxxxxxxxxxx>*References*: <y9ly8acfewc.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0506020833510.19932@xxxxxxxxxxxxxx>

On Jun 2, 2005, at 12:25 PM, bear wrote:

On Wed, 18 May 2005, Bradley Lucier wrote:The first part deals with IEEE 754/854 arithmetic. If you don't support this arithmetic, then things are still up in the air.I should not like to see conforming implementations restricted to exactly this representation and no other; It's nice to be able to use real numbers of specified precision for some tasks where the 500th bit of the mantissa actually matters.

6.1 Equivalence predicatesThe eqv? procedure returns #t if: * obj1 and obj2 are both IEEE 754/854 format numbers, and obj1 and obj2 have the same base, sign, number of exponent digits, exponent bias, biased exponent, number of significand digits, and significand. * obj1 and obj2 are both exact numbers and are numerically equal (see =, section 6.2). The eqv? procedure returns #f if: * one of obj1 and obj2 is an exact number but the other is an inexact number. * obj1 and obj2 are both IEEE 754/854 format numbers, and the base, sign, number of exponent digits, exponent bias, biased exponent, number of significand digits, or significand of obj1 and obj2 differ.* obj1 and obj2 are exact numbers for which the = procedure returns#f.I believe that it is also necessary to specify that if one or more of the arguments is NaN, eqv? returns false. It is not at all uncommon for NaN to have a single bit pattern, and thus if compared under the above definition, a call where two arguments were both NaN would return #t, which is a mistake in arithmetic.

It is not ideal IMO to declare it an error to pass NaN to eqv?, since that limits the composition of expressions.Note: This section does not state under which conditions eqv? returns #t or #f for inexact numbers that are not in IEEE 754/854 format. We recommend that numbers not in IEEE 754/854 format for which a base, sign, number of exponent digits, exponent bias, biased exponent, number of significand digits, and significand can be defined follow the same rules as above.I would require rather than recommend this property;

what I'd *recommend* is for you, in the future, to practice line wrapping at an earlier column. :-)

6.2.5. Numerical operations (number? obj ) procedure (complex? obj ) procedure (real? obj ) procedure (rational? obj ) procedure (integer? obj ) procedure These numerical type predicates can be applied to any kind of argument, including non-numbers. They return #t if the object is of the named type, and otherwise they return #f. In general, if a type predicate is true of a number then all higher type predicates are also true of that number. Consequently, if a type predicate is false of a number, then all lower type predicates are also false of that number.<delete this> If z is an inexact complex number, then (real? z) is true if and only if (zero? (imag-part z)) is true. If x is an inexact real number, then (integer? x) is true if and only if (= x (round x)). <add this>If an implementation uses IEEE 754/854 format for inexact numbersthen:* If z is an inexact complex number, then (real? z) is true if andonly if both (exact? (imag-part z)) and (zero? (imag-part z)) aretrue.* If z is an inexact real number, then (rational? z) is true if and only if z is not positive or negative infinity or a not-a-number.Note: IEEE 754/854 gives no way to represent complex numbers. You will have to use more precise language to say what you mean,

which is, I suspect, uses 754/854 to represent the real and imaginary parts of the (cartesian) complex number, or uses IEEE 754/854 to represent the magnitude and angle of the (polar) complex number. But once again, I don't think we need to specify this particular format, nor to relax all restrictions if a different format is used; In my opinion, the field widths for the mantissa and biased exponent are irrelevant to the requirement.

In particular, be careful not to assume that all complex numbers are internally represented in the same way; several implementations, I believe, use both polar and cartesian representations internally. Finally, from a mathematical point of view, a number is either inexact or exact; this includes complex numbers. A few implementations allow differing exactness in the real and imaginary parts of a complex number. This is a fact, but the fact lies at some intermediate position between being a mere artifact of the representation and a mathematical error. Consult a number theorist to understand more fully the nature of this error; it is beyond my feeble ability to explicate. It is not sensible to speak of an inexact complex number whose imaginary part is exact,

I believe that we should have (exact? (imag-part 1.0)) => #t

Furthermore, (* 1.0 +1i)

and if you require an implementation that allows it to be, there will be a certain amount of wailing and gnashing of teeth from mathematicians and number theorists, who are currently some of scheme's most dedicated and thankful users.

<add this> (real? -2.5+0.0i) =) undetermined (real? -2.5+0.0i) =) #f if IEEE 754/854 arithmetic is used. <end of addition>Nope, sorry, this just doesn't work.

I think it does. You'll need more here than proof by proclamation.

<Add the following> For implementations that allow (real z) and (imag z) to have different exactness, then (exact? z) returns #t if and only if both (exact? (real z)) and (exact? (imag z)) return #t. <end of addition>Once again, this proceeds from a delusory belief that one number, as a result of its mere representation, can have two different exactnesses simultaneously. This will not fly.

<Change the comparison predicates to the following>(= z1 : : : ) procedure (< x1 : : : ) procedure (> x1 : : : ) procedure (<= x1 : : : ) procedure (>= x1 : : : ) procedure<clip>Note: If an implementation uses IEEE 754/854 format for its inexact numbers, then these procedures shall return #f if called with two or more arguments when one of the arguments is a NaN."one of" should be changed to "one or more of" -- this does not change meaning, but adds clarity. And I think this should be true of NaN's always, no matter how numbers are represented.

The principle I'm working on here is that if (proc x)

(= x) => #t

<change the following predicates>(zero? z) library procedure (positive? x) library procedure (negative? x) library procedure (odd? n) library procedure (even? n) library procedureThese numerical predicates test a number for a particular property, returning #t or #f.If an implementation uses IEEE 754/854 format for its inexact numbers, then zero?, positive?, and negative? return #f if called with a NaN argument.I would go further and say *all* of these procedures should return #f if called with a NaN argument, regardless of how numbers or NaNs are represented.

NaNs are not integers, so they cannot be arguments to odd? and even?.

<change the following procedures>(max x1 x2 : : : ) library procedure (min x1 x2 : : : ) library procedureThese procedures return the maximum or minimum of their arguments.(max 3 4) =) 4 ; exact (max 3.9 4) =) 4.0 ; inexactIf an implementation uses IEEE 754/854 format for its inexact numbers, and any of the arguments to max and min are NaNs, then max and min returns one of the NaN arguments as its result.use "a" rather than "one of the", unless there is some significance to the eq?-ness of the NaN returned with one of its arguments. And say simply "NaNs" if there is not some significance to representing them in a particular IEEE format.

<change floor, ceiling, truncate, and round to take rationalarguments,not real arguments>I do not agree with you that these procedures ought not take real arguments. Instead, they should return inexact numbers when given inexact numbers and NaN when given NaN.

(trunc +inf.0) => ??? or something similar?

<change rationalize to take rational arguments, not real arguments>This does not make sense. If you have rational arguments to start with, what are you using rationalize for?

To find a "simpler" rational approximation to the argument.

**Follow-Ups**:

**References**:**My suggestions to the R6RS committee about numerics***From:*Bradley Lucier

**Re: My suggestions to the R6RS committee about numerics***From:*bear

- Prev by Date:
**Re: Two specific suggestions.** - Next by Date:
**string->number** - Previous by thread:
**Re: My suggestions to the R6RS committee about numerics** - Next by thread:
**Re: My suggestions to the R6RS committee about numerics** - Index(es):