bugGNU Octave - Bugs: bug #30442, incompatibilities for marker...


bug #30442: incompatibilities for marker "."

Submitted by:  Ben Abbott <bpabbott>
Submitted on:  Wed 14 Jul 2010 11:41:35 AM UTC  
Category:  None Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  bpabbot Open/Closed:  Closed
Release:  dev Operating System:  Mac OS

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)

Tue 31 Aug 2010 08:51:42 PM UTC, comment #10: 

Ok I pushed my fix for gnuplot since you've decided to do the same thing with fltk, adjusting it to have the same divide 3 behavior you used, and I'm closing this bug.


David Bateman <dbateman>
Project Member
Mon 30 Aug 2010 11:13:44 PM UTC, comment #9: 

I've pushed a changeset that changes the OpenGL behavior to be consistent with Matlab's.


Ben Abbott <bpabbott>
Project Member
Mon 30 Aug 2010 01:41:59 PM UTC, comment #8: 

I took a look at the FLTK backend implementation. If there is no objection, I'll correct the behavior there.

I also did some more testing in Matlab. The difference in markersize is 3x.

Ben Abbott <bpabbott>
Project Member
Tue 20 Jul 2010 08:47:34 PM UTC, comment #7: 

The change I posted makes the default markersize of the "." marker two times smaller than the "o" marker and so it would still be the size of a "." gnuplot marker. So I don't think you'd have to change anything.

Like you I'm not sure its the right thing to do and propose not to apply it unless someone supplies the matching patch for the FLTK backend so the behavior will be consistent for both backends


David Bateman <dbateman>
Project Member
Tue 20 Jul 2010 01:28:30 PM UTC, comment #6: 

Having never used Matlab, I found the distinction between "." and "o" in Octave intuitive.  If I want a single pixel, I use the ".".  Otherwise, I choose any other marker.  In fact, "." is my preferred marker so if the patch is committed I'll end up having to change all my markersizes down to 1.

I don't feel super strongly about this and would adapt, but perhaps this is an area where we don't need to reproduce Matlab behavior?

Rik <rik5>
Project Administrator
Sun 18 Jul 2010 09:36:07 PM UTC, comment #5: 

The attached should be something like the right thing to do with the gnuplot backend. I halved the size of the "." marker relative to the "o" marker and forced the marker always to be filled.

However, I have no idea what to do for the FLTK backend. So this is an incomplete changeset. I still hesitate to apply this and more so if the fltk backend has different behavior


(file #21004)

David Bateman <dbateman>
Project Member
Sun 18 Jul 2010 02:44:46 PM UTC, comment #4: 

The result is "none".

I'd prefer that marker "." produce round filled circles which respect the specified "markersize". I don't have an opinion about how "markerfacecolor" should be handled.

If we are to deviate from Matlab's approach, then I'd opt to have "." and "o" behave the same, except that "markeredgecolor" = "none" for ".". At least this looks consistent with the output rendered in Matlab ("." is smaller than "o"), and all the marker properties would still remain in effect.

Ben Abbott <bpabbott>
Project Member
Sun 18 Jul 2010 08:57:35 AM UTC, comment #3: 

and what does

h = plot(1:10, '.')

give in matlab? If I'm correct, it'll be "auto" rather than "none" and this feature will be trivial to implement in the fronend. If its "none" it'll need to be treated in the backend. However, do we want this "feature" of matlab?


David Bateman <dbateman>
Project Member
Sun 18 Jul 2010 01:48:47 AM UTC, comment #2: 

The command ...

plot (1:10,'marker','.','markeredgecolor', [1,0,0], 'markerfacecolor',[0,1,0])

... produces blue lines with round filled red circles.

Ben Abbott <bpabbott>
Project Member
Sat 17 Jul 2010 09:53:41 PM UTC, comment #1: 

This behavior of matlab doesn't really make sense. It basically means that the "." marker is the same as the "o" marker with the MarkerFaceColor set to "auto". This is basically what I showed in my comment on this thread. Why should there be two ways of creating the same marker?

What happens in matlab is the markeredgecolor and markerfacecolor properties are different for the "." marker? That is, what does

plot (1:10,'marker','.','markeredgecolor', [1,0,0], 'markerfacecolor',[0,1,0])

give in matlab? The face could be red or blue. Do we want to duplicate matlab's behavior for this? The existing "." in Octave is useful for things like the "spy" and "scatter" function, where there are many small points. We'd still be able to get the same behavior in Octave, but would need to specifically set the "markersize" to make the marker much smaller.


David Bateman <dbateman>
Project Member
Wed 14 Jul 2010 11:41:35 AM UTC, original submission:  

Matlab treats the marker "." as a filled circle. Octave's gnuplot backend treats it as a single pixel (doesn't change with size), and the fltk backend treats it as a filled square.

Ben Abbott <bpabbott>
Project Member


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

Attach Files:

Attached Files
file #21004:  patch.marker added by dbateman (1KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by bpabbott (Submitted the item)

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

    Only project members can vote.




    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-08-31 dbateman StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
    2010-07-18 dbateman Attached File- => Added patch.marker, #21004
    2010-07-17 dbateman StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5