[Octave-patch-tracker] [patch #8548] New integerizing range algorithm for non-integer elements using better interp.

[Dan Sebald]

URL:
  <http://savannah.gnu.org/patch/?8548>

                 Summary: New integerizing range algorithm for non-integer
elements using better interp.
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Wed 01 Oct 2014 09:17:09 AM GMT
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

The attached changeset is a hybrid of the existing Range algorithm for integer
elements and a new Range algorithm for non-integer elements that attempts to
"integerize" the underlying problem as a linear spacing.  It basically covers
all the combinations of limits and range as a whole number of increments.  It
seems to work pretty robustly, and at the same time avoids immediately
converting a Range object to a matrix_value object.  So the improvement
appears to be better numerical behavior in the circumstance most common where
the user enters evenly spaced decimal numbers (-2:.1:.1) and even scalings
inside the range such as (-N*pi:0.1*pi:N*pi).

Actually, there isn't too much new here.  I think it is more a case of
organizing things well enough to have the various float_is_int variations for
the limits/increment.  The patch chooses either an algorithm good for integers
or one good for floats.  I've centralized the algorithm so one can tweak
things pretty easily.

No need for a "convert to matrix_value" compile option.

I tried incorporating GNU library's ceil(), fabs(), and nextafter() functions
into the project, similar to gnulib::floor(), but I don't think I quite figure
it out.  I have some form of these routines in place though.  I wanted to
ensure they were all the gnulib routines because presumably these all work
nicely together in terms of floating point bit behavior.

We really need some tests for the range function, e.g., "test ::" or something
like.  The dodgy part is declaring a float to be the equivalent of an int. 
I've used within one floating point difference with the "nextafter" command. 
There is some other existing code that appears to use three floating point
numbers away.  Anyway, this could be hardware specific, depending upon the
number of guard bits and resolution used internal to the ALU.  I'm assuming
that most processors use lots of extra bits internally so that the math
operations come out within a bit of the IEEE Float value.

I removed the unused member functions


  Range::set_base
  Range::set_limit
  Range::set_inc


because it seems like those parameters should remain encapsulated, untouched
by outside code.  Changing those values has a lot of ramifications on other
parameters.  An external class modifying those parameters directly doesn't
take that into account.

I've also included a file of some sample range commands.





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 01 Oct 2014 09:17:09 AM GMT  Name: octave-range-2014oct01.patch 
Size: 16kB   By: sebald

<http://savannah.gnu.org/patch/download.php?file_id=32204>
-------------------------------------------------------
Date: Wed 01 Oct 2014 09:17:09 AM GMT  Name: rangetestscripts.m  Size: 3kB  
By: sebald

<http://savannah.gnu.org/patch/download.php?file_id=32205>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8548>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/