matplotlib-users Mailing List for matplotlib

On Thu, May 15, 2008 at 01:56:19PM -0500, John Hunter wrote:
> On Thu, May 15, 2008 at 3:41 AM, Friedrich Hagedorn <fri...@gm...> wrote:
> > On Thu, May 15, 2008 at 10:20:23AM +0200, Friedrich Hagedorn wrote:
> >> Hello,
> >>
> >> I think the following is'nt right:
> >>
> >> In [1]: plot([1,2,3])
> >> Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
> >>
> >> In [2]: ylim(-4,4)
> >> Out[2]: (-4, 4)
> >>
> >> In [3]: axhline()
> >> Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
[...]
> For example, consider this case
> 
> plot([1,2,3])
> ylim(-4,4)
> axhline(20)
> 
> What we want is to autoscale only if autoscale_on=True *and* the hline
> is outside the current bounds. Something like:
> 
> ymin, ymax = self.get_ylim()
> if ymax<ymin: ymin, ymax = ymax, ymin
> scaley = (y<ymin) or (y>ymax)
> 
> trans = mtransforms.blended_transform_factory(
> self.transAxes, self.transData)
> l, = self.plot([xmin,xmax], [y,y], transform=trans,
> scalex=False, scaley=scaley, **kwargs)
> 
> I just committed this to svn in r5141 so give it a test drive and let
> me know what you think.
You are right. This patch works fine for me, thanks.
> There is an unrelated problem with the autoscaler which is that in the example
> 
> plot([1,2,3])
> axhline(20)
> 
> it sets ymax to 20 making the hline invisible. 
But there is no problem with
 axhline(20.2)
Thats why the autoscale sets the outer ticks to the boundaries.
> We should probably
> force the ylimits to be strictly outside the data limits in some cases
> when autoscaling.
I think this would be better then the current (undefined) behaviour (sometimes
the datalines touches the boundaries and sometimes not).
For my own stuff I have used 
 gca().set_ylim(ax.dataLim.intervaly*1.2)
 
for a 'autoscale' replacement.
By,
 Friedrich

On Thu, May 15, 2008 at 3:41 AM, Friedrich Hagedorn <fri...@gm...> wrote:
> On Thu, May 15, 2008 at 10:20:23AM +0200, Friedrich Hagedorn wrote:
>> Hello,
>>
>> I think the following is'nt right:
>>
>> In [1]: plot([1,2,3])
>> Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
>>
>> In [2]: ylim(-4,4)
>> Out[2]: (-4, 4)
>>
>> In [3]: axhline()
>> Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
While I agree the behavior here is not optimal, I don't think the fix
is right. axhline already tells the axes not to autoscale in the x
direction, as it should
l, = self.plot([xmin,xmax], [y,y], transform=trans, scalex=False, **kwargs)
so I don't think automatically forcing the autoscale off entirely for
x and y as in your patch is what we want in general. For example,
consider this case
plot([1,2,3])
ylim(-4,4)
axhline(20)
What we want is to autoscale only if autoscale_on=True *and* the hline
is outside the current bounds. Something like:
 ymin, ymax = self.get_ylim()
 if ymax<ymin: ymin, ymax = ymax, ymin
 scaley = (y<ymin) or (y>ymax)
 trans = mtransforms.blended_transform_factory(
 self.transAxes, self.transData)
 l, = self.plot([xmin,xmax], [y,y], transform=trans,
scalex=False, scaley=scaley, **kwargs)
I just committed this to svn in r5141 so give it a test drive and let
me know what you think.
There is an unrelated problem with the autoscaler which is that in the example
plot([1,2,3])
axhline(20)
it sets ymax to 20 making the hline invisible. We should probably
force the ylimits to be strictly outside the data limits in some cases
when autoscaling.
JDH

Eric Firing wrote:
> Michael Droettboom wrote:
>> Yes, it looks like if it were an "unsigned int", we would have been 
>> okay. That looks like (essentially) what your patch does, but in a 
>> C++ idiom. I'll submit your patch and put a note out to the Windows 
>> guys to help test it. There's a good chance that if it compiles at 
>> all, it should work.
>
> Mike,
>
> If you understand what the patch does, and if you know how to do it in 
> a C idiom (or C++ for that matter) that is readable and that *will* 
> compile and run, then I would suggest that you modify the patch 
> accordingly instead of waiting to see if it *does* compile on whatever 
> compiler versions the Windows people happen to have right now.
It does compile and run on gcc-3.4 and gcc-4.2 on Linux, and solves 
Matle's crash (which I was never able to reproduce myself), so I 
committed the patch (with only cosmetic changes) to SVN. It just needs 
to be verified under Visual Studio, which I don't personally have.
Plus the whole Tcl thing where it encodes the pointer as a string of 
digits and then converts that back to an unsigned int gives me the 
heebie-jeebies, but I think we're stuck with that, for reasonable values 
of "stuck".
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

