CPUs have many different configuration bits to configure floating point rounding, flushing denormals, etc. which mean that in practice anything that relies on floats being deterministic has the stability of a house of cards.
> Floating point is deterministic, what are you talking about?
Order of operations can change a result, for example. I suspect you mean that the algorithm never changes. While op means that mathematical operations which most folks would expect to be reliable are not.
There are enough problems for a 44 page paper titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic"[1] I don't quibble on the language because I know what people mean.
Most folks won't encounter most of the issues, generally. But expose your code to a large enough dataset, or be like me and write a CAD/CAM system with motion control and experience most of them.
That (no doubt excellent, but) technical PDF is overselling the problem somewhat, when what every dev needs to know is better represented by a friendlier summary like https://floating-point-gui.de/
That's a great resource as well. Targeted at developers, rather than computer scientists. Same observations, different target audiences and expectations. You're probably right that the more practical reference targeted at developers is more useful here. My references are full of the academic papers because of my CAD work.
No. It's been quite some time since I realized that all language is a pidgin used to translate between individuals' unique lived experiences and points of reference. And find communication much more fluid and less confrontational when the focus is on shared meaning rather than perfect word choice. Especially when working with non-native speakers, but also just people in general. Stephen Fry captures the feeling: https://www.youtube.com/watch?v=Ovi7uQbtKas
When TZubiri made their original comment, I understood they were speaking about some or all of the issues outlined in the paper I linked. If you didn't, that's ok. If you think the referenced paper missed something, it's OK to add that.
These kinds of comments tend to happen when you are assuming a shared meaning that isn't so shared. Especially in this context, it's a good idea to be precise in your terminology when there is a commonly used vocabulary for talking about it. Especially when it comes to misconceptions about floating point, which is often treated as 'random' when it generally isn't.
Sometimes specificity matters. Usually when looking directly at some specific piece of code. In this conversation, the intended meaning was clear. Folks just love being the pedant and the brinksmanship which comes with it. There's a propensity to derail otherwise useful conversations into discussions like this rather than dig deeper into what people meant, and were trying to communicate.
> In this conversation, the intended meaning was clear
Apparently it wasn't, as the commenter who originally used the term has now clarified that they did indeed mean non-deterministic. You misunderstood them.
So maybe being specific about terminology here isn't just pointless pedantry?
Regardless of his choice of words, he's specified that he's speaking about IEEE754 and the sort of issues which arise systemically from the compromises inherent in it's design.
He can't attest to them being the same ones in the paper I linked, but I can. Everything he's said is in line with the situation detailed within.
He and I seem to understand each other. I get what he's saying. How the issues with IEEE754 give rise to the nondeterminism he's talking about. I should, I wrote a whole system of libraries to deal with them. Do you understand the conversation? Because it seems like you think we're talking about two unrelated things and you're still arguing over terminology.
Thanks for following the thread. I'll clarify on my intended meaning was indeed a strict actual definition of determinism, but a broader definition of floating point, to include its actual usage. But fwiw, it was indeed possible that I was someone who confuses determinism for precision, but no.
When I said that floating points are not deterministic, I wasn't very precise, but I do think that broadly speaking, floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type, the goal is to have a data type for approximate answers, turns out that when exact answers are sacrificed in the name of speed, so is determinism. And this has huge effects on modern day, Floating Point is used on separate hardware with parallel operations, and there's race conditions that make most Machine Learning and AI computing irreproducible, and that indeed seems to be a consequence, as you mention, of the lack of associativity of FP.
So, that said, I would make two clarifications:
>-- Floating Points
>++ Floating Point computing
where by Floating Point computing would mean the actual application computing that we build, as opposed to "Floating points" referring to the ideal ancient standardized hardware layer abstractions.
And if necessary:
> -- is
> ++ tends to be
In order to be perfectly correct, which after all, is what we are going after.
So if pressed, I wouldn't say "Floating points are not deterministic" but "Floating Point computing tends to be non-deterministic", but I would feel very comfortable shorthanding it to "Floating Points are non-deterministic" anyways.
The paper cited is a bit hard for me, so I can't verify if it matches what I'm saying. But I imagine by the date, it wouldn't be able to address the issues that we can empirically from the advent of ML systems, but maybe it did foresee from a theoretical standpoint some of their limitations.
There's a between-the-lines thesis here that there's two main schools of computing nowadays, one that seeks perfection, and another that seeks approximations, the CPU/GPU dichotomy is roughly analogous to the Mathematics/Physics vs Engineering/Industrial dichotomy.rroot@t14:/mnt/c/Users/TomZubiri/Desktop# cat fixed.txt
Thanks for following the thread. I'll clarify on my intended meaning was indeed a strict actual definition of determinism, but a broader definition of floating point, to include its actual usage. But fwiw, it was indeed possible that I was someone who confuses determinism for precision, but no.
When I said that floating points are not deterministic, I wasn't very precise, but I do think that broadly speaking, floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type, the goal is to have a data type for approximate answers, turns out that when exact answers are sacrificed in the name of speed, so is determinism. And this has huge effects on modern day, Floating Point is used on separate hardware with parallel operations, and there's race conditions that make most Machine Learning and AI computing irreproducible, and that indeed seems to be a consequence, as you mention, of the lack of associativity of FP.
So, that said, I would make two clarifications:
>-- Floating Points
>++ Floating Point computing
where by Floating Point computing would mean the actual application computing that we build, as opposed to "Floating points" referring to the ideal ancient standardized hardware layer abstractions.
And if necessary:
> -- is
> ++ tends to be
In order to be perfectly correct, which after all, is what we are going after.
So if pressed, I wouldn't say "Floating points are not deterministic" but "Floating Point computing tends to be non-deterministic", but I would feel very comfortable shorthanding it to "Floating Points are non-deterministic" anyways.
The paper cited is a bit hard for me, so I can't verify if it matches what I'm saying. But I imagine by the date, it wouldn't be able to address the issues that we can empirically from the advent of ML systems, but maybe it did foresee from a theoretical standpoint some of their limitations.
There's a between-the-lines thesis here that there's two main schools of computing nowadays, one that seeks perfection, and another that seeks approximations, the CPU/GPU dichotomy is roughly analogous to the Mathematics/Physics vs Engineering/Industrial dichotomy.
> when exact answers are sacrificed in the name of speed
I have found in https://github.com/timschmidt/hyperreal and the geometry layers built atop it, that exactness and speed are not fundamentally opposed. Hyperreal retains exact mathematical structure at the scalar level, and at each level higher up through vertices, vectors, matrices, triangles, curves, etc. And uses it to choose optimal datatypes, dispatch against the fastest algorithms, and eliminate large chunks of needless calculation where simpler proofs are sufficient.
The downside is a bit of additional code and API complexity. But the slightly more complex API accurately represents issues like uncertainty in decidable equality of arbitrary computables in bounded time, which is a limitation of math itself, so representing it accurately in the API permits the algorithms to be more robust.
> Floating Point is used on separate hardware with parallel operations, and there's race conditions that make most Machine Learning and AI computing irreproducible
Deterministic reproducibility is, I think, one of the most awesome superpowers of a system like hyperreal. It makes simulation much more interesting and useful. As well as cross-platform use.
floating point arithmetic, as used today, foregoes determinism, and this results from the very ethos of the foundational IEEE754 data type
This was somewhat true in the past, but the situation has been improving dramatically in recent years to the point where FP determinism is completely feasible. The remaining hurdles are primarily on the toolchains/kernel side. I have a library called rfloat that you can drop into most C/C++ code for practical determinism without thought (subject to documented caveats), for example. You can do the same thing manually with some more careful attention.
I'm in a very remote corner of the world on bad Wi-Fi though, so you'll have to forgive omitted links.
> I gonna be generous and guess this was upvoted as top post for being maybe possibly midwit-correct, hoho you are so right good sire, reddit-fedora-tip herpdy-derp.
You may want to look in a mirror. Your snide tone does not add anything here.
> - if they meant "diameter is similar to Ohio dimensions", they are a little bit off, because Ohio is about 355*355 km and Enceladus diameter is around 500km
I think they used the diagonal of a hypothetical square Ohio: sqrt(355^2 + 355^2) ≈ 502 km.
The classical definition of diameter of a set is "the largest possible distance between two points". So in this sense your square Ohio has a diameter of 502 km.
(It is still misleading to compare it to the diameter of an almost-spherical object, I agree. Especially because moving on the surface of a sphere it takes much longer than 502 km to walk from one point to the antipodal one.)
> First of all, there are many studies that show that plant-based meat alternatives are healthier than their meat counterparts
Define healthier, and link the studies.
I eat vegetarian more often than not these days (although I don't usually use plant-based meat), and I'm not disagreeing with you. But cite your sources rather than making vague health claims.
Well, why are people who are afraid of a long ingredient lists (without understanding what the ingredients actually are) and just blurt out that vegan meats are unhealthier not asked the same?
In any case, the sister comment linked to some studies. Have a look.
Also, a simple web search will show you that many animal-based meats (such as red meat) are linked to many cancers, this is not even disputed.
Fair point, there's a lot of nutritional bunk going about. I'm not an expert either, but the Wikipedia article seems to cover the big studies that I've heard of: https://en.wikipedia.org/wiki/Meat_alternative#Health
Is 100% taste match more important than not supporting an industry that kills Billions of animals a year and on top of that causing a huge amount of greenhouse gases and biosphere destruction?
What if it's 85% taste match, wouldn't that be enough to make the jump to plant based alternatives?
Male chicks for example get thrown in a wood chipper.
Hmm not sure. Depends on how well it is prepared. But yes, I said, there are much better brands. But the question was specifically about what's availabe in India, which I have no cllue about.
> You just have to use other data types to handle money or complex mathematical operations like 0.2+0.1
Such as... decimal floating point.
reply