patchGNU Octave - Patches: patch #8548, New integerizing range algorithm...

 
 

patch #8548: New integerizing range algorithm for non-integer elements using better interp.

Submitted by:  Dan Sebald <sebald>
Submitted on:  Wed 01 Oct 2014 09:17:09 AM UTC  
 
Category:  Core : other Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 01 Oct 2014 10:56:20 PM UTC, comment #2:

Also, if one feels the tolerance of a single float discrepancy is too small, this can be addressed by calling nextafter() multiple times:

However, I'm inclinded to assume the tolerance of one floating point number away is adequate until shown otherwise. A test script with a good test should indicate if that isn't adequate on some developer's computer.

Dan Sebald <sebald>
Wed 01 Oct 2014 10:43:03 PM UTC, comment #1:

I found a small bug in the changeset. The difference with the newly attached changeset is:

(file #32210)

Dan Sebald <sebald>
Wed 01 Oct 2014 09:17:09 AM UTC, original submission:

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

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.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #32210:  octave-range-2014oct02.patch added by sebald (16KiB - application/octet-stream)
file #32204:  octave-range-2014oct01.patch added by sebald (16KiB - application/octet-stream)
file #32205:  rangetestscripts.m added by sebald (3KiB - application/vnd.wolfram.mathematica.package)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-07 lachlan CategoryNone => Core : other
    2014-10-01 sebald Attached File- => Added octave-range-2014oct02.patch, #32210
    2014-10-01 sebald Attached File- => Added octave-range-2014oct01.patch, #32204
        Attached File- => Added rangetestscripts.m, #32205

    Back to the top


    Powered by Savane 3.3