121–130 of 158 posts
Earlier quoted context omitted.
If NaN is nonsense, what would you have 1/0 or acos(2) to produce? (An exception is the same NaN, only less convenientlying packaged.)
you throw an error and stop the calculation, and let the programmer decide what to do.
Honestly, I think IEEE 754 floating point numbers are a pretty bad way of dealing with real numbers and just cause tons of headaches that every math library has to deal with. Even high level programmers aren't shielded from the NaN nonsense. It would be great if we had an underlying implementation we could ignore and that allowed us to think at a more mathematical level. I actually found something recently on this to…
If NaN is nonsense, what would you have 1/0 or acos(2) to produce? (An exception is the same NaN, only less convenientlying packaged.)
NaNs should not be scary.
Honestly, I think IEEE 754 floating point numbers are a pretty bad way of dealing with real numbers and just cause tons of headaches that every math library has to deal with. Even high level programmers aren't shielded from the NaN nonsense. It would be great if we had an underlying implementation we could ignore and that allowed us to think at a more mathematical level. I actually found something recently on this to…
If NaN is nonsense, what would you have 1/0 or acos(2) to produce? (An exception is the same NaN, only less convenientlying packaged.)
Earlier quoted context omitted.
you throw an error and stop the calculation, and let the programmer decide what to do.
"Throw an error" makes no sense at the hardware level. That's like saying a NIC should "throw an error" when it loses link. It's up to languages and libraries to turn signals/registers/flags into higher-level concepts like structured exceptions.
My contention is that all NaN-resulting operations (Inf * 0, sqrt(-), e.g.) should halt the program instead of propagating a silent, dud value. When you reach them, it means usually there is something wrong with your algorithm (or less commonly, your data) and it is better to know that sooner than later.
The correct answer is 1,065,353,216. This is easy to work out yourself if you remember one basic, handy property of floats: adjacent floats are adjacent in bit representation, except -0.0f and 0.0f. For example, 0x00000000 is +0.0f. 0x00000001 is the smallest non-zero positive float. 0x00000002 is the second smallest. The only exception to this is -0.0f and +0.0f, which are 0x80000000 and 0x00000000. The rule works w…
The correct answer is 1,065,353,217. You have an off-by-one error in the following line of argument: > The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800000 This should be corrected to: > The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800001 In general, the number of numbers in the closed integral interval [a, b] is not b-a, but 1+b-a. For example, the closed interval […
Source: brute force counting in a small C program.
Naturally, this might not scale to 64-bits, unless you have lots of time and computing power to spare.
Ummm... maybe I am mistaken, but as the fp numbers are not uniform in [0,1] chances are I don't want to pick one at random. Rather I want to pick a fp representation of a random real between 0 and 1. In that case the readers suggested strategy seems fine. Am I wrong?
The author says in a comment > If hitting exactly zero is much less probable than hitting exactly 0.5, then I would argue that you do not have a uniform distribution… But due to the non-uniformity of floating point numbers, I think the author is wrong here. We can think of each floating point number as an interval. The probability that it is picked should ideally be equal to the size of the interval.
Earlier quoted context omitted.
The correct answer is 1,065,353,217. You have an off-by-one error in the following line of argument: > The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800000 This should be corrected to: > The number of values between the two is 0x3f800000 - 0x00000000 == 0x3f800001 In general, the number of numbers in the closed integral interval [a, b] is not b-a, but 1+b-a. For example, the closed interval […
I was under the impression (after several thousand attempts) that the correct answer is infinity, limited only by your addressable memory and bitspace.
Earlier quoted context omitted.
I'm not very familiar with refinement types. How would that work? For example, how would you write a function that answers the mean value of an array of numbers? You could define Array.Length to be of type NonNegativeInteger, but that still includes 0. Alternatively, you'd have to define a NonEmptyArray type that excludes arrays of length 0, but that seems less than useful.
> Alternatively, you'd have to define a NonEmptyArray type that excludes arrays of length 0, but that seems less than useful. I think the usefulness of a specific NonEmptyArray type is controversial, and I would say such types could be extremely useful. AFAIK there have been discussions if Haskell's Prelude (part of the standard library providing a name space for convenient functions and types, similar to the functio…
There is a pretty big assumption baked into the title.
Edit: hi, I see that I made a mistake, can someone correct my misunderstanding?
I can't believe I'm the only person to ask "what bit depth?" There is a pretty big assumption baked into the title. Edit: hi, I see that I made a mistake, can someone correct my misunderstanding?