qEric Firing wrote:
> Michael Droettboom wrote:
>> Yes, it looks like if it were an "unsigned int", we would have been 
>> okay. That looks like (essentially) what your patch does, but in a 
>> C++ idiom. I'll submit your patch and put a note out to the Windows 
>> guys to help test it. There's a good chance that if it compiles at 
>> all, it should work.
>
> Looks like the C idiom would almost have to use
> something like sscanf(argv[2], "%lu", tmpulong).
That is a reasonable alternative.
> Is it bad form to use this in C++?
> Is *anything* actually standardized in C++?
The stringstream class used is in the C++ standard library. My concern 
is only based on Visual Studio not always adhering to it. In this case, 
it's a pretty safe bet it does -- it's a very core and long-standing 
piece of functionality.
> How does one know whether something like stringstream is safe to 
> use? The "ask someone to try it" approach is not very reassuring.
Barring more obvious documentation from Visual Studio (which may be 
mostly ignorance on my part) the only sure way to know is to try it. 
But it is in the specification and mentioned in Stroustrup, "C++: The 
Programming Language".
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Yes, it looks like if it were an "unsigned int", we would have been 
> okay. That looks like (essentially) what your patch does, but in a C++ 
> idiom. I'll submit your patch and put a note out to the Windows guys to 
> help test it. There's a good chance that if it compiles at all, it 
> should work.
Looks like the C idiom would almost have to use
something like sscanf(argv[2], "%lu", tmpulong).
Is it bad form to use this in C++?
Is *anything* actually standardized in C++? How does one know whether 
something like stringstream is safe to use? The "ask someone to try it" 
approach is not very reassuring.
Eric

Michael Droettboom wrote:
> Yes, it looks like if it were an "unsigned int", we would have been 
> okay. That looks like (essentially) what your patch does, but in a C++ 
> idiom. I'll submit your patch and put a note out to the Windows guys to 
> help test it. There's a good chance that if it compiles at all, it 
> should work.
Mike,
If you understand what the patch does, and if you know how to do it in a 
C idiom (or C++ for that matter) that is readable and that *will* 
compile and run, then I would suggest that you modify the patch 
accordingly instead of waiting to see if it *does* compile on whatever 
 compiler versions the Windows people happen to have right now.
Eric

On Thu, May 15, 2008 at 8:29 AM, Matthias Michler
<Mat...@gm...> wrote:
> Hello Jon,
>
> maybe I don't undestand correctly, but try to use more space left of the axes
> to avoid the disappering of the ylabel like:
> ax1 = fig.add_axes([0.3, 0.7, 0.6, 0.2])
> instead of
> ax1 = fig.add_axes([0.1, 0.7, 0.8, 0.2]) .
And if you are using subplots, you can move the left over a bit:
fig.subplots_adjust(left=0.2)

On Thu, May 15, 2008 at 9:31 AM, Jon Choy <jon...@gm...> wrote:
> Can someone tell me how to position the title? When I do a multiple
> plots, the title ends up in my top plot. I position the plot locations
> using the following:
>
> ax1 =fig.add_axes([0.2, 0.8, 0.65, 0.05], **axprops)
> ax2=fig.add_axes([0.2,0.75,0.65,0.05],**axprops)
>
> No matter where I position these axes, the title shows up right in the
> middle of the upper most plot. I'd like to put the title above the top
> most plot. Another option maybe to title the entire window. I'd like
> to know how to do that as well.
Use figure text:
figtitle = 'This is a somewhat long figure title'
t = fig.text(0.5, 0.95, figtitle,
 horizontalalignment='center',
 fontsize=16)

Can someone tell me how to position the title? When I do a multiple
plots, the title ends up in my top plot. I position the plot locations
using the following:
ax1 =fig.add_axes([0.2, 0.8, 0.65, 0.05], **axprops)
ax2=fig.add_axes([0.2,0.75,0.65,0.05],**axprops)
No matter where I position these axes, the title shows up right in the
middle of the upper most plot. I'd like to put the title above the top
most plot. Another option maybe to title the entire window. I'd like
to know how to do that as well.
 Jon

