Maxatar

Having a terrible experience seems like a local issue, certainly some areas might have a worse pool of delivery personnel than others but where I live the people doing Instacart are primarily women and they do an excellent job. Many women can't do Uber because of the insane levels of harassment, but they are able to do "gig" work like Instacart or UberEats that doesn't involve interacting with random strangers.

Like most things in life, it's not a matter of difficulty, as if I am so incapable of going to a grocery store to buy groceries and the undue hardship it will cause me. It's simply a matter of how I like to budget my time. I judge that the 30 minutes it can take to do groceries is better spent doing other things with my life.

Not at all. The asymmetry holds whenever the other possibilities don't introduce an opposing infinite penalty for belief. There could be countless other gods who are indifferent to Christian belief, reward it, or impose only finite penalties, and the asymmetry would remain intact.

The hypothetical god who punishes believers of a Christian God is a legitimate objection to Pascal's wager, but it doesn't establish the original assertion I objected to. You're confusing demonstrating that the asymmetry isn't guaranteed with demonstrating that it requires Christianity to be the only possibility. Those are two entirely different claims.

Pascal's wager was not at all anchored to any specific attestations, you are taking his wager and reinterpreting it to give it some kind of legitimacy that it never originally held. The entire point of the wager was to justify belief in the absence of sufficient evidence, by appealing to the asymmetry between infinite reward and finite cost. If your now arguing that Christianity is more credible because of historical evidence, so be it and stick to it but you've abandoned Pascal's wager and moved on to an entirely different argument.

If this claim was in writing then it's legally binding in most U.S. states. Technically it's legally binding even if it's not written but in those cases it's harder to prove.

Yeah, you're referring to Scott Meyers and he gave a really insightful talk about how complex and inconsistent C++ has become here titled "The Last Thing D Needs":

https://www.youtube.com/watch?v=KAWA1DuvCnQ

Slides are here:

https://www.aristeia.com/TalkNotes/TheLastThingDNeeds2-ups.p...

The conclusion is "The last thing D needs is someone like me." meaning D should avoid designing a language where you basically need a niche of lawyers crawling through the language standard to decipher the meaning of various features and then write about how to safely use those features. It's not that languages shouldn't have experts who give good advice, but that the nature of advice in C++ has come down to explaining arbitrary rules, inconsistencies, and obscure corner cases rather than how to use the language effectively to solve actual problems.

He says at some points (taken from the transcript):

"There are some arbitrary, wacky decisions, in my opinion ... There's a lot of, in my opinion, simple arbitrary choices that did not have to be made that make explaining things more complicated and also make working with the tool more complicated."

"Much too much of what I've written about has been tool use, talking about language idiosyncrasies, arbitrary decisions, things you need to be able to remember."

"There is epicycle on epicycle on epicycle inside this language."

And then he followed it up a few years later with a blog post explaining that he won't be updating his book with language related fixes because he no longer trusts himself to know what's right from what's wrong:

"C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind."

https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...

It's a misleading number, the 500 billion in revenue is needed over a 10 year period, it's not a yearly figure. Anthropic isn't paying 500 billion a year for the commitments that OP posted, it's paying 500 billion between now and 2036.

The OP post is misleading because it makes you think Anthropic has to earn 500bn per year in revenue, but those commitments listed are not yearly commitments, they're commitments over 10 years with contracts that run until 2036.

Anthropic needs to earn 52B a year in annual revenue to honor those specific commitments plus obviously its own operating expenses... and yeah that will require Anthropic to grow as a company, but their S-1 indicates 67.2B a year in revenue and sure maybe they stop growing and this is their peak... or maybe they do manage to grow further to 80B a year, 90B a year...

These commitments aren't annual though, most of them amount to 10 billion a year commitments for 10 years. Put another way Anthropic has committed 52 billion dollar a year to these companies and their S-1 indicates they earn 67.2B a year in revenue.

I'm not going to predict whether Anthropic succeeds or fails, just that it's very misleading to claim that Anthropic needs to grow to $500b in revenue without making it clear that it's $500B in revenue per decade rather than $500B in revenue per year which is what most people reading such a number would assume.

Jonathan Blow made his own language and compiler because C++ was slow and miserable.

He recently released an indie game using that very language using his own 3D engine. The reviews on Steam are Overwhelimgly Positive and sales have so far significantly exceeded expectations.

https://store.steampowered.com/app/499170/Order_of_the_Sinki...

>The only benefit of them seems to be slightly better error messages if someone misuses a template class/function.

