Re: A problem with range objects and floating point numbers

[Daniel J Sebald]

On 09/29/2014 08:02 PM, s.jo wrote:
> Daniel Sebald wrote
> > On 09/29/2014 11:36 AM, s.jo wrote:

[snip]

> Dan,
>
> It will a good routine for NEW range operator.
> * A traditional incremental range operator (say, op1)
> * A new interpolated range operator (say, op2)
> The incremental range should be supported anyway.
>
> My idea is that colon operator can select a routine between implicitly based
> on solid rules:
> For example,
> R1. base, limit, and increment are all integers -->  op1
> R2. ((limit-base)/increment) is an integer -->  op2
> (We can check if floor((limit-base)/increment)==((limit-base)/increment))
> R3. Otherwise, -->  op1
> ... and so on.
>
> I think that R2 case is only our concern.

OK.  I created a changeset that does basically that:

https://savannah.gnu.org/patch/index.php?8548

The change uses the existing algorithm for integer elements because

output(i) = a + inc * i

has exact results when inc and a are integers.

However, for other cases the routine

output(i) = (a (N-i) + b (i)) / N-i * scale

is used because it has better floating point behavior (several Internet 
discussion boards cover this).

John, this is actually a pretty straightforward changeset.  I think more 
than anything it is a case of organizing in such a way that all 
variations of limit/increment as far as int/non-int can be addressed.

Dan