matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Fri, Jun 13, 2008 at 3:28 PM, Ryan May <rm...@gm...> wrote:
> 
>>> Ryan: I'm sure you could do it, and it would be a nice contribution to
>>> the community. There's some IDL code here
> 
>> Thanks. I also managed to find a matlab implementation, which was
>> straightforward to port over. I'm working on fleshing out the full
> 
> Just a note of caution: if you want to write something that will be
> included in matplotlib or a toolkit, you need to be mindful of the
> licenses of code you are looking at. While matplotlib has replicated
> to an extent the names and signatures of many matlab functions, we
> haven't looked at any of their code. A lot of IDL and matlab code
> comes with restrictive licenses, so make sure you are not violating
> the terms of those licenses for any code that might be suitable for
> contribution.
Yeah, I'm aware of this. The code I mention, however, is taken from 
meteorology class assignment. Also, in this case, I'm really only using 
it for a reference on how to do the "skew" calculation. The code is 
*far* too ugly to directly port. :)
I can appreciate the need for caution however.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jun 13, 2008 at 3:28 PM, Ryan May <rm...@gm...> wrote:
>> Ryan: I'm sure you could do it, and it would be a nice contribution to
>> the community. There's some IDL code here
> Thanks. I also managed to find a matlab implementation, which was
> straightforward to port over. I'm working on fleshing out the full
Just a note of caution: if you want to write something that will be
included in matplotlib or a toolkit, you need to be mindful of the
licenses of code you are looking at. While matplotlib has replicated
to an extent the names and signatures of many matlab functions, we
haven't looked at any of their code. A lot of IDL and matlab code
comes with restrictive licenses, so make sure you are not violating
the terms of those licenses for any code that might be suitable for
contribution.
Thanks,
JDH

On Friday 13 June 2008 9:54:58 pm you wrote:
> On Fri, Jun 13, 2008 at 3:20 PM, Darren Dale <dar...@co...> 
wrote:
> > I just deleted the static_figs directory from svn, and moved the contents
> > into pyplots. The generated figures were committed to svn as well, so
> > they should not be auto-generated. This way we can consistently use the
> > nice plot directive to include all of our figures. I think there should
> > be no problems with this transition, but if you see one, please let me
> > know.
>
> I think we can make it work, but there are some minor hurdles. It is
> a little brittle in my view to include auto-generated PNGs alongside
> svn pngs because it makes cleaning hard (we currently have the same
> problem in the _static dir with the mathtext pngs).
How often does cleaning need to be done? Can "svn up" be a part of the 
cleaning process?
> The other problem 
> is that when I went to implement your svg suggestion, which is a good
> one (ditto for ps links), I bumped into some not implemented errors
> since we don't have draw_tex for svg and some latex runtime problems
> when I tried to build the ps since I don't have the right fonts. All
> of this can be worked around, but it will take a little work. I have
> to run now...
>
> We could have a little extra meta data stored, tagging certain files
> that should not be auto-generated for certain extensions....
> Perhaps we should introduce a new plot directive option, much like
> include-source, which could be used to suppress auto-gen, or exclude
> certain targets.
>
> .. plot:: tex_unicode_demo.py
>
> :include-source:
> :no-autogen:
>
> .. plot:: tex_unicode_demo.py
>
> :include-source:
> :exclude-backends: svg, gdk
>
> I'll ponder this over the weekend.
May I suggest a third alternative, :exclude-formats: instead of backends.
Darren

On Fri, Jun 13, 2008 at 3:20 PM, Darren Dale <dar...@co...> wrote:
> I just deleted the static_figs directory from svn, and moved the contents into
> pyplots. The generated figures were committed to svn as well, so they should
> not be auto-generated. This way we can consistently use the nice plot
> directive to include all of our figures. I think there should be no problems
> with this transition, but if you see one, please let me know.
I think we can make it work, but there are some minor hurdles. It is
a little brittle in my view to include auto-generated PNGs alongside
svn pngs because it makes cleaning hard (we currently have the same
problem in the _static dir with the mathtext pngs). The other problem
is that when I went to implement your svg suggestion, which is a good
one (ditto for ps links), I bumped into some not implemented errors
since we don't have draw_tex for svg and some latex runtime problems
when I tried to build the ps since I don't have the right fonts. All
of this can be worked around, but it will take a little work. I have
to run now...
We could have a little extra meta data stored, tagging certain files
that should not be auto-generated for certain extensions....
Perhaps we should introduce a new plot directive option, much like
include-source, which could be used to suppress auto-gen, or exclude
certain targets.
.. plot:: tex_unicode_demo.py
 :include-source:
 :no-autogen:
.. plot:: tex_unicode_demo.py
 :include-source:
 :exclude-backends: svg, gdk
I'll ponder this over the weekend.
JDH

Eric Firing wrote:
> Ryan May wrote:
> 
>> Thanks. I also managed to find a matlab implementation, which was 
>> straightforward to port over. I'm working on fleshing out the full 
>> Skew-T look right now. As far as using the transforms, here's the 
>> question: Does anyone besides the meteorologists have a need for a 
>> plot with a skewed axis? If so, it might pay to make this general. 
>> Otherwise, this could stay as a specific Skew-T LogP plot. If the 
>> latter is the case, does it make sense to include such a method 
>> anywhere in Matplotlib? I guess if nothing else it could go in as an 
>> example.
> 
> Ryan,
> 
> I think that it would make the most sense as an example; it seems too 
> specialized to be suitable as an axes method, and I tend to think we 
> already have too many of those as it is.
> 
> It would be especially valuable if you can do it using the transforms 
> machinery, as a new projection, but this would require more work on your 
> part; it would be less of a direct translation of code from other 
> languages. If you have not already done so, look at 
> examples/api/custom_projection_example.py in svn.
Yeah, the projection approach is what I'm planning on using. 
Unfortunately, I can't use any of that immediately because Gentoo is 
stuck on Matplotlib 0.91.2 and Numpy 1.0.4. Once, Numpy 1.1 is in the 
tree, I can move to the latest matplotlib (even SVN), and then move over 
too it. In the meanwhile, I've at least looked over that code, and it 
looks promising. Half the problem has been figuring out the bizarre 
nature of the Skew-T LogP.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Thanks. I also managed to find a matlab implementation, which was 
> straightforward to port over. I'm working on fleshing out the full 
> Skew-T look right now. As far as using the transforms, here's the 
> question: Does anyone besides the meteorologists have a need for a plot 
> with a skewed axis? If so, it might pay to make this general. 
> Otherwise, this could stay as a specific Skew-T LogP plot. If the 
> latter is the case, does it make sense to include such a method anywhere 
> in Matplotlib? I guess if nothing else it could go in as an example.
Ryan,
I think that it would make the most sense as an example; it seems too 
specialized to be suitable as an axes method, and I tend to think we 
already have too many of those as it is.
It would be especially valuable if you can do it using the transforms 
machinery, as a new projection, but this would require more work on your 
part; it would be less of a direct translation of code from other 
languages. If you have not already done so, look at 
examples/api/custom_projection_example.py in svn.
Eric