5 ms·

Oh really??? That would make sense, though it raises more questions with perhaps not so brief answers.

lmm 2y ago
3 / 2 = 1, 3.0 / 2 = 1.5. So 3.equals(3.0) is false, as this "equals" is meant to have programming semantics rather than mathematical ones.
- happytoexplain 2y ago
  It looks like you're comparing integer arithmetic and float arithmetic. Are you saying BigDecimal can represent both??
  - lmm 2y ago
    That's a special case of decimal precision. 1/3 = 0, 1.0/3=0.3, 1.00/3=0.33 is probably a better example. (where by 1.0 I mean a BigDecimal with precision=2 - in fact the default is 40)
    - happytoexplain 2y ago
      Oh, thanks, I think the phrase "programming semantics" threw me off, since I don't think of the precision behavior of ints and floats as "programming semantics", but rather "int and float semantics". In other words, it makes sense to me that integer 3/2 = 1 while float 3/2 = 1.5, because int can not represent 1.5, not because that's just how "programming" works. So, extrapolating from that logic, since BigDecimal can represent 1.5, I would expect 3/2 = 1.5 no matter how 3 and 2 are internally represented. However, what I think I'm coming to understand, is that the precision of a BigDecimal is intentionally a semantic part of the value (duh, that's what you've been saying). The only reason I can think of (as a math layman) for including the precision as a semantic part is that there are real world use cases for indicating precision and carrying it forward into results via rounding, like physical measurements. This is useful, but it also vexes me slightly because it means BigDecimal is not just for getting more precision than other numeric types, it is also for knowing/controlling the amount of precision, meaning there is no type dedicated only to the former. But I suppose the cases where you want more precision tend to also be the cases where you want to know/control the precision... It's just that this demonstrably doesn't occur to everybody using the API who might just be reaching for it because "I want more precision". I don't know how you would make it more obvious. Then again, I am essentially guessing.
      - lmm 2y ago
        > This is useful, but it also vexes me slightly because it means BigDecimal is not just for getting more precision than other numeric types, it is also for knowing/controlling the amount of precision, meaning there is no type dedicated only to the former. But I suppose the cases where you want more precision tend to also be the cases where you want to know/control the precision... It's just that this demonstrably doesn't occur to everybody using the API who might just be reaching for it because "I want more precision". In practice someone who just "wants more precision" doesn't touch the precision and gets 40 significant figures of it, which will probably do what they want. Exact rationals have their own problems, and if you're not using exact rationals then however much precision you've got you'll always have rounding (as soon as you divide by anything other than 2 or 5).
        deleted 2y ago
        [deleted]

lmm 2y ago

3 / 2 = 1, 3.0 / 2 = 1.5. So 3.equals(3.0) is false, as this "equals" is meant to have programming semantics rather than mathematical ones.

happytoexplain 2y ago
It looks like you're comparing integer arithmetic and float arithmetic. Are you saying BigDecimal can represent both??
- lmm 2y ago
  That's a special case of decimal precision. 1/3 = 0, 1.0/3=0.3, 1.00/3=0.33 is probably a better example. (where by 1.0 I mean a BigDecimal with precision=2 - in fact the default is 40)
  - happytoexplain 2y ago
    Oh, thanks, I think the phrase "programming semantics" threw me off, since I don't think of the precision behavior of ints and floats as "programming semantics", but rather "int and float semantics". In other words, it makes sense to me that integer 3/2 = 1 while float 3/2 = 1.5, because int can not represent 1.5, not because that's just how "programming" works. So, extrapolating from that logic, since BigDecimal can represent 1.5, I would expect 3/2 = 1.5 no matter how 3 and 2 are internally represented. However, what I think I'm coming to understand, is that the precision of a BigDecimal is intentionally a semantic part of the value (duh, that's what you've been saying). The only reason I can think of (as a math layman) for including the precision as a semantic part is that there are real world use cases for indicating precision and carrying it forward into results via rounding, like physical measurements. This is useful, but it also vexes me slightly because it means BigDecimal is not just for getting more precision than other numeric types, it is also for knowing/controlling the amount of precision, meaning there is no type dedicated only to the former. But I suppose the cases where you want more precision tend to also be the cases where you want to know/control the precision... It's just that this demonstrably doesn't occur to everybody using the API who might just be reaching for it because "I want more precision". I don't know how you would make it more obvious. Then again, I am essentially guessing.
    - lmm 2y ago
      > This is useful, but it also vexes me slightly because it means BigDecimal is not just for getting more precision than other numeric types, it is also for knowing/controlling the amount of precision, meaning there is no type dedicated only to the former. But I suppose the cases where you want more precision tend to also be the cases where you want to know/control the precision... It's just that this demonstrably doesn't occur to everybody using the API who might just be reaching for it because "I want more precision". In practice someone who just "wants more precision" doesn't touch the precision and gets 40 significant figures of it, which will probably do what they want. Exact rationals have their own problems, and if you're not using exact rationals then however much precision you've got you'll always have rounding (as soon as you divide by anything other than 2 or 5).
      - deleted 2y ago
        [deleted]