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

*To*: Per Bothner <per@xxxxxxxxxxx>*Subject*: Re: reading NaNs*From*: bear <bear@xxxxxxxxx>*Date*: Mon, 24 Oct 2005 12:23:42 -0700 (PDT)*Cc*: Aubrey Jaffer <agj@xxxxxxxxxxxx>, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <435D1B3D.9080105@xxxxxxxxxxx>*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <20051022011713.1F22A1B77BB@xxxxxxxxxxxxxxxxxxxxx> <87vezqmjkq.fsf@xxxxxxxxxxxxxxxxx> <20051022232548.5A2971B77BB@xxxxxxxxxxxxxxxxxxxxx> <873bmtxdnm.fsf@xxxxxxxxxxxxxxxxx> <20051023181854.4E7DD1B77BB@xxxxxxxxxxxxxxxxxxxxx> <871x2cowe8.fsf@xxxxxxxxxxxxxxxxx> <20051023195403.A50AF1B77BB@xxxxxxxxxxxxxxxxxxxxx> <435BEC21.60509@xxxxxxxxxxxx> <20051023205012.BFD241B77BB@xxxxxxxxxxxxxxxxxxxxx> <87zmoz27dg.fsf@xxxxxxxxxxxxx> <87hdb7kgmk.fsf@xxxxxxxxxxxxxxxxx> <87k6g3zw34.fsf@xxxxxxxxxxxxx> <871x2bkfj7.fsf@xxxxxxxxxxxxxxxxx> <8764rnu45b.fsf@xxxxxxxxxxxxx> <87br1fiv26.fsf@xxxxxxxxxxxxxxxxx> <87ll0jpu0q.fsf@xxxxxxxxxxxxx> <20051024022744.6CA581B77BB@xxxxxxxxxxxxxxxxxxxxx> <87veznbb37.fsf@xxxxxxxxxxxxx> <8764rnbaqr.fsf@xxxxxxxxxxxxxxxxx> <435C9A65.7060106@xxxxxxxxxxxxxxxx> <20051024153539.D98031B77BB@xxxxxxxxxxxxxxxxxxxxx> <435D1B3D.9080105@xxxxxxxxxxx>

Okay... On a rereading of SRFI-77, I want to point out a couple things. First, the new external representation where you have a suffixed bar and decimal number indicating the bits of precision: This is a good and necessary extension to the information in inexact constants, and I applaud it. But we've got what is essentially one piece of information all over the place now. The inexact prefix, the exponent marker, and this new suffix all signify inexactness and information about inexactness. Since a lot of representations already support #<decimal>R prefixes for radix, could we consider #<decimal>I prefixes for inexactness? This would eliminate the need for the suffix entirely, and put the primary inexactness information in one place. The exponent markers are still somewhat useful as ways to specify the use of indeterminate amounts of precision that happen to be efficient on the current hardware. So somebody who needed only a little precision and wanted whatever the system found "easy" or "efficient" could write 6.0F0, and somebody who knows that his algorithm won't work if he has less than 16 bits of precision can write #16i6.0. I think you should specify that an implementation may use more bits of precision than requested, and introduce some way to request that an error be signalled if the implementation must use less. Regarding "safe" and "unsafe" mode; I think that "unsafe" mode should _allow_ implementations to skip checks, not _require_ them to skip checks. Code that is incorrect in safe mode is still incorrect in unsafe mode, and we should not provide a canonical way to run unsafe or incorrect code. Additionally, it is a lower initial bar for implementors; they can get the system working correctly (in safe mode) and provide a trivial unsafe mode (equal to their safe mode) to start with. Finally, we can't really tell in advance which checks can or ought to be done or skipped; as compiler technology advances or as hardware advances some checks may become "free" either at compile-time or in hardware at runtime. Theoretically, some checks may even acquire negative cost if the hardware uses them as "cue" indicators for heuristic branch predictions or prefetching. Your redefinition of eqv? makes it the case that: (eqv? #6.0L0 #6.0S0) => #t on implementations that use a single floating-point representation size and #f on implementations that use multiple floating-point representation sizes (because procedures like + can produce results differing in precision depending on the precision of its arguments). So we have a situation where, first, the results of eqv? are specified but implementation-dependent, and second, two numbers can be = without being eqv?. This is consistent with Lucier's proposal, which you mention at the end of the SRFI, but you don't highlight the difference anywhere. I think I agree with your rationale and I think I agree with the results and the respecification of eqv?; but the ramifications on numerically equal numbers of different precisions is not immediately obvious, so I wanted to point it out. I strongly disagree with the idea of mixed exactness in the real and imaginary parts of a complex number. 5.0+3i and 5+3.0i are the same inexact number and should not be treated differently. I would suggest requiring an error to be signalled if inexact->exact gets an argument greater or less than any exact number representable by the implementation. Likewise if exact->inexact recieves an argument outside the range representable as inexact numbers in the implementation. Your formulation permits a fixnum range [0,1] and then states that the modular mathematics primitives perform math modulo hi-lo+1. I first thought, somewhat obtusely, 'What does it mean to perform mathematics modulo zero??' After a fractional second's thought, it became clear that you meant (hi-lo)+1, not hi-(lo+1). Consider using fully parenthesized notation to avoid misinterpretation. Remember to also use it in your description of the functions that do modular operations. I still think that bitwise operations on numbers are incorrect. Bitwise operations should operate on bitvectors, not on numbers. You are not using them as numbers when you do bit operations on them, and their identity as numbers does not give the length of the bitvector you're using them for. This is faint and fuzzy thinking inherited from C and confuses bit representation with semantics. Absolute value is just a special case of complex magnitude, restricted to the various ranges. In fact, (define abs magnitude) works just fine. It didn't seem redundant in R5RS because complex numbers (and therefore the magnitude accessor) weren't required in R5RS. In a situation where the whole tower is required, it seems redundant. According to your definition of real? ... (real? z) <==> (let ((im (imag-part z))) (and (zero? im)(exact? im))) but simultaneously, (real? +nan.0) ==> #t. This implies that (imag-part +nan.0) is an exact zero, which seems wrong, although consistent with your declaration of NaN as a real number of indeterminate value. Are complex operations constrained to return some different kind of NaN, or do their results get coerced to the real line in the event of an error? Bear

**Follow-Ups**:**Re: reading NaNs***From:*Aubrey Jaffer

**Re: reading NaNs***From:*Marcin 'Qrczak' Kowalczyk

**References**:**arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Jens Axel Søgaard

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Aubrey Jaffer

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

**Re: arithmetic issues***From:*Thomas Bushnell BSG

**Re: arithmetic issues***From:*Alan Watson

**reading NaNs***From:*Aubrey Jaffer

**Re: reading NaNs***From:*Per Bothner

- Prev by Date:
**Re: reading NaNs** - Next by Date:
**Re: reading NaNs** - Previous by thread:
**Re: reading NaNs** - Next by thread:
**Re: reading NaNs** - Index(es):