SkiFire13

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.

I graduated from a not so incredible university and we had multiple such rooms. Teaching assistants and some tutors helped supervising the exams and it wasn't easy to cheat without getting caught.

It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.

If you are into constructive logic then this will only work for proving negative statements (where indeed the definition is the same as what a proof by contradiction would give you). For positive statements you won't get back a direct proof term of your initial statement, but rather a proof of a double negation of it.

My understanding is that the "logical bits" view breaks down for unions, because the nth logical bit could be at different offsets depending on the union variant that's considered active.

Everyone talking about malware in dev dependencies as if dependabot only raises issues about that, but it does not. It raises warnings about all sort of "vulnerabilities" irrespective of the threat model.

Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.

I don't buy the notion that tests do not test relevant skills.

In my long career I've noticed a strong correlation between SAT scores and academic performance as well as job performance.

A test doesn't need to test the relevant skills for that, it just needs to test _something_ that correlates with academic performance and job success.