Re: bin2dec behavior different from Matlab?

[Daniel J Sebald]

On 03/15/2012 10:57 PM, Miguel Bazdresch wrote:
> Hello,
>
> In my teaching I encourage students to use Octave, but some of them
> cling to Matlab. Today we found different behavior between the two:
>
> In Octave, both 3.4 and 3.6,
>
> >  s=num2str([1 0 1])
> s = 1 0 1
> >  bin2dec(s)
> ans = 257
>
> In Matlab (version 2009), the same commands result in number 5.

In Octave 3.2.4 I'm seeing an answer of 5.


> I believe Octave is interpreting the spaces in 's' as zeros, which
> explain the answer of 257. In any case, this difference in behavior is
> something we may want to address. Personally, I find Matlab's behavior
> to be more reasonable and useful in this particular case.

What you are saying about treating spaces as zero is true.  bin2dec() 
defers to base2dec (, 2) and base2dec does the following:

  ## Lookup value of symbols in symbol table, with invalid symbols
  ## evaluating to NaN and space evaluating to 0.
  table = NaN * ones (256, 1);
  table (toascii (symbols (1 : base))) = 0 : base-1;
  table (toascii (" ")) = 0;

What scenario should this behavior lend itself to, I can't imagine.

The thing that has changed in recent versions is that bin2dec no longer 
removes the white space as it used to:

      s = s(! isspace (s));

is missing from bin2dec in the online source tree.

This change happened with changeset 11172:7e8ce65f73cf shown here

http://hg.savannah.gnu.org/hgweb/octave/rev/7e8ce65f73cf

which overhauled the string number conversion routines.  (Maybe the 
intent was to move white space removal inside base2dec.)

In my opinion tossing away white space makes better sense than treating 
white space as zeros.

I also suggest adding a test to the file.  There currently are several, 
but none that test the behavior of white space.  E.g.,

%!assert (bin2dec ("1 0 1"), 5)

Dan