bugGNU Octave - Bugs: bug #43728, document / warn about integer...

 
 

bug #43728: document / warn about integer range multiplied with floating point scalar

Submitter:  Markus Appel <mappel>
Submitted:  Sun 30 Nov 2014 01:19:29 AM UTC
   
 
Category:  Libraries Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Documentation
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 27 Jul 2015 07:51:02 PM UTC, comment #5: 

I don't agree that this is only "incorrect documentation" ... since the behaviour is not matlab-compatible. Say you create two grids in Matlab (R2014b) with range times scalar and then use intersect to find common grid points:

>> x=(-3:1)*0.1;
>> y=(-2:2)*0.1;
>> intersect(x,y)

ans =

   -0.2000   -0.1000         0    0.1000


while octave gives:


>> x=(-3:1)*0.1;
>> y=(-2:2)*0.1;
>> intersect(x,y)
ans = 0


Using brackets [] instead of parenthesis () is indeed what I meant to do in the first place, and it gives the same result in both octave and Matlab.


Markus Appel <mappel>
Sun 31 May 2015 04:10:33 AM UTC, comment #4: 

Forgot to paste the relevant manual reference:

https://www.gnu.org/software/octave/doc/interpreter/Ranges.html

Mike Miller <mtmiller>
Group Member
Sun 31 May 2015 04:10:04 AM UTC, comment #3: 

It is pretty much stated in the manual that a range multiplied by a scalar gives another range, although maybe an extra example showing why you may not want that when dealing with floating point values would be warranted.

I think it's safe to say this is expected behavior, suggestions for patches to the manual welcome.

Mike Miller <mtmiller>
Group Member
Sun 31 May 2015 04:02:00 AM UTC, comment #2: 

I think the difference seen here may be because Octave allows a range to be multiplied by a scalar and the result is another range object. Multiplying the integer ranges by 0.1 as you have is effectively the same as a floating point range, with the drawbacks of which you were probably trying to avoid.

Specifically,


>> (-1:3) * 0.1 == -.1:.1:(3*.1)
ans =

   1   1   1   1   1

>> (-1:3) * 0.1 == [-.1, 0, .1, .2, .3]
ans =

   1   1   1   0   0

>> (-1:3) * 0.1 == [-1:3] * 0.1
ans =

   1   1   1   0   1

>> [-1:3] * 0.1 == [-.1, 0, .1, .2, .3]
ans =

   1   1   1   1   0


I would like to say this is working as expected, and what you really meant to do was [-1:3]*0.1 to expand the range into a full matrix of integers first, and then multiply elementwise by the scalar. Could be better documented somehow?

Mike Miller <mtmiller>
Group Member
Sun 30 Nov 2014 11:32:30 AM UTC, comment #1: 

Well, it is not just starting with negative index since:
octave:47> mx=(-1:2)*0.1
mx =

   -0.100000000000000    0.000000000000000    0.100000000000000    0.200000000000000

octave:48> mx(4)==0.2
ans =  1

but:
octave:49> mx=(-1:3)*0.1
mx =

 Columns 1 through 4:

   -0.100000000000000    0.000000000000000    0.100000000000000    0.200000000000000

 Column 5:

    0.300000000000000

octave:50> mx(4)==0.2
ans = 0
And, of course:
octave:51> mx=(0:4)*0.1
mx =

 Columns 1 through 4:

    0.000000000000000    0.100000000000000    0.200000000000000    0.300000000000000

 Column 5:

    0.400000000000000

octave:52> mx(3)==0.2
ans =  1

Michael Godfrey <godfrey>
Group Member
Sun 30 Nov 2014 01:19:29 AM UTC, original submission:  

In the following example, I would expect the superdiagonal to be 1 everywhere:


octave:16> m1=(-1:3)*0.1 ; m2=(0:4)*0.1 ; m1==m2'
warning: mx_el_eq: automatic broadcasting operation applied
ans =

   0   1   0   0   0
   0   0   1   0   0
   0   0   0   0   0
   0   0   0   0   1
   0   0   0   0   0


... but it isn't due to a floating point error:


octave:17> m1(4)-m2(3)
ans =    2.7756e-17


Seen on Ubuntu 12.04 with octave 3.8.0 and dev. Matlab R2012b gives the expected result ( with bsxfun(@eq,m1,m2') instead of m1==m2' ).

Complementary tests:

It seems that something goes wrong when the range extends to negative integers, I could not reproduce it with positive ranges only:


octave:89> m1=(1:5)*0.1 ; m2=(0:4)*0.1 ; m1==m2'
warning: mx_el_eq: automatic broadcasting operation applied
ans =

   0   0   0   0   0
   1   0   0   0   0
   0   1   0   0   0
   0   0   1   0   0
   0   0   0   1   0


And using a decimal that can be represented exactly also seems to work fine:


octave:94> m1=(-1:3)*0.125 ; m2=(0:4)*0.125 ; m1==m2'
warning: operator -: automatic broadcasting operation applied
ans =

   0   1   0   0   0
   0   0   1   0   0
   0   0   0   1   0
   0   0   0   0   1
   0   0   0   0   0


Markus Appel <mappel>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mappel (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 group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-01 mtmiller Carbon-CopyRemoved 80942 -
    2015-05-31 mtmiller CategoryInterpreter Libraries
        Severity3 - Normal 2 - Minor
        Item GroupIncorrect Result Documentation
        StatusNone Need Info
        Operating SystemGNU/Linux Any
        Summaryrounding error for integer range multiplied with floating point document / warn about integer range multiplied with floating point scalar

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code