sam tygier | 1 Mar 15:17
Picon
Favicon

Re: File format for plots

Eric Firing wrote:
> Sandro Tosi wrote:
>> Hi Sam,
>>
>> On Wed, Feb 25, 2009 at 09:35, sam tygier <samtygier@...> wrote:
>>> I think this topic has come up before, but i don't think anything has
>>> resulted from it.
>>>
> Correct, because the capability would require a *lot* of work to 
> implement,

Would i be right in assuming that it would take roughly the same amount of effort as writing a new backend? ie
for each motplotlib action it would need a function to store that action and a function to call that action again.

> and most of us don't see a compelling need; we believe that a 
> better practice is to structure one's work so that plotting is separated 
> from data (result) generation in any cases where the latter is highly 
> time-consuming.

It might not be essential, but it would offer an additional work flow, that a few people seem to like.

I think it would be especially useful when it comes to putting plots into papers. I often find that i want to
tweak something like the font size or labels. having a modifiable plot format seems the easiest way to
achieve that. maybe the could even be some integration into latex so that if you were to resize your plot in
your paper, it would be re-rendered with the fonts adjusted.

>>> I'd like a way for saving a plot from from matplotlib, so that it can be
>>> re-rendered later, possibly with a different backend, maybe to a different
>>> size, and maybe with changes to the labels. This would save me having to
>>> rerun the simulation that generated the plot.
(Continue reading)

Eric Firing | 1 Mar 21:02
Favicon
Gravatar

Re: File format for plots

sam tygier wrote:
> Eric Firing wrote:
>> Sandro Tosi wrote:
>>> Hi Sam,
>>>
>>> On Wed, Feb 25, 2009 at 09:35, sam tygier <samtygier@...> wrote:
>>>> I think this topic has come up before, but i don't think anything has
>>>> resulted from it.
>>>>
>> Correct, because the capability would require a *lot* of work to 
>> implement,
> 
> Would i be right in assuming that it would take roughly the same amount of effort as writing a new backend? ie
for each motplotlib action it would need a function to store that action and a function to call that action again.

It is much more than that; it would take a backend to write out the new 
format, and an interpreter to turn that format back into mpl objects or 
API calls.

One of the mpl backends is svg; can you use something like Inkscape to 
make the plot adjustments you are talking about?

Eric

> 
>> and most of us don't see a compelling need; we believe that a 
>> better practice is to structure one's work so that plotting is separated 
>> from data (result) generation in any cases where the latter is highly 
>> time-consuming.
> 
(Continue reading)

Michael Droettboom | 2 Mar 18:47

Re: hashing of FontProperties

Jae-Joon Lee wrote:
> The following code show how the FontProperties is currently hashed.
>
>      def __hash__(self):
>         l = self.__dict__.items()
>         l.sort()
>         return hash(repr(l))
>
>
> The hash does not account user's rcParams setting. And due to the font
> caching, findfont(FontProperties()) returns the same font even if user
> changes the rcParams["font.family"] and other parameters.
>
> So, I propose to change it to something like below.
>
>     def __hash__(self):
>         l = [(k, getattr(self, "get" + k)()) for k in self.__dict__]
>         return hash(repr(l))
>   
You'll need to maintain the call to sort in there, since dictionaries 
don't make any guarantee about ordering.  But otherwise, that seems like 
a reasonable solution to the problem.  There was a bug report about this 
on the list recently.
> The other change I want to make is the behavior of the findfont(None).
> As of now, it returns "fontManager.defaultFont" which is set when
> fontManager is initialized. Therefore, it returns same font even if
> user change the rcParams. I prefer to have "findfont(None) ==
> findfont(FontProperties())".
>   
That should be fine.
(Continue reading)

Ryan May | 2 Mar 20:49
Picon
Gravatar

Re: File format for plots

On Sun, Mar 1, 2009 at 8:17 AM, sam tygier <samtygier <at> yahoo.co.uk> wrote:
Eric Firing wrote:
> Sandro Tosi wrote:
>> Hi Sam,
>>
>> On Wed, Feb 25, 2009 at 09:35, sam tygier <samtygier-/E1597aS9LT10XsdtD+oqA@public.gmane.org> wrote:
>>> I think this topic has come up before, but i don't think anything has
>>> resulted from it.
>>>
> Correct, because the capability would require a *lot* of work to
> implement,

Would i be right in assuming that it would take roughly the same amount of effort as writing a new backend? ie for each motplotlib action it would need a function to store that action and a function to call that action again.

> and most of us don't see a compelling need; we believe that a
> better practice is to structure one's work so that plotting is separated
> from data (result) generation in any cases where the latter is highly
> time-consuming.

It might not be essential, but it would offer an additional work flow, that a few people seem to like.

I think it would be especially useful when it comes to putting plots into papers. I often find that i want to tweak something like the font size or labels. having a modifiable plot format seems the easiest way to achieve that. maybe the could even be some integration into latex so that if you were to resize your plot in your paper, it would be re-rendered with the fonts adjusted.

Other than the automatic regeneration from latex, what you want sounds like what we already have: small python scripts.

