octave-maintainers
[Top][All Lists]
Advanced

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

Improving handling of ranges (was: Re: mutable considered harmful, Range


From: John W. Eaton
Subject: Improving handling of ranges (was: Re: mutable considered harmful, Range edition)
Date: Mon, 29 Jun 2020 14:48:21 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 6/9/20 9:43 AM, I wrote:
On 6/9/20 12:11 AM, I wrote:

Separately, I see that other than the Range::matrix_value method, we set the cache value in the operators, like this:

   Range operator + (const Range& r, double x)
   {
     Range result (r.base () + x, r.limit () + x, r.inc (), r.numel ());
     if (result.m_numel < 0)
       result.m_cache = r.matrix_value () + x;

     return result;
   }

As I recall, setting the cache in these functions (and not just the matrix_value method) is done so that, for example, adding a constant to a range and then converting to a matrix will produce exactly the same result as converting a range to a matrix and then adding a constant to the matrix (in psuedo code):

   matrix (r) + c == matrix (r + c)

Using the cache this way does avoid the cost of any repeated conversions to a matrix value, but it also forces the cache to be created for any operation on a range, not just the result.  So it largely defeats the purpose of the efficient range object storage, and I'm wondering whether it is worth having a special range data type at all?  What do we really gain for the additional complexity?

I see now that there are limited cases where result.m_numel will be negative, so the cache is not updated for every operation.  However, the problems with the mutable cache remain, as do the issues with operations on ranges not being identical to the operations on the equivalent matrices.  Here is a simple example:

   r0 = 1:0.1:10;
   r1 = r0 + 2.3;   # range + scalar
   r2 = [r0] + 2.3; # matrix + scalar
   all (r1 == r2)   # returns false for me
   d = r1 - r2;     # show elements with differences
   idx = find (d)
   d(idx)

I understand the arguments about Octave being a numerical tool and not expecting exact results for floating point operations, but I'm still wondering whether the complexity of these range operations is justified.  If we do want to support operations that avoid immediate conversion to Matrix data, maybe we should only do so when we can guarantee that

   matrix (r) OP val == matrix (r OP val)

is true?  We should be able to do this when VAL and all elements of R are integers and will remain so after the operation.  Other cases might be possible as well, but harder to detect.  And maybe the cache should be eliminated and this test handled in the octave_value class hierarchy?

Are there any thoughts on this topic?

At the very leas, I would like to support integer ({u,}int{8,16,32,64}) and single-precision ranges in Octave. If possible, I'd like to have a unified solution for all range types, but that might be a somewhat disruptive change.

Comments would be helpful.

jwe




reply via email to

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