HN user

samatman

18,377 karma

..arc.arc.arcitecture..

working to liberate literate programming for the median developer.

Posts9
Comments6,807
View on HN

COUNTEREXAMPLE TO EULER'S CONJECTURE ON SUMS OF LIKE POWERS

BY L. J. LANDER AND T. R. PARKIN

A direct search on the CDC 6600 yielded:

    27⁵ + 84⁵ + 110⁵ + 133⁵ = 144⁵
> as the smallest instance in which four fifth powers sum to a fifth power. This is a counterexample to a conjecture by Euler that at least n nth powers are required to sum to an nth power, n>2.

https://www.ams.org/journals/bull/1966-72-06/S0002-9904-1966...

It is a conjecture whether grinding it out on Lean is a difference in kind, rather than degree. I say degree. But it remains to be seen.

I am doing so such thing. You are ignorant and you are being rude, it's a bad combination.

The English Rule has several variations by jurisdiction, you'll find a handy map here: https://en.wikipedia.org/wiki/English_rule_(attorney's_fees)

In England (where pounds come from) costs are not always rewarded, but very frequently, they are: and it's actual costs, not some fixed fee. A litigant who spends more on solicitors indemnifies the loser accordingly.

https://en.wikipedia.org/wiki/Costs_in_English_law#What_can_...?

Perhaps you live somewhere where this is not the usual basis. Perhaps you just felt like being rude online. We'll never know.

It does, and it absolutely has a chilling effect in countries which don't do things this way.

Sue someone who can spend millions of pounds (for the sake of argument) on defence? Better be certain you can win... against someone who can spend millions of pounds, and probably went to the same public school as the judge.

In America, legal fees can be awarded as additional damages. We should do it more than we do. But given those two options? I'm on Team American Rule, 100%

Scenario A: A program has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

Scenario B: A program writes machine code in an executable region of memory, and the code has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

Scenario C: A program write machine code to disk, which is then read into memory and executed. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

This seems too strong to me. I agree with reliable as "repeatable", it's the determinism which seems excess to purpose.

If I have a great meal every time I go to a restaurant, that chef is reliably good. I do not require that the tomatoes on the salad be of identical number or placement, or cut along the precise same bias. Nor would I count the sesame seeds on the bun.

Are LLMs reliable by that standard? Sometimes yes, for some tasks. The envelope of tasks for which they're reliable is continuing to grow.

I love it. Easily one of my favorite things about the language.

Example: shifting more than the width of the shifted integer is illegal behavior in Zig: therefore, the, what, shiftand? let's go with that, the shiftand for a u64 must be a u6 or smaller.

Sounds annoying? No, it's great! Check this out:

    const CodeUnitKind = enum(u2) {
        low, 
        high,
        follow,
        lead,
    };

    const CodeUnit = packed struct(u8) {
        val: u6,
        kind: CodeUnitKind,
    };
It's really nice!

I understand the reaction, but I don't agree. I suggest reading the associated proposal[0] along with the devlog, and having a real think about what's going on here. I'm responding to you saying that you "don't understand" the approach: reasonable, and resembles my initial reaction.

I was inclined to agree with you, but what decided it for me is that Zig has another mechanism for "reinterpret bytes". It's exposed on the stdlib as std.mem.asBytes, but this is literally a wrapper for the following:

    @ptrCast(@alignCast(ptr));
So nothing is lost here: if you need, for whatever reason (and those do exist), to get a raw array of underlying bytes, you absolutely may. Std.mem also has bytesToValue(T, bytes) T, which makes a copy. All the ingredients are there, and this family of mem functions are thin wrappers over builtins, which boil down to pointer casting, dereferencing, and comptime magic.

Also worth noting: packed structs in Zig are already defined as logically little-endian: the first field is of low significance, the second is above that, and so on. So this makes `@bitCast` consistent with an existing convention of treating integers as logically little-ended, without regard to how they're actually arrayed in memory.

Plus it stands to make low-level bit-twiddling, using oddly-sized integers, optimize better. I like that, especially when what we trade for that is: nothing. Nothing at all, this is a pure win.