In general, I'm completely amazed by how many people want to develop a new markup/script language to wrap what is already a simple and expressive language, both for plots and (at least around here) analyses.  If there are some spots that require too many lines of code to accomplish something really simple, then maybe we need to API additions. But in general, I think we have a format for specifying how to make a plot: python.  Now, if we're taking the output from some monstrous application or set of scripts, it might be nice to get the commands that made the plot, like MayaVi 2 and its ability to record.  However, at the end of the day what MayaVi creates is a python script, and I think that's more useful than any general markup since I can look at that file and figure out what's going on without learning anything new.

Now, a matplotlib backend that writes out python code could be useful and cool, though it would only matter for the large applications/scripts.  In fact, it's at the application level that such functionality would probably belong.

My 0.02 anyways.

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Gael Varoquaux | 2 Mar 22:52
Favicon
Gravatar

Re: File format for plots

On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote:
>    Other than the automatic regeneration from latex, what you want sounds
>    like what we already have: small python scripts.

>    In general, I'm completely amazed by how many people want to develop a new
>    markup/script language to wrap what is already a simple and expressive
>    language, both for plots and (at least around here) analyses.  If there
>    are some spots that require too many lines of code to accomplish something
>    really simple, then maybe we need to API additions. But in general, I
>    think we have a format for specifying how to make a plot: python. 

Although I agree with you that reinventing an extra scripting layer is
often a bad solution to a problem which should simply be solved by having
a good scripting API in Python, I believe there is here a fundamental
misconception.

Python is an imperative, Turing-complete. This is a very good thing for a
scripting language. For making a description of a static object as a
plot, this is not a good thing. For instance, if I want to make a plot,
save it, and later blow up all the fonts, I really don't want to be using
an imperative, Turing-complete language for the persistence model, as
static analysis of this persisted object is going to be next to
impossible. Same thing if I want to change colormaps, or just about
anything in my persisted object, for the same reason.

A good rule for most software design is that the state of the
application, or of the object of interest, in our case the plot, should
be fully represented by a fully-static set of values, that I like to call
the model. Although this sounds like a tautology, this design rule is
more often broken than followed. For instance the status of an
application may be entirely dependent on its past, or the important state
variables may be hidden in places where you can't get hold of them (eg
the status of a GUI widget, or inside a generator).

Having a very clean separation between your (fully-static) model, and the
logics around is a very important part of good application design, and I
believe I know this because I have so often made an error and violated
this rule :).

If you have this static model, rather than an imperative language, then
you can have persistence. By the way, Mayavi2 achieves its code
generation by introspection on the model. The generated lines of code are
just a way of expressing the changes.

Sorry for being fussy, I am just trying to pass on what I believe I am
learning painfully :).

Gaël

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Jonathan Taylor | 3 Mar 05:13
Picon
Picon
Favicon

Updating MPlot3D to a more recent matplotlib.

Hi,

I saw that 3D plotting was dropped from matplotlib since the last time
I used it.  Unfortunately, it is pretty necessary for some of the work
I am doing.  Thus, I have started the process of refactoring the code
to work with recent versions of matplotlib.

Right now, it is still in very early stages and is quite flaky but I
do have some functionality.  In particular, I am able to do a regular
3d plot, a wireframe plot and a scatter plot.  If this interests
anyone I am making the code available via git.  Instructions are
available on my website at:

http://jonathantaylor.ca/projects.shtml

Feel free to send any patches my way.

Best,
Jon.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
John Hunter | 3 Mar 15:14
Picon
Gravatar

Re: Updating MPlot3D to a more recent matplotlib.



On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor <jonathan.taylor-H217xnMUJC0sA/PxXw9srA@public.gmane.org> wrote:
Hi,

I saw that 3D plotting was dropped from matplotlib since the last time
I used it.  Unfortunately, it is pretty necessary for some of the work
I am doing.  Thus, I have started the process of refactoring the code
to work with recent versions of matplotlib.

Right now, it is still in very early stages and is quite flaky but I
do have some functionality.  In particular, I am able to do a regular
3d plot, a wireframe plot and a scatter plot.  If this interests
anyone I am making the code available via git.  Instructions are
available on my website at:

That's great -- a number of people were very disappointed to see the functionality removed, even though it was primitive compared to a good 3D toolkit.  The problem was, we could never find a core developer who was interested in taking it under his wing.  Once you get this to a satisfactory point, I suggest you develop it as an mpl toolkit.  That way, it will get installed with every mpl distro (the plain vanilla toolkits we ship, the complex ones like basemap are distributed separately) but without the implicit promise of full support until someone is willing to step up and offer to fully support it.

JDH

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Jonathan Taylor | 3 Mar 16:56
Picon
Picon
Favicon

Re: Updating MPlot3D to a more recent matplotlib.

That sounds reasonable.  Can I ask what it is that was primitive?
Having looked through the code I see that a few shortcuts were made to
minimize the amount of code written that makes it especially
susceptible to changes in the 2D code.  That said, it seems like it
was comparable functionally to matlab's 3d plots, which is my goal for
it.

