Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1/0 = 0

hillelwayne.com

Post reply on HN
Print view View original

371–380 of 593 posts

Re: 1/0 = 0

#371

Post by mirimir »

kenbellows wrote: post #362
mirimir wrote: post #356

As near as I can tell, he's just redefining what division means when the divisor is zero. That is, creating a special case. And yes, I get that it's a useful hack in programming. So anyway, IANAM. What I learned was that 1/0 is infinity. And in software, that generally means a divide-by-zero error. But I also learned the utility of making approximations and exploring behavior at limits. And 1/x obviously increases ex…

1/x as x -> 0 is a famously tricky expression because your statement that it "obviously increases exponentially as x approaches zero" is only true half the time, because it's only true if you approach zero from the positive side, with x being set to smaller and smaller positive values. If, on the other hand, you set x to negative values of smaller and smaller size, 1/x actually decreases toward -Infinity. This is one…

OK, sure. Either infinity or -infinity. But then just look at the absolute value of 1/x. And in any case, neither infinity nor -infinity look anything like zero.

Re: 1/0 = 0

#372

Post by behringer »

someone_is_here wrote: post #308
optimuspaul wrote: post #247

Earlier quoted context omitted.

If we assume that we got to 0 because of a rounding error we do know that it should be some positive integer. I think that 1/0 = infinity is a reasonable substitute for an actual value. 1/0 = 0 seems absurd. 1/(a number approaching 0) produces ever increasing integers. I don't know, does it even matter? What happens when you try to divide a physical object into 0 parts? It doesn't create infinite pieces. It doesn't m…

If you divide something 12 feet long into 3 parts, you don't get 4 parts, you get 3 parts that are each 4 feet long. So, if dividing a number by 0 yields infinity, you would expect that dividing something physical into 0 parts would yield 0 parts, each of infinite size, whatever that means. Sorry to be pedantic.

It's fine to be pedantic in math. You can't divide something 0 times, there's no solution for that. You can divide something by infinite times, but infinity is not 0. This might help explain things:

https://www.math.utah.edu/~pa/math/0by0.html

Re: 1/0 = 0

#373

Post by behringer »

spooneybarger wrote: post #234
behringer wrote: post #225

Earlier quoted context omitted.

1/0 is not infinity either...

but with floating point units, 1.0/0.0 is infinity.

That's not correct mathematically though. You can't divide something 0 times and get any number. Adding zero + zero + zero infinite times does not equal 1.

Re: 1/0 = 0

#374

Post by int0x80 »

cyphar wrote: post #346
bqe wrote: post #342

Earlier quoted context omitted.

This is valid C and C++.

It is, but it will always give you a divisor of 1 (because "true" is 1 -- I also thought it would work until I tested it): % cat >division.c int main(void) { printf("1/0 = %d\n", 1 / (0 || 1)); printf("1/2 = %d\n", 1 / (2 || 1)); printf("1.0/0 = %f\n", 1.0 / (0 || 1)); printf("1.0/2 = %f\n", 1.0 / (2 || 1)); } % gcc -Wall -o divison divison.c % ./divison 1/0 = 1 1/2 = 1 1.0/0 = 1.000000 1.0/2 = 1.000000 In Python thi…

What do you expect for that C code?

Re: 1/0 = 0

#375

Post by WalterBright »

whack wrote: post #72

My problem with "1/0 = 0" is that it's essentially masking what's almost always a bug in your program. If you have a program that's performing divide-by-zeroes, that's almost surely something you did not intend for. It's a corner case that you failed to anticipate and plan for. And because you didn't plan for it, whatever result you get for 1/0 is almost surely a result that you wouldn't want to have returned to the…

An issue with D that has repeatedly engendered heated debate is what should happen when a programming bug is detected at runtime. The two camps are:

1. The program should "soldier on" if it can.

2. The program should go immediately to jail, it must not pass Go, and must not collect $200.

I'm solidly in the latter camp. If a program has entered a state unanticipated by the programmer, then there is no way to know how it entered that state (until it is debugged), and hence no way to know what the program might do next (such as load malware).

