log scaling fixes in backend_ps.py

Development matplotlib-devel
1

But since I don't know whether numeric/numarray provide

    > fully consistent array2str functions (I only have
    > numeric to test with), I'm a bit afraid of touching this
    > part. It's also possible that John's backend
    > architectural changes end up modifying this, so perhaps
    > such changes are best thought about after John finishes
    > his reorganization.

No, now is a good time. Right now I'm proposing the *addition* of a
new method to the backend, with the *eventual* deletion of redundant
methods. draw_lines is one of those core methods that I think
deserves to remain and be highly optimized.

    > However, I'm afraid to rewrite this in a low-level way,
    > because of the numeric/numarray difference. The right
    > approach for this would be to generate a string
    > representation of the array via numeric/numarray, which
    > can do it in C. And then, that can be modified to add
    > the m/l end of line markers on the first/rest lines via
    > a (fast) python string operation.

Actually, I think the right way to do it me to save the x and y arrays
as postscript arrays, and then generate the postscript for loop to
iterate over the arrays at postscript render time. Then we have
no loop in python and smaller file sizes. I think this approach in
general could be a big win in PS both in terms of file size and file
creation times. The major feature of postscript that the mpl backend
currently underutilizes, dare I say almost ignores, is that postscript
is a programming language.

I'll leave it to Jochen to decide on the patch and/or apply it -- on
my quick read the changes look sensible, and since it passes
backend_driver, it must be good!

JDH

2

Hello,

Actually, I think the right way to do it me to save the x and y arrays
as postscript arrays, and then generate the postscript for loop to
iterate over the arrays at postscript render time. ...

The major feature of postscript that the mpl backend
currently underutilizes, dare I say almost ignores, is that postscript
is a programming language. ...

From reading parts of the green book ("PostScript Language Program Design")
I gathered the impression that the preferred way of generating PostScript
is to do most of the calculations before writing the PostScript.

Some references from the green book:

  p.9: It is better to translate into the PostScript imaging mod-
     el than to maintain another set of graphics primitives
     using the PostScript language for

  p. 80: Remember that the PostScript language is interpreted,
    and that it is a programming language only as one
    aspect of its design. It is best not to defer calculation
    (such as division problems, computing the diameter of a
    circle, or figuring the length of some text) to the inter-
    preter. Instead, perform these calculations on the host
    system as the script is being generated, providing the
    data to the procedures in the format expected by the
    PostScript language and the individual operators used.

  The section "Computation" starting at p. 83 has a similar stance.

The computers matplotlib runs on are probabily many times faster
than the ones built into printers and every PostScript file is
generated only once but potentially printed many times. Therefore
I would rather spend additional CPU cycles in backend_ps.py to
get a compact and computationally simple PostScript file.

Thus I do not think that the "PostScript loop" mentioned above is
a good idea.

I'll leave it to Jochen to decide on the patch and/or apply it -- on
my quick read the changes look sensible, and since it passes
backend_driver, it must be good!

The first version of the patch looked good to me.
Unfortunately I cannot spend any time on this before Thursday.
I suggest that you just apply the patch to CVS and I have
a look at the result on Thursday.

All the best and thank you very much and good night,
Jochen

···

On Tue, Feb 08, 2005 at 02:45:05PM -0600, John Hunter wrote:
--