Best,
Jon.

P.S.  I saw your talk at NIPS 2008 this year.  I have used mpl for a
while now but that demo where you url.opened() yahoo finance and
plotted it with those nice dates in 2/3 lines was very nice. ;)

On Tue, Mar 3, 2009 at 9:14 AM, John Hunter <jdh2358@...> wrote:
>
>
> On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor
> <jonathan.taylor@...> wrote:
>>
>> Hi,
>>
>> I saw that 3D plotting was dropped from matplotlib since the last time
>> I used it.  Unfortunately, it is pretty necessary for some of the work
>> I am doing.  Thus, I have started the process of refactoring the code
>> to work with recent versions of matplotlib.
>>
>> Right now, it is still in very early stages and is quite flaky but I
>> do have some functionality.  In particular, I am able to do a regular
>> 3d plot, a wireframe plot and a scatter plot.  If this interests
>> anyone I am making the code available via git.  Instructions are
>> available on my website at:
>
> That's great -- a number of people were very disappointed to see the
> functionality removed, even though it was primitive compared to a good 3D
> toolkit.  The problem was, we could never find a core developer who was
> interested in taking it under his wing.  Once you get this to a satisfactory
> point, I suggest you develop it as an mpl toolkit.  That way, it will get
> installed with every mpl distro (the plain vanilla toolkits we ship, the
> complex ones like basemap are distributed separately) but without the
> implicit promise of full support until someone is willing to step up and
> offer to fully support it.
>
> JDH
>
>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
John Hunter | 3 Mar 17:39
Picon
Gravatar

Re: Updating MPlot3D to a more recent matplotlib.



On Tue, Mar 3, 2009 at 9:56 AM, Jonathan Taylor <jonathan.taylor-H217xnMUJC0sA/PxXw9srA@public.gmane.org> wrote:
That sounds reasonable.  Can I ask what it is that was primitive?
Having looked through the code I see that a few shortcuts were made to
minimize the amount of code written that makes it especially
susceptible to changes in the 2D code.  That said, it seems like it
was comparable functionally to matlab's 3d plots, which is my goal for
it.

Well, it is painfully slow, since it does everything in software, and there are some corner cases where the zorder clipping is broken in the presence of alpha transparency, and it doesn't do lighting, shadows, etc....  But it does do enough for basic stuff, so we would be happy if you could resurrect it cleanly enough for a toolkit.
 

P.S.  I saw your talk at NIPS 2008 this year.  I have used mpl for a
while now but that demo where you url.opened() yahoo finance and
plotted it with those nice dates in 2/3 lines was very nice. ;)


Yep, that is a favorite example of mine :-)  I'm giving a talk at SIAM on Thursday, and I think I'll do this one again, time permitting.

JDH
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ryan May | 3 Mar 18:23
Picon
Gravatar

Re: File format for plots

On Mon, Mar 2, 2009 at 3:52 PM, Gael Varoquaux <gael.varoquaux-t+5nXNeJE7o5viHyz3+zKA@public.gmane.org> wrote:
On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote:
>    Other than the automatic regeneration from latex, what you want sounds
>    like what we already have: small python scripts.

>    In general, I'm completely amazed by how many people want to develop a new
>    markup/script language to wrap what is already a simple and expressive
>    language, both for plots and (at least around here) analyses.  If there
>    are some spots that require too many lines of code to accomplish something
>    really simple, then maybe we need to API additions. But in general, I
>    think we have a format for specifying how to make a plot: python. 

Although I agree with you that reinventing an extra scripting layer is
often a bad solution to a problem which should simply be solved by having
a good scripting API in Python, I believe there is here a fundamental
misconception.

Python is an imperative, Turing-complete. This is a very good thing for a
scripting language. For making a description of a static object as a
plot, this is not a good thing. For instance, if I want to make a plot,
save it, and later blow up all the fonts, I really don't want to be using
an imperative, Turing-complete language for the persistence model, as
static analysis of this persisted object is going to be next to
impossible. Same thing if I want to change colormaps, or just about
anything in my persisted object, for the same reason.

A good rule for most software design is that the state of the
application, or of the object of interest, in our case the plot, should
be fully represented by a fully-static set of values, that I like to call
the model. Although this sounds like a tautology, this design rule is
more often broken than followed. For instance the status of an
application may be entirely dependent on its past, or the important state
variables may be hidden in places where you can't get hold of them (eg
the status of a GUI widget, or inside a generator).

Having a very clean separation between your (fully-static) model, and the
logics around is a very important part of good application design, and I
believe I know this because I have so often made an error and violated
this rule :).

If you have this static model, rather than an imperative language, then
you can have persistence. By the way, Mayavi2 achieves its code
generation by introspection on the model. The generated lines of code are
just a way of expressing the changes.

Sorry for being fussy, I am just trying to pass on what I believe I am
learning painfully :).

Not at all.  You made some good points.  I hadn't really thought about the prospect of things changing in the core of the rest of the code.  It was probably just a knee jerk reaction to something I hear a lot around here, regarding making a small language/configuration file for automating analyses *in python*. :)

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Gmane