See "What do Visa and Mastercard do?" https://news.ycombinator.com/item?id=49614280
It's not something irreplaceable but it's not trivial either.
1,970 karma · joined March 10, 2021
It's not something irreplaceable but it's not trivial either.
Because it has the same issue.
SELECT DISTINCT and GROUP BY are equivalent from a query planner perspective.
That's what is generally suggested when handling money, at least for normal businesses (in finance related businesses you might have to handle a lot more decimal places for things like exchange rates, fractions of cryptos etc etc)
Be careful though that some currencies require more than 2 decimal places.
You also didn't give anything to opensource. This shows that AI can allow open source to be used in more cases and in more flexible ways, but in no way does this mean that open source (and especially the good high quality one) will explode.
If anything we saw an explosion of open source projects, most of them low quality slop, and even the ones that used to be high quality are slowly degrading.
Note that the result of 0.1+0.2 does not lie in the interval containing 0.3, which is was confuses most people. The issue is that there is some imprecision in representing 0.1 and 0.2 too, and that compounds when summing, resulting in something that does not actually correspond to 0.3 (hence the classic 0.1+0.2!=0.3)
> 0.2+0.1
0.2+0.1 with floating point numbers _is_ deterministic, as you'll always get the same answer.
I suspect you might instead mean exact calculations/answers (in the example above, neither 0.1, 0.2 nor 0.3 have exact representations using floating point numbers).
And just to be clear, there are non-determinism-like issues with floating point numbers, but those are much rarer/niche and _can_ be fixed. For example parallel summation depends on the order the summation was made, so non-determinism in the parallel implementation ripples through the summation result. Some non-basic operations (e.g. trigonometric operations) have platform dependent implementations with different roundings, so you might experience different result based on the platform you're on.
And they are probably right. But they are probably also missing that this will translate to worse quality. You know, the classic "you can only pick two among good, cheap and fast"
I have never seen Apple approving within 24 hours
They might also have unionized due to the bad conditions while developing GTA 6, which could also lead to it being a bad game. Who knows though.
It tries to argue that higher reward rates are necessary to attrach customers that pay a lot (for credit card companies) and that lower income people are generally subsidized by taxes (obvious but unrelated), but at no point (until where I read) it seems to address the issue of merchants having to generally increase prices due to these cards.
The article did an awesome job explaining what are the parties involved and you choose to use a generic term instead.
> dealing with fraud and chargebacks
A lot of that is offloaded to the merchant, which instead has to pay them on top of what they already pay to the issuer bank.
Note that usually you mount many solar panels, not just one, so this will stack relatively quickly.
- the size of the pointed type - the alignment of the pointed type - a function pointer for its drop glue
That's already quite big to inline to save on indirection, and this is before adding more methods.
Just to expand on this: which vtables will be needed is not known before running codegen. At that point however multiple codegen units might generate the same vtable, and that might not get deduplicated by a later pass.
Moreover with dynamic linking (especially on Windows) it's impossible to guarantee that such vtables will be unique.
Everything is possible, what matters is how much work you have to do to achieve and maintain it.
> You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.
On the other hand Rust uses less memory if you store 0 polymorphic pointers, while C++ still pays the cost of storing a vtable pointer for each object instance.
Effectively C++ choose a design that optimizes for having a lot of polymorphic pointers, while Rust optimized for supporting polymorphism for all objects at no extra cost if you don't use it.
The ones provided by the compilers are simply the libc ones.
LLVM will even go as far as detect attempts to rewrite memcpy and replace them with a call to the libc one!
Moreover the 26% is with mimalloc, with musl's allocator it's 144%, so there are likely other parts that are slower (likely the memcpy implementation)
This has always been the case. The RAM effects only changed at which point the O(n) stops being faster than the O(log n) solution.
Part of the issue is that this was never low-level stuff. When you're selecting between the two you're making a semantic choice, and that's not something a compiler can do for you.
Also, why do you need a proxy for the number of people when you can just count them? In Europe a service charge is relatively common and it's a per-person fixed charge.
This is not entirely correct (or at least it's worded a bit weirdly).
If you know that A goes in a certain place you can still try a word using A more than once. It's only once you know that A does not appear twice (because you tried a word containing A twice, and the second A way gray!) then you can no longer use A twice.
In your case you tried MAMMA which contained 2 As and the second one gave you the information that there's no second A.