On Sun, Nov 16, 2008 at 11:01 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Sun, Nov 16, 2008 at 9:39 PM, Alex Clemesha <[EMAIL PROTECTED]> wrote:
>>
>> On Sun, Nov 16, 2008 at 10:03 AM, mhampton <[EMAIL PROTECTED]> wrote:
>>>
>>> I think this sounds great, I give a hearty +1.
>>>
>>> I've gotten frustrated in the past by the plotting code. Being "more
>>> closely tied to matplotlib" would be nice for lots of reasons.
>> I as well support utilizing matplotlib way more. I wrote a lot of that
>> plotting
>> code almost 3 years ago and in the meantime have watched matplotlib
>> continually get
>> better and better. Their code is far better the (naive) stuff I wrote
>> way back then.
>
> Is there any code in matplotlib for actually drawing x and y axis?
> I mean, since you're saying their code is way better than yours
> for doing that, maybe you can confirm they actually have code
> for doing that? :-)
So, I just saw the email from Jason Grout which kinda answers this question.
Now that I think about it, the code I wrote to actually create the
Mathematica like
axis is actually pretty decent (decent in the sense that the result
look pretty in most cases).
I don't know if you recall William, but I put in a bit of sweat and
tears into those axes -
and you did your part in helping me out too :-)
So I guess I mean the matplotlib plotting framework as a whole is
really awesome,
and should be utilized to maximum extent, but it looks as though they
don't cover
every detail like fine grain axis control.
-Alex
>
>>
>> A big +1 for going with matplotlib as much as possible.
>>
>> -Alex
>>
>>
>>
>>
>>
>> The
>>> matplotlib documentation is pretty good, and maybe some of what we do
>>> could find its way upstream in Mike's approach. Its a similar
>>> situation to how I feel about the preparser and leaving python types
>>> alone - its a good thing to stay as close to python as possible.
>>>
>>> Many cheers for working on this!
>>>
>>> -Marshall
>>>
>>> On Nov 17, 11:23 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
>>>> Hello,
>>>>
>>>>
>>>>
>>>> On Sat, Nov 15, 2008 at 11:06 AM, Ronan Paixão <[EMAIL PROTECTED]> wrote:
>>>>
>>>> > Em Sex, 2008-11-14 às 16:22 -0200, Ronan Paixão escreveu:
>>>> >> I recently thought about implementing more functions used by non-math
>>>> >> people (I'm an Electronic Engineering student).
>>>>
>>>> >> I started by trying to make a Bode plot, but after a lot of digging to
>>>> >> find how to make subplots and how to use logarithmic scale in plot(), I
>>>> >> found that if applying that kind of scale can turn plot() unusable.
>>>>
>>>> >> The first problem is that the adaptive choosing of points just considers
>>>> >> linear scale, so the points get too much spaced apart in the beginning
>>>> >> of the plot and too close in the end.
>>>>
>>>> >> The second problem relates to the axis, which, for the same reason,
>>>> >> isn't located right.
>>>>
>>>> >> to test it, one can try:
>>>>
>>>> >> p=plot(x,marker='.')
>>>> >> f=pylab.figure()
>>>> >> f.gca().set_xscale('log')
>>>> >> p.save(figure=f)
>>>>
>>>> >> So, I intend to implement the changes in plot() to support it.
>>>> >> For that, I ask YOU (uncle sam pointing finger) sage gurus how to better
>>>> >> implement that: would it be better to try check if the user used a
>>>> >> custom figure() with different axis or would it be better to add another
>>>> >> kwarg like log="xy" where "x" would make the x axis logarithmic and "y"
>>>> >> likewise for the y axis, avoiding the need for the user to deal with
>>>> >> matplotlib's figure()?
>>>>
>>>> After thinking about this (and the plotting code in general), I think
>>>> our best bet is to scrap the custom axes code written in
>>>> sage/plot/axes.py and to let matplotlib handle axes, ticks, etc.
>>>> They've thought about and worked on this problem and have developed a
>>>> fairly robust solution. Most of the axes code hasn't been touched in
>>>> over 2 years despite complaints (
>>>> seehttp://groups.google.com/group/sage-devel/browse_thread/thread/394b2f...
>>>> ). If we want custom axes, then we should do so by properly
>>>> subclassing matplotlibs Axes class.
>>>>
>>>> Additionally, I think the Graphics wrapper should not be nearly as
>>>> heavy as it is. In particular, there's no way to get at and modify
>>>> the matplotlib subplot object. For example, I have some preliminary
>>>> code that would let one do this:
>>>>
>>>> sage: p = plot(e^x, 1, 5)
>>>> sage: p.subplot.set_xlabel('Mike')
>>>> <matplotlib.text.Text object at 0x46b8350>
>>>> sage: p.subplot.set_title('A plot')
>>>> <matplotlib.text.Text object at 0x46badd0>
>>>> sage: p.subplot.set_ylabel("Sage")
>>>> <matplotlib.text.Text object at 0x46ba090>
>>>> sage: p.save('plot1.png')
>>>> sage: p.subplot.set_yscale('log')
>>>> sage: p.save('plot2.png')
>>>>
>>>> to produce the following images:
>>>>
>>>> http://sage.math.washington.edu/home/mhansen/plot1.pnghttp://sage.math.washington.edu/home/mhansen/plot2.png
>>>>
>>>> While this would mean being more closely tied to matplotlib as a
>>>> backed, I think the benefits are worth it. I don't envision anybody
>>>> working on another backend for Graphics anytime in the near future.
>>>>
>>>> --Mike
>>> >
>>>
>>
>>
>>
>> --
>> Alex Clemesha
>> clemesha.org
>>
>> >
>>
>
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
> >
>
--
Alex Clemesha
clemesha.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
