[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A problem with range objects and floating point numbers

From: Daniel J Sebald
Subject: Re: A problem with range objects and floating point numbers
Date: Wed, 01 Oct 2014 04:25:39 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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



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:


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]