SkiFire13

> One of the basic ideas behind Rust's memory safety story is that eliminating race conditions

Rust does not prevent race conditions. You're getting confused with data races.

However GC's solution to data races (make every load/store act as very relaxed atomic instructions) makes race conditions much easier to write.

> Strictly speaking, there's an owning_ref crate

owning_ref is unsound and shouldn't be used. self_cell/yoke/ouroboros are much better alternatives, ableit more complex

> You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe.

Isn't this what MIRI already does?

Happy to see it's finally getting union types in 2026

But that's also arguably pretty boring because it's very easy to dynamically check and the cost for doing so is relatively small compared to what needs to be done for other properties.

On the other hand statically checking bounds for (dynamic and non) arrays is very very hard in the general case.

> This means that these frontier labs are truly susceptible to "predatory pricing" (economic term for a competitor selling at a loss to eliminate you)

OpenAI and Anthropic were losing money too until recently, when they started focusing more on increasing revenue (which is also part of why companies are now looking more at Chinese models to reduce costs).

What you're describing is akin to a basic pull-based incremental engine, akin to salsa. The base design is straightforward, but you need some additional logic to avoid following the whole execution tree when hashing. Their downsides is that sometimes you do have to follow the whole execution tree, even if nothing changed.

Push-based designs instead "push" changes to their dependants, which can be quite efficient especially in the case where the update doesn't propagate much. However it has the downside of potentially requiring to update nodes that are no longer used, or updating nodes multiple times.

> You can claim that it is obvious, and trivial, and uninteresting, but that doesn't invalidate it. Sometimes thinking outside of the box is required and such strict adherence to what has come before can cloud your view of an "obvious" solution that was there the whole time.

Then sure, go ahead. Define your own model of computation, one not based on turing machines and which somehow allows for infinitely big lookup tables, and then see what great insight it provides you.

I wonder discoveries you will be able to make in a system where you can say that the solution of a problem is just its solution.

Yup, and everyone measures it to be part of the algorithm, otherwise you start getting nonsensical results.

What you are stating is simply that any algorithm whose inputs are bounded can be solved in O(1) time with a lookup table. That's known and obvious, which makes it not interesting.

Moreover it only works with bounded inputs. If your input is unbounded (as is this case with multiplication over arbitrarily large numbers) then an infinitely big lookup table is just not possible because it's part of the algorithm and hence needs to be finite.

If infinitely-big lookup tables were allowed you could for example write an algorithm that solves the halting problem, just index into the lookup table for its solution. And actually you could do this for any problem! So any problem, even so called "non computable" ones, admit a solution that runs in time linear to their input. I hope you see that this is nonsensical and it's why lookup tables are considered part of the algorithm and hence need to be finite.

> You might not "want" something in a proof, but if it works then it works.

And at the same time you don't get to change the definition of algorithm to allow your "proof" to be valid, otherwise you're just talking about nonsense.

The lookup table is part of the algorithm, and is not finite.

In general any problem can be solved in 1 step with a lookup table, so here you go P=NP solved.

> If we're disregarding shifts and adds as completing in negligible time

When considering multiplication algorithms the parameter N is the number of digits of the two numbers. In that model adds do not complete in negligible time, and instead take O(N) time.

> Booth's idea is to rewrite one of the inputs in base (usually) "4", except that the digits go from -2 to +2 instead of 0 to 3.

That's base 5 then. It needs to go from -2 to +1 if you want base 4

> There doesn't seem to be any reason functionality like this couldn't also be added to Typst though.

If I have to guess it's because the temporal inconsistency tradeoff can actually affect the current page too, since it might depend on the previous pages for layout, references, etc etc.

Typst on the other hand aims to have no inconsistencies due to incremental compilation.

> EDIT to respond to the comments: in the article, they are only counting the number of multiplies in the O() value. They are not including the adds.

This simplification relies on the fact that after making a multiplication the cost of merging it with the result of another is always less than the cost of performing the multiplication, so it doesn't change the overall complexity.

This is not true in your proposed algorithm: a lookup is O(1), but merging is O(N), so you cannot do the same simplification and have to count the complexity of performing adds as well.

> There's little card payment fraud

You're confusing fraud as in unauthorized payments with fraud as in you not receiving what you paid for. The latter is not prevented by 3DS in any way.

Loggin into Paypal for me requires a 2FA code sent through either SMS or Whatsapp, both of which require a phone.

Stripe's and Braintree's fees are like night and day, at least for us.

> 3-D Secure has been a fiasco IMO.

> I can recall when we first tried 3DS in the US

Exactly, it has been a fiasco in the US, but it's working quite well in Europe.

> When we finally decide we don't want to get lapped by India and Brazil in payment tech

They are indeed ahead, but they still work based on some kind of user authentication that's not a plaintext credit card number. That's the same disruption as 3DS, except normalized and a better executed.

All OpenText EUIPO trademarks I can find are also figurative https://www.tmdn.org/tmview/#/tmview/results?page=1&pageSize...

You don't have to use median of medians for every pass, you can use it only when you detect that each pass is not making enough progress, i.e. when you hit the worst case.

That only seems to change how the query is performed, not which kind of data can be returned.

For example how would you use it to return a list of events and, for each event, the list of attendees in that event?

You don't need randomized pivoting for this, there are deterministic ones like median of median that will also result in a O(nlogn) worst case.

Also note that with a randomized pivoting you _might_ hit a O(n^2) worst case, it's just that it's incredibly rare and cannot be forced by an attacker controlling your input, so for most practical purposes can be ignored.

I'm now imagining two little SaaS getting together and making another small little SaaS.

If you feed data to a LLM then there will always be a prompt injection. What you described is limiting the damage that the prompt injection can do, but also its usefulness.

Honestly they sound like pokemon game names.

> and that data fetched from the internet can be changed later

So do you want the VCS to be the source of truth or not?

> The source of truth remains decentralized, in the individual VCSes.

That's not entirely true, if the VCS's tag changes the proxy might not pick it up.

> Doesn't matter whether I need to stock up on milk, vegetables or hand peeled shrimp in garlic sauce

I don't even consider those when shopping online.

Density is not the correct measure here because empty land decreases density but doesn't need to be covered. What matters is how much the population is clustered.