One aspect neither of you have explicitly addressed is the speaking of numbers; speaking, after all, predates writing. We say "one billion, four hundred twenty-eight million, [...]".
Given that that's what we say, the first two pieces of information we need are "one" and "billion". More generally, we need to get the first 1-3 digits (the leftmost comma-separated group), then we need the magnitude, then we can proceed reading off all remaining digits.
Given that the magnitude is not explicitly written down, we get it by counting the digits. If the digits are comma-separated into groups of 3 (and "right-justified", so that if there are 3n+1 or 3n+2 digits, then the extra 1-2 are the leftmost group), then it's generally possible to get the magnitude from your "peripheral vision" (as opposed to counting them one by one) for numbers less than, say, 1 billion, which are what you'd most often encounter; like, "52" vs "52,193" vs "52,193,034", you don't need to count carefully to distinguish those. (It gets harder around 52,193,034,892 vs 52,193,034,892,110, but manually handling those numbers is rare.) So if getting the magnitude is a mostly free operation, then you might as well just present the digits left-to-right for people who read left-to-right.
Now, is it sensible that we speak "one billion, four hundred twenty-eight million, [...]"? Seems fine to me. It presents the magnitude and the most significant digits first (and essentially reminds you of the magnitude every 3 digits), and either the speaker or the listener can cut it off at any point and have an estimate accurate to as many digits as they care for. (That is essentially the use case of "partially running the algorithm" you describe.) I think I'd hate listening to "six hundred sixty three, six hundred twenty-seven thousand, four hundred twenty-eight million, and one billion", or even suffixes of it like "four hundred twenty eight million and one billion". Tell me the important part first!
The other big-endian algorithm is the one I observe myself as usually using. For "321", it is:
- Count the digits (three), and convert that into an order of magnitude (one hundred). (Running total: ??? hundred ???.)
- Read the first digit, multiply it by its order of magnitude (one hundred), and add it to the total. (Running total: three hundred ???.)
- Read the second digit, multiply it by its order of magnitude (ten), and add it to the total. (Running total: three hundred and twenty ???.
- Read the third digit, multiply it by its order of magnitude (one), and add it to the total. (Arriving at three hundred and twenty one.)
I generally agree, except I find words like "multiply" and "add" a bit misleading to use in this context. If I read a number like 3,749,328, then it's not like I take 3 million, and then take 7, multiply by 100,000, and get 700,000, and then perform a general-purpose addition operation and compute the subtotal of 3,700,000. First of all, "multiply by 100,000" is generally more like "Shift left by 5 (in our base-10 representation)"; but moreover, the whole operation is more like a "Set the nth digit of the number to be this". If this were a computer working in base 2, "set nth digit" would be implemented as "mask out the nth bit of the current number [though in this case we know it's already 0 and can skip this step], then take the input bit, shift left by n, and OR it with the current number".
(In this context I find it a bit misleading to say that "One hundred plus twenty yields one hundred and twenty" is performing an addition operation, any more than "x plus y yields x+y" counts as performing addition. Because 100, by place-value notation, means 1 * 100, and 20 means 2 * 10, and 120 means 1 * 100 + 2 * 10, so you really are just restating the input.)
Also, I might switch the order of the first two steps in practice. "Three ... [pauses to count digits] million, seven hundred forty-nine thousand, ...".
Take note of the Underhanded C Contest for inspiration on the problem of auditing code written by an intelligent, untrusted source. I think one takeaway is that, with some ingenuity, one can often put malicious behavior into ok-looking code that maybe contains some innocent mistakes. It seems, then, that fully guarding against malicious code implies fully guarding against all bugs.
Which might be achievable if your style guides put heavy limitations on what kind of code can be written. (The halting problem makes it impossible for a deterministic program to always detect all bugs.) Something perhaps like the JPL C standards:
- Predictable Execution
- Use verifiable loop bounds for all loops meant to be terminating.
- Do not use direct or indirect recursion.
- Do not use dynamic memory allocation after task initialization.
...
Rule 3 (loop bounds)
All loops shall have a statically determinable upper-bound on the maximum number of loop iterations. It shall be possible for a static compliance checking tool to affirm the existence of the bound. An exception is allowed for the use of a single non-terminating loop per task or thread where requests are received and processed. Such a server loop shall be annotated with the C comment: /* @non-terminating@ */
Agreed on most of the above, but on this particular point:
This is pretty much parallel to a common argument for laws against euthanasia, assisted suicide, etc.: the easier it is for someone with terrible medical conditions to arrange to die, [...], or (this isn't quite parallel, but it seems clearly related) to make it appear that they've done so when actually they were just murdered.
I would expect the opposite there. If assisted suicide and stuff is legalized, I expect that to come with high standards of "There should be a notarized signature, multiple witnesses, a video from the person in question stating their intentions, and they walk into a building where some official people first take the person into another room and say 'Are these men coercing you? We can have our security staff subdue them and bring in the police'", etc., designed specifically to make it hard to cover up a murder like that. And the existence of that option should push a chunk of regular suicides in that direction, making it less plausible that someone would commit suicide in the "traditional" way where they give no one any warning, may or may not leave a note, etc.
Yup. Many programmer applicants famously couldn't solve FizzBuzz. Which is probably because:
[skipping several caveats and simplifying assumptions]
Now, when you get those 200 resumes, and hire the best person from the top 200, does that mean you’re hiring the top 0.5%?
“Maybe.”
No. You’re not. Think about what happens to the other 199 that you didn’t hire.
They go look for another job.
That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he’s the best, and now, in this contrived example, every employer thinks they’re getting the top 0.5% when they’re actually getting the top 99.9801%.
Without regard to anything specific to LLMs... Math works the same for all conceivable beings. Beings that live in our universe, of sufficient advancedness, will almost certainly know about hydrogen and other elements, and fundamental constants like Planck lengths. So there will exist commonalities. And then you can build everything else on top of those. If need be, you could describe the way things looked by giving 2D pixel-grid pictures, or describe an apple by starting with elements, molecules, DNA, and so on. (See Contact and That Alien Message for explorations of this type of problem.)
It's unlikely that any LLM resembling those of today would translate the word for an alien fruit into a description of their own DNA-equivalent and their entire biosphere... But maybe a sufficiently good LLM would have that knowledge inside it, and repeatedly querying it could draw that out.
The Wikipedia link for claddagh rings goes to the Project Semicolon page.
The true thing that Sagan's line might be interpreted to mean is "A claim which is very unlikely on priors needs very strong evidence to end up with a posterior probability close to 1." "Extraordinary evidence" would ideally have been stated as "extraordinarily strong evidence", but that makes the line a bit clunkier. Unfortunately, there is often a tradeoff between accuracy and pithiness. Many pithy sayings require a bit of interpretation/reconstruction to get the correct underlying idea. I think anyone who invokes a catchphrase should be aware of this, though I don't know how many people share this perspective.
Are there in fact a significant number of people who take it at the face value of "extraordinary evidence" and think it must mean it was obtained via super-advanced technology or something?
I think either I don't know exactly what defines a "subculture", or there needs to be a qualifier before "subculture". Might "people who are enthusiastic about X sport / hobby / profession" be a subculture? Because I think lots of those can be highly successful while remaining what they are. (Perhaps you'd say that hobbies that succeed get eaten in the Geeks/MOPs/Sociopaths way, but that's less so for professions.)
A "subculture of those dealing with X problem" sounds much more likely to fit what you describe, but that may not be your intent.
Pithy sayings are lossily compressed.