1/0 is a bug, and the program should immediately halt.

Re: 1/0 = 0

#376

Post by mcguire »

rcoveson wrote: post #173
hyperpape wrote: post #68

This thread is showing once again that reading comprehension is not our strong-suit here on HN. The author does not once say that Pony's choice is a good one, only that whether it is a good or bad one should be settled by engineering consequences, and that there is no purely mathematical argument that precludes it. I can't help but think it _is_ a bad idea, because it's easier to overlook a 0 appearing than a NaN. Th…

The Pony devs did chime in and mentioned that they do define division by zero to be NaN (or positive infinity) where the underlying type supports it (e.g. IEEE 754 floats). Most integer representations have no space for such a value, so the only choices available to language developers are: 1. Throw an exception or otherwise consider it an error 2. Define the result to be 0 or 1 or some other integer value (0 being t…

Pony requires special handling of partial functions. Option 1 means all integer divisions by other than constants would be partial.

That seems sub-optimal.

Re: 1/0 = 0

#377

Post by BillBohan »

I had considered this as a possibility following much the same train of thought expressed by abakker but because it diverges from most common practice (and from mathematics) and because I was unsure whether anyone would actually want it, I had not really considered using it.

While reading the article and the comments I realized that it will work perfectly in my NISC processor [1]. I just need to update my specification.

To extend the simple first specification to include multiply is very simple. I just need to have a MUL register which, when written, multiplies the written value by the value in the accumulator with the low part of the result being left in the ACC and the high part in the MUL register.

Extending to include integer divide is a little more complicated. I will have to add a DIV register and a DIVEX register. Writing to DIV will divide the value in the ACC by the value written leaving the result in the ACC and the remainder in the DIV register. DIVEX will contain the address of the routine to call when division by zero is attempted which means that DIVEX must be loaded before division is used. If I specify that DIVEX is initialized to zero by the hardware and that DIVEX==0 means that divide by zero leaves zero in the ACC and the remainder (former contents of ACC) is left in the DIV register then 1/0 = 0 will be the default behavior with the ability to change that behavior simply by writing the address of the divide exception handler to the DIVEX register.

I leave it as an exercise for the reader to determine how to deal with this in high level languages. I can fully support it in machine code and assembly language.

[1] https://github.com/BillBohan/NISC

Re: 1/0 = 0

#379

Post by starmole »

spooneybarger wrote: post #171
thanatos_dem wrote: post #156

Earlier quoted context omitted.

> 2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value. Oh jeeze... to me that almost nullifies all of the points in the article. It does an alright job explaining how 1/0 = 0 is at least consistent with other notions in the language, but to hear that the same logic can’t be applied to floats is just... well, objectively it’s a mess.

Hillel is talking about math. Unfortunately computers don't really do "math". For example, math doesn't have overflow and underflow to deal with. The floating point standard says that division by 0.0 should be Infinity and provides a value for it. The integer math, all possible values are used for numbers, so division by zero is undefined behavior. And from there, every language is potentially going to have a mess of…

Integers are perfectly fine in math. But they are not a field. Integers modulo something are also well understood in math - but again not a field.

Re: 1/0 = 0

#380

Post by Zarel »

jshap70 wrote: post #205
spooneybarger wrote: post #191

Earlier quoted context omitted.

Here's another good one for you... What does your favorite programming language return for 3/2 as compared to 3.0/2.0? Many will return different values. EDIT: for clarity of my point: integer math that uses machine types is pretty surprising compared to what we would expect from "math" in general for division.

`3/2 = 1` is a consistent answer as long as the programmer understands modulo. The way you're phrasing it makes it sound like there are languages out there that say "`3/2 = 2` because 1.5 rounds up to 2". just so long as you don't expect a consistent answer between python2.7 and 3.x... >.>

The phrasing is relatively clear to me as saying that some languages say 3/2 = 1.5 (e.g. JavaScript) and some languages say 3/2 = 1 (e.g. C).
Post reply on HN