4 ms·

This is solely due to differences in the / and % operators: # int/int -> int POSTGRESQL = 8291561284461.33301440 SQUILU = 8291561284461.3 JAVA = 8.2915

This is solely due to differences in the / and % operators: # int/int -> int POSTGRESQL = 8291561284461.33301440 SQUILU = 8291561284461.3 JAVA = 8.291561284461331E12 D = 8.29156e+12 # int/int -> float LUA = 11665910614443 PYTHON3 = 11665910614443.387 # int/int -> float, UNIQUE: pos%neg -> neg JAVSCRIPT = 8036090802426.098 MYSQL = 8036090802312.071 # single-precision FLOAT # int/int -> int, UNIQUE: negint/posint -> negint (the floor) PYTHON2 = 1.1107636287e+13 RUBY = 11107636286950.146 # int/int -> int, UNIQUE: negfloat%posint -> negint (the ceil) SQLITE = 8290383058308.3 # int/int -> float, UNIQUE: negfloat%posint -> negint (the ceil) PHP = 8035491468054

begueradj 5y ago
interesting note
specialist 5y ago
Interesting. What's the correct answer? Which programming languages specify which parts of IEEE 754 they follow (or not)? https://en.wikipedia.org/wiki/IEEE_754 https://en.wikipedia.org/wiki/IEEE_754 Ditto rendering of floating point numbers. Here's a prior thread about Steele & White, Grisu, Ryu: "Here be dragons: advances in problems you didn’t even know you had" https://news.ycombinator.com/item?id=24917659 https://news.ycombinator.com/item?id=24917659
- mjn 5y ago
  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.
  - _moof 5y ago
    Over thirty years of programming I've slowly become convinced that implicit conversions are the devil.
    - andi999 5y ago
      This devil allows high productivity though.
      - andybak 5y ago
        Must be down to all those idle hands he can bring to bear on a given task.
      - jl6 5y ago
        Bingo. When performance is the overriding goal, it is often a matter of choosing which deals to do with which devils.
      - tialaramex 5y ago
        Not everybody is convinced that it's "more productive" to produce more bugs.
        BiteCode_dev 5y ago
        Pareto, context and objectives are importort factors in that decision. Coding a 5 lines bash script in rust brings safety but it's not a win.
        dgellow 5y ago
        If the bash script had an incorrect value due to an implicit conversion, then yes, the rust implementation is clearly a win.
        BiteCode_dev 5y ago
        So, context.
- deleted 5y ago
  [deleted]
- chowells 5y ago
  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.
  - crazydoggers 5y ago
    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)
    - vidarh 5y ago
      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.
      - meowface 5y ago
        This is why Python 3 changed division to return floats rather than ints. ("//" retains the old floor division behavior.)
  - dirkt 5y ago
    > My ideal is a language that tells you that expression is bad and to actually clarify what you mean. And there are existing language that do that.
- guenthert 5y ago
  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) CL-USER> (+ (* (+ (* 788 8.46) (1- (* 8342 1.803))) 4186.4 15 (+ (* (/ (mod 22 284) (/ 7530 (* 2 (- 25 421) (mod 597 2663))))) 7283.8 -9.60 (mod 167.8644 3))) 8871) 8.03609e12 Wolfram Alpha finds for (((((((788)*(8.46))))+8342*1.803-1))*4186.4*(15))*(((mod [22, 284]/((7530/((2)*(((((25))-421))))))*mod[597, 2663])+7283.8-9.60+mod[167.8644, ((3))]))+(8871) 8.03609080242609957376254980079681274900398406374501992031872*10^12
- rmah 5y ago
  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.
  - lizmat 5y ago
    Indeed. But please note Perl 6 has been renamed to the Raku Programming Language (https://raku.org https://raku.org #rakulang).
- kazinator 5y ago
  They are possibly all correct. Correct means that the requirements of a documented specification are being followed.

begueradj 5y ago

interesting note

specialist 5y ago

Interesting. What's the correct answer? Which programming languages specify which parts of IEEE 754 they follow (or not)? https://en.wikipedia.org/wiki/IEEE_754 https://en.wikipedia.org/wiki/IEEE_754 Ditto rendering of floating point numbers. Here's a prior thread about Steele & White, Grisu, Ryu: "Here be dragons: advances in problems you didn’t even know you had" https://news.ycombinator.com/item?id=24917659 https://news.ycombinator.com/item?id=24917659

mjn 5y ago
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.
- _moof 5y ago
  Over thirty years of programming I've slowly become convinced that implicit conversions are the devil.
  - andi999 5y ago
    This devil allows high productivity though.
    - andybak 5y ago
      Must be down to all those idle hands he can bring to bear on a given task.
    - jl6 5y ago
      Bingo. When performance is the overriding goal, it is often a matter of choosing which deals to do with which devils.
    - tialaramex 5y ago
      Not everybody is convinced that it's "more productive" to produce more bugs.
      - BiteCode_dev 5y ago
        Pareto, context and objectives are importort factors in that decision. Coding a 5 lines bash script in rust brings safety but it's not a win.
        dgellow 5y ago
        If the bash script had an incorrect value due to an implicit conversion, then yes, the rust implementation is clearly a win.
        BiteCode_dev 5y ago
        So, context.
deleted 5y ago
[deleted]
chowells 5y ago
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.
- crazydoggers 5y ago
  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)
  - vidarh 5y ago
    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.
    - meowface 5y ago
      This is why Python 3 changed division to return floats rather than ints. ("//" retains the old floor division behavior.)
- dirkt 5y ago
  > My ideal is a language that tells you that expression is bad and to actually clarify what you mean. And there are existing language that do that.
guenthert 5y ago
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) CL-USER> (+ (* (+ (* 788 8.46) (1- (* 8342 1.803))) 4186.4 15 (+ (* (/ (mod 22 284) (/ 7530 (* 2 (- 25 421) (mod 597 2663))))) 7283.8 -9.60 (mod 167.8644 3))) 8871) 8.03609e12 Wolfram Alpha finds for (((((((788)*(8.46))))+8342*1.803-1))*4186.4*(15))*(((mod [22, 284]/((7530/((2)*(((((25))-421))))))*mod[597, 2663])+7283.8-9.60+mod[167.8644, ((3))]))+(8871) 8.03609080242609957376254980079681274900398406374501992031872*10^12
rmah 5y ago
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.
- lizmat 5y ago
  Indeed. But please note Perl 6 has been renamed to the Raku Programming Language (https://raku.org https://raku.org #rakulang).
kazinator 5y ago
They are possibly all correct. Correct means that the requirements of a documented specification are being followed.