I'd even guess it's that rare language update which silently fixes buggy code, where someone figured "well, basically everything is little-endian already" (or just didn't think about it), and now that code works properly on big-endian machines.

[0] https://github.com/ziglang/zig/issues/19755

It's fascinating how intuitions differ. To me, it doesn't feel like theft at all. For one thing, theft is depriving another of something, and has therefore never been a good metaphor for infringement; hackers used to be the most insistent about this principle, and it's weird to see a doctrine which was cooked up in a literal AI lab get thrown out the window for literal AI.

But pretending you said "infringement", for me it comes all the way back to the Constitution: "To promote the Progress of Science and useful Arts". I cannot possibly twist the development of large language models into something which violates the spirit of that purpose. I don't see how anyone can.

Your point about the scale is valid, and the alienness of it, sure. But you haven't made the case that the vastness of the scale should affect the conclusion.

Something I left out in the first post is that copyright is meant to protect expression, and not ideas: this is the deciding factor in the 'nature of the copyrighted work' test for fair use. More expression, more protection: more ideas, less.

I think the visual arts have a strong case that image generators directly infringe expression: I'm not convinced that authors do, and I think software should never have been protected under copyright because the ideas-to-expression ratio is all wrong for the legal structure. There's clearly no scale case to be made for ideas: "but what if it's _all_ the ideas" fails, because the ideas are not protected at all. Nor should they be, that's what patents are for, and why patents are very different from copyright.

LLMs are remarkably good at 'the facts of the matter', hallucination not withstanding. They're very poor at authorial 'voice transfer', something image generators are far too good at. It's when I start asking myself "well what even _is_ this 'expression' thing anyway?" that I conclude that we're out over our skis on the LLMs-and-IP question: precedent can't tell us enough, and that leaves legislation.

As an experiment, I ran this by A Certain Chatbot, but asking: who should I read to get a good answer to this question?

If you prefix the name of OpenAI's commercial offering's website to this string: "share/6a0f2a87-dba4-8328-a704-89b94fd0c121", you'll find an answer.

I don't know who you had in mind, how did it do?

All the elision is because there are filters to prevent low-effort slop-poasting, and I'm trying to evade them, hopefully while staying within the spirit of the site.

It's more complicated than that. Quite a bit more.

Commercial use counts _against_ a fair use defense, but is not dispositive: it's not accurate at all to say it "generally does not cover" commercial use. This is the "purpose and character" test, one of four in contemporary (United States) fair use doctrine.

Purpose and character also includes the degree to which a use is _transformative_. It's clear that the degree to which a training run mulching texts "transforms" them is very high. This counts toward a fair use finding for purpose and character.

is dependent on the amount of the original content present in the derived work, which I would contend in this case is “all of it”

The "amount and substantiality" test. Your case for "all of it" can't possibly be sustained: the models aren't big enough. It's amount _and_ substantiality: this has come up in the publication of concordances, where a relatively large amount of a copyrighted work appears, but it's chopped up and ordered in a way which is no longer substantially the same. Courts have ruled that this kind of text is fair use, pretty consistently. It's not an LLM, of course, but those have yet to be ruled on.

Also worth knowing that courts have never accepted reading or studying a work as incorporation, and are unlikely to change course on the question. It's taken for granted that anyone is allowed to read a copyrighted work in as much detail as they wish, in the course of producing another one. Model training isn't reading either, but the question is to what degree it resembles study. I'd say, more than not.

Specifically:

it’s impossible to make a useful model without the whole book and all of the artistry that went into it

Courts have never once accepted "it would be impossible for defendant to write his biography without reading plaintiff's" as valid, and it's been tried. The standard for plagiarism is higher than that.

"Effect upon the work's value" is probably the most interesting one. For some things, extreme, for others, negligible. I suspect this is the one courts are going to spend the most time on as all of these questions are litigated.

Ultimately, model training is highly out-of-distribution for the common law questions involving fair use. It was not anticipated by statute, to put it mildly. The best solution to that kind of dilemma is more statute, and we'll probably see that, but, I don't think you'll be happy with the result, given what I'm replying to. Just a guess on my part.

It may interest you to know that this was a misremembered truth.

It is widely believed by their neighbors, that the _Druze_ wear baggy pants because they believe that the Mahdi will be born to a male, and the pants will catch the baby etc. I say "widely believed", the Druze are famously secretive and will not confirm or deny most things about their religion. The 'elect' Druze men do wear distinctive baggy trousers with the crotch down around the knees: no one else does.

The Druze are people in the Arabic world: moreover, they are Arabs. They began as an Isma'ili sect, but do not identify as Muslim: they call themselves al-Muwaḥḥidūn, meaning 'the monotheists', or 'unitarians'.

Much closer to correct than not!

Well yes, but the _effect_ is to unroll the loop for runtime, if the inline-for survives that long.

A for loop executed during comptime is just

    const stuff = comptime stuff: {
       for (0...8) |i| {
         // etc, build up some stuff
       }
       break :stuff some_stuff;
    };
The difference is that a comptime block won't leave behind runnable 'residue', only whatever data is constructed for later. An inline for might not leave behind an unrolled loop either, but it can.

Is it older than March 2025?

The first year was rough, from what I've read. Mine arrived March 2025, it has taken no work to print excellently, and at about 700 hours I have lubricated it every 200 hours, and I just tightened the belts about 50 hours ago. That's it. If it's less than $100 a roll I've probably printed it. I have no complaints.

Dusting off my HN credentials to plug Qidi.

If you can afford to pay more for less printer, get a Prusa Core One. I almost did, but at the time the cost would have included four months of waiting, and that was just too much.

But the Qidi Plus 4 has been just a beast for me. It had some growing pains, and the Internet is forever, so if you read up on it you'll see some scary-looking problems involving the heating element which have been completely fixed for more than a year. From everything I've been able to determine, the QC issues with the Plus 4 are over, and the newer printers like the Q2 and Max 4 have never had them.

I think the intersection of "reads HN" and "needs that tiny delta of convenience between Bambu and Qidi" is empty, basically. Qidi are good open source citizens, and you get a lot of bang for your buck, especially handling high-temp filaments. It's _possible_ to print nylon and ABS on Bambu hardware, but realistically you want something a little better.

Also they're cheaper than Bambu. Thought that was worth mentioning as well.

I'd seriously consider the Snapmaker U1 also, but not the K2 Plus. For one thing, Creality has had to be bullied several times to meet GPL obligations, and I don't like to reward that kind of behavior. For another, the Qidi Max4 is bigger, prints hotter, is more precise, and costs less. Pareto improvement on the K2 Plus.

I'm holding out on the Snapmaker because a) my Qidi Plus 4 is a great piece of hardware and at only 700 hours it's got a lot of life left in it, and b) The Prusa + Bondtech INDX is right around the corner. That's probably going to be my next printer. I find the waste and extreme slowness of AMS-style multimaterial too distasteful to invest in, and I think that entire paradigm will end up in the dustbin as tool-changing consumer FDM matures.

