lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Numerics


From: Greg Chicares
Subject: Re: [lmi] Numerics
Date: Mon, 2 May 2016 14:24:03 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

Over the weekend I was thinking about this discussion of a currency class,
and I'd like to move forward with this idea now.

On 2016-03-31 21:49, Vadim Zeitlin wrote:
> On Thu, 31 Mar 2016 17:01:36 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-03-28 22:08, Vadim Zeitlin wrote:
[...discerning which variables represent currency in the problem domain...]
>  This is the problem, from my point of view: it's not clear to me which
> ones are which (well, I guess the first one is relatively obvious as lives
> are not supposed to be measured in cents, but all the rest are less so).

This problem domain is my specialty, so it's trivial for me to do this.
(I just can't do it right now, because I have to focus on this month's
release first.)

> GC> It wouldn't be too hard to go through all the code and replace "double" 
> with
> GC> "currency" as appropriate.
> 
>  If you could do it, with currency just as a typedef for double, I could
> then reimplement currency as a class and do the tests. But it's this "as
> appropriate" part which is the most complicated and time-consuming IMHO.

Would you do that please? I.e.:
  "reimplement currency as a class and do the tests"

[...snip technical details upon which we agree...]

>  I'm pretty sure there will be no abstraction penalty for using the
> currency class, any contemporary compiler is able to "look inside" such
> class and see that it's just an int and generate exactly the same code for
> it as if it were just an int in the first place.

That's a surprise to me: I didn't know compilers had evolved that far.
I'd be excited to see an implementation that behaves this way.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]