[Top][All Lists]

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

[Octave-bug-tracker] [bug #32497] Matlab differences when using abbrevia

From: Nicholas Jankowski
Subject: [Octave-bug-tracker] [bug #32497] Matlab differences when using abbreviated PROPERTY names
Date: Sat, 23 Mar 2019 23:17:18 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299

Follow-up Comment #9, bug #32497 (project octave):

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 = 

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

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

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

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. 


Reply to this item at:


  Message sent via Savannah

reply via email to

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