06:46 <gproto23> Can someone help me with the code snippet in the HTDP book?

11:12 <bremner> gproto23: hard to say, but more likely if you paste it to e.g. pasterack.org and link to that

11:53 <gproto23> :bremner http://pasterack.org/pastes/15938

12:03 <bremner> gproto23: I'm not very familiar with the universe stuff, but at a guess it has to do with fitting the rocket in the visible area while the height is high

12:19 <gproto23> bremner: yes, correct. but the point i don't understand is its calculation

12:22 <bremner> gproto23: maybe it helps that place-image takes the coordinates as the location for the center of the image, and dividing by 2 finds the vertical center

20:22 <WickedShell> I'm starting to experiment with the plot library, but a simple program that passes 1 million points to the line renderer takes an extremely long time to render (far, far longer then trying the same with matplotlib for example). Is there anything obvious I might be missing about getting the plot to run quickly?

20:35 <friscosam> WickedShell: if you're calling plot from untyped racket you may be incurring some contract checks. For a small number of points it is probably not taking as long to do the checks.

20:36 <friscosam> I wrote a simple test program to check from #lang racket but it is hanging on my computer now :(

20:36 <WickedShell> friscosam I'm calling it from typed racket actually, if I add a time call around the call to plot it's about 1.5 seconds, but the actual window that pops up takes more like a minute + to actually have lines shown

20:36 <WickedShell> I can post my terrible sample program, one moment

20:37 <WickedShell> friscosam https://pastebin.com/1P4MRMDi

20:37 <WickedShell> shortening the list will be much more responsive :)

20:39 <friscosam> my other guess is that it is truly trying to render a million lines and it is slow, and maybe matplotlib does some simplification depending on number of lines resolution etc.

20:39 <WickedShell> Also seems like some O(n^2) behaviour (although I haven't written enough down on the actual times taken), but plotting 60,000 points felt much longer then 2x 30,000

20:40 <WickedShell> Well it's worth noting that if you zoom in far enough on the 1 million point plot once it's there it's actually reasonably responsive

20:40 <WickedShell> So it's definetly during the renderering. It doesn't mean you are wrong of course :)

20:41 <friscosam> Yeah it may render everything in the first go and reuse a bitmap?

20:41 <WickedShell> Pretty sure it's re rendering when I zoom in

20:41 <WickedShell> Because the aspect ratios can get real weird as you zoom in (with the window controls)

20:42 <friscosam> Ah of course

21:05 <friscosam> So it took 24.5s on this macbook to render a png with 60000 points. Running it under the profiler it only took two samples?!? Which makes me wonder if it's spending a lot of time out in FFI to cairo doing some drawing

21:07 <friscosam> You might want to open an issue in the plot package and see if Alex can provide more info. https://github.com/racket/plot/issues

21:13 <friscosam> lol. I just looked at the 60k plot it's just a wall of red.

23:05 <WickedShell> friscosam sorry, I had to step away for a bit. Yeah it's a wall of red with that many samples. My long term goal is to role my own plotting solution for some log analysis stuff

23:06 <WickedShell> And a routine log for this produces about 2 million data points that you zoom in on depending on what you need to look at, and having 2-4 plots (admittedly not all of them are in the millions of points range) is not at all uncommon.

23:07 <WickedShell> I'm somewhat hoping to avoid roling my own entire solution for culling/rendering, but I may just need to accept that's the path I need to go

23:07 <WickedShell> But I am quite impressed with the general ease of making reasonable looking plots (although tbh I'm impressed at the number of things in the box so to speak with Racket anyways...)

23:33 <bremner> not sure if I'm doing it wrong, but the new build with CS backend does not seem parallelize much