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

571–580 of 593 posts

Re: 1/0 = 0

#571

Post by jle »

godelski wrote: post #520
gjulianm wrote: post #486

Earlier quoted context omitted.

The usual definition of division is the multiplicative inverse, yes. But that does not mean that, as an intellectual curiosity (which is how I take this post) you can't define "division" as having other value. Sometimes that's useful, sometimes it's not. Most of the time it is fun to see how things break and don't break. For example, the infamous 1+2+3+... = -1/12 sum[1]: for most purposes it's a divergent sum but yo…

The OP says > The field definition does not include division, nor do our definitions of addition or multiplication. This is clearly a misunderstanding of not realizing that the definition of division is a symbolic shorthand for inverse multiplication. Sure, you're right that we can define it another way. But I don't know what we would call an object with three operators. (Someone more knowledgeable in field theory pl…

That's not necessarily the definition of division, there are many commonly used definitions in different contracts that are different.

Re: 1/0 = 0

#572

Post by pron »

blablablerg wrote: post #569
pron wrote: post #568

Earlier quoted context omitted.

> Look at for example the set of real numbers. If you add the complex numbers to it, you can no longer speak of the real numbers. What does this have to do with adding axioms? You don't get the complex numbers from the real numbers by adding axioms. For example, the following is provable for the reals, but not for complex numbers: ∀x,y . x y ∨ x = y > You create something which has mayber has a field as a subset, but…

>What does this have to do with adding axioms? You don't get the complex numbers from the real numbers by adding axioms. For example, the following is provable for the reals, but not for complex numbers: > ∀x,y . x y ∨ x = y Since R is a subset of C, you can write C as R with additional axioms. See for example: http://www.math.mcgill.ca/gantumur/math249w15/numbers.pdf >I'm not looking for handwaving. Formal mathemati…

> Since R is a subset of C, you can write C as R with additional axioms.

That's not even remotely how it works. You may want to read up on logical theories and models[1].

> Well in language, in which I am corresponding with you, there is such a thing as 'makes no sense'.

Yes, and for the same reason we can have such a thing as "undefined" (that means more than merely 'not specified') in informal mathematics -- because both English and informal math are informal. But we are talking about formal languages[2], which do not have such a thing.

[1]: https://en.wikipedia.org/wiki/Theory_(mathematical_logic), https://en.wikipedia.org/wiki/Structure_(mathematical_logic)

[2]: https://en.wikipedia.org/wiki/Formal_system

Re: 1/0 = 0

#573

Post by ivanech »

spooneybarger wrote: post #325
ivanech wrote: post #45

I'm not seeing how the tweet is mocking the Pony developers. It seems to mirror the tone and the content of of the documentation in the screenshot. It looks like an absurdist spin on the ivory tower vs industry meme, and it doesn't make anyone the butt of the joke.

The screenshot in question cut off the explaination of why. I'm one of the Pony developers and I took it to be mocking.

Thanks for replying! I took a look at the thread in question and you're totally right. In context, this is unambiguously snide. I've been fortunate that my learning and working environments have been absolutely free of this kind of mean-spirited nonsense, so it really took me by surprise.

Re: 1/0 = 0

#574

Post by Retra »

NickNameNick wrote: post #334
kazinator wrote: post #159

Earlier quoted context omitted.

It is not valid to extrapolate an average of 0 from no data at all. For example, if we examine a sample of zero elephants, then we end up estimating the average elephantine mass as being zero. This shows to be wildly off as soon as we upgrade our statistical wherewithal to work with a sample size of one. A center of mass is a kind of average. If we have an empty object made of no particles of matter at all, can we ar…

This is probably beside the point, but shouldn't the center-of-mass of a massless object be everywhere simultaneously? With no reason to prefer any location, over any other?

The center of mass of a massless object makes as much as "everywhere" being a location of anything.

Re: 1/0 = 0

#575

Post by boomlinde »

WalterBright wrote: post #375
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…

I can't say that I'm firmly in either camp.

What seems much more important to me is that the behavior is well documented. If I am working with a system where 1 / 0 is defined to be zero, I will deal with that just as I deal with other peculiarities like 1 / 3 being 0 and 1.0 / 3.0 only approximately being a third in some systems. It's a practical concern like many others in programming.

Re: 1/0 = 0

#577

Post by karmakaze »

WalterBright wrote: post #555
karmakaze wrote: post #546

Earlier quoted context omitted.

To say that either (1) or (2) is always the right choice is unreasonable. It depends on context. If a program is running under a supervisor, it makes sense to bail, as a new clean instance will become available. If it was the code of the life support machine that displays data on the LEDs that I was connected to, I prefer that it solder on rather than stop functioning altogether because data for one of the digits was…

Aircraft and spacecraft all have backup systems for critical software. When software self detects a bug (such as an assert failure) the offending computer is shut down and electrically isolated, and the backup is engaged. What is absolutely NOT done is soldiering on with a computer in an unknown state. Any software system that is life critical is either designed this way or is very badly engineered. I've written a co…

And what if the program is the lowest level and getting into an impossible state due to a hardware issue (bad bit). At some level a program has to soldier-on.

Re: 1/0 = 0

#578

Post by dllthomas »

c3534l wrote: post #145

Edit: I guess there's a reason I'm not a language designer. I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible w…

The complaints from tikhonj about verbosity are on point, but I think you're right about the shape of it. Other things being equal, it's much better to enable the type system to help you move checks further upstream.

Re: 1/0 = 0

#579

Post by dllthomas »

throwaway080383 wrote: post #150
c3534l wrote: post #145

Edit: I guess there's a reason I'm not a language designer. I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible w…

You still have runtime issues if you're doing arithmetic with that type and end up getting zero.

Only if arithmetic operators have to return the same type they operate on.

Re: 1/0 = 0

#580

Post by dllthomas »

mywittyname wrote: post #169
c3534l wrote: post #145

Edit: I guess there's a reason I'm not a language designer. I've always thought that programming languages should have a nonzero number class in the vein of unsigned and float and that division should only be defined with a nonzero number class as the denominator. To divide a 64-bit float by another float, you'd have to either specify it as nonzero in the type or convert it somehow. Make division by zero impossible w…

I don't think this really solves the problem. It just kicks the same problem over to addition instead. let a = 17 let b = 10 let c = 7 let d = a - (b + c) // throws AddsToZeroException > Make division by zero impossible with the type-checker. Forcing programmers to consider division by zero when it occurs can be done simply by having the language compiler force handling of a divide by zero exception when division occ…

> Forcing programmers to consider division by zero when it occurs can be done simply by having the language compiler force handling of a divide by zero exception when division occurs.

That's materially different than a non-zero type, and IMO it's meaningfully worse. The type checker is most useful when it moves information.

Post reply on HN