bugGNU Octave - Bugs: bug #47063, computation between single and...

 
 

bug #47063: computation between single and double performed with single precision

Submitted by:  CarnĂ« Draug <carandraug>
Submitted on:  Fri 05 Feb 2016 02:45:01 AM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  WTF, Matlab?!?
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Fri 18 Mar 2016 02:43:58 PM UTC, comment #4:

Since you asked on IRC...

It's better to write something like "perform mixed single-double ops in double precision (bug #...)" as the summary instead of "fix the bug...". Many patches are bug fixes and you're already tagging the bug report number so it's redundant to say "fix the bug".

Similarly, just write

* foo.h, foo.cc (function_name): New function.

instead of "add function ...". I think there are some tips about this in the Octave style guidelines in the Octave manual and also in the GNU coding standards document that it references.

John W. Eaton <jwe>
Project Administrator
Fri 18 Mar 2016 02:25:26 PM UTC, comment #3:

You are on the right track, but "demotion" means to reduce the rank of something, so that seems like the wrong word for a function that promotes float to double. It also makes no sense to have a demotion or promotion function that just makes a new value of the same type. Instead, if we are going to promote singles to doubles, we should remove the function that used to demote doubles to singles and add a promotion function for singles to doubles. And rename all of them, if we only need to do promotion. And you need to do it for matrix types as well, not just scalars.

But I'm still not sure this is a good idea. I'm not sure we should follow Matlab in this case.

John W. Eaton <jwe>
Project Administrator
Fri 18 Mar 2016 02:15:22 PM UTC, comment #2:

I have attached a file(patch) that solves this problem for single-double operations.
The idea is preventing double variables from being casted to single and on the other hand casting singles to doubles in order to perform the operation smoothly.

Amr Mohamed <amr_keleg>
Thu 10 Mar 2016 10:47:11 AM UTC, comment #1:

I would like towork on this bug can anyone guide me how interpreter works in octave.

SatyamPandey <spandey>
Fri 05 Feb 2016 02:45:01 AM UTC, original submission:

An operation between a double and a single returns a single for Matlab compatibility. However, it seems that Matlab actually performs the computations with doubles. See https://stackoverflow.com/questions/35213845/subtracting-double-precision-from-single-precision-gives-me-0-not-what-i-want

Carnë Draug <carandraug>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #36686:  ScalarFloatBugFix.diff added by amr_keleg (2KiB - text/x-patch - Kindly Review the attached patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by amr_keleg (Updated the item)
  • -email is unavailable- added by spandey (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by carandraug (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 project members can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-18 amr_keleg Attached File- => Added ScalarFloatBugFix.diff, #36686
    2016-02-21 mtmiller CategoryNone => Interpreter
        Operating SystemGNU/Linux => Any
    2016-02-05 jwe Item GroupInaccurate Result => WTF, Matlab?!?

    Back to the top


    Powered by Savane 3.3