The problem is that if you try to teach the average college freshman/sophomore that there are two different real number systems and even though we use one 99% of the time we occasionally want to use the other, they’re going to end up extremely confused. So we keep it simple in the introductory math classes, and bring in the details for the people who ask for them by taking higher math classes.
I’ve not heard of that one, but it sounds to me more like it might be an unhandled condition in the programming - it can happen quite easily, for example, consider this (purposely badly written) program in BASIC:
Rem **Giraffe-O-Meter**
Print "Enter the height in feet"
Input A
If A>15 then B$ = "a giraffe"
if A<15 then B$ = "probably not a giraffe"
Print "The animal being measured is "; B$
-In this program, if you enter exactly 15, you’re told “The animal being measured is” - which is a nice little bit of existentialism, but not the kind of answer you were expecting.
A better way to handle this would be to use a Case statement, which catches all possible fallthrough conditions with ‘case else’ at the end, but not everybody does that and I’ve seen real-world examples of unhandled conditions in various bits of software (including the job I inherited to work on now).
Real world story. I once had to work on a project with a particularly sloppy programmer. Never validated anything. Never anticipated any sort of strangeness. And to be fair, this was partly because he was from a world of DOS based tools that pretty much hogtied a user into compliance with a step-by-step away of doing things. Of course, Windows changed all that, and I tried to explain to him that users could now click anywhere and enter anything in any order. You couldn’t take anything for granted, which brings us to the point.
He wrote a Select Case statement that dealt with the possibilities he had in mind, but did not address weirder things. Like entering “My cat sucks” for the employee’s department field. He said I was paranoid and silly, but I stuck to my guns and insisted that at the very least we insert a Case Else, which he derisively made to put up a message box saying, “How the hell did this happen? This is impossible.”
You guessed it…
Lo and behold, we got a call shortly after release from a client saying that her computer was asking her how the hell this could have happened, and wanting to know how to proceed from there.
I imagine it’s just the result of the IEEE floating-point standard including the values of positive and negative infinity and specifying that division by (positive) zero work in the way reported.
The calculator designers were probably alright with this and didn’t see any great need to put in an exception-handler to print out a special message instead.
So what happens if you try to just postulate that there is something (not necessarily a number, let’s designate it # ) that’s defined as # x 0 = 1. This approach worked for the base of imaginary numbers: i x i = -1. So 1 / 0 = #, 2 / 0 = 2#, etc.- and follow the logic from there? Or perhaps in broader terms, the function that transforms the additive identity into the multiplicative identity?
(BTW: I’m certain this would have already been tried if it worked, but what does happen?)
It’s possible to define a consistent mathematical system like that, but it’s not a very interesting system and you lose a lot of nice properties that normal mathematics have(for instance, if xy = xz you can’t conclude that y = z).
As was mentioned above, you have to abandon some cherished principle. Consider: 1 = # * 0 = # * (0 * 2) = (# * 0) * 2 = 1 * 2 = 2. Presumably, you don’t want to let this go through, so what principle are you going to abandon? There isn’t really any nice way to do it. You’ll have to get rid of either associativity, the fact that 0 * 2 = 0, the fact that 1 * 2 = 2, or the fact that 1 is unequal to 2. The last three are really compelling to keep…