The error messages are arguably worse with concepts than without them but it's really just a trade-off. Without concepts you got long "stack-traces" of raw syntax errors that could dig deep into nested functions. With concepts you get long stack-traces of concept failures where concept A fails because concept B fails because concept C isn't satisfied and then you need to dig through this chain of concepts to figure out what's actually needed.

Traits in more principled languages like Haskell/Rust don't have this issue whatsoever because traits are semantic requirements in those languages while concepts in C++ just perform a "will it compile" kind of check.

The primary benefit of concepts in C++ is overload resolution, they allow you to write multiple functions with the same name, and same number of parameters, but where the types of the parameters are required to satisfy certain properties.

For example:

    void serialize(std::ranges::contiguous_range auto&& range) {
      // Serialize the underlying memory directly
    }

    void serialize(std::ranges::range auto&& range) {
      // Serialize elements individually
    }

The compiler selects the first overload for contiguous ranges such as std::vector and the second for non-contiguous ranges such as std::list.

It's not even that though. Looks like public utilities are only offered in areas where those utilities are cheap to provide or abundant, and private utilities fill in a gap in harder to reach areas.

The study even points this out as a foot-note but then focuses on rate of price increase versus nominal price. It should not come as a surprise that in areas where utilities are less abundant the price will increase faster than in areas where that same utility is plentiful.

This is mixing up consistency with impartiality. Imagine judging every athlete by making them run the same marathon. Everyone faces identical conditions but you just rigged the competition to favor one type of athleticism over another.

An interview format is no different. It rewards certain personalities, temperaments, and ways of communicating at the expense of others. Applying the same bias consistently doesn't magically make it objective, it just makes the bias systematic and less obvious.

It's pretty well established that this blog is LLM generated. The cpp subreddit has recently banned it, for example.

If every single SIGTRAP was caused by an INT3 instruction, then this would work, but SIGTRAP can also be generated by single stepping where subtracting 1 would be incorrect.

GDB already compensates for breakpoints it inserts itself because it knows their locations, so it subtracts 1 as you suggest. It could also recognize embedded INT3 instructions but that requires distinguishing their traps from other causes of SIGTRAP which is much more complicated. So instead GDB generally leaves the instruction pointer unchanged for embedded INT3 instructions.

Here's a discussion of precisely this issue from the GDB developers:

https://sourceware.org/pipermail/gdb/2009-February/034621.ht...

This is the the release of the Roadster introduced 9 years ago. This is what people who put down a deposit (upwards of 250k) back 9 years ago are in line to receive.

>To the extent the theorems in question are impossible to formalize this means the original proof must be in error.

Theorems by definition must be formalizable. A theorem is not simply a true proposition, it's a provable proposition and a proof is necessarily a formal/syntactic property of a proposition.

That said, I agree with the sentiment that dismissing the entire article on the basis of the incompleteness theorems is shallow and the article is not about formalizing "all" of mathematics in the strict sense. It's mostly about introducing formal tools to the everyday mathematics.

The one with the actual rocket engine is not being sold to the public and Tesla website explicitly states it's not legal to drive it on public roads. It's mostly just a cool demo/prototype and I'm sure there will be privately run tracks that let people drive one.

The generally available car will have cold-gas thrusters which boost acceleration but is nothing like what was demo'd.

I was skeptical about this article's claim about LLMs so I tried it out myself. Looks like there are several layers of pedantry involved, for example, strictly speaking in base C it's undefined behavior to divide by 0.0, even for floats, so the author's initial implementation is incorrect and a optimizer could elide the call to isfinite in certain scenarios where the denominator is 0.0.

Presumably the airtight implementation assuming Annex F is as follows:

    #pragma STDC FENV_ACCESS ON

    int my_div(float x, float y, float* r) {
      if(!r) {
        return -1;
      }

      fenv_t environment;
      if(feholdexcept(&environment) != 0) {
        return -1;
      }

      float result = x / y;
      int failed = fetestexcept(
        FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW);

      if(fesetenv(&environment) != 0 || failed != 0) {
        return -1;
      }

      *r = result;
      return 0;
    }

When I asked about the author's implementation I got the response that the author's implementation is deficient in several areas:

   - Underflow produces a finite result and passes this check.
   - Overflow can produce a finite maximum value under some rounding modes.
   - Quiet NaNs and valid infinite results fail this check, even without an arithmetic exception.

     It also assumes floating-point traps are disabled. Annex F defines the arithmetic behavior; your function still needs a chosen definition of “failure.”

So the answer really is... safely dividing two floats really depends on what trade-offs you're willing to make, and the original reply of just checking for a 0 denominator is honestly the most sensible, portable, and safest.

