MurphyA/hacker-news huggingface dataset:
by gus_massa | 2025-05-31 02:53:59+00:00
You can try to codify for example https://pixelogic.app/every-5x5-nonogram#10725003 as "11-31-1-12-0+11-3-1-11-11" (is there an standard in the community?) and add the 9 million "unsolvable" codified strings to a vector and sort the vector, and then look for not repeated consecutive. For example, your case "1-1-1-1-1+1-1-1-1-1" should appear exactly 120 consecutive times in the sorted 9 million vector. Is there one that is not repeated?

Feature request: It would be nice to have a jump to unsolved puzzle. In section 1 it's difficult to find an empty one. Also, there is something weird with scrolling.
by necessary | 2025-05-31 02:54:08+00:00
Thanks for posting these - these books look like exactly what I have been looking for recently! I'm someone who procrastinated and crammed my way through high school and undergrad level maths and then promptly forgot all of it once I finished schooling. I plan on working through them soon. Hopefully this isn't an annoying question, but do you still intend to publish a guide to statistics?
by VonTum | 2025-05-31 02:55:35+00:00
What a weird crabs-in-a-bucket argument against unions. "Don't empower yourself and the rest of your colleagues because they might get powerful enough to kick you out"?

The whole reason H1Bs were invented is to disempower the existing workforce. Not reaching for a (long overdue) tool of power for tech workers is playing right into their hand.
by npunt | 2025-05-31 02:56:32+00:00
At first glance its like Hollywood movies announcing they're the best selling of all time, ignoring inflation. In other words a ratchet just to get clicks.

However this is relevant because this is an investor report helping people forecast, and this stat helps calibrate readers expectations of just how fast a product can scale in this day & age, using a relevant comparison of products in the same category that when launched offered the same step change in value.

Also, quantity has a quality of its own.
by barchar | 2025-05-31 02:57:44+00:00
It's not really enough to predict the outcome, you need something concrete to actually bet on, and you need to time things right (particularly for the pessimistic bet).

For any bet that involves purchasing bits of profits you you could be right and lose money because because the government generally won't allow the entire economy to implode.

By the time a bubble pops literally everyone knows they're in a bubble, knowing something is a bubble doesn't make it irrational to jump on the bandwagon.
by toomuchtodo | 2025-05-31 02:58:24+00:00
$80 (£52.40) per metric ton is still substantially below true costs by orders of magnitude.

Comprehensive evidence implies a higher social cost of CO2 - https://www.nature.com/articles/s41586-022-05224-9 | https://doi.org/10.1038/s41586-022-05224-9

The social cost of carbon dioxide under climate-economy feedbacks and temperature variability - https://iopscience.iop.org/article/10.1088/1748-9326/ac1d0b | https://doi.org/10.1088/1748-9326/ac1d0b
by natmaka | 2025-05-31 02:59:09+00:00
> "pacify" a place and to take control of it has little to do with a full annexation

Indeed. No objective is intangible. Actions taken to reduce an aggressive enemy to inaction can lead to a promising discovery (in this case, that of what would become Algeria, which was then a rich agricultural and pleasant territory occupied by non-unified tribes) leading to a desire to seize it.
Show HN: Open-Source LLM-Powered Invoice and Receipt Extractor
by maxime_wellapp | 2025-05-31 02:59:16+00:00
Hey HN,

I recently open-sourced a tool to extract structured data (like total, date, vendor) from invoices and receipts using LLMs.

Works out of the box with OpenAI & Mistral Bring your own model if you want MIT-licensed, ready to hack

Perfect for devs building finance, accounting, or automation tools.

→ https://github.com/WellApp-ai/Well/tree/main/ai-invoice-extr...

Curious to hear thoughts or feedback — especially from folks working on document parsing, LLM orchestration, or AI agents.
by nopinsight | 2025-05-31 03:00:31+00:00
My thesis is that this could lead to a booming market for “pink-collar” service jobs. A significant latent demand exists for more and better services in developed countries.

