If you are going to use floating point numbers in any programming language, Pharo included, you need to understand something about them. Things like - the relevant precision is *fixed*; a Float in Pharo is *always* a 64-bit IEEE floating-point number, which amongst other things means (to a first approximation) 54 binary digits of precision. It doesn't make the slightest amount of difference how many decimal digits you use when writing the number, the precision is *always* 54 binary digits. So you *did* get the precision out of rounding that you put in, it's just that the precision you put in was not what you thought it was. - almost all modern architectures offer BINARY arithmetic, not decimal. (The main exceptions are IBM z/series and IBM POWER, which offer binary *and* decimal.) Rounding a number to n decimals is ALWAYS problematic using binary floats. This has little or nothing to do with Smalltalk: it's the hardware. (This is why you are advised to keep money in cents, not dollars.) - Again, this is NOT a language issue, it is a hardware issue. IF you understand how binary floating point arithmetic works, then the arithmetic you get in C or R or Smalltalk or Matlab does not surprise you at all. If you DON'T understand how binary floating point arithmetic works, the hardware will *get* you sooner or later. - ScaledDecimal in Pharo didn't have to violate the principle of least surprise, but it does, big time. - It would be really nice if Pharo offered true decimal arithmetic as an option. There may already be a package for this.
On Tue, 8 Sep 2020 at 15:46, Esteban Maringolo <emaring...@gmail.com> wrote: > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <rao...@gmail.com> wrote: > > > > "7.1 roundTo: 0.1 should return 7.1" > > You're still not getting it. > > I was until Konrad explained it. > > > Binary floating point CANNOT represent either of those numbers. > > You seem to be assuming that Pharo is making some mistake. > > It isn't. All it is doing is refusing to lie to you. > <snip> > > The systems that print 7.1 are LYING to you, > > and Pharo is not. > > I'm not assuming a mistake from Pharo, I had a wrong expectation what > to get if I round to that precision. > I don't know whether other systems lie or simply fulfill user > expectations, if you send the #roundTo: to a float, I did expect to > get a number with the same precision. > That is my expectation as a user. As in the other thread I expected > two scaled decimals that are printed equal to also be compared as > equal (which they don't). > > Whether there is a good reason for those behaviors is beyond my > current comprehension, but it certainly doesn't follow the "principle > of least surprise". > > In any case, the method proposed by Tomohiro solved my issues. > > Regards, > > Esteban A. Maringolo > >
