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

*To*: andyw@ibeam.ht.intel.com, macrakis@osf.org*Subject*: Re: bounded, infinite ranges?*From*: dyer@eagle.sharebase.com (Scot Dyer)*Date*: Thu, 22 Oct 92 08:56:15 PDT*Cc*: info-dylan@cambridge.apple.com

andyw@ibeam.ht.intel.com (Andy Wilson) writes: /// Stavros Macrakis writes: /// /// ----------------------------------------------------------- /// The elements of the range should be in general calculated as from+I*by /// rather than as ((from+by)+by)+by+... This also guarantees that you /// don't get killed by round-off. On the other hand, it does mean that /// more than one element of the range may have the same value. /// ----------------------------------------------------------- /// /// Due to the miracle of floating point arithmetic, there is always /// a value for "by:" where even from+I*by == from for at least some /// part of the range. This leads to one of two undesirable states: /// 1) more than one element of the range has the same value, as Stavros /// suggests, or 2) the (size) of the range is not equal to the number /// of values one would see iterating over it. Really the only way to get around this is to work with the underlying exponent and mantissa. A good floating point representation will not permit the same number two representations, and most will guarantee that the highest mantissa with some exponent will be just less than the lowest mantissa with the next possible exponent. This means that the items in the list will not be evenly spaced, but rather, logarithmically. /// Again, these unpleasant facts of floating point life could be avoided /// if from/up-to/by were constrained to be <rational>. I think even <rational> might have it's problems... This kind of confusion about floats is exactly why I don't like the idea of enumerating a range of <real> -- Dylan programmers (mostly) don't have enough experience in systems programming (read: C and assembly language) to really have much a clue how this would work. Most likely it will be an error, and if it isn't, it should be written differently (at least in Dylan -- this style is practical in 'C'). I also don't think one should be able to test for exact equality of floats. (Ergo, id? should be valid, but = invalid). At least not in a _high_level_ language. /// atw -- Scot

- Prev by Date:
**Re: contractual programming** - Next by Date:
**Re: Dylan Constants** - Previous by thread:
**Re: bounded, infinite ranges?** - Next by thread:
**Re: bounded, infinite ranges?** - Index(es):