|
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:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 09/29/2014 08:02 PM, s.jo wrote:
Daniel Sebald wroteOn 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 * scaleis 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
[Prev in Thread] | Current Thread | [Next in Thread] |