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
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

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:

float_is_int (double x)
{
  double absx = fabs (x);
  double roundabsx = gnulib::round (absx);
  double na = nextafter (absx, roundabsx);
  if (na == roundabsx)
    return true;
  else
    {
      na = nextafter (na, roundabsx);
      if (na == roundabsx)
        return true;
      else if (nextafter (na, roundabsx) == roundabsx)
        return true;
    }
  return false;
}

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:

3,4c3,4
< # Date 1412154354 18000
< # Node ID 53f156abe4c95e33aec601291aa92b9662c05abd
---
> # Date 1412203130 18000
> # Node ID 6933dcc7bb3427e25d5157868dd8c9fe22d25491
307c307
< +      lspc_toB = lspc_fromA + lspc_Ninc;
---
> +      lspc_toB = lspc_fromA + lspc_Ninc * rng_inc;

(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

  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.

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    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.9