On Feb 29, 12:52 pm, William Stein <wst...@gmail.com> wrote: > On Wed, Feb 29, 2012 at 5:30 AM, Jason Grout > > <jason-s...@creativetrax.com> wrote: > > IIRC, the idea was to rely more on matplotlib, and the default ways to > > configure matplotlib (which includes setting the default figure size). IIRC, > > It seemed that the default matplotlib figure size was pretty close to what > > we had. > > > Is it possible that you have magnified your webpage (command +), so that all > > figures show up bigger than they should be? > > I did. But even resetting to the default zoom I think the resulting > plot looks far too big by default (the first screenshot). > > > It's also possibly your > > high-resolution display. The figures have a default dpi, and maybe you > > should set that dpi to a higher dpi to have figures that appear the same > > size as on a lower-dpi screen. > > Carl also pointed out that he didn't delete the DEFAULT_DPI option.
And I'll point out again that it was Jason who actually commented out the DEFAULT_FIGSIZE option, and a number of us who gave it positive review :) > the work Carl (and you) did on graphics was to "unify" Sage and > matplotlib, which in some cases breaks the main idea behind the > original design of 2d graphics in Sage. I'm not saying that is > necessarily bad, but I'm curious if you were aware of this. > > The above distinction is similar to the relation between Sage matrices > and numpy arrays. It was good that we made the indexing compatible, > but there are many situations where the semantics are different, e.g., > in numpy "A*B" is componentwise product, and it would be > counterproductive to change Sage to be the same as numpy. My take on the various tickets along these lines is more like the discussion about how to use Maxima. We try to expose as much as possible without being onerous, but if there is something that is better to use Maxima (or Ginac) native functionality, we should, without the end user knowing it. (I agree with you there.) There is a lot of stuff that is much, much nicer now that we have access to mpl stuff internally and aren't redoing it from scratch (like axes). So the "solution" to this part of the comment is to expose that functionality in a Sage-native way. > One part of the philosophy of 2d graphics in Sage was supposed to be > that use of matplotlib is abstracted away completely, so that we can > have different backend rendering for plotting. E.g., in many cases > you can embed a 2d plot in a 3d plot right now, which draws the 2d > plot without using matplotlib; of course, this doesn't fully work due > to some 2d plotting being tied to matplotlib still. This would also > be important if we want to implement some completely new way of > rendering 2d plotting, e.g., using html5... That's a different question, and a really important one. But since there hasn't been too much work on the other backends (the flot example went somewhere briefly...), it's hard to blame people for wanting things like aspect ratio to work right. > Anyway, from the above perspective, it is not optimal that setting the > default figure size (or dpi) requires calls directly into the > matplotlib library. Naturally. > Incidentally, 3d graphics also have the same philosophy as above, but > Robert Bradshaw wrote much of the rendering engine, and did a much, > much better job enforcing isolation between the actual libraries doing > the rendering and the abstract 3d graphics objects. Either that, or > he made the code so hard to work on that nobody messed it up :-). In Both :) > any case, the situation with 3d graphics now is that it is not at all > fundamentally tied to jmol in the way that 2d graphics are > fundamentally tied to matplotlib (and getting more that way, rather > than less). I personally consider anything at all that ties 2d > graphics fundamentally to matplotlib to be a bug, and wish that all To be fair to those who have worked on graphics in the last few years, this was never really articulated until now, and looking at http://trac.sagemath.org/sage_trac/query?status=closed&author=%7E&component=graphics&order=author&col=id&col=summary&col=author&col=component&col=status&col=type&col=priority&col=milestone&merged=%5Esage-4. one can see a host of contributors, very few of whom would have been involved in the original 2D plotting code design (which must be >5 years ago now?). Although the _render_on_subplot is somewhat modular, I guess, even that assumes that the 'subplot' thingie makes sense. I think it would be hard to just rip that all out in a quick way. Hence: > such things would be completely removed from Sage. Project for GSOC application? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
