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.
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)
CFFI is fast on PyPy. The JIT still cannot peer into the compiled C/C++ code, but it can generate efficient interface code since there is a dedicated _cffi_backend module built into PyPy. Originally that was the motivation for the PyPy developers to create CFFI.
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).
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.
There should exist a .jsonl file somewhere with exactly that information in it - might be worth Dan preserving that, it should be in a ~/.claude/projects folder.
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.
Yeah, that's possible, but seems to me more about contract law and creating an EULA for the code, than it is about copyright-derived enforcement. maybe 'copyleft' stuff will move in that direction.
it's barely tangential to the topic but worth pointing out, I don't think there's firm legal consensus on your library point, that is just the position of the FSF that that's true. IANAL tho. https://en.wikipedia.org/wiki/GNU_General_Public_License#Lib...
This is also my thinking. A(ffero)GPL does something similar by saying a user of an API to AGPL code is bound by the AGPL license. You can always choose not to use the code, and not to use the license.
For the parent comment on discoverability, I honestly don't know. Some models list their data sources, others do not. But if it came down to a dispute it may be that a court order could result in a search of the actual training data and the system that generated it.
For the second case of derived work through context inclusion, it may end up in a similar situation with forensic analysis of the data that generated some output.
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 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.
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.
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.
Uncrossy creator here. Yes, I design each by hand using a highly custom editor that I built to help with many of the common challenges. People keep asking me if it's a job that AI could do, but I think it would be really hard to get right. There's a lot of craft in building the shape of the puzzle and picking words that allow as many spaces as possible to get filled in.
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.
https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st...
reply