Syntax looks matplotlib-ish so we’re going back to 2003
Fastplotlib: GPU-accelerated, fast, and interactive plotting library
151–160 of 190 posts
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#152Syntax looks matplotlib-ish so we’re going back to 2003
I'd prefer even more matplotlib-ish. Don't fix what's not broken.
A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#153Syntax looks matplotlib-ish so we’re going back to 2003
I'd prefer even more matplotlib-ish. Don't fix what's not broken. A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
> of complicated APIs
of which the matplotlib is the embodiment. Terrible API with terrible terrible performance.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#154Earlier quoted context omitted.
Thanks, and the purpose was to show what's possible on modest hardware that most people have. We have created gigabytes of graphics that live on the gpu for more complex use cases and they remain performant, but you need a gaming gpu.
But why do you want to fit the whole dataset in memory? If the dataset is stored in a tiled and multi-scaled representation you need to only grab the part of it that is needed to fit your screen (which is a constant , small amount of data, even if the dataset is arbitrarily large). If you insist to fit the entire thing in memory, it may seem better to do so in the plain RAM, which nowadays is of humongous size even i…
Maybe it's an instance of Parkinson's law [1]: if it all fits in GPU memory, just put it all in and plot it. This is much simpler to implement than any out-of-memory technique. It's also easier for the user—`scatter(x, y)` would work effortlessly with, say, 10 million points.
But with 10 billion points, you need to consider more sophisticated approaches.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#155Earlier quoted context omitted.
I'd prefer even more matplotlib-ish. Don't fix what's not broken. A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
> of complicated APIs of which the matplotlib is the embodiment. Terrible API with terrible terrible performance.
Yeah, I'm not sure why anyone likes matplotlib, but then I guess I liked base-R which is even more niche, so :shrug:.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#156Earlier quoted context omitted.
I'd prefer even more matplotlib-ish. Don't fix what's not broken. A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
> of complicated APIs of which the matplotlib is the embodiment. Terrible API with terrible terrible performance.
Not sure what you mean by complicated API. The (pylab) API is a very straightforward (mostly) immediate rendering typeish interface, with a lot of convenient shortcuts for operations used a lot in data analysis.
For architecture astronauts there's also the OOP API over which the pylab API is a wrapper.
Of course there are also a lot of all sorts of declarative APIs, which are popular with people copy-pasting code from cookbooks. These become very painful very fast if you do something that's not in the cookbook.
Matplotlib does struggle with performance in some/many cases, but it has little to do with the API.
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#157Syntax looks matplotlib-ish so we’re going back to 2003
I'd prefer even more matplotlib-ish. Don't fix what's not broken. A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
> Don't fix what's not broken.
I would argue that the Matplotlib syntax is horribly broken (or rather, the Matlab syntax it historically tried to emulate, and had to stick with for better or worse..)
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#158Earlier quoted context omitted.
I'd prefer even more matplotlib-ish. Don't fix what's not broken. A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
> Don't fix what's not broken. I would argue that the Matplotlib syntax is horribly broken (or rather, the Matlab syntax it historically tried to emulate, and had to stick with for better or worse..)
What are your issues with the matplotlib API more specifically?
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#159Earlier quoted context omitted.
Yeah, I remember looking into it myself as well, and not finding any easy path. A shame.... Maybe there's a hard way to do it though :)
I've been looking into this issue with Datoviz [1] following a user request. It turns out there may be a way to achieve it using Vulkan [2] (which Datoviz is based on) and CuPy's UnownedMemory [3]. I wrote a simple proof of concept using only Vulkan and CuPy. I'm now working on a way for users to wrap a Datoviz GPU buffer as a CuPy array that directly references the Datoviz-managed GPU memory. This should, in princip…
I published my proof-of-concept here: https://gist.github.com/rossant/517806ea551f4038fd412c23c3d6...
Re: Fastplotlib: GPU-accelerated, fast, and interactive plotting library
#160Earlier quoted context omitted.
I'd prefer even more matplotlib-ish. Don't fix what's not broken. A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
> of complicated APIs of which the matplotlib is the embodiment. Terrible API with terrible terrible performance.
I feel like everyone has different expectations for a scientific plotting API. The tension between ease of use and expressivity is so strong that a one-size-fits-all solution is unlikely ever to exist.