Clarifications for numeric-range Wolfgang Corcoran-Mathe (29 Aug 2020 17:15 UTC)
Re: Clarifications for numeric-range Arthur A. Gleckler (29 Aug 2020 17:36 UTC)
Re: Clarifications for numeric-range Wolfgang Corcoran-Mathe (29 Aug 2020 17:43 UTC)
Re: Clarifications for numeric-range Arthur A. Gleckler (29 Aug 2020 17:49 UTC)
Re: Clarifications for numeric-range Wolfgang Corcoran-Mathe (29 Aug 2020 18:31 UTC)
Re: Clarifications for numeric-range Marc Nieper-Wißkirchen (29 Aug 2020 17:41 UTC)
Re: Clarifications for numeric-range Wolfgang Corcoran-Mathe (30 Aug 2020 00:05 UTC)

Re: Clarifications for numeric-range Marc Nieper-Wißkirchen 29 Aug 2020 17:40 UTC

Am Sa., 29. Aug. 2020 um 19:15 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> I've pushed a change to the specification of numeric-range which (I
> think) correctly describes the values contained in the range returned,
> at least when <step> is non-zero:
>
> > This range produces the sequence
> >
> >     start, (+ start step), (+ start (* 2 step)), …, (+ start (* n step)),
> >
> > where n is the greatest integer such that (+ start (* n step)) < end
> > if step is positive, or such that (+ start (* n step)) > end if step
> > is negative.
>
> This is somewhat wordy, but, I think, superior to merely describing the
> range's indexer (as in draft #4).
>
> It remains to be determined: Is a range with a zero step an infinite
> sequence of the <start> parameter, is it an error to create such a
> range, or what?

Good catch!

As long as infinite sequences are not mentioned in this SRFI, it
should be an error. However, this can happen not only when (zero?
step) but also with a purely negative or positive step due to rounding
errors (we cannot assume any particular, e.g. the IEEE,
representation).

Therefore, I would write:

"It is an error if the step is numerically zero or if there is no such
n fulfilling [*]." (Where [*] points to the wording above.)

With infinite sequences (which behave better than infinite generators
because they can produce a meaningful result for their length, that is
#f), this won't be needed.

That you need so many words to describe the sequence of the numeric
range, is not accidental. The point is that the range produced by
"numeric-range" is not continuous in its arguments:

Given (numeric-range 0.0 1.0 x), the behavior changes abruptly when x
goes from a small negative value (range of length 0) to a small
positive value (range of a very long length).

When dealing with inexact numbers, this is never a good thing (ask any
numerical analyst :)). Thus, it would be way better to always use the
bound "< end" and not to switch the interpretation of the end argument
dependently on a continuous argument.

If we drop infinite sequences, so any step value near zero, this is
less of a concern.