That is default IEEE behaviour: https://en.wikipedia.org/wiki/Rounding#Rounding_half_to_even
This is the default rounding mode used in IEEE 754 operations for results in binary floating-point formats.
Though it's definitely a bad default because it's so surprising. Javascript and Rust do not do this.
Not really anything to do with determinism though.
That doesn't make any sense. As you say, in that case you have to "spread leftovers", but that isn't really any more difficult with floats than integers.
It's better to use integers, sure. But you're waaaay over-blowing the downsides of floats here. For 99% of uses f64 will be perfectly fine. Obviously don't run a stock exchange with them, but think about something like a shopping cart calculation or a personal finance app. Floats would be perfectly fine there.
Does that imply anything at all in LLMs’ favour?
Yes it suggest lower cognitive load.
I don't think so. It's more likely to be a lock-in method. Go to another AI provider and it won't remember all the useful things you've told it.
I guess we'll see if OpenAI starts an ad network...
In my experience taking an inefficient format and copping out by saying "we can just compress it" is always rubbish. Compression tends to be slow, rules out sparse reads, is awkward to deal with remotely, and you generally always end up with the inefficient decompressed data in the end anyway, whether in temporarily decompressed files or in memory.
I worked in a company where they went against my recommendation not to use JSON for a memory profiler output. We ended up with 10 GB JSON files, even compressed they were super annoying.
We switched to SQLite in the end which was far superior.
Well that's clearly worse... Why even make this comment?
I think once things get established the people in charge see any attempt to change it as some kind of personal insult, so they just go into defence mode. You see the same thing e.g. with Python - for literally decades they've denied that performance matters and it's really only recently that that has changed.
I think it will only get worse for C++ because the people who understand this stuff have mostly given up on C++.
I’m pretty senior, having been in the industry for some time, so I tend not to be asking the questions that will have a million examples out there
Me too, but this was C++ where there isn't a strong culture of making high quality libraries available for everything (because it doesn't have a proper package manager, at least until very recently), so you do end up having to reinvent the wheel a fair bit.
And sometimes you just need things a bit different to what other people have done. So even though there are a gazillion expression parsers out there (so the LLM understood it pretty well) there are hardly any that support 64-bit integers. But that's a small enough difference that it can deal with it.
It's definitely not cheating. But you also do need to understand what you're doing.
Ada is not strictly safer. It's not memory safe for example, unless you never free. The advantage it has is mature support for formal verification. But there's literally no way you're going to be able to automatically convert C to Ada + formal properties.
In any case Rust has about a gazillion in-progress attempts at adding various kinds of formal verification support. Kani, Prusti, Cruesot, Verus, etc. etc. It probably won't be long before it's better than Ada.
Also if your code is Ada then you only have access to the tiny Ada ecosystem, which is probably fine in some domains (e.g. embedded) but not in general.
Saving this for the next "Year of desktop Linux" discussion 😄
Glad you recovered it.
Except on Windows! Actually it depends on if you installed Python from the Microsoft store or the official download. What a mess.
They don't want to fix it because it might be confusing temporarily, so instead they're going to leave it broken forever.