This comment seems to be a hypercorrection, where someone attempts to demonstrate superior linguistic knowledge by correcting something that isn't actually wrong in the first place. You've likely heard somewhere before, almost certainly on HackerNews in fact, "lede" is proper and "lead" is not but don't really have a genuine understanding of it and are just repeating what you've heard before.

In actuality both "lede" and "lead" are correct. "Lede" is mostly an American and recent respelling of the word "lead" and "lead" still remains the predominantly used term (while "lede" is predominantly an American journalistic spelling).

That paper explicitly states that the implementation is proprietary and the paper is not intended to describe the implementation itself. The paper focuses on the design considerations, technical challenges, and lessons learned from developing and deploying SynthID at scale. It explicitly omits critical implementation details such as the neural network architecture, training process and the loss functions used. The paper is really focused on deployment, not on SynthID's actual implementation.

Can't speak for C# but in C/C++ the optimization can rarely be applied safely due to aliasing. If any part of the data you're working with involves a char* then C/C++ optimizers refrain from doing these kinds of optimizations because of how difficult it is to guarantee the absence of mutability.

Ad-blocking breaks the original site. A lot of functionality stops working properly.

It's not about what is charged, it's about what is recommended. Wealthier people are recommended more expensive products while poorer people are recommended cheaper products. They are different products being recommended.

I don't really see why this is a problem.

I was under the impression that solving QP optimization problems (subject to constraints) was largely performed by SMO.

That's kind of the point though. There are a ton of alternative underground music and art, but it's not popular and it's even less popular outside of the various countries from which it originates.

The same is true of Chinese culture. China has an unbelievably diverse range of music, film, theater, etc... but what gets exported to a Western audience is not going to be things like Beijing's underground punk and experimental noise scenes, Chinese shoegaze, Sichuan and Yunnan folk music, Mongolian throat-singing fused with metal, dozens of completely different regional opera traditions, underground queer cinema, or Sichuanese rap.

Westerners will mostly get the small slice of Chinese culture that is easiest to export, translate, market, and fit into familiar expectations about what "Chinese culture" is supposed to look like.

AIs do a good job of maintaining their own code, including refactoring, increasing test coverage, ensuring documentation doesn't become stale, updating dependencies. They've been extensively trained to perform pretty much all of the functions of maintaining codebases and they do it far more diligently than most people.

A plugin system in no way impedes having a set of curated and polished features out of the box. It simply allows the addition of new features to have the same status and be part of the same class as existing features. It's an architectural and design property of the system, not a property pertaining to quality.

In your case you can stick to installing plugins written by first parties or write your own plugin for specific use cases that you come across. You don't need to have any use cases for plug ins right this moment, but perhaps at some point if you find yourself repeating the same manual process over and over again, you can write a plugin to automate a substantial portion of it.

The fact that it will never exist.

This is a really bizare argument for anyone who actually knows about options and trades them. If your thesis is that RAM is in a massive bubble and Micron is going to crash when it bursts, you don't express that thesis by buying a put struck around Micron's current bubble price. The fact that you chose a $1000 strike as your example is weird because that's basically the most expensive way to make the argument you're supposedly making.

"IV crush" is an especially strange objection in this context. IV crush matters when you buy options at elevated implied volatility and that volatility collapses. If Micron suddenly drops hundreds of dollars because the alleged bubble is bursting then the implied volatility would sharply rise, which makes your put more valuable, not less. Invoking "IV crush" here mostly makes it sound like you've heard the terminology without thinking through how it actually applies to the scenario you're describing.

If you genuinely think Micron is going to collapse sometime over the next two or three years because this entire RAM shortage is an overhyped bubble, then the obvious trade is to buy puts around where you think the stock should return to once that bubble disappears. Micron wasn't remotely a $1000 stock before this run. We can be generous and use a $300 strike since even though that's still 100% higher than Micron's price prior to this run-up, it gets the point across.

A long dated $300 put is currently around $7 per share, so one contract costs roughly $700. If Micron eventually falls to $200, that contract is worth $10000 at expiry. At $100, it's worth $20000. If the crash happens well before expiry, it can be worth even more than its intrinsic value because there's still time value left.

If you're claiming to be certain that a gigantic bubble is going to burst and wipe hundreds of dollars off the stock price, there are long dated far out of the money puts specifically capable of expressing that position. Pointing at an expensive $1000 strike put and saying "look, options are complicated" is just a weird or rather superficial misunderstanding of some financial concepts.

How does buying long term put options require perfect timing? The whole point of a long term put option is that you only have to be right at some point between when you buy it and when it expires.