Hi Sven, On Sun, Sep 6, 2020 at 11:57 AM Sven Van Caekenberghe <s...@stfx.eu> wrote: > > On 6 Sep 2020, at 16:06, Esteban Maringolo <emaring...@gmail.com> wrote:
> > (9.1 + (-2.0)) roundTo: 0.1. > > "7.1000000000000005" > > Is this a bug? > > Maybe. > > But I would not approach the problem of rounding like that. > You probably want to control how numbers are printed. It is not for printing but for testing. I want to assert that a certain calculation gives the expected result. And then it fails because of the difference above when it is "semantically" correct. > I would keep the numbers themselves at maximum internal precision and only do > something when printing them. I do. I'm implementing the full WHS specification [1], and it mentions that most calculations should preserve the maximum internal precision and even introduces some weird situation where you have an "index" that is rounded and another one that is called the same way but must not be rounded because is going to used to compute some other value. For most calculations it specifies it must round to 1 decimal or even to no decimal, based on a round up if the decimal is greater or equal than zero (e.g. 1.5 becomes 2), except for negative numbers, in which case it rounds "down" (-1.5 becomes 1). > 1 / 3 asFloat printShowingDecimalPlaces: 1. > > Since you like Seaside, the following is even much more powerful (has *many* > options): > GRNumberPrinter new precision: 1; print: 1/3 asFloat. I'm already using the GRNumberPrinter and also the Date printer to print these values. Regards! [1] https://en.wikipedia.org/wiki/Handicap_(golf)#World_Handicap_System