For instance, upper-middle-class and middle-class individuals in countries like India and Thailand often have access to better services in restaurants, hotels, and households compared to their counterparts in rich nations.

Elderly care and health services are two particularly important sectors where society could benefit from allocating a larger workforce.

Many others will have roles to play building, maintaining, and supervising robots. Despite rapid advances, they will not be as dexterous, reliable, and generally capable as adult humans for many years to come. (See: Moravec's paradox).
by digdugdirk | 2025-05-31 03:00:43+00:00
More people need to understand the actual history of the luddites. The real issue was the usage of mechanized equipment to overwhelm an entire sector of the economy of the day - destroying the labor value of a vast swath of craftspeople and knocking them down a peg on the social ladder.

Those people who were able to get work were now subject to a much more dangerous workplace and forced into a more rigid legalized employer/employee structure, which was a relatively new "corporate innovation" in the grand scheme of things. This, of course, allowed/required the state to be on the hook for enforcement of the workplace contract, and you can bet that both public and private police forces were used to enforce that contract with violence.

Certainly something to think about for all the users on this message board who are undoubtedly more highly skilled craftspeople than most, and would never be caught up in a mass economic displacement driven by the introduction of a new technological innovation.

At the very least, it's worth a skim through the Wikipedia article: https://en.wikipedia.org/wiki/Luddite
by mullingitover | 2025-05-31 03:01:39+00:00
I went from a 2.0 GPA in high school to a 4.0 in college, and I credit a large part of that to a few habits I developed:

- Show up to each and every class, sit in the front row (they don't charge extra for these prime seats!) and write down everything that goes on the board. Ask good questions when you have the opportunity.

- Take advantage of office hours (another perk that doesn't cost extra)

- Do every scrap of extra credit that's offered

The last two items help, partly because there's a lot of subjectiveness in grading so impressions matter, but I think the biggest thing was the writing. I would fill a D-ring binder with a couple hundred pages each semester, and a lot of it stuck with me.
by ocdtrekkie | 2025-05-31 03:03:22+00:00
The "replaceable compute card" design has been done dozens of times, unfortunately often before even a second generation of compute modules or enclosing form factors happens. I do still like the idea.

I've long thought the idea of bringing my personal phone with all my settings and data should let me dock into more powerful hardware without leaving data behind when I disconnect... lapdocks and such similarly having been done a bunch of times but rarely surviving a hardware generation.
by magicalhippo | 2025-05-31 03:04:01+00:00
Another is lower road tolls. Used to be exempt, but it's been bumped a lot recently. Still much cheaper than dinosaur fueled cars though.

A third point is that quite a lot will have the option to charge at home. If you charge at night, prices can be dramatically lower than gas.

Assuming an consumption for a typical EV of 16 kWh / 100 km and an typical price of 1 NOK / kWh, that's 16 NOK per 100 km (or about $1.6).

If you take an typical ICE consumption of 5 liters / 100 km, and a typical pump price of 20 NOK / liter, that's 100 NOK per 100 km for the ICE (or about $10).

Of course during winter, electricity can be much more expensive than during summer, up to 4-5 NOK / kWh. But even at 5 NOK / kWh, it's still cheaper than gas.
by Maxatar | 2025-05-31 03:05:26+00:00
The Java specification which can be found here [1] makes clear that with respect to its memory model the following is true:

1. Per 17.4.5 your example can lead to a data race. "When a program contains two conflicting accesses (§17.4.1) that are not ordered by a happens-before relationship, it is said to contain a data race." 2. Per 17.7 the variable s is accessed atomically. "Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values."

However, atomic reads and writes are not sufficient to protect against data races. What atomic reads and writes will protect against is word tearing (outlined in 17.6 where two threads simultaneously write to overlapping parts of the same object with the result being bits from both writes mixed together in memory). However, a data race involving atomic objects can still result in future reads from that object to result in inconsistent values, and this can last indefinitely into the future. This does not mean that reading from a reference will produce a garbage value, but it does mean that two different threads reading from the same reference may end up reading two entirely different objects. So, you can have thread A in an infinite loop repeatedly reading the value "uninitialized" and thread B in another infinite loop repeatedly reading the value args[0]. This can happen because both threads have their own local copy of the reference which will never be updated to reflect a consistent shared state.

As per 17.4.3, a data-race free program will not have this kind of behavior where two threads are in a perpetually inconsistent state, as the spec says "If a program has no data races, then all executions of the program will appear to be sequentially consistent."

So while atomicity protects against certain types of data corruption, it does not protect against data races.

[1] https://docs.oracle.com/javase/specs/jls/se24/html/jls-17.ht...
by purpleidea | 2025-05-31 03:05:56+00:00
It's very interesting (I applaud this) that one of the main goals seems to be to make it more approachable as compared to TLA+, but then they go in write it in C# which I consider to be an incredibly unapproachable community and language.

I'm not trying to draw the ire of the Microsoft fan boys, and there are certainly smart people working on that, but it's just not going to happen for most people.

Had this been in golang, or maybe java, I'm sure many more hands would be digging in! Having said that, I hope this helps bring correctness and validation more into the mainstream. I've been casually following the project for a while now.

My long-term goal is to integrate model validation into https://github.com/purpleidea/mgmt/ so if this is an area of interest to you, please let me know!
by ccorcos | 2025-05-31 03:06:53+00:00
What makes you so concerned about rapid onset of we haven’t seen any significant change in the (USA) unemployment rate?

And there are some laws of nature that are relevant such as supply-demand economics. Technology often makes things cheaper which unlocks more demand. For example, I’m sure many small businesses would love to build custom software to help them operate but it’s too expensive.
by sarchertech | 2025-05-31 03:08:14+00:00
> by the late 2010s it was getting hard to find new grads who actually understood systems internals and OS/architecture concepts, so a lot of jobs adjacent to those ended up moving abroad to Israel, India, and Eastern Europe where universities still treat CS as engineering instead of an applied math disciple

That doesn’t fit my experience at all. The applied math vs engineering continuum is mostly dependent on whether a CS program at a given school came out of the engineering department or the math apartment. I haven’t noticed any shift on that spectrum coming from CS departments except that people are more likely to start out programming in higher level languages where they are more insulated from the hardware.

That’s the same across countries though. I certainly haven’t noticed that Indian or Eastern European CS grads have a better understanding of the OS or the underlying hardware.
by JoshTriplett | 2025-05-31 03:09:50+00:00
Every argument I made in this thread was about private companies, who have every incentive to only take customers who make them money; that's especially true if they're spending marketing money attempting to pursue such customers. I am making no claim or argument about government spending, which has fundamentally different strategies and goals.

> Is this just word lawyering over what "subsidize" means?

Insofar as words have meaning, possibly. Before arguing that one group is subsidizing another, you'd first have to argue that one group is being subsidized. Leaving aside the original meanings (which only describe public funds in the first place, which this isn't), and interpreting the apparent meaning, the claim is apparently that credit cards lose money on rewards programs for rich customers, and those programs are thus subsidized, and specifically that they're subsidized by poor customers. If that were the case, they wouldn't have those rewards programs. (I'm not claiming that no company in the world has ever spent marketing money they didn't have to or spent it unwisely; I am claiming that an absurd amount of analysis has gone into the finances of rewards programs, in particular, and it is extremely unlikely that card companies are spending more to acquire a class of customers than the revenue they get from that class of customers.)

Now, more broadly, if you want to claim that credit card companies make more money from poor customers than rich customers, that would not be too surprising of a claim. (It's not obvious if the evidence supports that, and it seems like it may not be the case, but let's set that aside for a moment.) That's not a subsidy, and I wouldn't even call it "regressive", any more than I'd call a company that makes more money from rich people than poor people "progressive".

If you want to say that, in general, the practices of credit card companies and the financial industry are not fair to lower-income people, I would agree with you there. I don't think any subsidizing is going on, and I don't think rewards programs are a redistribution program; any such claim would imply taking a loss on a class of customers but keeping those customers anyway. But I absolutely would support a claim that (for instance) credit cards are predatory. Or, for instance, that airline miles programs are deliberately confusing and misleading and to a first approximation no customer "makes money" on those either.
by jaaamesey | 2025-05-31 03:10:05+00:00
I'd agree that generally, using `key` to reset state at the component tree level is fine, and that good component structure or persisting state through other means makes it a lot harder for this issue to come up.

> my mental model is that each item in the list has it's own form, rather than sharing one

100% - it makes things a lot easier to reason about if you're guaranteed to have a fresh instance of a component for each item being switched to. In fact, if I saw that stale state issue come up again in production, and it wasn't the kind of thing avoiding state entirely could fix, my suggestion would just be `key` instead of reaching for a third party hook.

I wouldn't be suggesting a change to React itself if that change also didn't enforce that way of thinking, albeit at the hook level instead of component tree level. `key` always felt like a weird escape hatch to me in that:

- it's not a solution lint rules would nudge someone towards

- `key` needs to be applied by the consumer of the component, not the component itself

- we lose all state in the tree and re-create all DOM nodes

I'll admit that it's hard finding good examples of where that last thing is an issue. The only other one off the top of my head might be preserving component/DOM state between route changes, e.g. keeping the same scroll position in a list of filters between similar screens for searching products. These issues only really come up when you have a deep component tree and lifting components up gets much trickier than having state reset naturally and atomically.
by magicalhippo | 2025-05-31 03:10:28+00:00
Our Renault Megane e-Tech, starting from 80% battery, does about ~350 km during summer, and ~200-250 km during the cold of winter depending on outside temperature and who's in the car. It is quite noticeable, no doubt.

But it's been perfectly sufficient for us. We seldom travel that long during winter, and there's plenty of fast chargers around if we do. Typically one or two charging stops is all we need, and we'd have one stop for restrooms and drinks/snacks regardless.

When it's not biting cold, it's not something we think about. And our Renault is certainly not the best in the battery department.
by ivape | 2025-05-31 03:10:35+00:00
Companies are not accepting that their entire business will mostly go away. They are mostly frogs boiling in water, that's why they are kinda just incorporating these little chat bots and LLMs into their business, but the truth of the matter is it's all going away and it's impossible to believe. Take something like JIRA, it's entirely laughable because a simple LLM can handle entire project management with freaking voice with zero programming. They just don't believe that's the reality, we're talking about Kodak moment.

Worker productivity is secondary to business destruction, which is the primary event we're really waiting for.
by dataflow | 2025-05-31 03:12:58+00:00
> But, unlike C++ loss of Sequential Consistency isn't fatal in Java

I have no idea what you mean here. Loss of sequential consistency is in no way fatal in C++. There are several access modes that are specifically designed to avoid sequential consistency.

Regarding the rest of your comment:

You're making exactly my point though. These are guaranteed atomic accesses -- and like you said, we are guaranteed to see either the old or new value, and nothing else -- and yet they are still data races. Anyone who agrees this is a data race despite the atomicity must necessarily understand that atomics don't imply lack of data races -- not in general CS terminology.

The only way it's correct to say they are mutually exclusive is when you define "data race" as they did in the C++ standard, to imply a non-atomic access. Which you're welcome to do, but it's an incredibly pedantic thing to do because, for probably >95% of the users of C++ (and probably even of TSAN itself), when they read "data race", they assume it to mean the concept they understand from CS. They don't know that the ISO standard defines it in its own peculiar way. My point here was to convey something to normal people rather than C++ committee language lawyers, hence the use of the general term.
by simonsarris | 2025-05-31 03:16:15+00:00
> And you DO see companies laying off people in large numbers fairly regularly.

Sure but, so far, too regularly to be AI-gains-driven (at least in software). We have some data on software job postings and the job apocalypse, and corresponding layoffs, coincided with the end of ultra-low interest rates. If AI had a recent effect this year or last, its quite tiny in comparison.

https://fred.stlouisfed.org/graph/?g=1JmOr

so one can argue more is to come, but its hard to see how its had a real effect on jobs/layoffs thus far.
by Dylan16807 | 2025-05-31 03:19:23+00:00
The examples matter for the correctness.

This example is a little flawed, but go with me. Imagine someone was making an argument that an algorithm is too powerful because it can solve really hard problems, then list a bunch of problems that need ridiculous amounts of compute time to solve, but half their examples are NP-hard and half their examples are P.

The intuition that says "wow, that problem is very difficult to solve, so I'm very skeptical of a solution" is wrong. Because that intuition applies to both the NP examples and the P examples. That intuition is too simplistic and overgeneral.

You need an intuition that is right with both classes of problem. It has to say "no" to one class and "yes" to another. Ignoring the wrong examples is not how you evaluate an intuition.
by simonsarris | 2025-05-31 03:20:03+00:00
I think the real white collar bloodbath is that the end of ZIRP was the end of infinite software job postings, and the start of layoffs. I think its easy to now point to AI, but it seems like a canard for the huge thing that already happened.

just look at this:

https://fred.stlouisfed.org/graph/?g=1JmOr

In terms of magnitude the effect of this is just enormous and still being felt, and never recovered to pre-2020 levels. It may never. (Pre-pandemic job postings indexed to 100, its at 61 for software)

Maybe AI is having an effect on IT jobs though, look at the unique inflection near the start of 2025: https://fred.stlouisfed.org/graph/?g=1JmOv

For another point of comparison, construction and nursing job postings are higher than they were pre-pandemic (about 120 and 116 respectively, where pre-pandemic was indexed to 100. Banking jobs still hover around 100.)

I feel like this is almost going to become lost history because the AI hype is so self-insistent. People a decade from now will think Elon slashed Twitter's employee count by 90% because of some AI initiative, and not because he simply thought he could run a lot leaner. We're on year 3-4 of a lot of other companies wondering the same thing. Maybe AI will play into that eventually. But so far companies have needed no such crutch for reducing headcount.
by theamk | 2025-05-31 03:20:27+00:00
"Seems those scissors could be a knife instead? And anyway, cutting paper is only part of the problem, sometimes I want to cut steak as well. Or sometimes I want to carve something from wooden blank"

No, this could not be done as a phone app. This is a narrow-scope product with specific goal: let someone know when to depart without having to stare at the phone continuously.
by wahern | 2025-05-31 03:20:50+00:00
The OOM error is the back pressure. This is why some engineers working on highly concurrent frameworks insist on pervasive OOM recovery.

I haven't done any Java in years, but I always thought OOM errors were recoverable in the JVM. Or is this just a case where the author never thought to catch OOM exceptions? My instinct would be to catch OOM early (i.e. in entry function) in a virtual thread and re-queue the task. In theory re-queueing might fail, too, I guess, but in practice probably not.

This is why I like to code in C (and Lua) for this kind of thing, as in C my core data structures like lists and trees don't require additional allocations for insert. My normal pattern here would be to have, say, three job lists--todo, pending, complete; a job would always exist in one of those lists (presuming it could be allocated and initialized, of course), and no allocations would be required to move a job back from pending to todo on an OOM error during processing.
by simonw | 2025-05-31 03:20:54+00:00
From that article:

> According to the report, Anthropic was holding talks with Amazon, the company’s major investor and partner, and voice-focused AI startup ElevenLabs, to possibly drive future voice features for Claude.

> It’s unclear which of those partnerships, if any, came to fruition.

Here's an easy way to confirm that: check Anthropic's "Trust Center" and review any recent updates. https://trust.anthropic.com/updates

Sure enough, on May 29th they have a subprocessor change:

> As of May 29th, 2025, we have added ElevenLabs, which supports text to speech functionality in Claude for Work mobile apps.

I wonder what they're using for speech-to-text?