bugGNU Octave - Bugs: bug #41672, fread for "float" not...

 
 

bug #41672: fread for "float" not matlab compatible

Submitter:  Rik <rik5>
Submitted:  Sat 22 Feb 2014 09:58:20 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 31 Aug 2017 10:48:41 PM UTC, comment #6: 

I made Octave compatible with Matlab both in action and in documentation in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/3706091dc91c).  Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Sat 26 Aug 2017 10:00:04 PM UTC, comment #5: 

I changed the documentation to show that "float" is not system-dependent, but actually 32 bits (http://hg.savannah.gnu.org/hgweb/octave/rev/58435a400d4e).

The Matlab documentation for fread (http://www.mathworks.com/help/matlab/ref/fread.html) has a table with all of the sizes in bits and bytes for each type.  These are not platform dependent.  Should the function "oct_data_conv::string_to_data_type (const std::string& str)" in liboctave/util/data-conv.cc be re-written?

Here is an excerpt:


  if (s == "int8" || s == "integer*1")
    retval = dt_int8;
  else if (s == "uint8")
    retval = dt_uint8;
  else if (s == "int16" || s == "integer*2")
    retval = dt_int16;
  else if (s == "uint16")
    retval = dt_uint16;
  else if (s == "int32" || s == "integer*4")
    retval = dt_int32;
  else if (s == "uint32")
    retval = dt_uint32;
  else if (s == "int64" || s == "integer*8")
    retval = dt_int64;
  else if (s == "uint64")
    retval = dt_uint64;
  else if (s == "single" || s == "float32" || s == "real*4")
    retval = dt_single;
  else if (s == "double" || s == "float64" || s == "real*8")
    retval = dt_double;
  else if (s == "char" || s == "char*1")
    retval = dt_char;
  else if (s == "schar" || s == "signedchar")
    retval = dt_schar;
  else if (s == "uchar" || s == "unsignedchar")
    retval = dt_uchar;
  else if (s == "short")
    GET_SIZED_INT_TYPE (short, );
  else if (s == "ushort" || s == "unsignedshort")
    GET_SIZED_INT_TYPE (unsigned short, u);
  else if (s == "int")
    GET_SIZED_INT_TYPE (int, );
  else if (s == "uint" || s == "unsignedint")
    GET_SIZED_INT_TYPE (unsigned int, u);
  else if (s == "long")
    GET_SIZED_INT_TYPE (long, );
  else if (s == "ulong" || s == "unsignedlong")
    GET_SIZED_INT_TYPE (unsigned long, u);
  else if (s == "longlong")
    GET_SIZED_INT_TYPE (long long, );
  else if (s == "ulonglong" || s == "unsignedlonglong")
    GET_SIZED_INT_TYPE (unsigned long long, u);
  else if (s == "float")
    {
      if (sizeof (float) == sizeof (double))
        retval = dt_double;
      else
        retval = dt_single;
    }
  else if (s == "logical")
    retval = dt_logical;
  else
    (*current_liboctave_error_handler) ("invalid data type specified");


Given that the sizes are fixed, it seems like "schar", for example, should return dt_int8 rather than dt_schar. 

This would also be the place to change unsigned long to return 32 bits.



Rik <rik5>
Group administrator
Wed 19 Mar 2014 06:46:48 PM UTC, comment #4: 


> Does Matlab really always force long to be 32 bits, even on 64-bit Linux systems?


Yes, it does.

On 64-bit Windows R2011a and 64-bit Linux R2010a:

>> oct_bug_41672

pos =
     8

arr =
    -1
    -1

pos =
     8


Philipp Kutin <pkutin>
Mon 10 Mar 2014 04:38:36 AM UTC, comment #3: 

This seems to be the case, the docs for fread/fwrite don't seem to distinguish between platform types.

Someone could verify by running the following in Matlab on 64-bit Windows:


fid = fopen('test.dat', 'wb');
fwrite(fid, int64(-1), 'int64');
pos = ftell(fid)
fclose(fid);
fid = fopen('test.dat', 'rb');
arr = fread(fid, inf, 'long')
pos = ftell(fid)
fclose(fid);


In 64-bit Octave, arr is a one-element array of -1, but in 64-bit Matlab it may be a two-element array of -1.

Mike Miller <mtmiller>
Group Member
Sun 23 Feb 2014 07:09:43 PM UTC, comment #2: 

I suspect that Matlab dropped the system-dependence of the float at some point.  We can too.

As for integer types, I think it is pretty much universal now that short is 16 bits and int is 32 bits and on 32-bit systems, long is also 32 bits.  But on 64-bit systems, long is 64 bits on Linux systems and still 32 bits on Windows systems.  Does Matlab really always force long to be 32 bits, even on 64-bit Linux systems?  If so, I guess we have to do the same or I'm sure we'll eventually get complaints about that difference.


John W. Eaton <jwe>
Group administrator
Sun 23 Feb 2014 06:33:17 PM UTC, comment #1: 

I think we've eliminated support for all non-IEEE floating point types now, so float will always be 32 bits. But that could be made more explicit to be Matlab compatible. I think the integer types are more troublesome, if we want Matlab compatibility we should get rid of all platform-dependence for the type names, right?

Mike Miller <mtmiller>
Group Member
Sat 22 Feb 2014 09:58:20 PM UTC, original submission:  

This may just be a documentation issue.  According to Matlab's documentation for fread (http://www.mathworks.com/help/matlab/ref/fread.html), the 'float' type should always be 32 bits.  Octave's documentation states that the 'float' type is platform dependent.  In fact this difference occurs for all the types which are not strictly defined by a standard (so short, long, etc.).

I don't if Octave is actually doing what it is saying it does, or whether it too just assumes float is 32 bits always.

Rik <rik5>
Group administrator

 

(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 pkutin (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-31 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-03-27 mtmiller CategoryNone Octave Function
        StatusNeed Info Confirmed
    2014-03-10 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code