bugGNU Octave - Bugs: bug #41770, Some factory defaults don't...

 
 

bug #41770: Some factory defaults don't conform to matlab values

Submitted by:  Pantxo Diribarne <pantxo>
Submitted on:  Tue 04 Mar 2014 12:45:26 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 13 Apr 2014 03:57:09 PM UTC, comment #11:

For locale-specific defaults, is it as simple as using the existing site-wide octaverc file to set defaults?

I have 3.8.1 installed in /usr/local and the relevant file is /usr/local/share/octave/3.8.1/m/startup/octaverc.

You could place a bunch of commands like

in that file.

Rik <rik5>
Project Administrator
Sun 13 Apr 2014 03:29:25 PM UTC, comment #10:

We are getting a build failure due to the changes applied so far for this bug:

http://hydra.nixos.org/build/10317330/log/tail-reload

I pushed the following change to fix this error:

http://hg.savannah.gnu.org/hgweb/octave/rev/93d0fc8a5d86

Mike Miller <mtmiller>
Project Administrator
Sun 13 Apr 2014 08:42:44 AM UTC, comment #9:

Hello Rik,

Thanks for the review of all those patches.
I checked the properties you mentioned in matlab:

"cameraupvector" value depends on the type of object (and probably the current axes "view" property), but its factory value is not conform to their documentation.

"alphadatamapping" is not conform to their documentation neither, at least in the version I use for testing.

