I agree that the new logo looks nice, but I also think that
Rob is right: When you see the logo you wouldn't know that
we are talking about a general purpose plotting package.
So the question is: are we going for looks over meaning?
I guess the other way around would be terrible: choosing
meaning o
Hi folks,
I've added this little bit of code to the default ipython -pylab startup:
exec ("import numpy\n"
"import numpy as np\n"
"import matplotlib\n"
"import matplotlib.pylab as pylab\n"
"try:\n"
"import matplotli
John Hunter wrote:
> On Sat, May 24, 2008 at 6:02 PM, Olle Engdegård <[EMAIL PROTECTED]> wrote:
>
>> I very much miss the 'l' shortcut for toggling log/lin y-scale in the
>> trunk! I use it a lot.
>>
>> I suggest restoring it with something like
>>
>> if self.get_yscale() is ("log" or "linear"):
>
Darren Dale wrote:
> On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
>
>> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
>>
>>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <[EMAIL PROTECTED]>
>>>
> I tracked this down by checking the contents of the generated
> bu
It's giving a floating point exception on the following operation:
i % Nface
where Nface is the number of face colors, which in this case is 0.
We probably want to trap for this case in the C code so it at least
doesn't crash, but am I right that "c=''" is an invalid input? What
should that
John Hunter wrote:
> On Sat, May 31, 2008 at 9:19 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
>
>> I'll be working on converting docstrings to rest this weekend. Should any of
>> this be done on the branch? Or should we just focus on the trunk?
>>
>
> As far as I am concerned, the documentat
On Mon, Jun 2, 2008 at 8:12 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I agree with John -- I think the documentation effort should be focused on
> the trunk. Now that we have (apparently) such a stable 0.91.3, hopefully
> the maintenance branch will be much less frequently modified anyw
On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> We probably want to trap for this case in the C code so it at least
> doesn't crash, but am I right that "c=''" is an invalid input? What
> should that do, if not raise an exception?
facecolor='' or facecolor='None'
On Mon, Jun 2, 2008 at 3:26 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> I've added this little bit of code to the default ipython -pylab startup:
The latest releases of pylab already provide np and plt in the pylab namespace.
Would it be better to simply add a "pyplot" mode to ipython to
enc
Ok. This should now be fixed in r5358.
Cheers,
Mike
John Hunter wrote:
> On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> We probably want to trap for this case in the C code so it at least
>> doesn't crash, but am I right that "c=''" is an invalid input?
Hey Michael,
I recently committed a pyplot patch for the switch_backends
functionality, and when I went to svnmerge it I go the changes for
your backend_agg fix. Since I would rather let you handle these, what
is the best way to back out of the situation I am in. I guess what I
would like to do
On Mon, Jun 2, 2008 at 7:28 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 3:26 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
>
>> I've added this little bit of code to the default ipython -pylab startup:
>
> The latest releases of pylab already provide np and plt in the pylab
John Hunter wrote:
> Hey Michael,
>
> I recently committed a pyplot patch for the switch_backends
> functionality, and when I went to svnmerge it I go the changes for
> your backend_agg fix. Since I would rather let you handle these, what
> is the best way to back out of the situation I am in. I
Howdy,
just saw this on the sage list:
http://sview01.wiredworkplace.net/pub/vfplot/index.html
The code is partly GPL (it uses a BSD kd-tree library), so don't go
looking there. But the basic ideas sound pretty neat for producing
very clean-looking vector fields. It would be neat if mpl grew
s
On Mon, Jun 2, 2008 at 2:42 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> The code is partly GPL (it uses a BSD kd-tree library), so don't go
> looking there. But the basic ideas sound pretty neat for producing
> very clean-looking vector fields. It would be neat if mpl grew
> something along
John Hunter wrote:
> And now that we have spline path elements in mpl98, we can actually
> implement curved arrows w/o an onerous polygon approximation.
Then could we do this too?
http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg
from:
http://ccom.unh.edu/vislab/projects/FlowVis.html
On Mon, Jun 2, 2008 at 4:32 PM, Christopher Barker
<[EMAIL PROTECTED]> wrote:
> John Hunter wrote:
>> And now that we have spline path elements in mpl98, we can actually
>> implement curved arrows w/o an onerous polygon approximation.
>
> Then could we do this too?
>
> http://ccom.unh.edu/vislab/im
On Mon, Jun 2, 2008 at 2:32 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>> http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg
>
> That appears to have a gradient field gray->white on the arrows, which
> we haven't implemented. But I'd like too...
A bit of acid and the right music on top o
While going through and updating some scripts to use the new features
that were recently added to hist(), I found myself very confused by
the align keywords - I had to go and look at Manuel Metz's post a
couple weeks ago to believe it wasn't a typo in the documentation...
"center" and "edge" are ex
19 matches
Mail list logo
