No Claude was not involved in any way in me writing it, and honestly it's kind of getting depressing how many comments are constantly questioning peoples use of LLMs.
>Recently it's been shown that there are real, physical processes which are undecidable
I want to push back a bit on this claim along two dimensions.
Imagine a physical Turing machine built out of atoms, gears, levers, and an electron parked on the read/write head and ask whether that electron ever crosses some fixed plane in space, which it does only when the machine enters its halt configuration. That's now a purely physical question about a trajectory (does this electron ever reach a certain target), yet answering it for the whole family of such machines is literally the halting problem, so there's a physical process that's undecidable.
Your examples about physical processes being undecidable are all basically just this... there examples of using reflections of light, or the flow of liquid, etc... and demonstrating that these physical processes in principle are sufficient to model a universal Turing machine.
And while it's fascinating that certain things you may not have expected can be used to model computation, it's misleading, or rather it's too strong of a claim to believe that there exist actual/real physical processes whose outcomes are undecidable. That's a subtle but very common misinterpretation of what undecidability is.
Undecidability, whether in physics or computer science, only applies to the infinitely broad class of a problem as a whole, it never applies to a specific instance of a problem. So it can never be the case that there's a certain configuration of reflections for which it's undecidable whether a ray of light reaches a target. Nor can it be the case that for a specific lattice of atoms, it's undecidable whether it has a spectral gap or not. It can only be the case that for the problem as a whole where the parameter space is entirely unbounded, there is no single algorithm that can decide if a ray of light reaches a specific target for all possible arbitrary (and infinitely many) configurations. Once you fix a specific system, then the undecidability goes away.
Not claiming that you are necessarily making this misconception, but I often see people misinterpret undecidability to mean that there exists a specific problem, like with specific inputs, where it's somehow impossible to know what the answer will be. Undecidability always requires an infinite family of instances, and it's a statement about the nonexistence of a single algorithm that correctly answers every instance in that family. It says nothing about any particular instance being unknowable/undecidable.
In Canada all homeopathic medicine must clearly identify itself as such and must also state that it's based on traditional form of medicine and not based on any kind of scientific evidence.
The very "medicine" you linked to in fact displays it right on the cover.
This is a big part of the problem... Kramnik had been bullying people for years about cheating, including aggressively bullying Daniel Naroditsky, and for the most part the chess community did nothing about it. It would be very hard for people to condemn Kramnik for his cheating accusations all the while chess' top star Carlsen was on a bullying spree of his own against Niemann.
Kramnik was accused of pushing Naroditsky to suicide and defended himself by saying that it was far more likely that Naroditsky died due to a drug overdose.
Toxicology reports later showed that Naroditsky did die due to the combination of an abnormal heartbeat, sarcoidosis and drugs, specifically methamphetamines and kratom.
Now if you want to speculate that he took those drugs due to the harassment that's a possibility, but claiming he died due to suicide is entirely unsubstatiated and uncalled for.
Depends on your use case, once again. If your use case requires that arithmetic involving cents is exact, then yes defining 1.0d = 1 cent guarantees that, just as using the int value 1 = 1 cent guarantees that. Floating point numbers can represent and perform exact arithmetic on integer values, no loss of precision.
The original example was being concerned that 10 cents plus 20 cents should equal 30 cents exactly, not 30.000000...2 cents. Well if you set 1.0d = 1 cent, you get that exact result. In fact for any arithmetic performed on values greater than or equal to 1 cent, you are guaranteed to get exact results just like you get exact results using an int to represent cents.
Now if your use case does not require exact arithmetic on cents, then by all means stick to using 1.0d = 1 dollar. Evaluate your use case and decide on an appropriate scale to use by default.
Where the benefit of floating point kicks in, for certain use cases, is that you can continue to use the same representation with operations that don't work well with fixed precision, like interest rate calculations, financial derivatives, or more advanced financial modelling techniques and you get these operations at significant orders of magnitude faster than you would using decimal representations.
And I'm not talking like 20% faster or 50% faster... the difference between using a binary floating point representation versus decimal ranges from 10x to 100x, and the difference between using a double versus a big decimal is on the order of 1000x.
In order words, a financial report that can be generated in 1 second using binary floats can end up taking almost 2 minutes using a decimal representation, and 16 minutes using a big decimal.
By not thinking in terms of strict rules and dogmas and instead focusing on the actual problem you want to solve.
If you want to guarantee that adding cents together results in an exact value without any loss of precision, and you also want a tiny memory footprint and very high performance, then use a binary floating point to represent cents, just as you would use an int.
Also the question of how it's better depends on your use case and my argument is not that one representation is universally better than another, it's that money is used for such a diverse range of use cases that you need to actually understand what you're doing, what the goal is, what the potential issues are etc... in order to pick the right representation for your use case. At my trading firm we have three different Money classes optimized for three different use-cases (with functions to allow interoperability between them).
For the use case where the representation needs to use little memory, is fast, and needs to be used to perform complex financial calculations at an enormous scale, then you use binary floating point where a value of 1.0d = 0.000001 dollars. This gives you exact precision when working with cents, and lets you perform all of the usual financial computations that most quantitative applications need to perform with excellent performance.
We also have a use case optimized for I/O, where no calculations are expected to be performed but the data will be transmitted over a network or to/from a database etc...
If this isn't your domain, maybe you're just writing a GUI application/web app, then by all means use a big decimal or use an integer... I don't know, but it's very sad seeing how many people who are presumably professionals don't take just the bare minimum amount of time to think things through and instead just reason in terms of strict dogmas.
It might be your least concern, and that's fine but it's not the least concern for many people who need to process large volumes of transactions.
Money, even within fintech, is a concept used across a wide variety of domains, and you can't assume that what concerns you is what concerns everyone else relying on it elsewhere.
There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 and it saddens me when this topic comes up and people go to such extreme lengths to recreate a second hand buggy reimplementation of a subset of floating point numbers to do it.