Coming back to my interrogation, do someone have an idea on a central place to set non factory defaults? E.g. locale specific defaults (papersize, paperunits) could be set there (as a European I'd really be happy to not mess with those esoteric inches :-).

Pantxo Diribarne <pantxo>
Project Member
Sat 12 Apr 2014 08:40:23 PM UTC, comment #8:

Now that image objects have a DisplayName property, they should be supported by legend(). I filed a separate bug report about that feature here https://savannah.gnu.org/bugs/?42103.

Rik <rik5>
Project Administrator
Sat 12 Apr 2014 08:31:25 PM UTC, comment #7:

I modified your patch slightly for Octave coding conventions. We place the '++' modifier directly next to the variable, e.g., 'C++' rather than 'C ++'. We also prefer to use the C++ casting standards so I changed

I checked it in here (http://hg.savannah.gnu.org/hgweb/octave/rev/2deed6538c72).

Could you double-check two of the values?

According to http://www.mathworks.com/help/matlab/ref/image_props.html the default for AlphaDataMapping is 'scaled' (what it was before) rather than 'none'.

According to http://www.mathworks.com/help/matlab/ref/axes_props.html the default CameraUpVector is [0 0 1], rather than [0 0 0].

Rik <rik5>
Project Administrator
Sun 06 Apr 2014 04:53:30 PM UTC, comment #6:

Sorry if it looks like I use the bug tracker to show my drafts but each time I come back to this bug I discover something new.

In ML as in octave you can display all the root defaults using "get (0, 'default')". Matlab result :

So you can see all the "color" properties I described, but also some run time defaults for figures and axes properties.

In octave the result depends on wether the graphics toolkit (Qt here) is loaded:

My impression is that, if we want to be reasonably compatible with ML here, there should be a central place where defaults (toolkit specific or not) are set at startup (or after a neww toolkit has been loaded) .

Even if we don't want to follow matlab on every choice (such as the default figure color) it can be usefull to reassemble all non-factory defaults in one place.

Is there a convenient place to do that? Any comment?

Pantxo Diribarne <pantxo>
Project Member
Sun 30 Mar 2014 09:36:04 PM UTC, comment #5:

I attached a new version of the patch.

I added "octave-default-image.h" in libinterp/corefcn. It contains the octave logo (64x64 char array) indexed against the "Jet" colormap.

Remaining issues:
*'surfaceedgecolor', 'patchedgecolor', 'patchfacecolor', 'linecolor' (see comment #4): if we want to be fully conform with ML factory defaults, those properties values will have to be changed at startup (using e.g. "set (0, "defaultPROPNAME", VAL)").
*'surfacefacelighting', 'patchfacelighting': factory values should be 'flat' instead of 'none' but the current implementation in openGL renders black surfaces/patches. I think we should wait until the bug (bug #42006) is solved before setting the correct values for those properties.

(file #31080)

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Mar 2014 10:09:39 PM UTC, comment #4:

cdata: should octave logo be loaded (and how) at run time or included from a data header file at compile time?

color:

AFAICS, octave and ML perform pretty much the same (see the diagram in [1]). The thing is for lines ML has to change the line default at run time. Looks like internal cuisine that leads to weird behavior after reset. If it as acceptable to not have the same factory default here, I would not try to mimic this ML behavior.

In ML you can retrieve root level (default && !factory) for a given graphic object type using "get (0, 'defaultOBJTYPE')"

Now about "displayname", forget about it: the error message is the same with or without the added property. I did not investigate but it looks like images don't qualify as an "legendable" object. I would add the property, and file a bug report for legend.

Finally, I'll have to rework the patch anyway as I just noticed it breaks "surface ()" default behavior.

[1] http://www.mathworks.fr/fr/help/matlab/creating_plots/setting-default-property-values.html

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Mar 2014 08:21:47 PM UTC, comment #3:

For cdata, how about just embedding the data for the Octave logo?

For the line color property, do Octave and Matlab behave differently for

? Is Octave just not using the defaultlinecolor propertly correctly when drawing lines? Is this unique to lines, or is it a deeper problem with all default properties?

I'm not sure what to do about the image displayname property. What's the exact problem with legend?

John W. Eaton <jwe>
Project Administrator
Tue 25 Mar 2014 10:45:15 PM UTC, comment #2:

I see I have missed some of the non conforming factory defaults. I updated the patch but some differences remain.

The main one is in image properties: "cdata" should contain the factory image (double [64x64]) color data. Is there such default image that can be read in octave tree (preferably without requiring GraphicsMagick)?

Some other minor problems:
- line: "color" should be [1 1 1] (but then "line ()" returns a white line). In ML black color is set in root "defaultlinecolor" so that if you "reset (0)" you fall back to factory defaults and also obtain white lines.
- text: "clipping" should be "off" but as it belongs to base_properties it is "on" by default for every graphics objects. Same problem with "color" as for line objects.
- patch: "facecolor" same color problem
- image: should have a "displayname" property. Adding this property is easy but then legend fails when there is an image in the axes.

(file #31038)

Pantxo Diribarne <pantxo>
Project Member
Mon 24 Mar 2014 08:43:27 PM UTC, comment #1:

Pantxo,

I applied your patch and confirmed that all graphics.cc tests pass for me on MacOSX.

Ben Abbott <bpabbott>
Project Member
Tue 04 Mar 2014 12:45:26 PM UTC, original submission:

I have only investigated defaults returning empty matrices that shouldn't. This is not a big issue as they are updated when an object is created but querying their factory value doesn't return the expected value as in Matlab (attached matlabfactory.mat file).

You may try the following in octave 3.8 or dev:

I also attached a patch that make this test script pass (and all tests in graphics.cc still pass)

Pantxo Diribarne <pantxo>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #30769:  matlabfactory.mat added by pantxo (254B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by pantxo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 19 Apr 2014 02:38:11 AM UTCrik5StatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Sat 12 Apr 2014 08:31:50 PM UTCrik5Item GroupIncorrect Result=>Matlab Compatibility
      StatusNone=>In Progress
    Sun 30 Mar 2014 09:36:04 PM UTCpantxoAttached File-=>Added adjust_factorydefaults_v3.patch, #31080
    Tue 25 Mar 2014 10:45:15 PM UTCpantxoAttached File-=>Added adjust_factorydefaults_v2.patch, #31038
    Tue 04 Mar 2014 12:45:26 PM UTCpantxoAttached File-=>Added matlabfactory.mat, #30769
      Attached File-=>Added adjust_factorydefaults.patch, #30770

    Back to the top


    Powered by Savane 3.1-cleanup1