Re: [matplotlib-devel] STIX fonts
Darren Dale wrote: > On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote: >> This is maybe another push in the direction of using fontconfig (which >> claims to support otf fonts already). I'd really prefer to go in that >> direction rather than continue to tack on partial reimplementations of it >> in font_manager.py -- but it does complicate dependencies on non-X11 >> platforms). > > What are the dependency problems? I thought freetype was the only > requirement. > Incidentally, GIMP uses fontconfig on windows, and they comment at > http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary to what many > seem to think, fontconfig is in no way dependent on X11, so it does make some > sense to use it on Windows." Fontconfig depends on freetype and either expat or libxml2 (expat being the easier/lighter dependency). But the real dependency problem is that on Windows it generally isn't already there. So it would have to be added to the external windows dependency zip, and we would probably have to go through a few contortions to call it as a commandline tool. If we go the route of wrapping the API (which would be better anyway, since then we could look for fonts in our own custom font directory), it would just be like the existing dependencies on freetype and libpng. Not a big deal, really, but it adds an additional maintenance burden on those Windows dependencies. On the Mac, fontconfig appears to be installed as part of Apple's X11 distribution, but not without it, even though it is useful outside of X11. So, in case you can't tell, I've long been torn by this -- fontconfig solves the font lookup problem in a much more robust way than matplotlib will probably ever have the resources to do. On the other hand, it adds complexity to the matplotlib build req's. Perhaps if there were buy-in from some regular Windows and Mac devels to help maintain this going forward I wouldn't be so hesitant. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts
On Monday 05 November 2007 8:07:04 am you wrote: > Darren Dale wrote: > > On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote: > >> This is maybe another push in the direction of using fontconfig (which > >> claims to support otf fonts already). I'd really prefer to go in that > >> direction rather than continue to tack on partial reimplementations of > >> it in font_manager.py -- but it does complicate dependencies on non-X11 > >> platforms). > > > > What are the dependency problems? I thought freetype was the only > > requirement. Incidentally, GIMP uses fontconfig on windows, and they > > comment at http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary > > to what many seem to think, fontconfig is in no way dependent on X11, so > > it does make some sense to use it on Windows." > > Fontconfig depends on freetype and either expat or libxml2 (expat being > the easier/lighter dependency). Oh, your right. > But the real dependency problem is that on Windows it generally isn't > already there. So it would have to be added to the external windows > dependency zip, and we would probably have to go through a few > contortions to call it as a commandline tool. I wonder if that comes with additional overhead. > If we go the route of > wrapping the API (which would be better anyway, since then we could look > for fonts in our own custom font directory), it would just be like the > existing dependencies on freetype and libpng. Not a big deal, really, > but it adds an additional maintenance burden on those Windows dependencies. > > On the Mac, fontconfig appears to be installed as part of Apple's X11 > distribution, but not without it, even though it is useful outside of X11. > > So, in case you can't tell, I've long been torn by this -- fontconfig > solves the font lookup problem in a much more robust way than matplotlib > will probably ever have the resources to do. On the other hand, it adds > complexity to the matplotlib build req's. Perhaps if there were buy-in > from some regular Windows and Mac devels to help maintain this going > forward I wouldn't be so hesitant. Thanks for explaining. What a headache. I wonder what other cross-platform applications and libraries use to deal with fonts, like Qt and OpenOffice. Are there native alternatives to fontconfig that are universally installed on mac and windows? Or do all these projects have to roll their own solution like we do? - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts
On Monday 05 November 2007 8:49:01 am Darren Dale wrote: > On Monday 05 November 2007 8:07:04 am you wrote: > > Darren Dale wrote: > > > On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote: > > >> This is maybe another push in the direction of using fontconfig (which > > >> claims to support otf fonts already). I'd really prefer to go in that > > >> direction rather than continue to tack on partial reimplementations of > > >> it in font_manager.py -- but it does complicate dependencies on > > >> non-X11 platforms). > > > > > > What are the dependency problems? I thought freetype was the only > > > requirement. Incidentally, GIMP uses fontconfig on windows, and they > > > comment at http://www.gimp.org/~tml/gimp/win32/downloads.html: > > > "Contrary to what many seem to think, fontconfig is in no way dependent > > > on X11, so it does make some sense to use it on Windows." > > > > Fontconfig depends on freetype and either expat or libxml2 (expat being > > the easier/lighter dependency). > > Oh, your right. > > > But the real dependency problem is that on Windows it generally isn't > > already there. So it would have to be added to the external windows > > dependency zip, and we would probably have to go through a few > > contortions to call it as a commandline tool. > > I wonder if that comes with additional overhead. > > > If we go the route of > > wrapping the API (which would be better anyway, since then we could look > > for fonts in our own custom font directory), it would just be like the > > existing dependencies on freetype and libpng. Not a big deal, really, > > but it adds an additional maintenance burden on those Windows > > dependencies. > > > > On the Mac, fontconfig appears to be installed as part of Apple's X11 > > distribution, but not without it, even though it is useful outside of > > X11. > > > > So, in case you can't tell, I've long been torn by this -- fontconfig > > solves the font lookup problem in a much more robust way than matplotlib > > will probably ever have the resources to do. On the other hand, it adds > > complexity to the matplotlib build req's. Perhaps if there were buy-in > > from some regular Windows and Mac devels to help maintain this going > > forward I wouldn't be so hesitant. > > Thanks for explaining. What a headache. I wonder what other cross-platform > applications and libraries use to deal with fonts, like Qt and OpenOffice. > Are there native alternatives to fontconfig that are universally installed > on mac and windows? Or do all these projects have to roll their own > solution like we do? (That was a rhetorical question. I know we have gone around these circles a couple times before now.) - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] remove ipython hack?
On 11/4/07, Eric Firing <[EMAIL PROTECTED]> wrote: > John, Fernando, > > Is it OK to remove the hack now? In pyplot.py: > > # a hack to keep old versions of ipython working with mpl after bug > # fix #1209354 This was added in 2005 when mpl was at 0.83 and ipython was at 0.6.15, so yes, it is OK to remove it now. If someone wants to run the latest mpl, surely they can upgrade ipython. JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts
On 11/5/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > > If we go the route of > > > wrapping the API (which would be better anyway, since then we could look > > > for fonts in our own custom font directory), it would just be like the > > > existing dependencies on freetype and libpng. Not a big deal, really, > > > but it adds an additional maintenance burden on those Windows > > > dependencies. My inclination is to try and fix font_manager. Paul's goal was to implement the W3C specification for cross-platform font finding, which seems like a good starting point. So far, I've heard two complaints about the current setup: font_manager will throw up its hands and return a default if an exact match fails rather than returning the closest (this doesn't seem too hard to improve upon in the existing framework) and we do not have support for OpenType (not sure how hard this would be to add). Are there other problems? While I am sympathetic to the desire to depend on standard, maintained-by-someone-else, packages, I am also sympathetic to the problems of users on a variety of platforms who are currently finding mpl hard to build and install ( I had my own troubles on a new box this weekend). If everyone were on ubuntu, life would be great, but in the current environment adding a dependency (fontconfig) which also has a dependency (xml parser) is a lot to take on. I am definitely -1 on calling out to the command line. So if the consensus is that we really need fontconfig, I would be inclined to wrap the API and bring it in as an optional build dependency. Nadia looked at this at one point: having a repository of dependencies which the mpl could grab, unpack and build if needed. A general solution for zlib, png, freetype and possibly fontconfig and friends would be a welcome addition for OS X and win32 users. JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts
John Hunter wrote: > On 11/5/07, Darren Dale <[EMAIL PROTECTED]> wrote: If we go the route of wrapping the API (which would be better anyway, since then we could look for fonts in our own custom font directory), it would just be like the existing dependencies on freetype and libpng. Not a big deal, really, but it adds an additional maintenance burden on those Windows dependencies. > > My inclination is to try and fix font_manager. Paul's goal was to > implement the W3C specification for cross-platform font finding, which > seems like a good starting point. IMHO, it's just a not a very good algorithm. The key section (when an exact font-family match can not be found) is this: "UAs that implement intelligent matching may proceed to examine other descriptors such as x-height, glyph widths, and panose-1 to identify a different tentative font family. If there are matches for *all* the remaining descriptors, then that is the matching font face for the given element." (Emphasis mine). Certainly one can do better than all-or-nothing like this. Something like a weighted nearest neighbor match would result in much better near matches. > So far, I've heard two complaints > about the current setup: font_manager will throw up its hands and > return a default if an exact match fails rather than returning the > closest (this doesn't seem too hard to improve upon in the existing > framework) Not a lot of work, but the main data structure for lookups will need to be completely different. Right now it is a tree with font-family name at the top, so if that fails it's difficult to find something close. > and we do not have support for OpenType (not sure how hard > this would be to add). That's easy -- freetype handles them correctly and the interface to the metadata ends up looking the same as a ttf file. It's only because of the different file extension that they are not being seen now. I'll have a patch shortly. > Are there other problems? .dfont support on the Mac -- it only looks at the first font in the file. (Though, when I checked fontconfig a few months ago, it also exhibited this problem.) Maintaining a separate font cache means that the user must know to delete the matplotlib font cache file in order to use newly installed fonts. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts (status with matplotlib)
The STIX fonts are now passing the mathtext_examples.py unit test. This font blends much better with fonts like Times. The rcParam "mathtext.use_cm" (which is new since the last release) has been replaced with "mathtext.fontset" which takes either "cm", "stix" or "custom". To use the STIX fonts, set it to "stix". While "custom" mostly works with the STIX fonts, "stix" will turn on a little extra code that knows how to use the dynamically sized characters (such as the radical sign) from the correct STIX fonts. There are far more characters in the STIX fonts than in the Bakoma fonts, and many of them are not accessible through a "named" symbol, such as "\foo". At present, matplotlib only understands the common math symbols in core LaTeX, and a handful of symbols defined in commonly used LaTeX extension packages. Ideally, now that we have much more complete fonts, we could create mappings from all the symbols in the "Comprehensive LaTeX symbol list" to Unicode, but that's a considerable amount of bookkeeping work, unless someone else has already done it for some other project. I suspect that there's a 90/10 rule here: 90% of users use 10% of the symbols, and vice versa. (It may even be more like 99/1.) As a way around this, you can insert Unicode characters directly into the math string and it will correctly use that character in the STIX font. For example, the following will produce a carriage return symbol: ur"$\u23ce$" This even works for the *really* rare symbols (that don't have an official Unicode code point and have been placed in the "Private Use Area" codepage in a separate font file)... matplotlib has a little extra code to use the "Non-Unicode" fonts when necessary (when the codepoint is E000 - F8FF). Currently, there's no way to get at all of the fancy integral signs that STIX provides. Cheers, Mike Michael Droettboom wrote: > John Hunter wrote: >> On 11/5/07, Darren Dale <[EMAIL PROTECTED]> wrote: > If we go the route of > wrapping the API (which would be better anyway, since then we could look > for fonts in our own custom font directory), it would just be like the > existing dependencies on freetype and libpng. Not a big deal, really, > but it adds an additional maintenance burden on those Windows > dependencies. >> My inclination is to try and fix font_manager. Paul's goal was to >> implement the W3C specification for cross-platform font finding, which >> seems like a good starting point. > > IMHO, it's just a not a very good algorithm. The key section (when an > exact font-family match can not be found) is this: > > "UAs that implement intelligent matching may proceed to examine other > descriptors such as x-height, glyph widths, and panose-1 to identify a > different tentative font family. If there are matches for *all* the > remaining descriptors, then that is the matching font face for the given > element." (Emphasis mine). > > Certainly one can do better than all-or-nothing like this. Something > like a weighted nearest neighbor match would result in much better near > matches. > >> So far, I've heard two complaints >> about the current setup: font_manager will throw up its hands and >> return a default if an exact match fails rather than returning the >> closest (this doesn't seem too hard to improve upon in the existing >> framework) > > Not a lot of work, but the main data structure for lookups will need to > be completely different. Right now it is a tree with font-family name > at the top, so if that fails it's difficult to find something close. > >> and we do not have support for OpenType (not sure how hard >> this would be to add). > > That's easy -- freetype handles them correctly and the interface to the > metadata ends up looking the same as a ttf file. It's only because of > the different file extension that they are not being seen now. I'll > have a patch shortly. > >> Are there other problems? > > .dfont support on the Mac -- it only looks at the first font in the > file. (Though, when I checked fontconfig a few months ago, it also > exhibited this problem.) > > Maintaining a separate font cache means that the user must know to > delete the matplotlib font cache file in order to use newly installed fonts. > > Cheers, > Mike > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OS X Leopard install, snag
John Hunter wrote: > Now for my next problem: I built zlib, libpng an freetype from source > and I get a William Kyngesburye is building and maintaining a nice set of Universal Frameworks of various libs that are more or less standard on Linux: http://www.kyngchaos.com/software/unixport/frameworks Maybe they would be a good set to use as a standard recommendation for folks building/using MPL on OS-X. I think the Freetype and UnixImageIO Frameworks would cover it for MPL. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Inches?
On Sat, Nov 03, 2007 at 05:43:55PM +0100, Olivier Verdier wrote: > This is much worse than I thought. The "inch" unit is used in many places in > matplotlib. In particular in `figure` and `savefig`. Please, please consider > allowing other units. Let me emphasise this once more: in Europe, and, I > believe in most places around the world, one NEVER uses inches. Neither in > engineering nor, i think, in typography. For most people "inch" is basically > an unusual measure of how big screens are. I'm not kidding. Same for dpi, > it's a specific measurement of a resolution but nobody thinks of it as a > number of pixels per inches. > I have nothing against an internal use of inches inside matplotlib but > please consider allowing other units for all kinds of interfaces with the > user! > > The best choice in my opinion would be to have a unit preference in the > .matplotlibrc file. This unit could be, say, `inch` or `cm` (or mm). Then > any length would be expressed using this unit of length. That seems simple > enough, doesn't it? You have to be careful about the use of global flags which change the behaviour of a library --- they make it very difficult to write applications that work on all users machines. Consider an application where you have two graphs on the same page, and you want the axes to be aligned. The only way to do this reliably is to set the margin size. If you write code assuming mm and the users machine uses inches, the results will not be pretty. One solution is to attach units to all your values. With a set of base units that supports multiplication by scalars, this could be something like: figure(figsize=(100*mm,50*mm)) A sensible default such as printer points is needed if no units are specified. The reason you need to carry around the units is that you may want the size to scale with the font. For example, you may want to provide for 6 digits in the tic labels, so the margin should be ten times the width of a single digit (allowing for sign and spaces). Currently margins and legend boxes scale with the size of the plot, which is not ideal. Latex uses these units: mm Millimetres cm Centimetres in Inches pt Points (1in = 72.27pt) pc Picas (1pc = 12pt) em The width of the letter M in the current font ex The height of the letter x in the current font - Paul - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
On Wed, Oct 31, 2007 at 01:55:09PM -0400, Darren Dale wrote: > > Beta versions of tarballs are on > > http://code.enthought.com/downloads/source . I will make cleaner tarballs > > of the release that was done last week when I get back home. These > > tarballscan be used for eg packaging, or integrating the dependency, as > > Fernando does in ipython. > This is just what we are looking for. Please let me know when the new > tarballs are available. I forgot to let you know :->. I made a new release on Saturday. Its a traits 2 release, not a traits 3, but eventhough this is not the latest and greatest, this is what I use on a day to day basis, and it is a well tested and solid release. 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] STIX fonts (status with matplotlib)
STIX fonts seem to be break with PDF or PS font subsetting. Looking into it... Cheers, Mike Michael Droettboom wrote: > The STIX fonts are now passing the mathtext_examples.py unit test. This > font blends much better with fonts like Times. > > The rcParam "mathtext.use_cm" (which is new since the last release) has > been replaced with "mathtext.fontset" which takes either "cm", "stix" or > "custom". To use the STIX fonts, set it to "stix". While "custom" > mostly works with the STIX fonts, "stix" will turn on a little extra > code that knows how to use the dynamically sized characters (such as the > radical sign) from the correct STIX fonts. > > There are far more characters in the STIX fonts than in the Bakoma > fonts, and many of them are not accessible through a "named" symbol, > such as "\foo". At present, matplotlib only understands the common math > symbols in core LaTeX, and a handful of symbols defined in commonly used > LaTeX extension packages. Ideally, now that we have much more complete > fonts, we could create mappings from all the symbols in the > "Comprehensive LaTeX symbol list" to Unicode, but that's a considerable > amount of bookkeeping work, unless someone else has already done it for > some other project. I suspect that there's a 90/10 rule here: 90% of > users use 10% of the symbols, and vice versa. (It may even be more like > 99/1.) > > As a way around this, you can insert Unicode characters directly into > the math string and it will correctly use that character in the STIX > font. For example, the following will produce a carriage return symbol: > > ur"$\u23ce$" > > This even works for the *really* rare symbols (that don't have an > official Unicode code point and have been placed in the "Private Use > Area" codepage in a separate font file)... matplotlib has a little extra > code to use the "Non-Unicode" fonts when necessary (when the codepoint > is E000 - F8FF). > > Currently, there's no way to get at all of the fancy integral signs that > STIX provides. > > Cheers, > Mike > > Michael Droettboom wrote: >> John Hunter wrote: >>> On 11/5/07, Darren Dale <[EMAIL PROTECTED]> wrote: >> If we go the route of >> wrapping the API (which would be better anyway, since then we could look >> for fonts in our own custom font directory), it would just be like the >> existing dependencies on freetype and libpng. Not a big deal, really, >> but it adds an additional maintenance burden on those Windows >> dependencies. >>> My inclination is to try and fix font_manager. Paul's goal was to >>> implement the W3C specification for cross-platform font finding, which >>> seems like a good starting point. >> IMHO, it's just a not a very good algorithm. The key section (when an >> exact font-family match can not be found) is this: >> >> "UAs that implement intelligent matching may proceed to examine other >> descriptors such as x-height, glyph widths, and panose-1 to identify a >> different tentative font family. If there are matches for *all* the >> remaining descriptors, then that is the matching font face for the given >> element." (Emphasis mine). >> >> Certainly one can do better than all-or-nothing like this. Something >> like a weighted nearest neighbor match would result in much better near >> matches. >> >>> So far, I've heard two complaints >>> about the current setup: font_manager will throw up its hands and >>> return a default if an exact match fails rather than returning the >>> closest (this doesn't seem too hard to improve upon in the existing >>> framework) >> Not a lot of work, but the main data structure for lookups will need to >> be completely different. Right now it is a tree with font-family name >> at the top, so if that fails it's difficult to find something close. >> >>> and we do not have support for OpenType (not sure how hard >>> this would be to add). >> That's easy -- freetype handles them correctly and the interface to the >> metadata ends up looking the same as a ttf file. It's only because of >> the different file extension that they are not being seen now. I'll >> have a patch shortly. >> >>> Are there other problems? >> .dfont support on the Mac -- it only looks at the first font in the >> file. (Though, when I checked fontconfig a few months ago, it also >> exhibited this problem.) >> >> Maintaining a separate font cache means that the user must know to >> delete the matplotlib font cache file in order to use newly installed fonts. >> >> Cheers, >> Mike >> > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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
Re: [matplotlib-devel] units
John,
Sorry about the late replay - I've been out sick.
I don't mean to turn this around on you but it might be best if we
could define what mathematical operations MPL requires from a
type. Our types support all "reasonable" math ops. The examples of
things that have caused problems in the past are things like this:
1) Converting to array and assuming the input is float (this happened
in the last step patch that was submitted). I.e. something like this
(from memory):
my_y = npy.asarray( y, npy.float_ )
2) Assuming numeric properties for dates. For example, if you want a
midpoint of 2 x values, someone might write this:
xmid = 0.5 * ( x1 + x2 )
But you can't add 2 dates together so this won't work when using
dates for x. You could do this:
xmid = x1 + 0.5 * ( x2 - x1 )
Off the top of my head, the operations that our "extended types"
don't support are:
1) Mixing units (5*km + 4*sec). But this throws an exception so I
don't think it's problem that MPL has to deal with.
2) Passing extended types to other routines that expect floats (like
the math library trig functions). However, python __XXX__ math ops
like __abs__ and __nonzero__ are supported where appropriated
(numbers with units have __abs__ but dates don't).
3) Some math operations on times (epoch in our terminology). The
valid operations for epochs and durations are:
epoch <,>,== epoch (i.e. __cmp__ )
duration <,>,== duration (i.e. __cmp__ )
epoch = duration + epoch
epoch = epoch - duration
duration = epoch - epoch
duration = duration + duration
duration = duration - duration
duration = float * duration
duration = duration / float
float = duration / duration
duration = abs( duration )
duration.__nonzero__
I would expect these rules to hold true for python date/time objects
as well. The noteworthy operations that are NOT permitted are:
epoch + epoch
float * epoch
epoch / float
At 11:13 AM 11/2/2007, John Hunter wrote:
On 11/2/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> Now I am not so sure that the use of lists in errorbar is a fossil, but
> I certainly don't understand it. Would you give a summary of when one
> can and cannot use arrays in axes.py, please? The errorbar and bar
> methods seem to be the only victims of this restriction, and it looks
> like some of the instances are accomplishing nothing--the arguments get
> converted to arrays with the next method call anyway. I haven't tried
> to trace things carefully, obviously.
I just wrote some related stuff in the other thread, but will jump in
here. I think I may be being overzealous in my avoidance of arrays. What
we cannot assume is that asarray is creating an array of floats, so we
cannot do scalar array operations, eg 2*x. But we should be able to
assume object arrays, with indexing, and element wise opertations
which are well defined, eg for the canonical date example.
In [3]: import datetime
In [4]: date0 = datetime.date(2004,1,1)
In [5]: days = datetime.timedelta(days=1)
In [6]: d = [date0, date0+days, date0+2*days, date0+3*days]
In [7]: import numpy as n
In [8]: x1 = n.array(d)
In [9]: xerr = n.array([days]*len(x1))
In [10]: x1.dtype
Out[10]: dtype('object')
In [11]: x2.dtype
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'x2' is not defined
In [12]: xerr.dtype
Out[12]: dtype('object')
In [13]: x1 + xerr
Out[13]: array([2004-01-02, 2004-01-03, 2004-01-04, 2004-01-05], dtype=object)
The reason we are bumping into so may problems with errorbar is not
only because it is complex, but because it is doing more arithmetic
than other plotting code.
Ted, can you clarify what kinds of operations are permitted with your
iterable unit objects if they are initialized into numpy object
arrays?
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
