[Octave-bug-tracker] [bug #58147] Matlab 2020 compatibility: dec2bin, dec2hex shouldn't error on negative inputs

[Rik]

Update of bug #58147 (project octave):

                 Release:                   5.2.0 => dev                    

    _______________________________________________________

Follow-up Comment #11:

Matlab programmers apparently enjoy introducing inconsistencies in to their
code.  According to the documentation, 


If D is an array of floating-point numbers, and any element of D has a
fractional part, then dec2bin truncates it before conversion. For example,
dec2bin converts both 12 and 12.5 to '1100'. The truncation is always to the
nearest integer less than or equal to that element.


This is equivalent to floor(), and I can verify with


dec2bin (12)   => "1100"
dec2bin (12.1) => "1100"
dec2bin (12.9) => "1100"
dec2bin (13)   => "1101"


However, for negative numbers they have an entirely different convention and
use round().


dec2bin (-12)   => "11110100"
dec2bin (-12.1) => "11110100"
dec2bin (-12.9) => "11110011"
dec2bin (-13)   => "11110011"


Currently, Octave does stricter input validation than Matlab and issues an
error whenever the input is not an integer.  For the moment, I think we should
keep that standard and force the programmer to decide on a rounding strategy
(fix, floor, ceil, round) so that the decision is explicit.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58147>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/