SRFI 196 ready for finalization? John Cowan (27 Jul 2020 22:57 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (28 Jul 2020 00:24 UTC)
Re: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (29 Jul 2020 06:59 UTC)
Re: SRFI 196 ready for finalization? John Cowan (29 Jul 2020 14:32 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (29 Jul 2020 17:52 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (29 Jul 2020 18:56 UTC)
Re: SRFI 196 ready for finalization? Arthur A. Gleckler (30 Jul 2020 05:50 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (30 Jul 2020 17:03 UTC)
Re: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (30 Jul 2020 18:34 UTC)
Re: SRFI 196 ready for finalization? Arthur A. Gleckler (30 Jul 2020 20:17 UTC)
Re: SRFI 196 ready for finalization? John Cowan (30 Jul 2020 23:44 UTC)
Re: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (31 Jul 2020 06:14 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (31 Jul 2020 17:33 UTC)
Re: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (31 Jul 2020 18:01 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (31 Jul 2020 18:49 UTC)
Re: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (01 Aug 2020 06:55 UTC)
Re: SRFI 196 ready for finalization? John Cowan (01 Aug 2020 17:20 UTC)
Re: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (01 Aug 2020 19:14 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (04 Aug 2020 22:35 UTC)
(missing)
Fwd: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen (26 Aug 2020 19:12 UTC)
Re: Fwd: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (26 Aug 2020 21:03 UTC)
Re: SRFI 196 ready for finalization? John Cowan (05 Aug 2020 02:02 UTC)
Re: SRFI 196 ready for finalization? John Cowan (05 Aug 2020 02:28 UTC)
Re: SRFI 196 ready for finalization? Wolfgang Corcoran-Mathe (05 Aug 2020 02:35 UTC)

Fwd: SRFI 196 ready for finalization? Marc Nieper-Wißkirchen 26 Aug 2020 19:12 UTC

---------- Forwarded message ---------
Von: Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>
Date: Mi., 5. Aug. 2020 um 08:33 Uhr
Subject: Re: SRFI 196 ready for finalization?
To: Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>

Am Mi., 5. Aug. 2020 um 00:35 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> On 2020-08-01 21:14 +0200, Marc Nieper-Wißkirchen wrote:
> > >     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.
>
> The really important thing is that the range created by numeric-range
> have a valid length, that is, that (- end start) satisfies both
> positive? and integer?.

> I'm not sure if dropping the divisibility-by-step constraint would
> break anything, but it's certainly confusing to allow uses like
>
>     (numeric-range 0 10 11),  ; => 0, 11, 22, ...

I would turn "end" into the upper limit, which doesn't have to be
reached exactly. So, (numeric-range 0 10 11) would produce the
one-element sequence "0". In other words, you do some rounding down in
the (end - start) / step calculation. (You have to do some rounding
anyway due to the possible inexactness.)

> in which the `end' parameter is meaningless.  So I'm in favor of
> John's Scheme rewording of the constraint, s/modulo/floor-remainder/.

I am still not sure that this makes sense in the presence of 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)"
>
> I do think this is related to numerics, in that it hinges on whether
> we are talking about ranges of numbers or of their floating-point
> representations.  Provided we're talking about the former, we can
> certainly require that the above constraint holds without breaking
> numeric-range.

You can certainly talk about the former but this won't help you in the
Scheme world of inexact numbers (or other "inexact" user-defined
indexers). range-split-at simply won't work universally due to
rounding errors.

> I do think that we've gone into something of a rat-hole in trying to
> take into account the possible behavior of inexact numbers under range
> operations.  The original reason for proposing some constraints on

What rat hole? The solution is simple (using composed indexers). And
you can drop the special indexer constraint completely.

Marc