Hello Jon,
maybe I don't undestand correctly, but try to use more space left of the axes 
to avoid the disappering of the ylabel like:
ax1 = fig.add_axes([0.3, 0.7, 0.6, 0.2]) 
instead of
ax1 = fig.add_axes([0.1, 0.7, 0.8, 0.2]) .
That should be a solution, if you have not too different (considering their 
length) ylabels.
regards Matthias
PS: By the way, it might be useful to you to change the figure size with the 
keyword argument figsize of figure ( like fig=figure(figsize=(12, 6)) ).
On Thursday 15 May 2008 15:10:47 Jon Choy wrote:
> Yes, something I forgot to add is that I tried to resize the window
> and a couple more characters would show; but not the entire string.
> I'm trying to do multiple plots. Below is a signal named
> "pesm_gsm_prime" which is a good example of a signal with lots of
> characters. Unfortunately, I would like to preserve the name if
> possible and adjust the graphing frame if possible.
>
>
> Jon
>
>
>
> t = signals[signal][0]
> s1=signals[signal][1]
>
> fig = figure()
> yprops = dict(rotation=0,
> 	horizontalalignment='right',
> 	verticalalignment='center',
> 	clip_on = False,
> 	fontname='courier')
> axprops = dict(yticks=[])
> ax1 =fig.add_axes([0.1, 0.7, 0.8, 0.2], **axprops)
> ax1.plot(t, s1)
> ax1.axis([0,10000,-0.1,1.1])
> ax1.set_ylabel(signal, **yprops)
>
> axprops['sharex']=ax1
> axprops['sharey']=ax1
> # force x axes to remain in register, even with toolbar navigation
>
> signal = "pesm_gsm_prime"
> signals[signal]=[],[]
> for line in filedata:
> loadValueChange(signals,signal,line)
> t = signals[signal][0]
> s2=signals[signal][1]
>
> ax2=fig.add_axes([0.1,0.5,0.8,0.2],**axprops)
> ax2.plot(t,s2)
> ax2.axis([0,10000,-0.1,1.1])
> ax2.set_ylabel(signal,**yprops)
>
>
> for ax in ax1,ax2:
> setp(ax.get_xticklabels(),visible=False)
>
> #show()
> savefig('testplot.png')
>
>
> On Thu, May 15, 2008 at 2:35 AM, Matthias Michler wrote:
> > Hi Jon,
> >
> > On Thursday 15 May 2008 03:17:29 Jon Choy wrote:
> >> I maybe asking a dumb question, forgive me I'm a novice. I try to add
> >> a ylabel and the left portion of the signal name is cut off when it is
> >> plotted. I can't seem to find the option for displaying the whole
> >> signal. Or do I need to resize the plotting window?
> >
> > I think resizing the window is a good first attempt to see, if there is
> > everything written, but not shown to you.
> > Is your ylabel a very long string? Could you provide a small stand-alone
> > example of your problem, please?

Yes, it looks like if it were an "unsigned int", we would have been 
okay. That looks like (essentially) what your patch does, but in a C++ 
idiom. I'll submit your patch and put a note out to the Windows guys to 
help test it. There's a good chance that if it compiles at all, it 
should work.
Thanks for getting to the bottom of this.
Cheers,
Mike
Malte Marquarding wrote:
> Hi
>
> Attached is the the patch. It uses stringstream, so I don't know if it 
> will work on all platforms. I am not a windows person ;-)
> I didn't read your email properly about the existence of "atoll", so 
> as I am a c++er I am a bit more comfortable with stringstream.
>
> Cheers,
> Malte.
>
>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 15, 2008 at 10:20:23AM +0200, Friedrich Hagedorn wrote:
> Hello,
> 
> I think the following is'nt right:
> 
> In [1]: plot([1,2,3])
> Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
> 
> In [2]: ylim(-4,4)
> Out[2]: (-4, 4)
> 
> In [3]: axhline()
> Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
> 
> In [4]: ylim()
> Out[4]: (0.0, 3.0)
With the attached patch the thinks are ok:
In [1]: plot([1,2,3])
Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ac>]
In [2]: ylim(-4,4)
Out[2]: (-4, 4)
In [3]: xlim(-4,4)
Out[3]: (-4, 4)
In [4]: axhline()
Out[4]: <matplotlib.lines.Line2D object at 0x8fa6e6c>
In [5]: axvline()
Out[5]: <matplotlib.lines.Line2D object at 0x9062fec>
In [6]: xlim()
Out[6]: (-4.0, 4.0)
In [7]: ylim()
Out[7]: (-4.0, 4.0)
By,
 Friedrich

Hello,
I think the following is'nt right:
In [1]: plot([1,2,3])
Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
In [2]: ylim(-4,4)
Out[2]: (-4, 4)
In [3]: axhline()
Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
In [4]: ylim()
Out[4]: (0.0, 3.0)
By,
 Friedrich

