octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #42562] 3.8.1 can't load mat file (>maltab r20


From: Juan Pablo Carbajal
Subject: [Octave-bug-tracker] [bug #42562] 3.8.1 can't load mat file (>maltab r2010b)
Date: Mon, 16 Jun 2014 01:36:20 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Follow-up Comment #11, bug #42562 (project octave):

OK, I think I found the problem.

I created a file as explained below using R.


hexdump -C test.mat 
00000000  4d 41 54 4c 41 42 20 35  2e 30 20 4d 41 54 2d 66  |MATLAB 5.0
MAT-f|
00000010  69 6c 65 2c 20 50 6c 61  74 66 6f 72 6d 3a 20 75  |ile, Platform:
u|
00000020  6e 69 78 2c 20 53 6f 66  74 77 61 72 65 3a 20 52  |nix, Software:
R|
00000030  20 76 33 2e 30 2e 32 2c  20 43 72 65 61 74 65 64  | v3.0.2,
Created|
00000040  20 6f 6e 3a 20 4d 6f 6e  20 4a 75 6e 20 31 36 20  | on: Mon Jun 16
|
00000050  30 33 3a 30 32 3a 33 31  20 32 30 31 34 20 20 20  |03:02:31 2014  
|
00000060  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |               
|
00000070  20 20 20 20 20 20 20 20  20 20 20 20 00 01 49 4d  |           
..IM|
00000080  0e 00 00 00 40 00 00 00  06 00 00 00 08 00 00 00 
|address@hidden|
00000090  06 00 00 00 00 00 00 00  05 00 00 00 04 00 00 00 
|................|
000000a0  01 00 00 00 00 00 00 00  01 00 00 00 07 00 00 00 
|................|
000000b0  6c 61 74 65 6e 63 79 00  09 00 00 00 08 00 00 00 
|latency.........|
000000c0  00 00 00 00 00 00 14 40                           |.......@|
000000c8


As anonymous pointed out the tag for dimension of the data element is in 0x90

05 00 00 00 04 00 00 00

According to the format specification (note on page 1-17) the 04 means there
is a single dimension (1x1 not 1x0). This is correctly calculated in line 669
of ls-mat5.cc. However in the following for loop the index_type dims is not
fully fill and is left as 1x0.

This is a miss interpretation of the format specification. If the number of
dimensions is 1 then the data should be seen as 1x1.

The fix of anonymous works cause ndims is 2 in that case and each value 1, so
the resulting index_type dims is 1x1.

Is this correct?

I arrive to this conclusion by looking at the actual creation of the data
container in octave


1418            NDArray re (dims);
...      
1430            octave_idx_type n = re.numel ();
(gdb) p re
$21 = {<MArray<double>> = {<Array<double>> = {
      _vptr.Array = 0x7ffff7d18150 <vtable for NDArray+16>, 
      dimensions = {rep = 0x7c6548}, rep = 0x7c65e0, 
      slice_data = 0x7ce750, 
      slice_len = 0}, <No data fields>}, <No data fields>}




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42562>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]