Thanks very much for the review, Marc!

On 2020-07-29 10:32 -0400, John Cowan wrote:
> On Wed, Jul 29, 2020 at 2:59 AM Marc Nieper-Wißkirchen <
> xxxxxx@nieper-wisskirchen.de> wrote:
> > - The implementation of "numeric-range" does seem to assume that
> > rounding errors cannot happen when computing the length. I think a
> > test has to be added whether "start + calculated-len * step < end" but
> > "start + (calculated-len - 1) * step >= end".
>
> Wolfgang, what do you think?

We should have

    end = (+ start (* calculated-len step))

since the last valid index is (- length 1).  If we replace
calculated-len with its definition, this is

    end = (+ start (* (/ (- end start) step) step)),

which is just reversing the computation and checking if we get
the same `end' that we were given.  This seems a little redundant,
but the overhead (at range creation time) is minimal; if it catches
some bad ranges, all the better.

The second constraint needs to be a little more complex, I think.
Since numeric ranges may be decreasing, or may be empty (start =
end), we need something like

    (assume
     (or (= start end)
         (if (< start end)
             (< (+ start (* (- calculated-len 1) step)) end)
             (> (+ start (* (- calculated-len 1) step)) end))))

In some quick tests, this is sufficient to catch problem ranges like

    (numeric-range 1 (expt 1000.0 10)).

There may be additional subtleties here.  Please correct me if I've
missed some.

I'll add both checks.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Industry has surrounded people with artifacts whose inner workings
only specialists are allowed to understand." --Ivan Illich