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)
|
---------- 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