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. 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
