matplotlib-devel Mailing List for matplotlib (Page 6)

On Fri, Aug 31, 2007 at 01:22:54PM +0400, Farid Khalili wrote:
> I have just found matplotlib, and it seems to me that it is very good
> and promising product, albeit not yet as polished as octave/gnuplot
> pair.
As a long-time user of gnuplot, I find that in certain areas matplotlib
is more polished.
Gaël

On 8/31/07, Paul Kienzle <pki...@ni...> wrote:
> That's wonderful! I'm attaching a screen shot for wx 2.8 on OS/X.
>
> The rendering is kind of ugly, but I haven't looked into it.
My giess is that for some reason wx is not respecting the alpha
channel -- that will give you the rough, chunky text you are seeing.
I saw similar looking text when working with dvipng output before I
got the alpha channel right.
JDH

On 9/4/07, Manuel Metz <mm...@as...> wrote:
> Hello,
>
> I just re-created the patch against svn revision 3773 and also updated
> it on sourceforge. I also added a modified version of
> scatter_star_poly.py from the examples and its output.
>
> It would really be nice to have this patch applied
Thanks for the remionder Manuel -- I added the patch and example to svn

Just FYI -- this is what it looks like in Linux/wxGTK.
Paul Kienzle wrote:
> On Fri, Aug 31, 2007 at 03:28:49PM -0400, Michael Droettboom wrote:
>> There is now preliminary support for getting a mathtext bitmap to 
>> transfer to a GUI widget in SVN, along with a toy wxPython example in 
>> examples/mathtext_wx.py. I've only tested this on 
>> Linux/wxGTK2/wxPython-2.8. I'd appreciate help with testing (and 
>> screenshots) on any other platforms you may care about.
> 
> That's wonderful! I'm attaching a screen shot for wx 2.8 on OS/X.
> 
> The rendering is kind of ugly, but I haven't looked into it.
> 
> 	- Paul
> 
> 
> ------------------------------------------------------------------------
> 

Hello,
I just re-created the patch against svn revision 3773 and also updated 
it on sourceforge. I also added a modified version of 
scatter_star_poly.py from the examples and its output.
It would really be nice to have this patch applied
Manuel

Eric,
Eric Firing wrote:
> Manuel,
> 
> Sorry for the delay in looking at your patch.
> 
> I am not familiar with this type of plot, as opposed to ordinary 
> errorbars. What is it used for? What is the meaning of the upper and 
> lower limits?
Sometimes physicist or astronomers want to indicate that a certain
measurement only given an upper- or lower-limit for a _measured value_,
which means that the true value can not directly be measured.
 One example is the mass of the (electron)-neutrino which is not 
known, but some experiments indicate that it has to be smaller than some 
M +- dM. In such a case one would use an arrow pointing downwards to 
indicate that this measurement only gives an upper limit for the mass.
 Another example is the inferred mass of satellite galaxies of the 
Milky Way. Here some measurements give the minimum mass of the galaxies, 
while its total mass might be larger; in this case one wants to indicate 
a lower limit, i.e. use an error-bar with an arrow pointing upwards.
So, the basic meaning is: you can derive a value and its formal
uncertainties, but you *know* that this value is only an
upper-/lower-limit of the true value; this is indicated by the arrow.
> The errorbar docstring will need to be modified to explain the new 
> kwargs. Additional comments are interspersed below.
 >
