Maxatar

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.

You can try to request a refund for free software but the terms of the compiler explicitly state that undefined behavior is permitted to "time travel" and that there's nothing faulty about it. That's C++ for you ;P

Since 2025 in the U.S. computer hardware qualifies for 100% depreciation in its first year of service.

C++ implementations don't make any sort of special or unique accommodations for UNIX/POSIX APIs. For the most part calls into external libraries are firewalled and not optimized in a way that typically engenders undefined behavior, so POSIX APIs tend to work. But any external library would also work since it's not like POSIX is exclusively shielded or singled out in any particular way.

UNIX APIs are not implementations.

I worked briefly in heath care and the code is so brittle and so poorly understood that almost everyone is afraid to touch anything and instead it's just layers and layers of stuff trying to patch around existing code.

When coding agents first came out, the overwhelming narrative was how bad they were, they don't know what they're doing, the code they write just sucks and they hallucinate APIs.

While these criticisms were technically true, they were stated mostly out of a sense of insecurity from people whose jobs were basically spending years and years just glueing code together and mixing APIs to display some CRUD apps rather than out of a genuine concern for whether LLMs were actually producing poor products.

Nowadays those concrete criticisms don't really work anymore, LLMs are pretty good now and surpass most developers when it comes to writing the majority of shovelware that people have been employed, and so the narrative is changing from concrete criticisms about how LLMs were genuinely not capable of writing software... to these kinds of abstract and philosophical arguments that are really hard to argue against because they make no concrete claims.

If you say an LLM can't implement a feature, we'll we can test that claim concretely and LLMs are getting much better with every new release. If you say its code is slower, buggier, or less maintainable, those claims too can be measured and once again they're getting really good at these. If you say it takes longer to complete a task or requires more human intervention, we can compare it and measure etc...

But now the objection has shifted not to LLMs are incapable, but people are now incapable and LLMs represent a degradation of the "craft". And here there is nothing left to test or falsify. The argument has stopped being about whether the LLMs work, because that's verifiable and they are now at a point where it's hard to argue against their ability to actually produce functioning software, so now the argument is about whether people are morally, culturally, or intellectually permitted to use it.

You are mixing some things up. Yes the `sizeof(char)` is defined to always be 1 by the standard... but the size of char is not 1, it's defined by CHAR_BIT which can in principle vary from platform to platform.

>At least historically, we haven’t really been able to tell what will be transformative in terms of real world applications ahead of time.

This is mostly false. There are certainly some famous cases where math pursued for theoretical reasons later resulted in major practical applications but historically a great deal of math was developed either in response or alongside practical problems with anticipated real world applications, with war, industry and commerce being the major drivers.

We can play with words all day, but in the sense of a particle entering into the event horizon of a black hole and then at some point in the future exiting from inside of the event horizon, that simply never happens and Hawking radiation does not propose that.

Not sure I follow your comment exactly, perhaps I am misunderstanding it but Hawking radiation doesn't involve anything escaping a black hole.

The radiation never originates from within the event horizon. Furthermore the radiation itself does not encode any information about what fell into the black hole apart from the electric charge, angular momentum, and mass (all of which must remain conserved).

People who actually did the original work care because this guy appears to be strip mining their content, running it through LLMs, and repackaging the result as if it were his own expertise. He also leans on inflated credentials to sell the illusion that he independently understands or developed the material. He's laundering other people's work through AI and personal branding, then taking the credit, so yeah that can piss people off and if you don't care then by all means continue supporting this hack.

Some documented examples along with confirmation from the vendors themselves:

https://www.tomshardware.com/features/crucial-p2-ssd-qlc-fla...

https://www.tomshardware.com/news/wd-blue-sn550-ssd-performa...

https://www.tomshardware.com/news/adata-switches-nand-on-sx8...

It's not that physics feels no responsibility to explain why, it's that all other fields of science answer the why by punting to some lower level of science that is taken as an assumption until you get down to physics which has nothing lower level to punt to.

Psychology explains why you feel tired by pointing to biology. Biology explains why cells need ATP by pointing to chemistry. Chemistry explains why ATP releases energy by pointing to physics. Physics explains that by pointing to some higher level form of physics like thermodynamics, which points to statistical mechanics, which point to quantum laws. When you get down to a certain level you simply have nothing left to punt to. You simply accept it because it's what's observed and makes reproducible predictions or you don't and go study philosophy or religion or something.

> += deferred concatenation requires lazy strings and that didn't come until 10-15 years later.

CPython's += does not perform deferred concatenation and CPython does not use lazy strings. The optimization uses an eager in-place realloc if the string's ref-count is 1. This remains the optimization used even to this day and was introduced in 2005:

https://docs.python.org/3/whatsnew/2.4.html#optimizations

>However, concatenating string lists with sum() was a common Python idiom at the time

It could not possibly have been a common Python idiom since sum() explicitly rejected strings by throwing a TypeError. This was explicitly special cased to avoid the degenerate performance and the TypeError even has an error message saying "TypeError: sum() can't sum strings [use ''.join(seq) instead]".

>Gvr's reduce dislike was more about its syntax. It doesn't mesh well with Python's lambda syntax.

No it had nothing to do with mixing with lambda syntax, on the contrary GvR actually wanted to remove reduce and lambda (and map and filter as well). Here is the actual article by GvR regarding removing reduce, absolutely nothing in it involves how it mixes with lambda expressions.

https://www.artima.com/weblogs/viewpost.jsp?thread=98196

>So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.