Waldemar Horwat wrote: > Mike Cowlishaw wrote: >>> There is still a blocking issue that's been discussed a lot but left >>> off the issues here: >>> >>> - Treatment of cohorts in the default conversion of decimal to >>> string. Despite objections, I still get the following results: >>> >>> 1/3m - 1/3m produces 0e-34 >>> >>> 1e12m - 1e12m produces 0e+12 >>> >>> 1/.1m produces 1e+1 >> I'm still not clear what your objections are -- we can discuss on >> Thursday, but the intent here is that the toString conversion be >> reversible (i.e., from the string representation one can recreate the >> decimal128 from which it was derived). So I think you are really >> complaining about the rule for division (which is 'the best yet' that >> anyone has come up with, as it matches the rule for multiplication) and >> the rule for subtraction (which preserves the smaller exponent). Hence >> 1.23-1.22 -> 0.01 and 1.23-1.23 -> 0.00. The exponent is not >> data-dependent unless there is rounding. >> >> Mike > > No; I'm complaining about the bizarre results that toString produces > which are counter to its existing behavior. I don't care how many extra > zeroes division sticks at the end of the number because I should never > see them. This has been hashed out many times and also breaks things > such as arrays if left uncorrected.
Agreed. It's fine to have an operation that maps decimal128 values to strings reversibly, but '.toString()' should not be that operation. -- David-Sarah Hopwood _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