> Manuel Metz wrote:
>> Hello,
>> I have attached a patch that adds the ability to draw upper/lower 
>> limits indicators for errorbars. New keyword args had to be introduced 
>> to the errorbar command, and I also had to add new plot styles. I 
>> chose 'y','Y','z' and 'Z' as new linestyles for arrowheads pointing 
>> up,down, left, right (see lines.py).
> 
> These markers seem to me to be very special, more similar to the 
> TICKLEFT and friends than to the general-use markers for which letters 
> are assigned. Since there is nothing mnemonic about your suggested 
> letter assignments, I think it would be better not to further clutter 
> that list of letters, and instead to extend the list of tick-like 
> things. I suggest calling them CARETUP, CARETDOWN, etc, since they seem 
> to me more like carets than anything else. The change to names from 
> single characters will make the code in the errorbar method more readable.
> 
>>
>> An example and its output is also attached.
>>
>> Eric: I know, I don't use masked array in this patch ;_) . The reason 
>> was that errorbar() also doesn't use them, and a did not want to 
>> completely change that function but just add the new feature. 
>> Switching to masked arrays should be straight forward, I think :-)
>>
>> Manuel
>>
>>
>> ------------------------------------------------------------------------
>>
>> Index: axes.py
>> ===================================================================
>> --- axes.py (revision 3727)
>> +++ axes.py (working copy)
>> @@ -3554,7 +3554,30 @@
>> lines_kw['linewidth']=kwargs['linewidth']
>> if 'lw' in kwargs:
>> lines_kw['lw']=kwargs['lw']
>> -
>> + + lolims = uplims = False
>> + xlolims = xuplims = False
>> + if 'lowerlimits' in kwargs:
>> + lolims = kwargs.pop('lowerlimits')
>> + if 'upperlimits' in kwargs:
>> + uplims = kwargs.pop('upperlimits')
>> + if 'xlowerlimits' in kwargs:
>> + xlolims = kwargs.pop('xlowerlimits')
>> + if 'xupperlimits' in kwargs:
>> + xuplims = kwargs.pop('xupperlimits')
> 
> Instead of using **kwargs and popping them, the new kwargs should be 
> part of the signature. This would be consistent with the present 
> signature, in which **kwargs is used only to pass additional marker 
> parameters.
> 
>> + + if not iterable(lolims): lolims = 
>> npy.asarray([lolims]*len(x), bool)
> Minor point: here (above) you *know* you are not starting with an array, 
> so it would be clearer and more efficient to use npy.array, reserving 
> npy.asarray for the case below where you *don't* know whether the 
> argument is an array or not.
>> + else: lolims = npy.asarray(lolims, bool)
> 
> [...]
> 
> The main thing I need from you is the modified docstring, although a new 
> patch incorporating that and the other suggested changes would be even 
> better.
> 
> Eric
I modified the docstring, but I'm also sure that it might need some 
further adjustments ... ;-)
I also tried to incorporate all your suggestions made about the 
marker-symbols, keywords and usage of asarray<->array.
Manuel

Manuel,
Sorry for the delay in looking at your patch.
I am not familiar with this type of plot, as opposed to ordinary 
errorbars. What is it used for? What is the meaning of the upper and 
lower limits?
The errorbar docstring will need to be modified to explain the new 
kwargs. Additional comments are interspersed below.
Manuel Metz wrote:
> Hello,
> I have attached a patch that adds the ability to draw upper/lower limits 
> indicators for errorbars. New keyword args had to be introduced to the 
> errorbar command, and I also had to add new plot styles. I chose 
> 'y','Y','z' and 'Z' as new linestyles for arrowheads pointing up,down, 
> left, right (see lines.py).
These markers seem to me to be very special, more similar to the 
TICKLEFT and friends than to the general-use markers for which letters 
are assigned. Since there is nothing mnemonic about your suggested 
letter assignments, I think it would be better not to further clutter 
that list of letters, and instead to extend the list of tick-like 
things. I suggest calling them CARETUP, CARETDOWN, etc, since they seem 
to me more like carets than anything else. The change to names from 
single characters will make the code in the errorbar method more readable.
> 
> An example and its output is also attached.
> 
> Eric: I know, I don't use masked array in this patch ;_) . The reason 
> was that errorbar() also doesn't use them, and a did not want to 
> completely change that function but just add the new feature. Switching 
> to masked arrays should be straight forward, I think :-)
> 
> Manuel
> 
> 
> ------------------------------------------------------------------------
> 
> Index: axes.py
> ===================================================================
> --- axes.py	(revision 3727)
> +++ axes.py	(working copy)
> @@ -3554,7 +3554,30 @@
> lines_kw['linewidth']=kwargs['linewidth']
> if 'lw' in kwargs:
> lines_kw['lw']=kwargs['lw']
> -
> + 
> + lolims = uplims = False
> + xlolims = xuplims = False
> + if 'lowerlimits' in kwargs:
> + lolims = kwargs.pop('lowerlimits')
> + if 'upperlimits' in kwargs:
> + uplims = kwargs.pop('upperlimits')
> + if 'xlowerlimits' in kwargs:
> + xlolims = kwargs.pop('xlowerlimits')
> + if 'xupperlimits' in kwargs:
> + xuplims = kwargs.pop('xupperlimits')
Instead of using **kwargs and popping them, the new kwargs should be 
part of the signature. This would be consistent with the present 
signature, in which **kwargs is used only to pass additional marker 
parameters.
> + 
> + if not iterable(lolims): lolims = npy.asarray([lolims]*len(x), bool)
Minor point: here (above) you *know* you are not starting with an array, 
so it would be clearer and more efficient to use npy.array, reserving 
npy.asarray for the case below where you *don't* know whether the 
argument is an array or not.
> + else: lolims = npy.asarray(lolims, bool)
[...]
The main thing I need from you is the modified docstring, although a new 
patch incorporating that and the other suggested changes would be even 
better.
Eric