Hi Jon,
On Thursday 15 May 2008 03:17:29 Jon Choy wrote:
> I maybe asking a dumb question, forgive me I'm a novice. I try to add
> a ylabel and the left portion of the signal name is cut off when it is
> plotted. I can't seem to find the option for displaying the whole
> signal. Or do I need to resize the plotting window?
I think resizing the window is a good first attempt to see, if there is 
everything written, but not shown to you.
Is your ylabel a very long string? Could you provide a small stand-alone 
example of your problem, please?
regards
Matthias

Hi
Attached is the the patch. It uses stringstream, so I don't know if 
it will work on all platforms. I am not a windows person ;-)
I didn't read your email properly about the existence of "atoll", so 
as I am a c++er I am a bit more comfortable with stringstream.
Cheers,
Malte.

Hi,
we were on the right track just the inverse. The number of argv[4] is 
bigger then MAX_LONG on 32bit.
So what I did is:
unsigned long tmplong;
std::stringstream ss;
ss.str(argv[4]);
ss >> tmplong;
bboxo = (PyObject*)tmplong;
Now it works.
Also, I will change all other atol()'s to stringstream, we are c++ 
er's anyway.
I will check out the svn and send a patch. Where do I send it to?
Cheers,
Malte
On 15/05/2008, at 8:40 AM, Malte Marquarding wrote:
> Hi,
>
> unfortunately 32-bit ;-) I tried digging around, but I don't know
> much about tcl/tk. Seeing a char string argv atol'ed into a pointer
> address left me with an uncomfortable feeling...
> Anyway her is the argv value
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7c516c0 (LWP 5638)]
> 0xb6f4500e in PyAggImagePhoto (clientdata=0x0, interp=0x87396f0, 
> argc=5,
> argv=0xbfc8874c) at src/_transforms.h:362
> 362 Point* ll_api() {return _ll;}
> Current language: auto; currently c++
> (gdb) p argv[4]
> 1ドル = 0x895d0f0 "3085736160"
> (gdb) p bboxo
> 2ドル = (PyObject *) 0x7fffffff
>
> The cast doesn't seem to work.
>
> Cheers,
> Malte
>
> On 14/05/2008, at 10:47 PM, Michael Droettboom wrote:
>
>> Ouch! The way that pointer is obtained is really weird (though I
>> believe it is a common idiom in Tcl extensions):
>>
>> PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
>> int argc, char **argv) {
>> ...
>> bboxo = (PyObject*)atol(argv[4]);
>> if (bboxo != Py_None) {
>> bbox = (Bbox*)bboxo;
>>
>> That means the pointer comes to us encoded as a string of digits,
>> which gets converted to an integer, cast to a (PyObject*), and then
>> cast to a (Bbox*) (which is a subclass of PyObject, in the C-object-
>> oriented sense). That's just one of those things you'd rather not
>> be doing ;)
>>
>> Are you running the 64-bit version of OpenSUSE by any chance? That
>> might explain this if the atol call is overflowing. That's only
>> theoretical, as I think it *should* work. atol is supposed to
>> return a "long", which is supposed to be 64-bit on a 64-bit Linux
>> machine. Could you try replacing "atol" with "atoll", recompile
>> and see what happens? Do you get any warnings during compilation
>> of _tkagg.cpp?
>>
>> Failing that, it would be useful, I suppose, to print out "argv[4]"
>> from the debugger.
>>
>> Thanks for helping with this. Hopefully we're honing in on 
>> something.
>>
>> Mike
>>
>> Malte Marquarding wrote:
>>> Hi,
>>>
>>> The segv also occurs in matplotlib-0.90.1. A clean build doesn't
>>> help.
>>>
>>> Here is the gdb output, looks like something is pointing into
>>> nirvana..
>>>
>>> (gdb) p bboxo
>>> 1ドル = <value optimized out>
>>> (gdb) p bbox
>>> 2ドル = (Bbox *) 0x7ffffffb
>>> (gdb) p bbox->_ll
>>> Cannot access memory at address 0x7ffffffb
>>>
>>> Cheers,
>>> Malte
>>>
>>> On 13/05/2008, at 10:19 PM, Michael Droettboom wrote:
>>>
>>>> p bboxo
>>>> p bbox
>>>> p bbox->_ll
>>>
>>>
>>>
>>>
>>>
>>
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>
> Malte Marquarding
> Mal...@cs...
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Malte Marquarding
Mal...@cs...

I maybe asking a dumb question, forgive me I'm a novice. I try to add
a ylabel and the left portion of the signal name is cut off when it is
plotted. I can't seem to find the option for displaying the whole
signal. Or do I need to resize the plotting window?
 Jon