bugGNU Octave - Bugs: bug #32497, Matlab differences when using...

 
 

bug #32497: Matlab differences when using abbreviated PROPERTY names

Submitter:  Thomas Dean <tomdean>
Submitted:  Tue 15 Feb 2011 09:46:42 PM UTC
   
 
Category:  Plotting Severity:  2 - Minor
Priority:  3 - Low Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Thomas Dean 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

Sun 01 Aug 2021 10:31:21 AM UTC, comment #17: 

I agree. It looks like the original issue was fixed somewhere along the way.

Closing as report.

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Jul 2021 04:00:50 PM UTC, comment #16: 

it appears that what is left of this old bug is specific to implementation in an external package and separate from what initiated the report.  recommend it be closed and new issues be made in new, specific reports.

Nicholas Jankowski <nrjank>
Group Member
Fri 02 Apr 2021 11:43:59 PM UTC, comment #15: 

yes, that version of m_grid avoids the encoding issue.  it still has the 'disappearing figure' issue when he turns axes visibility off.

since he has an MAP_PROJECTION.IsOctave flag, should be straightforward to edit that block of code to:

starting at line 594:


if isempty(strfind(version,'R2013b'))  % 27/Sept/13 - Handling for 2013b provided by CB.
    set(ax,'visible','off',...
            'dataaspectratio',[1 1 1],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
else
    set(ax,'visible','off',...
            'dataaspectratio',[1 1 1e16],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
end


to something like:


if (MAP_PROJECTION.IsOctave)
    set(ax,'xcolor','none',...
    'ycolor','none',
    'dataaspectratio',[1 1 1e16],...
    'xlim',MAP_VAR_LIST.xlims,...
    'ylim',MAP_VAR_LIST.ylims);
else

  if isempty(strfind(version,'R2013b'))  % 27/Sept/13 - Handling for 2013b provided by CB.
      set(ax,'visible','off',...
            'dataaspectratio',[1 1 1],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
  else
      set(ax,'visible','off',...
            'dataaspectratio',[1 1 1e16],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
 end
end


Nicholas Jankowski <nrjank>
Group Member
Fri 02 Apr 2021 07:53:30 AM UTC, comment #14: 

I contacted the author of m_map about the encoding issue directly, and he asked me to test the attached file.
Unfortunately, I haven't found a self-contained test case here or in the discourse thread.
I hope it's ok with him if I share his function here.

Does the attached file prevent the encoding error?


(file #51177)

Markus Mützel <mmuetzel>
Group administrator
Thu 01 Apr 2021 07:04:14 PM UTC, comment #13: 

as discussed in a conversation over on the Octave Discourse page  [1], the following code changes create an m_grid that runs in Octave:

add the following before the label blocks to remove any degree symbols and just replace them with blank spaces:


labs = cellfun(@strrep, labs, {char(176)},{char(32)},"UniformOutput",false);


And replace the aspect ratio block with:

  set(ax,'xcolor','none',...
    'ycolor','none',
    'dataaspectratio',[1 1 1e16],...
    'xlim',MAP_VAR_LIST.xlims,...
    'ylim',MAP_VAR_LIST.ylims);


There are still some issues with label layout (rotation, and exact placement), but it's fairly functional, and it produces the following:

Octave:
file Octave_m_grid.png

versus in Matlab 2020b with the original scripts:
file Matlab_m_grid.jpg

I've also attached the version of m_grid.m edited to work only in Octave.

[1] https://octave.discourse.group/t/a-problem-with-function-regexprep/981/5

file #51171,

Nicholas Jankowski <nrjank>
Group Member
Wed 24 Mar 2021 05:51:40 PM UTC, comment #12: 

ok, understood. So this just falls under the already well documented multi-byte unicode compatibility issues?

Nicholas Jankowski <nrjank>
Group Member
Wed 24 Mar 2021 12:08:36 PM UTC, comment #11: 

With respect to the UTF-8 error message:
char(176) is not valid UTF-8. The only valid single byte sequences in UTF-8 are for the codepoints it shares with ASCII (0-127).

You could convert to UTF-8 using, e.g.:

native2unicode(176, 'iso-8859-1');


Or depending on where the degree sign comes from, setting the .m file encoding to 'iso-8859-1' might also help.

Markus Mützel <mmuetzel>
Group administrator
Tue 23 Mar 2021 09:08:20 PM UTC, comment #10: 

new version, new update, new error. testing this in both Octave 6.2.0 and Matlab R2020b, the non-compatibility with the comment #0 script has changed (it appears that the package and Octave have changed a bit in the past two years). 

TL;DR: i think bug should be closed.

running the comment #5 test scripts in Matlab produce the expected plot of the shape of the Oregon/British Columbia coast with superimposed latitude/longitude grid.

running in Octave 6.2.0, the plot up to m_coast is produced, but running the m_grid command the new error is now:


octave:14> m_grid
error: regexprep: the input string is invalid UTF-8
error: called from
    text at line 176 column 14
    m_grid at line 491 column 4


current line 491 appears to be the same line as the line 345 causing errors in the previous comments:


for k=ik
   [rotang(k), horizk, vertk] = upright(rotang(k), horiz, vert);
   text(xx(k),yy(k),labs{k},'horizontalalignment',horizk,'verticalalignment',vertk, ...
        'rotation',rotang(k),'fontsize',gfontsize*scl(k),'color',gcolor,...
        'tag','m_grid_xticklabel','fontname',gfontname,'parent',ax);
 end


Note that it calls 'horizontalalignment' in full.  Now, however, instead of the ambiguous property error the error is about the call to text(x(k),y(k),label{k}), where in Matlab I see the label contents as:


 5×1 cell array

    {' 136°W '}
    {' 132°W '}
    {' 128°W '}
    {' 124°W '}
    {' 120°W '}


in Octave, it has issues with char(176) or °. Confirming this, just running in Octave: 


>> figure
>> text(1,2,char(176))
error: regexprep: the input string is invalid UTF-8
error: called from
    text at line 176 column 14


Is it expected to get this error message? I thought it is valid UTF-8? or is it just the usual non-ascii character problem and it means UTF-8 usage is invalid?

If I break the script and delete the °, the script runs without either the new or old errors.

it does however, run into another apparent compatibility issue where a Matlab command rescales the figure and hides the x-y axes leaving the map, but in octave hiding the x-y axes hides the entire figure.  The code block in question at line 590 is:


% Give a 1-1 aspect ratio and get rid of the matlab-provided axes stuff.


if isempty(strfind(version,'R2013b'))  % 27/Sept/13 - Handling for 2013b provided by CB.
    set(ax,'visible','off',...
            'dataaspectratio',[1 1 1],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
else
    set(ax,'visible','off',...
            'dataaspectratio',[1 1 1e16],...
            'xlim',MAP_VAR_LIST.xlims,...
            'ylim',MAP_VAR_LIST.ylims);
end


Note it runs the first 'not R2013b' block.  In Matlab, this turns off the axes and leaves the figure contents. In octave, this turns off the whole figure. Is that a bug? Already reported? Known behavior?

worth noting that the comment #7 and comment #9 behaviors are unchanged.

Since this is a 10+ year old bug, the last error on using the actual package in question is from 2013, the package no longer triggers the bug in the title...  I think this can be closed. Unless the property ambiguity behavior still needs to be ironed out for compatibility.

If either the regexp issue or the 'ax, visible, off' issue are new and unreported, they can become other bugs.

Nicholas Jankowski <nrjank>
Group Member
Sun 24 Mar 2019 03:17:18 AM UTC, comment #9: 

updating that the script from comment #7 still returns true in Octave 5.1.0

On the issue of 'it works in matlab' - are there any examples anyone can point out where matlab has ambiguous property names that behave differently than erroring out?

using the fieldnames example from the script, there are several FontXYZ properties. if can call:


>> get(text,'FontSize')
ans =
    10

>> get (text,'FontSmoothing')
ans =
    'on'

>> get (text,'FontS')
Error using matlab.graphics.primitive.Text/get
There is no FontS property on the Text class.

>> get (text,'FontSm')
ans =
    'on'


So, Octave is behaving better than Matlab I think if it actually gives you suggested property names instead of just an error. 

I guess then this boils down to the problem of: Is it a compatibility error if Octave implements a property that triggers an ambiguity while running the same code in Matlab does not? From Comment #1 and Comment #3, it sounds like maybe the answer is no, as Octave having a superset of capabilities relative to Matlab has never been seen as a bug, even though this does trigger an non-compatibility error.


Nicholas Jankowski <nrjank>
Group Member
Sat 19 Nov 2016 02:23:04 PM UTC, comment #8: 

This issue seems to still be present in Octave 4.2.0. (The script from comment #7 still returns true.)

Hartmut <hardy>
Wed 10 Sep 2014 07:33:35 AM UTC, comment #7: 

Maybe a reasonable solution for this bug would be to not allow the abbrev matching to search also for hidden properties names. A user can't know that a given pattern is ambiguous as long as the following test returns true:


pattern = "horiz";
fields = fieldnames (get (text ()));
tst = @cellfun (@(s) strncmp (pattern, s, length (pattern)), fields);
sum (tst) == 1



Pantxo Diribarne <pantxo>
Group Member
Thu 07 Nov 2013 04:22:45 PM UTC, comment #6: 

The solution is simple, don't use an ambiguous abbreviated property name.  In this case, search for a line with 'horizontal' and replace the 'horizontal' with 'horizontalalignment'.

Rik <rik5>
Group administrator
Thu 07 Nov 2013 02:46:38 PM UTC, comment #5: 

Hello
I have repeated what Thomas Dean done on  15 Feb 2011 21:46:43 +0000
U
I downloaded the m_map Matlab application from
http://www.eos.ubc.ca/~rich/map.html

1.  Start octave
2.  cd to the m_map directory
3.  addpath("private");
4.  m_proj('oblique mercator'); m_coast;
5.  m_grid;
error: get: ambiguous text property name horizontal; possible matches:

horizontalalignment      horizontalalignmentmode

error: called from:
error:   /usr/share/octave/3.6.4-rc0/m/plot/text.m at line 99, column 5
error:   /home/users/dacosta/M_MAP/m_map/m_grid.m at line 345, column 4
error: _go_draw_axes_: gnuplot (as of v4.2) only supports 3D filled triangular patches
error: called from:
error:   /usr/share/octave/3.6.4-rc0/m/plot/private/__go_draw_axes__.m at line 647, column 20
error:   /usr/share/octave/3.6.4-rc0/m/plot/private/__go_draw_figure__.m at line 167, column 19
error:   /usr/share/octave/3.6.4-rc0/m/plot/__gnuplot_drawnow__.m at line 86, column 5

Do you have any suggestion for avoiding this error ?

Thanks a lot in advance.

Ed.




Anonymous
Fri 10 Feb 2012 05:46:22 PM UTC, comment #4: 

Re-titling report to reflect true issue.

Rik <rik5>
Group administrator
Wed 16 Feb 2011 08:33:13 PM UTC, comment #3: 

This seems like a lot of added complexity to solve a "problem" that can be avoided by using the full property names.  Presumably, the list of properties in Matlab can also change over time, so which set of properties is Octave expected to conform to, and who maintains the list?  I guess you would not want the list compiled in to Octave so that it could be easily updated without recompiling?

I would perhaps consider such a change, but I'm not going to volunteer to implement it myself.

John W. Eaton <jwe>
Group administrator
Wed 16 Feb 2011 07:20:01 PM UTC, comment #2: 

If we compile a list of property names that exist in Matlab, then perhaps in those cases that the abbreviation would be resolvable against the list of properties that Matlab supports, we can resolve it to the Matlab expansion and issue a warning instead of an error?

Rather than issuing an error that "horizontalalignment" and "horizontalalignmentmode" conflict and stopping execution when encountering "horizontal", octave could instead check the alternatives against the Matlab compatibility list and if a unique solution was found issue a warning and continue with the Matlab expansion.

So in this case "horizontalalignment" and "horizontalalignmentmode" would be searched and presumabley "horizontalalignment" would be found but "horizontalalignmentmode" would not. Octave would issue a warning asking the user to repair the code, and then continue while using the "horizontalalignment" property.

Thoughts?

Judd Storrs <judd>
Wed 16 Feb 2011 06:24:08 PM UTC, comment #1: 

Apparently in this case, Matlab does not have a horizontalalignmentmode property, so horizontal is not ambiguous?

But what happens if they do add a new property that makes previously unique abbreviations ambiguous?

Should Octave not ever provide additional properties over what is provided in Matlab?

I don't know what the best solution is here, except to recommend that you not use abbreviated property names.

John W. Eaton <jwe>
Group administrator
Tue 15 Feb 2011 09:46:42 PM UTC, original submission:  

I downloaded the m_map Matlab application from
http://www.eos.ubc.ca/~rich/map.html

1.  Start octave
2.  cd to the m_map directory
3.  addpath("private");
4.  m_demo();

error: get: ambiguous text property name horizontal; possible matches:

horizontalalignment      horizontalalignmentmode

error: called from:
error:   /usr/local/share/octave/3.4.0/m/plot/text.m at line 78, column 18
error:   /home/tomdean/Math/Octave/work/m_map/m_grid.m at line 345, column 4
error:   /home/tomdean/Math/Octave/work/m_map/m_demo.m at line 40, column 5
error: _go_draw_axes_: gnuplot (as of v4.2) only supports 3D filled triangular patches
error: called from:
error:   /usr/local/share/octave/3.4.0/m/plot/__go_draw_axes__.m at line 595, column 20
error:   /usr/local/share/octave/3.4.0/m/plot/__go_draw_figure__.m at line 167, column 19
error:   /usr/local/share/octave/3.4.0/m/plot/__gnuplot_drawnow__.m at line 86, column 5

Using m_demo(n) where 0<= n <= 13 shows some other incompatibilities.

Thomas Dean <tomdean>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51177:  m_grid.m added by mmuetzel (35KiB - text/plain)
file #51170:  Octave_m_grid.png added by nrjank (36KiB - image/png - m_grid edited to work with Octave. )
file #51171:  m_grid.m added by nrjank (34KiB - application/octet-stream - m_grid edited to work with Octave. )
file #51172:  Matlab_m_grid.jpg added by nrjank (38KiB - image/jpeg - m_grid edited to work with Octave. )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by judd (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by tomdean (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 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-01 mmuetzel StatusNone Fixed
        Open/ClosedOpen Closed
    2021-04-02 mmuetzel Attached File- Added m_grid.m, #51177
    2021-04-01 nrjank Attached File- Added Octave_m_grid.png, #51170
        Attached File- Added m_grid.m, #51171
        Attached File- Added Matlab_m_grid.jpg, #51172
    2019-03-24 mtmiller Carbon-CopyRemoved 80942 -
    2014-01-19 mtmiller CategoryNone Plotting
        Release3.4.0 dev
        Operating SystemGNU/Linux Any
    2013-11-07 rik5 Carbon-CopyRemoved 72865 -
    2012-02-10 rik5 Severity3 - Normal 2 - Minor
        SummaryMatlab Incompatibilities Matlab differences when using abbreviated PROPERTY names
    2011-02-21 rik5 Priority5 - Normal 3 - Low

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code