Re: [lmi] Numerics

[Greg Chicares]

On 2016-05-09 17:16, Vadim Zeitlin wrote:
> On Mon, 9 May 2016 04:04:10 +0000 Greg Chicares <address@hidden> wrote:
> GC> On 2016-05-08 22:59, Vadim Zeitlin wrote:
[...]
> GC> A masked edit control makes sense for mixed-base systems, but aside from
> GC> calendar dates, who uses them any more?
> 
>  FWIW I did see them used for currency values. Admittedly, this is (much?)
> more rare than just having one field accepting values with the decimal
> point, but it does happen.

OTOH, in US life-insurance practice, I've never seen a masked edit control
for currency entry. And it's less likely to happen now than ever, because
end users' thinking is shaped by spreadsheets, so lmi is never going to
need it.

> GC> (you wouldn't give your height as two meters and five
> GC> centimeters--you'd say 2.05m, right?)
> 
>  No, unless I was feeling pretty boastful. But I would say 1 meter 94
> centimeters, normally.

Even google
  https://www.google.com/search?q=1.94+meters+to+feet
expresses that as 6.364829 decimal feet, not 6'4".

> GC> > GC> Can the "using" typedef and the "constexpr" things be made private?
> GC> > 
> GC> >  They could, but I think they should be public because it can be useful 
> to
> GC> > this class clients. The constants probably won't be that much if the 
> ctor
> GC> > from dollars+cents doesn't exist any more, but the underlying type still
> GC> > seems to be useful.
> GC> 
> GC> Are you arguing against premature encapsulation--preferring to keep these
> GC> implementation details public until the interface is settled and we can be
> GC> sure that we won't have to un-hide them in order to implement some 
> function
> GC> we haven't thought of yet? If so, okay...but when the design is complete,
> GC> wouldn't we want to hide these details?
> 
>  The number of decimal points/cents can be useful for validating the user
> input: even if we use a single control for currency entry, we still want to
> limit the fractional part to 2 digits, I think, don't we? So I don't think
> this should be hidden.

Actually, no, we don't limit it: I can enter a face amount of $1000000.01234 .
Even if we wanted to limit it, what would we do when someone pastes a number
like that into the field? Truncate? Round up? Consult the product's rounding
rules for that field, making the GUI even slower? No, I think rounding and
data entry are separate concerns that should remain separated.

>  The underlying type is an implementation detail but it may be useful to
> the class users too. Also, as long as we provide total_cents() method, this
> type is the type of its return value anyhow, so we can't really hide it.

I would argue that total_cents() should be private--see below.

> GC> > GC> I think these functions should be private:
> GC> > GC>   amount_type units() const
> GC> > GC>   int subunits() const
> GC> > 
> GC> >  Again, for me these methods are useful for a GUI showing the amount in
> GC> > dollars and cents.
> GC> 
> GC> Well...I suppose they might be useful in check-writing software that needs
> GC> to form strings like "One hundred twenty-three dollars and forty-five 
> cents".
> GC> But...no, in that contrived case, natural language must replace digits. Do
> GC> you see any concrete use case that is really plausible?
> 
>  Any presentation not using simple strings. E.g. if we wanted to use a
> "LED" widget to prominently display some amount. Or maybe if we wanted to
> format the currency in some fancy way (use slightly larger font for the
> dollar part than for the cents? or underling the latter?) in PDF output.
> I don't know how plausible is this...

In real-world life-insurance practice, it won't occur; lmi doesn't need this.

> GC> > GC>   amount_type total_subunits() const
> GC> > 
> GC> >  This one is admittedly mostly an implementation detail but it seems 
> pretty
> GC> > harmless to have and it makes writing tests much simpler. Could we 
> please
> GC> > keep it?
> GC> 
> GC> If you really want to keep it, could it be private (with the unit-test 
> class
> GC> declared as a friend)?
> 
>  I should have been more precise, it's convenient for the tests but it's
> not only useful for them. It would also be needed for serializing the
> object in a binary form, for example.

Yes, it's needed for serialization, but the currency class should offer
a public serialization API that hides this detail: it should transform a
currency value representing $1.23 to and from the string "123", not the
integer 123.

> It looks unnecessarily petty to hide
> it, after all this class basically exists solely in order to have this
> "total_cents" member, why not allow accessing it?

Clients of this class shouldn't need to access the internal representation.
Allowing them to access it would create opportunities for error. I'd say
the purpose of the class is to perform exact integer arithmetic on
currency amounts with two decimals, and the actual mechanics should be
an opaque secret.