Re: [matplotlib-devel] fix to clabel issues plus more

2008-09-23 Thread John Hunter 
On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would just undo what I have done rather than putting a lot of moved
> messages all over the place.  I personally find the mix of matlab and
> non-matlab stuff in mlab confusing, but I will go with the group
> consensus.

Since noone else had anything to add here, I moved all the
numerical_methods methods back into mlab until we have a more
comprehensive solution that is friendly to the existing codebase (one
of my apps was just bitten by it...)

JDH

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] color mix

2008-09-23 Thread Jae-Joon Lee 
Hi.

I don't think my last message (sent a few days ago) made it to the
mailing list. I'm reposting it again.


On Fri, Sep 19, 2008 at 4:50 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> I just uploaded a slightly modified patch with more doumentations.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2119751&group_id=80706&atid=560722
>
> I added a documentation for the colors.py module and
> ColorConverter.to_rgb() method. Is there any other place I need to
> care?
> I'll see what I can do with the user's guide also.
>
> Jouni,
> Thanks for the suggestion. But I'm afraid that I'm not so keen about
> implementing your suggestions, although their implementation should be
> very straight forward. My intention was to support only a simple color
> mixing, so trivial that my brain can actually predict the result.
> While my current code understands strings like
> "orange!30!purple!50!white", I don't think I'll ever use it because it
> is hard to predict the resulting color (at least for me). Instead,
> I'll just to look up the color table and pick up the color I want. So,
> I'm sorry, but I may not implement those features you suggested unless
> you or someone else give me a good motivation. On the other hand, I
> added a "mix_rgb" method in the ColorConverter class, which partially
> support what you have suggested.
>
> Regards,
>
> -JJ


I also tried to take a look at the user's guide documentation, but I
couldn't find the relevant section about the color (under the
doc/users directory) while the pdf version linked in the homepage DO
have a section about the color. Is it that the new sphinx-based docs
does not have the color section yet? or am I looking at the wrong
directories?

Regards,

-JJ

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for scatter plot legend enhancement

2008-09-23 Thread John Hunter 
On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
> Attached is a diff against revision 6115 that contains a patch to
> improve the behavior of the legend function when showing legends for

Erik,

I haven't had a chance to get to this yet.  Could you please also post
it on the sf patch tracker so it doesn't get dropped, and ping us with
a reminder in a few days if nothing has happened

JDH

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] yet another fancy arrow, etc

2008-09-23 Thread Jae-Joon Lee 
Hello,

I'm working on the fancy annotation thing I mentioned the other day,
and I want to have some feedback and advice.

As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
the annotation will be consist of a fancy box + fancy arrow. And my
current plan is to put the fancy arrow things as an arrow patch class
in the patches.py. The new class would be very similar to the
FancyBboxPatch class. It will take three control points of quadratic
bezier path as an input, and will draw an arrow around this path (an
example is attached). For example

mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
  arrowstyle="simple",
  ec="blue!50!white",
  fc="blue!20!white")

But, patches.py already has three arrow classes.

 * Arrow(x, y, dx, dy)
 * FancyArrow(x, y, dx, dy)
 * YAArrow(figure, xytip, xybase)

And I'm a bit hesitating in adding yet another arrow class. One way
I'm considering is to merge my arrow class with the currently existing
FancyArrow class (or other). But their interface is a bit different
and I'm afraid that it may confuse users. So, how others think? Would
it better to simply have a seperate arrow class or to have it merged
into one of the existing arrow classes?



The other thing is, as I said, the annotation is consist of a fancy
box and fancy arrow, which means we need to draw a union of two closed
bezier path. I hoped that the agg package have those kind
functionality but I couldn't find one (if there is, please let me
know). So, I think there are two options.

 * Forget the union operation and fake it by modifying the order of
"stroke" and "fill", i.e, stroke the paths of the box and arrow first
then fill each path later (with a same color). The above figure uses
this approach. It would not work if your want a transparent fill
color.

 * Or, use an external library.
2geom(http://lib2geom.sourceforge.net/) seems promising, and I
currently have a simple wrapper based on it which does the job (2geom
does provide a python interface but not all of its funtionality are
wrapped yet. So I needed make a few changes).

My inclination is to go with the first option. But since this seems a
bit hackish way to do it, I want to know how others think.

Any comment, suggestion, or advice would be appreciated.

-JJ
<>-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] yet another fancy arrow, etc

