The correct answer is not making the computer guess what you mean. That's the root problem here. You're being super-sloppy about specifying what actual operations you want to take place. What are the types of the operands? What are the semantics of the arithmetic operators for the pairs of operand types you get?
Without bothering to tell the computer what you want for the types or select the correct operators for the types you provided, you're falling back on guessing. Not every language guesses the same way, because not every language designer has the same guess what people meant.
My ideal is a language that tells you that expression is bad and to actually clarify what you mean. But a lot of people seem to hate having to explicitly communicate their intent.
Who even programs like this? If I saw that expression in code I think I’d have a fit.
I love Ruby for lots of things, and even with its duck typing system I’d never see someone plop down stuff like that. Ruby’s got quo, fdiv, divmod etc for good reason!
So is this contrived, or do people encounter programmers who do this stuff on a regular basis (not newbies, like experienced people… this feels like programming 101 to me)
I love Ruby too, but "/" giving integer results when both sides of the expression is integer is a frequent source of error, and I'm not convinced it's a good choice - in my experience at least it is rarely (though sometimes) what people want.
IEEE 754 doesn't really have anything to say about which semantics you should choose for int/int division. If you choose the semantics of casting both operands to floating point and then dividing, IEEE 754 specifies both 1) how the int->float conversion should happen, and 2) how the float/float division should happen. But if you choose the semantics that int/int division returns an int without any floating-point conversions (like C's '/' operator), then no floating point numbers enter into the question at all, and it's out of scope for IEEE 754.
Not everybody, but probably enough people. Actually you could even build your career around it. Some guy got into office at night time to fire estinguish the problem his buggy code created. Got appraisal from management for such extra effort. Everybody else's not so buggy code didn't get that appraisal...
There is no correct answer. There is no correct answer. The various ways different languages handle implicit type conversion with division and modulo operations are all both correct and incorrect at the same time. It's really an arbitrary choice. In fact, there are more choices than presented above. I think, for example, Perl6, uses rational numbers in some of the above situations.
Well, ideally you'd want to treat int/int -> rational. The original form is quite obfuscated, some of the parentheses are to enforce evaluation of the given string as number (and the various programming languages will differ as what number that'll be, due to representation of decimal fractions and type conversion), some parenthesis are plainly superfluous, yet still there is remaining ambiguity (how is a%b/c to be interpreted? Most programming languages will do this left->right, but better make that explicit). Prefix notation to the rescue:
Common Lisp (with *read-default-float-format* -> SINGLE-FLOAT)
