Re: bounded, infinite ranges?

[dyer@eagle.sharebase.com (Scot Dyer)]

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