[racket] Plot: #:samples parameter of function---is this what was meant?

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 ⊥