Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On Fri, Jul 27, 2007 at 08:52:27AM -0400, Michael Droettboom wrote: > Using this "mathtext=True" option (as opposed to using a delimiter that > TeX doesn't understand) or something else entirely, would certainly make > it easier to make usetex vs. not usetex more consistent. I think so to. > More broadly, it will probably never be 100% compatible -- I don't think > reimplementing all of TeX is feasible or desirable, and the fact that it > is a macro language makes it hard to fully emulate. Defining what is a > "hack" vs. normal usage is also subjective, of course... No, of course, but you are making some progress in this direction, and I think that would be a great added value coming from your work. Cheers, Gaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
Gael Varoquaux wrote: > On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote: > >>> text(x, y, 'what is the $\sin(x)$', mathtext=True) >>> > > >> Except for the backward incompatibility, I like this because it is explicit. >> > > Juust a data point for the discussion. I think it would be very nice if a > script gave the same result on a system with or without TeX (as long as > you don't do TeX hacks). > Using this "mathtext=True" option (as opposed to using a delimiter that TeX doesn't understand) or something else entirely, would certainly make it easier to make usetex vs. not usetex more consistent. More broadly, it will probably never be 100% compatible -- I don't think reimplementing all of TeX is feasible or desirable, and the fact that it is a macro language makes it hard to fully emulate. Defining what is a "hack" vs. normal usage is also subjective, of course... Cheers, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote: > > text(x, y, 'what is the $\sin(x)$', mathtext=True) > Except for the backward incompatibility, I like this because it is explicit. Juust a data point for the discussion. I think it would be very nice if a script gave the same result on a system with or without TeX (as long as you don't do TeX hacks). My 2 cents, Gaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
John Hunter wrote:
> Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
Except for the backward incompatibility, I like this because it is explicit.
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text.
That's close to what it does at the moment.
> Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option.
I'm not sure the performance hit would be so bad. The parser is
completely flat until it goes between the $'s. But it would require all
$'s to be escaped, of course.
> In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
>
Well, that certainly is no shortage of options! ;) I think the decision
should ultimately lie with someone with a better sense of the existing
"feel" of matplotlib than I.
If we go with another delimiter, there are others in TeX to choose
from. Plain TeX uses $$ for display math, and LaTeX uses \[, \]. Both
of these are less likely to be legitimate literals. While display math
normally implies that the math is placed on a separate line (not inline
with the text), it's not far from what matplotlib does, since it follows
the display math layout patterns.
Cheers,
Mike
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On Friday 27 July 2007 08:38:49 am Michael Droettboom wrote: > If we go with another delimiter, there are others in TeX to choose > from. Plain TeX uses $$ for display math, and LaTeX uses \[, \]. Both > of these are less likely to be legitimate literals. While display math > normally implies that the math is placed on a separate line (not inline > with the text), it's not far from what matplotlib does, since it follows > the display math layout patterns. I think $$ might be a bad idea, that has a very specific meaning in TeX, which is different than $. Like wise, \[ means display math while \( means inline math. \( ... \) is considered to be fragile, while $ ... $ is robust, but maybe \( \) would be a good solution. Then you could even switch between mathtext and usetex, and the usetex code wouldnt have to go through strings trying to substitute latex mathmode indicators for mpl indicators. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] organization of traited config system
On Thursday 26 July 2007 11:40:23 am Fernando Perez wrote: > On 7/26/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > On Thursday 26 July 2007 10:30:34 am Ted Drain wrote: > > > Why do you need an api file at all? Why not have config be a python > > > package and let config/__init__.py take care of importing > > > everything? [...] > I don't remember the exact details, but we started using the api.py > approach instead of __init__ on Enthought's lead [...] > You may want to inquire with them for the details I did ask at enthought-dev, and they said it was primarily due to circular dependencies. The use of __init__ is already causing us some headaches in mpl, so I decided to stick with api.py, leaving __init__ empty. I just uploaded my work to matplotlib svn. The idea is that matplotlib would import the rcParams (and eventually mplConfig) from config/api, but for just think of config/ as a sandbox. The new config system is turned on by default in api.py by setting USE_NEW_CONFIG = True If it is True, you can run configtest.py in IPython, which will import the traited mplConfig object and rcParams, a thin wrapper to mplConfig. configtest will change rcParams['backend'] to Cairo, validate that the change occured in mplConfig, and will then try to change the backend to something nonsensical and should throw an error. For now, validation in mplConfig is very similar to validation in the old system. I have not taken advantage of the more advanced capabilities of traits, like shadow attributes and so forth. For now I just wanted to get something that should work with existing matplotlib. The first time the traited config module mplconfig is loaded, it checks your config_dir (the cwd and then probably ~/.matplotlib) for a matplotlib.conf file. If it does not exist, it creates one, loads your old matplotlibrc, updates mplConfig based on your matplotlibrc, saves any non-default settings to the new matplotlib.conf. If the file does exist, it updates mplConfig accordingly. The config/matpltolib.conf.default file was auto-generated (comments and all, thanks to Fernandos wizardry). Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
"John Hunter" <[EMAIL PROTECTED]> writes:
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX.
Those users are probably also not so likely to want to use mathtext, so
there could be an rc setting for toggling the meaning of $ between the
currency symbol and the math delimiter. Adding rc settings is probably
not good for the API, though.
Is it an option to use something rarer than $ to delimit formulas? Most
of the printable ASCII characters are probably being used by someone,
and the unprintable characters are likely to be difficult to handle. ISO
Latin 1 contains e.g. the little-used currency sign ¤. But perhaps it is
too difficult to type on US keyboards?
(There is a Unicode Technical Note at http://unicode.org/notes/tn28/
which suggests using U+23A8 LEFT CURLY BRACKET MIDDLE PIECE and U+23AC
RIGHT CURLY BRACKET MIDDLE PIECE as math delimiters, but it also has its
own Unicode-based math syntax.)
> Option 1 is to educate them, and require them to \$ quote that symbol.
I guess Option 1' is to move away from $ to something else, and educate
mathtext users. If there are fewer of them (us), this would seem to be
easier globally.
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
You're right that it would be quite different than the rest of the API.
Perhaps your Option 2 (a text property) would cause the least surprise
in the long run, although it would break current mathtext-using code.
--
Jouni K. Seppänen
http://www.iki.fi/jks
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Determining file format in print_figure
A problem was reported on the users list that saving to a file named 'blah.pdf' using the wxagg backend actually saves a jpeg file named 'blah.pdf.jpg'. I think I can see how to fix this (by adding a block to FigureCanvasWx.print_figure() similar to the existing blocks for ps and svg), but would prefer to leave it to someone who actually works with wx, in case I accidentally break something and never notice. I'll file a bug on sourceforge. Overall, the system for determining file format looks like it has evolved and not been designed: various backends have their own code to look at the file name extension and then switch to the proper backend. Wouldn't it make sense to share at least the code that determines the backend from the extension? -- Jouni K. Seppänen http://www.iki.fi/jks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
John Hunter wrote:
> On 7/26/07, Darren Dale <[EMAIL PROTECTED]> wrote:
>>> where Math is a wrapper object that signals to "text" that its contents
>>> are to be passed to the mathtext interpreter.
>> I would like to voice my opinion against this idea. I think the backward
>> imcompatibility will be rare, and does not justify the additionaly complexity
>> of the far more common need to interpret mathtext.
>
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX. Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text. Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option. In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
> JDH
Let's rule out option 3 completely; it is an example of the type of
cleverness that ends up causing more trouble and confusion than it is worth.
I also oppose using something other than the $ to delimit math, if
delimiters are needed, which I think they are. At least in *Tex, a
string of characters (a word) is rendered very differently depending on
whether it is inside an equation or outside.
I suspect that options 1 and 4 will cause endless questions to
matplotlib-users, and grumbling among people in the business and
financial community who use lots of dollar signs and no math.
That leaves some variant of 2 and the Math('string') idea. I find the
latter quite pythonic; it is a very concise, readable, and general way
of attaching extra information to a string object, and it does not
require passing yet another kwarg through a sequence of function and
method calls. But if it is judged to be too out-of-character with the
rest of the mpl api, or if in practice it would cause trouble that I
don't see yet, then I am happy to let it go. I have not thought it
through carefully, and I am not attached to it.
If a variant of 2 is chosen, one might shorten the kwarg to "math". Or
use "format='math'" or something like that. This is more flexible than
a boolean kwarg, leaving the door open to additional options for
interpretation of strings--but not quite as flexible and powerful as the
math('string') idea.
Eric
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
On Jul 25, 2007, at 12:09 PM, John Hunter wrote: > > Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring > you. Real life has made some demands on my time of late, and probably > will until next week, but I was able to download, read through and > test your code. I appreciate you making the time to take a look at my code in spite of it. > But I don't think that closes the book on the subject -- for > example, I have realized I am introducing too much complexity and > trait forwarding, and I think I know a way to work around this, so > I will be hacking through my version one more time while at the > same time taking a closer look at yours. I'd hardly expect it to close the book on the subject. Although it functions as a proof-of-concept, my rendering model needs more work before it can handle special cases like the blended affine transformation to plot an axis. I've been thinking about how best to accomplish this and will try to have something for you to look at by early next week. Please drop me a line when you're satisfied with your changes to mpl1.py, as I'm looking forward to seeing them. > I also would like to hear more about the "hard to optimize" part, > because that is not intuitively clear to me. Moving to a rendering model when the primitives modify the CTM instead of replacing it with a pre-calculated value removes the dependency between primitives and their containers. A Primitive object, like a Path, may be reused and shared between renderers. The native version of a Primitive object is stored by the Primitive object itself, so it can be reused by any Canvas that draws the Primitive. This also means that you incur very little cost in clearing a Renderer and then repopulating it with existing Primitives. An Artist-level implementation of z-order could leverage this to avoid having to sort primitives by z-order every time a figure is rendered. Since primitives modify graphics state instead of replacing it wholesale the it's easier for the Canvas to push as few changes to the backend as possible. For example, if none of the child primitives of a ScaledView have their own transforms then the CTM only gets modified once when the ScaledView is rendered. The same is true for all of the other graphics state parameters, like linewidth and strokecolor. This saves on unnecessary backend overhead (e.g. creating the same agg.trans_affine repeatedly). It could also lead to tighter PDF and EPS output. Finally, the Renderer class is canvas-independent so it can be used to draw on multiple canvases during the course of its lifetime. I hope this will substantially simplify the process of saving a figure that was drawn interactively. I'm also contemplating making Renderers able to contain child Renderers so parts of a figure can be selectively updated. For example, drawing the non-Axis children of an Axes by using a subrenderer could further improve animation performance. > I confess to being a meta-class ignoramus, so I am intrigued to study > how you handled the canvas primitive cache problem using meta classes. I hate to disappoint you, but metaclasses aren't involved. Right now the caching is implemented cooperatively by Canvas and CanvasPrimitive to reduce duplicate code. CanvasPrimitive.get_canvas_primitive() handles the caching logic and calls CanvasPrimitive.create_canvas_primitive() to create a new native object if necessary. Subclasses of CanvasPrimitiveoverride create_canvas_primitive() to delegate the call to the appropriate method of Canvas, e.g. Path.create_canvas_primitive() returns the result of Canvas.create_canvas_path(). Subclasses of Canvas that do not cache Primitives should not override the create_canvas_xxx() methods. > How for example, if one modifies a Rectangle object which embodies a > path primitive, would the canvas get the notification to update it's > internal path representation (egg the agg_path_storage)?. Native canvas objects are always created at render-time, so rectangle would just update its associated Path instance when its bounds changed. The next time the Path is drawn, Canvas.draw_path() would call CanvasPrimitive.get_canvas_primitive() and end up with a new AGG path. That being said, it might be more efficient if all Rectangles share one Path that draws a unit square and change its size by updating the CTM. > With traits, I use the trait event handling mechanism so that when > any of > the box properties (left, width, top, etc...) are modified, the > PathPrimitiveAgg would get a callback. So when the user does > > rect.left = 0.1 > > the agg path knows to update itself. This is pretty cool. Yes it is, and I agree that mpl1 should have an attribute-based API for modifying plot object parameters. > vis-a-vis properties vs traits, I second Peter's comment that once > you've written 8,000 setters and getters and
Re: [matplotlib-devel] mpl1 draft
Sent via BlackBerry from T-Mobile -Original Message- From: Ken McIvor <[EMAIL PROTECTED]> Date: Fri, 27 Jul 2007 17:35:05 To:John Hunter <[EMAIL PROTECTED]> Cc:matplotlib development list Subject: Re: [matplotlib-devel] mpl1 draft On Jul 25, 2007, at 12:09 PM, John Hunter wrote: > > Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring > you. Real life has made some demands on my time of late, and probably > will until next week, but I was able to download, read through and > test your code. I appreciate you making the time to take a look at my code in spite of it. > But I don't think that closes the book on the subject -- for > example, I have realized I am introducing too much complexity and > trait forwarding, and I think I know a way to work around this, so > I will be hacking through my version one more time while at the > same time taking a closer look at yours. I'd hardly expect it to close the book on the subject. Although it functions as a proof-of-concept, my rendering model needs more work before it can handle special cases like the blended affine transformation to plot an axis. I've been thinking about how best to accomplish this and will try to have something for you to look at by early next week. Please drop me a line when you're satisfied with your changes to mpl1.py, as I'm looking forward to seeing them. > I also would like to hear more about the "hard to optimize" part, > because that is not intuitively clear to me. Moving to a rendering model when the primitives modify the CTM instead of replacing it with a pre-calculated value removes the dependency between primitives and their containers. A Primitive object, like a Path, may be reused and shared between renderers. The native version of a Primitive object is stored by the Primitive object itself, so it can be reused by any Canvas that draws the Primitive. This also means that you incur very little cost in clearing a Renderer and then repopulating it with existing Primitives. An Artist-level implementation of z-order could leverage this to avoid having to sort primitives by z-order every time a figure is rendered. Since primitives modify graphics state instead of replacing it wholesale the it's easier for the Canvas to push as few changes to the backend as possible. For example, if none of the child primitives of a ScaledView have their own transforms then the CTM only gets modified once when the ScaledView is rendered. The same is true for all of the other graphics state parameters, like linewidth and strokecolor. This saves on unnecessary backend overhead (e.g. creating the same agg.trans_affine repeatedly). It could also lead to tighter PDF and EPS output. Finally, the Renderer class is canvas-independent so it can be used to draw on multiple canvases during the course of its lifetime. I hope this will substantially simplify the process of saving a figure that was drawn interactively. I'm also contemplating making Renderers able to contain child Renderers so parts of a figure can be selectively updated. For example, drawing the non-Axis children of an Axes by using a subrenderer could further improve animation performance. > I confess to being a meta-class ignoramus, so I am intrigued to study > how you handled the canvas primitive cache problem using meta classes. I hate to disappoint you, but metaclasses aren't involved. Right now the caching is implemented cooperatively by Canvas and CanvasPrimitive to reduce duplicate code. CanvasPrimitive.get_canvas_primitive() handles the caching logic and calls CanvasPrimitive.create_canvas_primitive() to create a new native object if necessary. Subclasses of CanvasPrimitiveoverride create_canvas_primitive() to delegate the call to the appropriate method of Canvas, e.g. Path.create_canvas_primitive() returns the result of Canvas.create_canvas_path(). Subclasses of Canvas that do not cache Primitives should not override the create_canvas_xxx() methods. > How for example, if one modifies a Rectangle object which embodies a > path primitive, would the canvas get the notification to update it's > internal path representation (egg the agg_path_storage)?. Native canvas objects are always created at render-time, so rectangle would just update its associated Path instance when its bounds changed. The next time the Path is drawn, Canvas.draw_path() would call CanvasPrimitive.get_canvas_primitive() and end up with a new AGG path. That being said, it might be more efficient if all Rectangles share one Path that draws a unit square and change its size by updating the CTM. > With traits, I use the trait event handling mechanism so that when > any of > the box properties (left, width, top, etc...) are modified, the > PathPrimitiveAgg would get a callback. So when the user does > > rect.left = 0.1 > > the agg path knows to update itself.
