bugGNU Octave - Bugs: bug #38449, Changing default*units triggers a...

 
 

bug #38449: Changing default*units triggers a position update

Submitter:  Muhali <muhali>
Submitted:  Fri 01 Mar 2013 12:26:40 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 13 Sep 2014 03:08:40 PM UTC, comment #14: 

Yes, I followed your advice and bravely pushed a second one :-)

Pantxo Diribarne <pantxo>
Group Member
Sat 13 Sep 2014 01:04:46 PM UTC, comment #13: 

Good.  Often the only way to get significant testing done is to push the change.

Ben Abbott <bpabbott>
Group Member
Sat 13 Sep 2014 09:26:14 AM UTC, comment #12: 

Hi,

Thank you ben. I went ahead and pushed the changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/dc88c5784f74). Closing bug report.

Pantxo Diribarne <pantxo>
Group Member
Mon 08 Sep 2014 01:12:51 AM UTC, comment #11: 

I can confirm the patch fixes the prior examples for figure and axes objects.

I'm not sufficient familiar with Octave's classes to comment on the merits implementation, but I like that the patch is short and simple.

Ben Abbott <bpabbott>
Group Member
Sun 07 Sep 2014 10:37:16 AM UTC, comment #10: 

Hi,

I have attached a patch proposal in which I implemented a new class (pval_vector), based on std::vector< std::pair<std::string, octave_value> >. The type which is used to store default properties, pval_map_type, is redefined as a pval_vector instead of a std::map.

I reimplemented some of the std::map methods so that the type change doesn't affect much functions.

Can someone test the patch and eventually comment the approach?

(file #32040)

Pantxo Diribarne <pantxo>
Group Member
Mon 30 Jun 2014 03:11:16 PM UTC, comment #9: 

Looks like I have underestimated this task: currently, the default values are stored in a std::map<std::string, octave_value>, which means that the order in which key/values are inserted is lost.
The only solution I can see is to replace this container by an octave_scalar_map or a custom class that keeps track of the order in which the values have been inserted (e.g. std::vector<std::pair<std::string, octave_value>>).

In any case this will involve many more changes than I had expected.

Does someone have another approach?

Pantxo Diribarne <pantxo>
Group Member
Thu 26 Jun 2014 10:46:39 AM UTC, comment #8: 

The patch has never been pushed, and it is a good thing.

I had a look a few days ago to this bug and found that my approach was wrong: it makes octave behavior independent of the order in which the default properties have been set by the user (which doesn't match matlab behavior). I'll propose a neww patch in the coming days/week.

Pantxo Diribarne <pantxo>
Group Member
Thu 26 Jun 2014 10:16:11 AM UTC, comment #7: 

I still see the bug. Is it possible that the patch never made it into the repository?

Muhali <muhali>
Mon 24 Feb 2014 09:12:27 AM UTC, comment #6: 

Thanks Ben.

Pantxo Diribarne <pantxo>
Group Member
Mon 24 Feb 2014 01:57:59 AM UTC, comment #5: 

Pantxo, I applied your patch. All tests in graphics.cc passed for me.

Ben Abbott <bpabbott>
Group Member
Sun 23 Feb 2014 09:40:54 PM UTC, comment #4: 

Hello,

Ben, you are right the problem is in the order the properties are set.
The simplest way I found to solve this issue is to set the whole list of defaults (not that much) twice. It seems a bit hacky but I think it's robust.

Can someone try the attached patch?

Pantxo

(file #30681)

Pantxo Diribarne <pantxo>
Group Member
Mon 04 Mar 2013 01:55:33 AM UTC, comment #3: 

Equivalent problem for axes objects.


h1 = axes ();
set (h1, "units", "pixels")
p1 = get (h1, "position")
p1 =

    73.800    47.200   434.000   342.300
set (0, "defaultaxesunits", "pixels", "defaultaxesposition", p1);
h2 = axes ();
p2 = get (h2, "position")
p2 =

   4.1329e+04   1.9825e+04   2.4304e+05   1.4377e+05


Ben Abbott <bpabbott>
Group Member
Mon 04 Mar 2013 12:15:59 AM UTC, comment #2: 

A second test that seems to confirm the "position" is set before the "units", and the changing the "units" triggers the updater.


set (0, 'defaultfigureunits', 'normalized')
figure
get (gcf (), 'position')
ans =

   0.17798   0.18952   0.33333   0.40000

get (0, 'defaultfigureposition')
ans =

   300   200   560   420


I'm modifying the summary to to better indicate the problem.

Ben Abbott <bpabbott>
Group Member
Mon 04 Mar 2013 12:09:52 AM UTC, comment #1: 

To help isolate the problem, I tried converting the figure's units to the coded default value of "pixels".


set(0, 'defaultfigureunits', 'normalized')
set(0, 'defaultfigureposition', [0.7 0 0.3 0.3])
figure
get (gcf (), 'position')
ans =

  -1.7857e-04  -9.5238e-04   1.7857e-04   2.8571e-04

set (gcf (), 'units', 'pixels')
get (gcf (), 'position')
ans =

   0.70000   0.00000   0.30000   0.30000


Without looking at the code, I guess that the the updaters for the figure's properties are active during the initialization process.  I had thought the updaters were off (or should be) during the initialization process.

Ben Abbott <bpabbott>
Group Member
Fri 01 Mar 2013 12:26:40 PM UTC, original submission:  

This code


set(0, 'defaultfigureunits', 'normalized')
set(0, 'defaultfigureposition', [0.7 0 0.3 0.3])
figure
get(gcf, 'position')


shows that setting 'defaultfigureposition' has no effect. What I get is

ans =

  -1.7857e-04  -9.5238e-04   1.7857e-04   2.8571e-04

(along with a tiny figure at the lower left corner).

I am using the dev tip f837bdd535f7 of Feb 14.

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #30681:  defaults_bug38449.patch added by pantxo (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by huntj
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by muhali (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-09-13 pantxo StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2014-09-07 pantxo Attached File- Added implement_pval_vector.patch, #32040
        StatusConfirmed Patch Submitted
    2014-02-23 pantxo Attached File- Added defaults_bug38449.patch, #30681
    2013-03-04 huntj Carbon-Copy- Added huntj
    2013-03-04 bpabbott SummaryChanging defaultfigureunits triggers a position update Changing default*units triggers a position update
    2013-03-04 bpabbott SummaryChanging defaultfigureunits triggers a position/outerposition update Changing defaultfigureunits triggers a position update
    2013-03-04 bpabbott Summarydefaultfigureposition has no effect Changing defaultfigureunits triggers a position/outerposition update
    2013-03-04 bpabbott Item GroupNone Incorrect Result
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code