Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kardos
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
61.
▲
by
kardos
2y ago
BNPL is often free to the customer [1], to whom it amounts to a free loan. The merchant, however, is soaked for the interest/fees. So merchant prices will rise slightly, for everyone, to cover those costs..... much like credit cards do
62.
▲
by
kardos
2y ago
The challenge is to get the right answer. It's much less interesting if you relax the challenge to no longer require the right answer. Here's a really fast approximate answer: 50000000*(2^31-1)/2
63.
▲
by
kardos
2y ago
For 1, can you raise that to 28 with unsigned accumulators?
64.
▲
by
kardos
2y ago
The LLMs are basically useless for anything requiring reasoning or to help solve real problems, but the big use-case is that LLMs are competing with google search. Google search is so polluted with low quality ads-first SEO garbage that the
65.
▲
by
kardos
2y ago
Sounds like a mechanism to test for bad hardware (akin to memtest86) and find compiler bugs =)
66.
▲
by
kardos
2y ago
Forcing the ordering to be deterministic is a well-established part of the process https://reproducible-builds.org/docs/stable-inputs/ https://reproducible-builds.org/docs/stable-outputs/
67.
▲
by
kardos
2y ago
The reproducible builds effort means same input (code, libraries, compiler, flags, build-environment), should give the same output (build artifacts). I don't think RB is trying to get reproducible across platforms and across varying co
68.
▲
by
kardos
2y ago
> There just isn't a one-size-fit-all solution to be had here. But there is: https://news.ycombinator.com/item?id=40867842
69.
▲
by
kardos
2y ago
Yes this is exactly it. The gold standard is bit-4-bit matching when shifting code between systems. If you move your code to a new system and get different results --> is it due to different summing order, or something else wrong? By rul
70.
▲
by
kardos
2y ago
As far as I know, xsum [1] more or less solves the problem completely: order invariant and exact, at less than 2x the cost of the naive summation. Further speeding it up may be the only avenue left for improvement. [1] https://gi
71.
▲
by
kardos
2y ago
It may be true in some cases, but not in general. I think of it as an observation that for large swathes of code the branch is predictable. Eg, we usually don't go down the error checking codepath. Faced with flow control that depends
72.
▲
by
kardos
2y ago
Once the data is leaked it is leaked
73.
▲
by
kardos
2y ago
Agree if we need exact for any range of inputs. It should be possible to get by with fewer for real life problems, for ex, https://www.sciencedirect.com/science/article/abs/pii/S01678...
74.
▲
by
kardos
2y ago
Thanks! Yes this is exactly it. Interesting about the choice of 32 bits for carries. N=67 is pretty high. I suspect N could be tuned down significantly depending on the problem. Eg global sums in geophysics models -- the range of values b
75.
▲
by
kardos
2y ago
Aha. So it could be optimized into two tight loops. The linked wikipedia on pairwise says the numpy implementation is same speed as naive
76.
▲
by
kardos
2y ago
Why is pairwise summation 1/5th as fast as naive? I would expect these to be essentially the same speed, there is only one more addition and a logic operation which is surely negligible ..
77.
▲
by
kardos
2y ago
How does it compare to converting each number to a large fixed-point integer (implemented as N 64-bit integers), summing them with exact integer math (order-invariant), and converting back to floating point at the end? The sum part can be d
78.
▲
by
kardos
2y ago
https://news.ycombinator.com/item?id=40418312 Well that was quick We're going to need a ad-removal LLM frontend next
79.
▲
by
kardos
2y ago
It often replaces google search. Instead of sifting through heaps of SEO junk and accompanying trackers,ads,popups,widgets, etc and going through a search-term refinement cycle to eventually find something, the LLM immediately produces a cl
80.
▲
by
kardos
2y ago
So allow sshd to start in a failed mode and then restart it?
81.
▲
by
kardos
2y ago
I don't know. It's probably a problem of effort -- if you need a sink, do you buy a new one, or spend tons of time perusing various used-stuff markets looking for something suitable? There may be an opening there for technology to
82.
▲
by
kardos
2y ago
> the much greater weight increases fuel This may be technically correct, but is it significant? The difference in weight from glass bottles vs plastic bottles is surely nonzero but how does it compare to the weight of the truck moving i
83.
▲
by
kardos
2y ago
Indeed. That seems wrong unless the clients have explicitly agreed to let CF manage CAA records
84.
▲
by
kardos
2y ago
Would retro rental solve the scalper problem?
85.
▲
by
kardos
3y ago
Could the checks be binned into some categories or time strata, such that obsolete ones could be dropped. Eg, we could keep them all there under a --exhaustive flag for those 6 or 7 people who are really attached to their computer that they
86.
▲
by
kardos
3y ago
I wonder if one of these coding assistant things could be trained to port autotools to cmake [1]? That is, finally transition away from it.... autotools is cryptic and slow and this cacher is 20 years old and hasn't caught on. Or alte
87.
▲
by
kardos
3y ago
The commit timestamps are not a reliable indicator of this actor's work day. It's trivial to work on a different schedule than local 9-5, or simply falsify the time stamps [1]. [1] https://github.com/jbranchaud
88.
▲
by
kardos
3y ago
That amounts to changing it to a 33 bit time stamp
89.
▲
by
kardos
3y ago
Yes that is what I mean -- the commit in TFA is from the bad actor -- so the quoted comment is suspect..
90.
▲
by
kardos
3y ago
Well, do we know if that commented code you quoted is accurate?
More ›