2008-09-23 Thread John Hunter 
On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm working on the fancy annotation thing I mentioned the other day,
> and I want to have some feedback and advice.
>
> As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
> the annotation will be consist of a fancy box + fancy arrow. And my
> current plan is to put the fancy arrow things as an arrow patch class
> in the patches.py. The new class would be very similar to the
> FancyBboxPatch class. It will take three control points of quadratic
> bezier path as an input, and will draw an arrow around this path (an
> example is attached). For example
>
>mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
>  arrowstyle="simple",
>  ec="blue!50!white",
>  fc="blue!20!white")
>
> But, patches.py already has three arrow classes.
>
>  * Arrow(x, y, dx, dy)
>  * FancyArrow(x, y, dx, dy)
>  * YAArrow(figure, xytip, xybase)
>
> And I'm a bit hesitating in adding yet another arrow class. One way
> I'm considering is to merge my arrow class with the currently existing
> FancyArrow class (or other). But their interface is a bit different
> and I'm afraid that it may confuse users. So, how others think? Would
> it better to simply have a seperate arrow class or to have it merged
> into one of the existing arrow classes?

Well merging is obviously better. I wrote YAArrow to support
plain-vanilla annotations.  AFAIK, they are used nowhere else, so as
long as we could come up with one arrow class that works with
plain-vanilla and fancy annotations, that would be good.  But it may
be easier said than done.  These annotation arrows are really helper
classes that are instantiated by higher level functions (eg users most
likely won't be creating them themselves) and since they all have the
basic patch interface, I don't think having a proliferation of them is
the worst thing in the world, though the ideal is to have as few
classes as possible that serve as many cases as possible.


> The other thing is, as I said, the annotation is consist of a fancy
> box and fancy arrow, which means we need to draw a union of two closed
> bezier path. I hoped that the agg package have those kind
> functionality but I couldn't find one (if there is, please let me
> know). So, I think there are two options.

I believe you are looking for the scanline boolean algebra -- search
the antigrain demo page

  http://www.antigrain.com/demo/index.html

for scanline_boolean.cpp.  Of course, we would need to support the
other major backends too

>  * Forget the union operation and fake it by modifying the order of
> "stroke" and "fill", i.e, stroke the paths of the box and arrow first
> then fill each path later (with a same color). The above figure uses
> this approach. It would not work if your want a transparent fill
> color.
>
>  * Or, use an external library.
> 2geom(http://lib2geom.sourceforge.net/) seems promising, and I
> currently have a simple wrapper based on it which does the job (2geom
> does provide a python interface but not all of its funtionality are
> wrapped yet. So I needed make a few changes).

This appears to be LGPL, so we will not be using it in the main distro.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Outdated pytz and dateutil

2008-09-23 Thread Russell E. Owen 
In article 
<[EMAIL PROTECTED]>,
 "John Hunter" <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 18, 2008 at 2:33 PM, Russell E. Owen <[EMAIL PROTECTED]> 
> wrote:
> > The versions of pytz and dateutil that are included with matplotlib
> > 0.98.3 are outdated
> 
> Hey Russell, thanks for the head's up.
> 
> For our source installs, by default we install them only if they are
> not on the system, but you can configure this with setup.cfg to
> always, never or conditionally install them.
> 
> I have updated the mpl versions to the ones you point to above.

I just discovered that matplotlib 0.98.3 is not compatible with pytz 
2008c due to an unexpected change in pytz. The following fix works (I 
chucked it into __init__.py near the beginning).

# the following fix for compatibility with pytz 1.4.1 is from
# 
import pytz
try:
import pytz.zoneinfo
except ImportError:
pytz.zoneinfo = pytz.tzinfo
pytz.zoneinfo.UTC = pytz.UTC

-- Russell


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] color mix

2008-09-23 Thread Tom Holroyd 
Repost; the list bounced my last attempt.

On Fri, 2008-09-19 at 18:42 -0400, Tom Holroyd wrote:
> On Thu, 2008-09-18 at 20:40 +0200, Jouni K. Seppänen wrote:
> > I would prefer something like the following options:
> > 
> > fc={'orange': 20, 'white': None}
> > fc=[[20, 'orange'], [None, 'white']]
> > fc=ColorMixture('orange', 20, 'white') # where ColorMixture is a fairly
> ># trivial class
> 
> +1
> 
> simpler, easier to read & write, less ad-hoc
> 
> I'd go ahead and make ColorMixture a fancy class with __rmul__ and
> __add__ methods to allow things like
>   orange = ColorMixture(255, 165, 0)
>   blue = ColorMixture(0, 0, 255)
>   mycolor = .7 * orange + .2 * blue
> 
> like,
> 
> class cm:
>   def __init__(self, r, g, b):
> self.r = r
> self.g = g
> self.b = b
>   def __rmul__(self, a):
> return cm(a * self.r, a * self.g, a * self.b)
>   def __add__(self, a):
> return cm(a.r + self.r, a.g + self.g, a.b + self.b)
> 
-- 
Elephants can paint.
http://www.elephantart.com/catalog/thailand.php


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel