On 04/27/2012 03:31 PM, Deren Dohoda wrote:
> Thanks, Neil. I don't mind. Clearly rough sampling would make plots
> really icky. That's not at all my goal. It was more like localization
> of the parameters.--- which is still true under the current
> interpretation, just not in a way I expected.
>> Backstory: I was plotting splines and it was extremely slow and at
> first all I found to speed things up was to decrease the number of
> samples... with predictable results. What I had done was interpolate
> 520 points, generating 519 polynomials evaluated over a short
> distance, which when plotted used (function ... ) 519 times. I was
> getting worried that it was trying to plot all 519 functions over the
> entire range but then discarding results not wanted to be seen or
> something, which got me worried that I couldn't plot these at all
> because my range was really large and to see the results I needed
> quite a few samples. But in the end the problem wasn't sampling in the
> way this mentioned: after I packed all 519 cubics into a single
> procedure which knew on its own which part of the spline to evaluate
> for a given x-value, necessitating a single (function ...) in the
> renderer tree, everything went as fast as I'd originally hoped.
>> Which means, short version: plot is still awesome.
Aww! Thanks!
Now that you've pointed out that function renderers with bounds that are
small relative the plot bounds are so incredibly wasteful, it's obvious
I should do something about it. I could alter the sampler so that it
takes two ranges, one for the plot bounds and one for the renderer
bounds, and only samples within the renderer bounds (and just outside
them) but with spacing relative to the plot bounds. Then a `spline'
function that returns a big list of small function renderers would be
feasible.
This is probably not an isolated incident. I can only provide so many
kinds of renderers. It's inevitable that someone will need to generate a
big list of them and expect their efficiency to be proportional to their
size.
It'll take a bit of thought to figure out how it will interact with
determining plot bounds and such. For now, I've submitted a bug report
for myself, with this test case:
#lang racket
(require plot)
(define count 0)
(plot (function (λ (x) (set! count (+ 1 count)) x) 0 1/100)
#:x-min 0 #:x-max 1)
count
Here, `count' should evaluate to a number much smaller than 1000. :)
Thanks again!
Neil ⊥