-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integers are real numbers #2
Comments
Hey, thank you for the comment! There are multiple things going on here, so I'll try to split them off and give me thoughts on them separately. That said, I am not going to insist that my conclusion, that integers are not real numbers, is correct. I posted this article on /r/haskell too, and many other commenters also pointed out that that's an incorrect conclusion. I still feel that integers are not real numbers. I am unable to give a clear exposition why. Or maybe it is just that thinking of them as distinct, disjoint, sets that has helped me understand why the Haskell types (which are sets) to represent them also need to be distinct. i.e. they're distinct only in a programming context (or in my own head), but they still are mathematically the same thing.
Agreed, and I also mention this is the post that was my first, but ultimately flawed, realization. I can see that this line of thinking is not mathematically justifiable. However, for me this line of reasoning points out that the nature of the infinity that we're dealing with when dealing with real numbers is different from the more comprehensible infinity that we deal with when we deal with integers. Calling both of them infinity is maybe a mistake too, there is something more monstrous about the infinity of real numbers. And now I'm a bit more apprehensive when drawing conclusions, both for or against integers == or != real, using these lines of thought. So the selection argument is not my primary premise, it is just something that lead me to see how integers and reals behave differently.
I agreed with this paragraph, I never said otherwise. The issues of floating point representation vs the underlying numbers (real or integral) is a different concern, not related to the my main concern: are integers real (sic). Though interestingly, we can create bigint types that can be arbitrary precision representations of integers, but we don't have types that can provide arbitrary precision representation of reals. So coming back to the core issue. I have actually trouble formulating what is the core issue:
For (1), I think your line of thought (Every integer is a rational number, and every rational number is a real number.) is correct. In the reddit comments also, some people pointed out that we can construct homomorphisms from the ZF sets that represent 1 (the integer) to ZF sets that represent 1.0 (the real) and so mathematically, these are equivalent. So this isn't the sticking point. For (2), the arguments for (1) can be just extended to show that all ZF sets that represent an arbitrary integer i are homomorphic to an set in the set of reals. And thus, integers can be thought of as a subset of reals. I sort of agree with this. The line of reasoning is correct. What I'm having trouble with is that I think it fails to capture the infinity that hides behind each real number. A real number is an potentiality, not a thing. There is a thing called 𝜋, but I think it is not a thing, it is an asymptotic perfection that cannot be reached. On the other hand, 22 is a perfectly reachable thing. So maybe the issue is just (3) - I'm maybe mixing mathematics and philosophy, and mixing them in ways that I don't fully understand. BTW, I put a disclaimer in the article ("I’m sure I still have some, maybe all, of the technicalities wrong."), but if you feel the article is coming off as misleading, let me know, I'll put in a stronger disclaimer. Thanks for commenting, really. I feel these are fascinating topics, numbers. And by having such conversations I get to improve my understanding of them. |
I don't want to imply that what I have thought of is an absolutely certain and correct conclusion. See #2
Just to be on the safer side, so as to not even unintentionally mislead, I've gone ahead and added a stronger disclaimer to the post - e01acd7 |
Yes, this is the interesting difference. While integers are a subset of the real numbers, the integers are countably infinite, meaning that a one-to-one mapping can be established between the natural numbers and the integers (0, -1, 1, -2, 2, -3, 3, ...), while the real numbers are uncountably infinite. Rational numbers, interestingly, are countably infinite like the integers (via diagonalization) despite being densely ordered (between any two distinct rational numbers there exists at least one other rational number—their average—and thus an infinite set of rational numbers).
I think I would have to disagree with you there. The irrational, transcendental number number π is one of the more "real" numbers to exist. As the ratio between the circumference of a circle and its diameter it appears everywhere in nature. On the other hand, when it comes to measurements 22 inches and 7π inches are equally approximations, limited by the precision of our tools. Even in simple counting there is always some uncertainty. Objects move around, their classification as members of the set may be questioned, and even their existence may be in question to a degree. For example while counting electrons in a given space an electron-positron pair may come into existence briefly from the quantum vacuum, meaning that over any given time period the average count may not be exactly 22, or even an integer. Improved measuring technique—faster samples, better signal-to-noise ratio—can reduce the uncertainty, but in a sense we only get an exact answer like "22" by ignoring these minor variations and rounding to the nearest integer.
We can have types that provide arbitrary precision representations of some kinds of irrational reals. For example, we can trivially define a type Unfortunately the irrational and transcendental numbers are mostly defined by what they aren't (not rational, not algebraic) which does not readily lead to a common standardized representation distinct from their individual derivations, and the encodings which are available are not necessarily suited for common arithmetic operations like addition, subtraction, or multiplication. In general it's easier to work with approximations such as floating point. Thanks for pointing out the r/haskell post. There were some good comments there. I found your article via Planet Haskell rather than Reddit, and as there was no obvious way to respond on the page itself I followed the GitHub link and ended up here. |
There is a lot in your comment that's new to me. To bits in particular:
While I'm still not convinced that ints are a subset of real - but I now think it has more to do with how the elements of ints behaves as a set (vs how the elements of real behave as a set) than the individual numbers themselves. As in, maybe 1 and 1.0 are the same number, but they are different things if we consider them in the context of the set (integer or real) that we're talking about. Your comment had many things for me to think more of, and maybe dwelling more on them will help me elucidate my argument (or understand for myself why it is wrong), so thanks! Also, that continued fraction of 𝜋 you linked to is beautiful, as if it is a work of art (and maybe indeed it is). The way 292 makes a sudden appearance there is, haha, something. |
In
mrmr.io/pages/num/index.mdx
Line 148 in 47f06c5
Floating point numbers are an extended subset of the rational numbers (they cannot represent non-rational real numbers) with power-of-two denominators within a fixed range, augmented with negative zero, positive and negative infinity, and various forms of NaN. Because they are a subset many operations on rational numbers can only give approximate results, but double-precision floating point math can at least give exact answers for addition, subtraction, and multiplication of all 32-bit integer operands for which the corresponding integer operation would not overflow as the significand is more than 32 bits. This is how Lua and JavaScript can get by with using only floating point numbers. (The same does not hold for 64 bit integers, however.)
The text was updated successfully, but these errors were encountered: