101–110 of 125 posts
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.
https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp...
The following values were inspected: 1 2 4 8 16 32 64 32 48 40 44 42 43 The most surprising part for me is that in the integer search 32 is inspected twice. From my brief testing it seems to only happen with infinite ranges. Is that a bug in bsearch or am I missing something?
With a finite range, you can bisect directly by splitting in the middle of the range. With infinite ranges, you can't do that; so the usual way is to start with a small number and increase exponentially until you find a number that is too large; which is what is done here. When you got that number, it becomes the upper bound of a finite interval. So that's a two step process, which we can see here. The first 32 is in…
In fact, if you're checking N, it's guaranteed that N/2 has already been checked, and the next best step should be (3/4)N; in this case 48.
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.
Not true. You actually can. Aliasing is about viewing the same bits as two different types (what `reinterpret_cast`, union-based type punning, and cast pointers do) `memcpy` copies the bits to a new location which doesn’t violate aliasing. I don’t have time to find the reference in the standard, but cppreference.com[0] says it’s ok: > Where strict aliasing prohibits examining the same memory as values of two differen…
I don't see any such a claim about memcpy having magic powers in the N4659 C++ draft.
All it says is that the underlying bytes of an object can be copied to an array of char, unsigned char, or std::byte. Then if that array is copied back into the object, the object subsequently holds its original value.
Anything more about memcpy comes from C by reference, and that would be about the last document on Earth to grant definedness and portability to something like this.
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
It's also the midpoint of the positive rationals, as modeled by the Stern-Brocot tree. https://www.cut-the-knot.org/blue/Stern.shtml
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.
memcpy() by itself cannot violate aliasing rules. By definition, char can alias any object. Whether you can access an object that has been memcpy()'d into is a separate question. I can't find specific language about this, but I strongly suspect that the result is implementation-defined or unspecified (not undefined), unless there is a possibility of a trap representation.
Earlier quoted context omitted.
It's also the midpoint of the positive rationals, as modeled by the Stern-Brocot tree. https://www.cut-the-knot.org/blue/Stern.shtml
Perhaps I'm confused, but doesn't that site indicate that the midpoint of the positive rationals is 1.0? Or am I misreading it?
Earlier quoted context omitted.
From Python: >>> import numpy as np >>> 1 + np.Inf inf >>> (0 + np.Inf)/2 inf >>> Infinity is not a number it is a concept[1] My math teacher used to say think of infinity like a impossibly large number. An impossibly large number divided by two is still an impossibly large number [1] http://mathforum.org/dr.math/faq/faq.large.numbers.html
While you’re correct, you’re being downvoted probably because you’re taking this seriously. I’m sure most everyone here knows infinity isn’t a number, but a concept, but you never know.
This is why participating on Hacker News conversations are problematic. I think you are talking about downvoting because a persons misunderstands me. Even in your statement you imply by saying "but you never know" that it is possible people aren't being aware of the point I was making
Earlier quoted context omitted.
From Python: >>> import numpy as np >>> 1 + np.Inf inf >>> (0 + np.Inf)/2 inf >>> Infinity is not a number it is a concept[1] My math teacher used to say think of infinity like a impossibly large number. An impossibly large number divided by two is still an impossibly large number [1] http://mathforum.org/dr.math/faq/faq.large.numbers.html
I'm not talking about math. I'm talking about computer numbers, specifically IEEE-754. NaN is represented by a maximal (all ones) exponent, and at least one non-zero in the mantissa. Infinity has the same exponent but an all-zero mantissa. So with a naive comparison, NaN compares greater than infinity. If you only believe output from programming languages, javascript claims that the type of infinity is "number". >>>…
I was fully away of that stuff you say about how NaN is represented and was also aware of how Inf is represented. My statement and link to the concept of Infinity on mathforum was an effort to support the idea of why most math done with code involving Inf will also result in an answer of Inf.
The article that this whole discussion is about seems to think it is OK (ie not a bug) to convert a float like Inf to a integer do some math and convert back to a float and get 1.5 and that is OK. It seems like a bug to me.
Earlier quoted context omitted.
Perhaps I'm confused, but doesn't that site indicate that the midpoint of the positive rationals is 1.0? Or am I misreading it?
You are not misreading. That's correct.
Earlier quoted context omitted.
The lack of precision leads to increasing error over time in many contexts (off the top of my head, multiplication and division). I still think that if an algorithm can be rewritten to work with ints instead of floats, it will be served better the vast majority of the time.
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…