Am Sa., 1. Aug. 2020 um 19:20 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> And I think I made a mistake in my previous post. A procedure
>> "range-map" would be possible, wouldn't it? The mapping procedure
>> would just have to be post-composed with the indexer, wouldn't it?

> You'd also have to specify a new lower bound and comparator that are consistent with the codomain of the mapping procedure, and there would of course be no way to check this consistency because mapping procedures are Turing-complete.

What is the meaning of the lower bound actually? The way SRFI 196 is
currently written, it is just an extra parameter to the indexer and
can be ignored for the mapped range.

The comparator, on the other hand, would have to be provided, of course.

But the comparator is only used in two places. Its inequality relation
is only used in "range-includes?", which doesn't seem to make a lot of
sense, and its equality relation is only used in "range-contains?",
which is just a thin layer of "range-index".

Therefore, it smells like that the comparator (and the lower bound) do
not really belong to such a general range interface as defined by SRFI
196. It actually looks as if two separate ideas are being fused into
one: (1) general indexers for higher order procedures like
XXX-for-each or XXX-fold; (2) ranges in the sense of intervals with
respect to some ordering. However, the latter concept does not really
fit to how the former is presented in SRFI 196.

I would therefore propose to drop "lower-bound" and the comparator and
focus on the O(1)-in-space indexing capabilities of SRFI 196. This
will give a nice self-contained API for ranges (which, however, can
benefit from another name).

>> one can simply
>> factor our the algorithmic complexity of the indexer procedure, but
>> this will make the given running time bounds somewhat arbitrary
>> because the indexer procedure is not under the control of the user but
>> can be changed by subrange or range-reverse.

> These procedures wrap the indexer in an O(1) procedure, so do not affect running time.

Will you add this to the text as well?

>> - range-split-at has rounding problems for numeric ranges, hasn't it?
>
>
> I think the problem comes from this sentence in the description of `numeric-range`:  "It is an error if end - start is not a multiple of step."  This is phrased in the language of mathematics, and so is taken to be a statement about real numbers, but it isn't meant to be.

>     It is an error if (zero? (modulo (- end start) step)) => #f.

Why do you need such a constraint at all? By the way, it would only
make sense if multiplication would be the exact inverse of division,
which it isn't for inexact numbers.

>> So range-split-at has to use a custom
>> indexer for the second subrange.
>
> On the above view, it does not.

It does because the root cause is not related to numerics but to the
fact that indexers do not have the following constraint:

"(indexer lower-bound (+ k l)) is equal to (indexer (indexer lower-bound k) l)"

But we cannot impose this constraint because it will make many
indexers impossible (including the one used for "numeric-range").

Marc