111–120 of 125 posts
Earlier quoted context omitted.
You are not misreading. That's correct.
But the article is saying that in Ruby, it's 1.5, right? So it's not the same as here? Or were you referring to the general notion of a midpoint of an infinite range?
> In surreal numbers [1], the midpoint between 0 and infinity would be the simplest number greater than 0, which is { 0 | } = 1
Earlier quoted context omitted.
Infinitesimals and infinities are nice if you're doing some sort of bucketing logic. tiny = infinitesimal huge = infinity N = number to be bucketed tiny bucket 1 10 bucket 2 ... X last bucket This removes edge cases you need to test for if you're trying to bucket positive values. This may not be something you've had to do, but I've had reason to want this before on a few occasions.
Infinitesimals do not exist in the standard real number system. 'tiny' seems to be more related to the smallest positive representable (normal or subnormal) IEEE 754 float/double type of value which is a real number.
As for how common they are, we learn about them in any introductory calculus course when defining derivatives. You come across the idea whenever discussing limits, if somewhat obliquely.
If I learned about it in high school math, and again in "real" math courses at my university, I'd say it's pretty standard.
Earlier quoted context omitted.
Rant: Technically , that code invokes undefined behavior as you use `reinterpret_cast` to alias variables. The only standards conforming way (prior to `std::bit_cast`[0] in C++20) was to use `memcpy`.[a] `reinterpret_cast` was added for situations where code you have no control over requires a certain type, but you need to force it to take your variable.[b] [a]: As `memcpy` (in addition to reinterpreting bits) copies…
memcpy certainly violates aliasing rules. You can access an object as an array of bytes, but you can't memcpy an object to one of a different type and then access it as that type without invoking undefined behavior.
Earlier quoted context omitted.
Multiplication and division of floats creates rounding errors of The operations you need to watch out for are addition/subtraction, in cases where your result has much smaller magnitude than your inputs, causing loss of significance. Sometimes great care must be taken in implementing numerical algorithms to avoid this. But this is an inherent problem in numerical computing, not the fault of the floating point format…
When does this problem crop up when only dealing with pure ints?
Earlier quoted context omitted.
But the article is saying that in Ruby, it's 1.5, right? So it's not the same as here? Or were you referring to the general notion of a midpoint of an infinite range?
Right again. The "also" is a reference to the parent comment. > In surreal numbers [1], the midpoint between 0 and infinity would be the simplest number greater than 0, which is { 0 | } = 1
Earlier quoted context omitted.
memcpy certainly violates aliasing rules. You can access an object as an array of bytes, but you can't memcpy an object to one of a different type and then access it as that type without invoking undefined behavior.
My reading of section 8.2.1 suggests that it is not UB to copy bytes from an object of one type to an object of another type, and then to read the value of the second object, since it is explicitly allowed to access each object as bytes.
Like every blog post or article that talks about something weird related to IEEE floats, this absolutely needs to find a way to link to "What Every Computer Scientist Should Know About Floating-Point Arithmetic", over on https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h... , because that's mandatory reading if you're programming.
Shorter and at a level the simple masses of programmers will likely work at - https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp...
Spend the time up from to understand the why, especially if you're the simple masses. If you're programming, it pays to properly learn how something that is integral to programming works and what you can therefore expect when you use it. Which will be all the time.
In surreal numbers [1], the midpoint between 0 and infinity would be the simplest number greater than 0, which is { 0 | } = 1 [1] https://en.wikipedia.org/wiki/Surreal_number
That's not right. 1 is different to half the sum of 0 and infinity. Another way to look at it is that infinity minus one is larger than one minus zero (which can be easily proven using the basic definitions used to define the surreals). Moreover, what is at the right side of {0|} is not infinity, but the empty set.
But { 0 | ω } = 1, right?
Earlier quoted context omitted.
Well, if you map the contents of the unit circle (|z| 1. So there really is no need to give unique names to anything beyond 1 as it's already contained in the proverbial nutshell of the unit circle via 1/z.
You don't even need the unit circle. The unit interval is enough, as is any set whose cardinality is aleph-1.
Earlier quoted context omitted.
Infinitesimals do not exist in the standard real number system. 'tiny' seems to be more related to the smallest positive representable (normal or subnormal) IEEE 754 float/double type of value which is a real number.
Infinitesimals tautologically exist in any finite representation of numbers. For floats, it's the smallest representable positive number. For integers of any type, it's 1. As for how common they are, we learn about them in any introductory calculus course when defining derivatives. You come across the idea whenever discussing limits, if somewhat obliquely. If I learned about it in high school math, and again in "real…
Also, you seem to be conflating "common" with "standard". "standard" is a mathematical term. Infinitesimal are handwavy in standard analysis (epsilon-delta are the rigorous alternative), but exist rigorously in nonstandard analysis.