9,664 karma · joined June 14, 2010
I'm not sure where you're getting these numbers from, but German has around 45 phonemes according to all sources I could find, depending on how you count: 17 vowels (including two different schwa sounds), 3 diphthongs, 25 consonants.
People have also been reporting that ChatGPT's new "memory" feature is poisoning their context. But context is also useful. I think AI companies will have to put a lot of engineering effort into keeping those LLMs on the happy path even with larger and larger contexts.
> I think just PA+"PA is consistent" is enough?
It's not clear to me how. I believe PA+"PA is consistent" would allow a model where Goodstein's theorem is true for the standard natural numbers, but that also contains some nonstandard integer N for which Goodstein's theorem is false. I think that's exactly the case that's ruled out by the stronger statement of ω-consistency.
Here's a quote from the article:
> How many humans can sit down and correctly work out a thousand Tower of Hanoi steps? There are definitely many humans who could do this. But there are also many humans who can’t. Do those humans not have the ability to reason? Of course they do! They just don’t have the conscientiousness and patience required to correctly go through a thousand iterations of the algorithm by hand. (Footnote: I would like to sit down all the people who are smugly tweeting about this with a pen and paper and get them to produce every solution step for ten-disk Tower of Hanoi.)
In case someone imagines that fancy recursive reasoning is necessary to solve the Towers of Hanoi, here's the algorithm to move 10 (or any even number of) disks from peg A to peg C:
1. Move one disk from peg A to peg B or vice versa, whichever move is legal.
2. Move one disk from peg A to peg C or vice versa, whichever move is legal.
3. Move one disk from peg B to peg C or vice versa, whichever move is legal.
4. Goto 1.
Second-graders can follow that, if motivated enough.
There's now constant, nonstop, obnoxious shouting on every channel about how these AI models have solved the Turing test (one wonders just how stupid these "evaluators" were), are at the level of junior devs (LOL), and actually already have "PhD level" reasoning capabilities.
I don't know who is supposed to be fooled -- we have access to these things, we can try them. One can easily knock out any latest version of GPT-PhD-level-model-of-the-week with a trivial question. Nothing fundamentally changed about that since GPT-2.
The hype and the observable reality are now so far apart that one really has to wonder: Are people this easily gullible? Or do so many people in tech benefit from the hype train that they don't want to rain on the parade?
The article is full of "community" this and "local people" that, and very low on details. The little that is there raises red flags. For example: The fact that their rented machine shop had to close down is given as an explanation for them having to sell all their machines below cost and then not having the money to buy the machines back when they found a new place. That doesn't add up: temporary storage spaces exist and aren't even expensive, given that you can choose a remote location. It seems like a crucial detail was left out, maybe one that would paint them in a bad light.
I gather that they sell (apparently unsafe?) wood chippers, presses and some injection moulds, probably at cost. I don't understand what else is there. The "version 4" release thing mentioned in the article might be their open-source "academy" [1, 2] that's supposed to teach you how to start your local recycling shop. It includes valuable tips like "add all your expenses" and "don't forget to include taxes" and comes complete with an empty Excel sheet -- I'm sorry, a "Business Calculator". No commits since 2020, so the "version 5" of this guide that they claim to have been working on for five years must be hosted somewhere on a private GitHub fork instead. I'm sure it's awesome. Best of luck.
[1] https://community.preciousplastic.com/academy/business/works...
No, please, no.
(Edit: As this seems to trigger some people: I code in Rust. I’m just stating the facts.)
There are two actual differences in this regard: C pointers are more ergonomic than Rust pointers. And Rust has an additional feature called references, which enable a lot more aggressive compiler optimizations, but which have the restriction that you can’t have a reference to uninitialized memory.
>> It was home consoles on televisions where people get the idea from that all CRTs were blurry.
The video you linked shows a PS1 game, which proves my point. It's possible you're too young to remember the big difference between a CRT TV and a CRT monitor. Monitors really did show discrete pixels (which was important for tiny text in applications to be readable), while TVs were blurry messes.
> a bad approximation that can only result in unnecessarily blurry images
I think your two examples nicely illustrate that it's all about the display technology.
> The computer is running a service that is resizing images from 100x100 pixels to 200x200 pixels. Would the programmer of this server be better off thinking in terms of samples or rectangular subdivisions of a display?
That entirely depends on how the resizing is done. Usually people choose nearest neighbor in scenarios like that to be faithful to the original 100x100 display, and to keep the images sharp. This treats the pixels as squares, which means the programmer should do so as well.
> Alvy Ray Smith, the author of this paper, was coming from the background of developing Renderman for Pixar.
That's meaningful context. I'm sure that in 1995, Pixar movies were exposed onto analog film before being shown in theatres. I'm almost certain this process didn't preserve sharp pixels, so "pixels aren't squares" was perhaps literally true for this technology.
Audio samples are point samples (usually). This is nice, because there's a whole theory on how to upsample point samples without loss of information. But more importantly, this theory works because it matches how your playback hardware functions (for both analog and digital reasons that I won't go into).
Pixels, however, are actually displayed by the hardware as little physical rectangles. Take a magnifying glass and check. Treating them as points is a bad approximation that can only result in unnecessarily blurry images.
I have no idea why this article is quoted so often. Maybe "everybody is doing it wrong" is just a popular article genre. Maybe not everyone is familiar enough with sampling theory to know exactly why it works in audio (to see why those reasons don't apply to graphics).
Nothing about this question feels natural. I've noticed that random facts often don't have simple proofs.
> Bailey: "one is free to trust their "verbal agreement" that they did not train their models on that, but access they did have."
1. You’re confusing motte and bailey.
2. Those statements are logically identical.
> Add the tag and the exact string you signed to the object, validate the signature and then validate that the JSON object is the same as the one you got.
In cryptographic practice, redundant information usually spells disaster, because inevitably, someone will use the copy that wasn't verified.
But let's dig into it. If I understand this correctly, the suggestion is to have something like this:
{
"object": "with",
"some": "properties",
"signatureInfo": {
"signedString": "{\"object\":\"with\",\"some\":\"properties\"}",
"signature": "... base64-encoded-signature ..."
}
}
1. Parse the outer object as JSON, extract and remove signatureInfo.
2. Verify the signature.
3. Parse the signedString as JSON.
4. Verify that the object you got in step 1 equal to object you got in step 3 using a some kind of deep equality.
First of all, this is error prone, and as underspecified as JSON is, there are potential exploits if the comparison isn't done carefully. But even worse, if you think about it, the outer JSON is entirely useless, since you need to parse the inner JSON anyway -- so why not just use it directly?
It seems to me that this suggestion is strictly worse than just sending the inner part:
{
"signedString": "{\"object\":\"with\",\"some\":\"properties\"}",
"signature": "... base64-encoded-signature ..."
}
I personally like that approach, but I'm not sure how much sense that makes without static typing. (Maybe TypeScript is established enough that JavaScript APIs are now designed with TypeScript in mind?)
From experience with js-joda, there's a definitely learning curve compared to moment's "one size fits all" type for all things date related. But I found that a lot of stupid mistakes of the kind "a person's age is wrong for an hour after midnight during daylight savings time" are prevented by default.