Re: tick marks
David Joyner
http://www.sagemath.org/doc/html/prog/node72.html
http://wiki.sagemath.org/TracGuidelines
My suggestion is to email sage-support and
(a) report the problem (include OS, example, and sage version)
(b) ask if it is recommended to create a trac ticket (it might be an
old, known bug)
(c) explain you have a patch (a mercurial patch, created via the hg_sage.export
command is preferred).
Thanks for helping with SAGE!
On Fri, Apr 4, 2008 at 11:43 AM, Gerhard Ertaler <ge0...@yahoo.de> wrote:
>
> Hello Prof. Joyner,
>
> what is the proper way to submit a minor patch to sage?
>
> specifically, I ran into some problems with the 2D _tasteful_ticks
> routine (tick marks for 2D axes). One such can be seen in the "Polynomial
> evaluation"
> notebook on the public sagemath server (by ge01705),
> together with a possible replacement for the routine in the "More tasteful
> ticks?"
> notebook.
>
> I do not wish to assert any copyrights or any attribution
> should this code get used, I'd just like not to have to patch
> my version of sage for a trivial problem.
>
> -gerhard
> ________________________________
> Gesendet von Yahoo! Mail.
> Dem pfiffigeren Posteingang.
gerhard
implements 2D plot tick marks restricts the
range of values of the axis.
Since I needed additional functionality,
I implemented a different version for my use.
I have a mercurial bundle available if there is
interest?
* The actual bounds used for the axes
can yield very surprising results.
Should the range bounds be honored if
the user sets them explicitely?
-gerhard
William Stein
>
> * The _tasteful_ticks routine in axes.py that
> implements 2D plot tick marks restricts the
> range of values of the axis.
>
> Since I needed additional functionality,
> I implemented a different version for my use.
> I have a mercurial bundle available if there is
> interest?
I'm interested.
>
> * The actual bounds used for the axes
> can yield very surprising results.
> Should the range bounds be honored if
> the user sets them explicitely?
It seems like it. We should fix this. Does your
bundle fix this?
William
gerhard
I took the liberty to mail the boundle to your gmail address.
What is the preferred way to submit a bundle?
> It seems like it. We should fix this. Does your
> bundle fix this?
-gerhard
Joel B. Mohler
> * The actual bounds used for the axes
> can yield very surprising results.
> Should the range bounds be honored if
> the user sets them explicitely?
Since we had a thread about this a bit ago and I was allegedly going to write
a patch, I'll share my results of the patch. I had a patch which (in the
case I was interested in) eliminated 3 places which nudge the margins about
for aesthetic reasons. I thought it might be a manageable job to turn that
into a more generic patch which honors margins.
However, I was thoroughly scared off when I saw what would need to be done to
honor the bounds setting for all cases (frame/no frame, etc). There is a lot
of "magic constants" in the code (0.1, 0.015, 0.002, etc) which evidently
were labored over for days. This is a very worthwhile task, but it sure
looks like it needs a more massive overhaul than I wanted to engage in.
In general, I think the right algorithm is something like this:
1) Honor the bounds settings
2) Check if there are tick marks, axis labels, tick labels outside the
viewable area
3) Enlarge the viewable area using font metrics to include these labels.
I know nothing about matplotlib so parts 2&3 are not possible for me in any
amount of time I wanted to commit to this. However, parts 2&3 are necessary
for the frames=True option. I don't know if it is actually difficult or not.
I totally reject the "aesthetic" padding idea though so it really is (IMO)
just a matter of finding font metrics from whatever code is making text.
--
Joel
mhampton
often irritated by my explicit bounds being expanded in hard to
predict ways. I am somewhat confused by the way the 2D graphics use
and alter matplotlib, so I didn't fix it myself either, but I could at
least review a patch.
The first thing a lot of people want to do with something like Sage is
plot something, and if it doesn't look good they might not try it
again. I have literally seen that happen. The 3D graphics have been
a huge boost but 2D is what people try first.
-M. Hampton
gerhard
plot(sin(40*x),(1.96,2.04))
are intriguing....
-gerhard
William Stein
The output in Sage now is just plain crap and totally wrong.
William
gerhard
should the current 2D plotting package be maintained and upgrated
(a lot of work!), or might it be preferable
to slip another graphics engine underneath
(maintaining the API)?
Since R will be a standard package,
using R graphics would be an option:
statisticians need good graphics capabilities,
and have made a lot of effort.
-gerhard
Note R also has an addon rggobi that allows data brushing.
It might also be of interest
William Stein
>
> To play devil's advocate:
> should the current 2D plotting package be maintained and upgrated
> (a lot of work!), or might it be preferable
> to slip another graphics engine underneath
> (maintaining the API)?
It would indeed be preferable to slip another graphics engine underneath
so we just have to maintain an API. In fact that is exactly what we
already *did*. Sage's 2d graphics are just an API and the graphics
engine underneath is matplotlib, which is the canonical choice for
2d plotting for Python: http://matplotlib.sourceforge.net/
> Since R will be a standard package,
^^^^^^^^
R *is* a standard package in Sage, and I hope will always remain so.
> using R graphics would be an option:
> statisticians need good graphics capabilities,
> and have made a lot of effort.
>
> -gerhard
>
> Note R also has an addon rggobi that allows data brushing.
> It might also be of interest
R definitely has lots of cool graphics capabilities, and I really
hope we can vastly improve the usability of them from Sage.
It's even possible that the R foundation will select
a Google Summer of Code project on doing exactly this and more
(but we'll see); I'm strongly voting for it.
William