Is it? I'm with you on gobsmackingly ancient, but it's "doesn't support long options" which I haven't bumped into. I do replace some coreutils, but not all of them.

What's a good example of such a utility?

Ok, sure, we can reason about anything. We could reason about machine code, if we had the time and inclination.

I barely participate in Hacker News anymore because it seems to have collectively lost the ability to extract meaning from words, unless an exhausting and totally excessive amount of attention is put into satisfying a misplaced sense of precision. There's no intellectual charity left and it sucks.

The central claim is that Zig's use of comptime is similar enough to templates to conflate them. That's simply incorrect. There's no value in trying to extract information from something which makes such a basic mistake as that, it doesn't contribute to a discussion, it distracts that discussion down a blind alley.

This blog post is disqualified from any serious discussion, because it doesn't know the distinction between templates, which Zig's comptime constructs are not, and partial evaluation with reified types, which Zig's comptime constructs are.

It's not possible to make a positive contribution after a mistake that basic.

Here's an example of someone getting the design space correct, and therefore contributing to the discussion in a positive way. He doesn't end up liking Zig, for reasons I disagree with, but he does completely evade being not-even-wrong, which is table stakes.

https://hirrolot.github.io/posts/why-static-languages-suffer...

You can't reason about macros, that's not how they work.

You can read their definition, you can expand them, but there's no way to look at a macro call and reason about it, it can do anything at all. In C you don't even know what is and isn't a macro, so Rust has a modest edge in that respect.

Zig just doesn't have this problem to begin with.

My life would rapidly fall apart.

I use Siri for about three things: timers, reminders, and asking about the weather. But the reminders are mission critical. I use the watch, and any time my flighty brain hits on something, I set a reminder for it on the spot.

I literally couldn't get along without it. The only killer feature of Siri is accurate voice transcription, and that's all I need (and it could be more accurate, I just get used to comical translations when I use a rare word).

I guess I wouldn't mind if it were better, but I don't need it to be. Reminders are enough.

I've never heard from anyone who likes the Apple Mouse enough to use it, but doesn't like the charging from the bottom. It's frequently cited as a 'flaw' by those who don't use it, this has become a bit of conventional wisdom. In reality it's a non-issue.

I have heard from a whole lot of people who don't like the Apple Mouse. I don't like that mouse. But it isn't because of the charge port. It's an uncomfortable shape for my hand, and I prefer a trackball.

I think it's fine for Apple to have one peripheral which appeals to a minority taste. We're not short of mouse designs and they all work with the operating system. It's not even the main peripheral Apple sells for the purpose, that's the trackpad and everybody likes it. I still prefer a trackball, Tim Cook uses some kind of oddball vertical mouse with a bunch of buttons. It's a big design space.

If they wanted to please the maximum amount of people, they'd need to clone Microsoft's mouse, and that would be boring.