Re: Interesting plot behavior

[Daniel J Sebald]

David Bateman wrote:
> Robert T. Short wrote:
>
> > So do we have to do it the same as Mathworks?  This topic has come up 
> > a few times since I have been on this list - what, exactly, does 
> > compatibility mean?
>
> Compatibility to me means I can share my code with others and expect it 
> to work exactly the same way if these others happen to use matlab.

This isn't so.  Matlab's syntax is a subset of Octave.  There are a lot of things that 
pass in Octave (e.g., "endfunction") that Matlab doesn't understand.


> Also 
> and perhaps more importantly we the octave community can use the vast 
> store of user generated matlab code out there and expect it to work 
> correctly in Octave. So yes I personally consider that compatibility is 
> important.

For the most part, this is true.


> > I got around this just fine, so I don't figure this is a bug, just 
> > thought it was kind of goofy.  BTW, MATLAB scatter plots are horribly 
> > slow too (not as bad as this), but I never found a good way around 
> > it.  Also, I have an old version of MATLAB, so I could be all wet.
>
> I presume that matlab is horrible slow for the same reason. In fact if 
> it wasn't for the fact that all of the patches can have different colors 
> we could keep compatibility and basically combine all of the patches 
> into a single gnuplot plot command as your workaround basically does. I 
> suppose we could special case this case, but the __go_draw_axes__ 
> function is already incredibly complex..

gnuplot does have a feature where symbol color information can be in the data 
itself:

http://gnuplot.sourceforge.net/demo_4.3/rgb_variable.html

Also, I'd think that sorting by color shouldn't be too bad in Octave.  There 
can then be separate sub-commands for each group of points, pretty much the 
same way that plot currently works, if I'm not mistaken.

Dan