an1sotropy
an1sotropy on Hacker News
The bummer is that the transmission is only unidirectional, but a unicycle needs bidirectional control, with very little backlash. Every economical planetary gear hub involves over-running pawls, alas.
Sorry, I'll try to be clearer. QRhi docs[1] say "The Qt Rendering Hardware Interface is an abstraction for hardware accelerated graphics APIs, such as, OpenGL, OpenGL ES, Direct3D, Metal, and Vulkan." And PySide6 includes a (python) wrapper for QRhi[2]. Meanwhile, pygfx builds on wgpu-py[3] which builds on wgpu[4] which is a "is a cross-platform, safe, pure-rust graphics API. It runs natively on Vulkan, Metal, D3D12, and OpenGL".
So, from the standpoint of someone using PySide6, QRhi and pygfx seem to be alternative paths to doing GPU-enabled rendering, on the exact same range of GPU APIs.
Thus my question: How do they compare? How should I make an informed comparison between them?
[1] https://doc.qt.io/qt-6/qrhi.html
[2] https://doc.qt.io/qtforpython-6/PySide6/QtWidgets/QRhiWidget...
[3] https://github.com/pygfx/wgpu-py/
[4] https://github.com/gfx-rs/wgpu
Sourceforge still works, and is (now) reliable. The awful DevShare malware stuff that Sourceforge started (under new ownership) in 2012 was stopped (under different new ownership) in 2016.
Thank you for sharing these links. They both worked for me (in the US); both were set to ON when I got there, and I was able to turn both OFF.
Fwiw the github page for that proposal isn't linking to what seems to be the most recent discussion *. I thought type-annotations-as-comments was a no-brainer, but it seems messy. The Sept 2023 discussion shows that it is complicated by the current variety of annotation schemes (TypeScript is not the only one), and the parsing subtleties, which gave rise to unresolved questions about what is the basic motivation. bummer.
* https://github.com/tc39/notes/blob/main/meetings/2023-09/sep...
What a sweet film. Thank you for the link. This whole time when I heard about work on the Voyager mission I assumed there was a larger team, with fewer single points of failure.
I first learned about "leaky abstractions" from John Cook, who describes* IEEE 754 floats as a leaky abstraction of the reals. I think this is a good way of appreciating floating point for the large group of people who's experience is somewhere between numerical computing experts (who look at every arithmetic operation through the lens of numerical precision) and total beginners (who haven't yet recognized that there can't be a one-to-one correspondence between a point on the real number line and a "float").
* https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leak...
He actually just posted a video in which he admits he lost the plot, and forgot that the real goal is something that is
fun. I hope he finds his way back to that!
https://youtu.be/BpJYqC4PWEw
I love that that page is nearly the same as it when I saw it ~20 years ago. Things things are still the right way.
I guess "floats are weird" is a catchier title than "numerical computing is an acquired skill based in part on understanding the various consequences of value representation density being inversely proportional to the absolute value".
I'm looking forward to learning more about which one makes it easier to see how various possible changes in the data are mapped to legible changes in the visualization.
Also tracks my experience as a unicyclist. When you keep poking at humanity with the same but unusual prompt, you glimpse how similar people can be. To the quip about losing a wheel, my sadly habituated response is "that was the training wheel!", and then they chuckle, because it's new to them ...
The last event in their timeline is 2020. Moon presumed shot.
Interesting - thanks dahart (hi again!) for pointing out these references. They do seem to be missing in the Cornell report.
I wonder if Apple will use this to annoy people who are still happily using the (admittedly old versions of) OpenGL, which has been deprecated for awhile but still working for people who want simple cross-platform graphics.
Thanks for the detailed info. I'm glad it's not me trying to craft this code. Good luck with the optimizations.
Thanks for sharing this. I was worried when I saw the rejection test at the end (around line 1749) that this could be slow, but I guess that for cases like a=0 and b=1, your code avoids that rejection ever happening, is that right? So the rejection only kicks in when the bounds are in the middle of range of one fixed exponent?
well that's the article-wave duality in action.
I think Alvy Ray Smith understands both the fundamentals of sampling theory and the practicalities of real-world image synthesis and display, given his role in the creation of computer graphics.
Re "If they [displays] did [filtering] then anti-aliasing wouldn't be a thing" - that doesn't match my understanding of sampling theory. If the computer graphics process of image synthesis has folded down high frequencies in the hypothetical source signal, well above (half) the image sampling resolution, so that they now overlap with lower frequencies of the image -- i.e. the image generation suffers aliasing -- then no "filtering" downstream (at least in the traditional signal processing sense) can undo that, and the shape the display elements certainly won't save you either. The job of anti-aliasing is to prevent high-frequency energy from landing in the band-pass in the first place.
Re "plenty of cameras don't have any filtering": the physical act of counting photons that fall onto the areal extent of a CCD element (with an the associated directional distribution created by the prior optics) is absolutely a filtering of the incoming optical signal. That is independent of any subsequent digital filtering of the pixel data.
Suns ran Solaris, of course.