SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S






1
2
3
(2)
4
(11)
5
(10)
6
(9)
7
(29)
8
(1)
9
(3)
10
(10)
11
(14)
12
(16)
13
(2)
14
15
16
17
(2)
18
19
(1)
20
(1)
21
(5)
22
23
(2)
24
(5)
25
(2)
26
27
(1)
28
(3)
29
(1)
30
(2)






Showing 2 results of 2

From: Manuel M. <mm...@as...> - 2007年09月03日 09:05:42
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
From: Eric F. <ef...@ha...> - 2007年09月03日 02:33:20
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

Showing 2 results of 2

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /