I see that https://en.wikipedia.org/wiki/SRGB#Translation_to_integers implies what I would call node-centered sampling ("standard" or "mid-tread" in the post), but are you aware of sRGB documentation that precisely specifies the quantization semantics?
Most of what I've read about sRGB focuses on the semantics of continuous (floating-point) R,G,B channels.
This is like a 1D version of what a scientific computing person might describe as the distinction between node-centered ("standard" or "mid-tread" in this post) vs cell-centered ("alternative", "mid-riser") samples: do consider values to be at the middles of bins (or middles of triangles, or middle of tetrahedra), or the boundaries between intervals (or vertices of triangles, or of tets).
In a scientific computing setting it would be insane to start doing data processing without knowing how to interpret the values. In the context of audio signal processing, if you just get a stream of integers, you'd have to know the representational intent of those integers (mu-law encoding or linear?) if you're going to compute anything about the underlying signal. The meta-data accompanying the values would hopefully provide the answer.
But with 8-bit pixel values, absent any meta-data from a competent file format that can communicate the representational intent, we're adrift and there's no right answer (like the author says). Certainly no one can fault you for picking whichever one seems to be give better results for your application, but you can raise awareness that bits without context have had their meaning undermined.
This is very cool! I would love the ability to scribble arbitrary smooth curves (like a little right hand, or a comma, something asymmetric to highlight the symmetries in play) and see how they are repeated.
Thanks for highlighting this. I've seen a lot of popular press about Magnifica Humanitas that notes the slavery apology. It does make some sense with this (recent, as you note) humanist push, but shoe-horning a centuries-overdue apology about actual terrible slavery into a consideration of how AI might metaphorically enslave us feels a little weird.
As a standard for floating point representation and computation, IEEE 754 solved multiple long-standing serious problems better than anything that came before it. I don't think its sensible to judge it with a PL design lens like "principle of least astonishment"; certainly not as if IEEE754 is a peer to Rust or Python. Or, you could learn about the surprise, frustration, and expense involved in trying to write portable numeric code in the 1970s, prior to IEEE 754:
I like this justifiation of NaN != NaN; it emphasizes that NaN has representional intent, more than just some bit pattern.
We take for granted that (except for things like x86 extended precision registers) floating point basically works the same everywhere, which was the huge victory of IEEE 754. It easy to lose sight of that huge win, and to be ungrateful, when one's first introduction to IEEE 754 are details like NaN!=NaN.
Thank you for the background info, and sorry for me explaining CFFI (I just wanted to be sure we were talking about the same thing). Being ignorant about PyPy, I honestly had no idea until now that there was a personnel or purpose overlap between CFFI and PyPy. I am very grateful for CFFI (though I only use it API mode).
Sorry can you explain more the connection between PyPy and CFFI (which generates compiled extension modules to wrap an existing C library)? I have never used PyPy, but I use CFFI all the time (to wrap C libraries unrelated to Python so that I can use them from Python)
Is there any visibility or accountability to record exactly what it did and not look at? I doubt it. So we're left with a kind of Rorschach test: some people think LLMs follow rules like law-abiding citizens, and some people distrust commercial LLMs because they understand that commercial LLMs were never designed for visibility and accountability.
Sure, a license can't create new legal understanding of "derived work", but I think the intent of what Splinelinus said still works: a license outlines the terms under which a licensee can use the licensed Work. The license can say "if you train a model on the Work, then here are the terms that apply to model or what the model generates". If you accept the license, those terms apply, even if the phrase "derived work" never came up. I hope there are more licenses that include terms explicitly dealing with models trained on the Work.
Also, for comparison, both GPL and LGPL, when applied to software libraries (in the C sense of the word), assert that creating an application by linking with the library creates a derived work (derived from the library), and then they both give the terms that govern that "derived work" (which are reciprocal for GPL but not for LGPL). IANAL but I believe those terms are enforceable, even if the thing made by linking with the library does not meet a legal threshold for being a derived work.
I love the Vernier scales! But I honestly hadn't known about the sense in which slide rules have a Venier scale until your comment, which led me to [1]. In another class on laser-cutting I had students make a kerf-meter, which became more accurate with a Vernier scale.
A big 6-foot K&E sliderule hung at the front of my high-school chemistry classroom, but was never used. At graduation ('91) I asked the teacher if I could have the slide rule and she said "sure".
I keep it now in my office, and once a year I bring to the data visualization class I teach at UChicago, to show how it works, and to show it as an example of a visual device in aid of computational thinking (nomographs being another great example).
I learned about this not from Mathologer, but Numberphile [1]. The second half of the video is the continued fraction derivation. I remember this being the first time I appreciated the sense in which the phi was the most irrational number, which otherwise seemed like just a click-bait-y idea. But you've found an earlier (9 years ago vs 7) Mathologer video on the same topic.
That's super cool! Thanks for explaining. Just to clarify myself - when I was thinking of automation I was not thinking of AI, or at least not how its popularly understood these days. I was thinking more like how 2D mazes can be automatically made by non-AI methods. Uncrossy would need a kind of constraint solver that can navigate words lexically and the spatial intersection of words (and their possible slides). I'm certainly not telling you anything you don't know. There are some algorithms for these (general) kinds of constraint satisfaction problems and they long pre-date "AI", but I think the application to uncrossy and refinement would be quite challenging.
It may have jumped the shark, but it may be that now there's space for actual experimentation and innovation again. This talk from Scott Jenson (who worked at Apple in Human Interfaces) was thought-provoking and gave me a little optimism: https://www.youtube.com/watch?v=1fZTOjd_bOQ
The website says "I basically need to design puzzles in reverse and have built a set of tools to help me with that." Does that mean that each day's puzzle is essentially built by hand? It seems like an interesting and non-trivial search problem to automatically generate puzzles, given a dictionary.
Most of what I've read about sRGB focuses on the semantics of continuous (floating-point) R,G,B channels.