RE: [boost] Fixed-Point Decimal Proposal

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-03-10 19:37:01

> Jeff wrote:
> >
> > The use of the term precision (despite any C++ precedent)
> > I think is actually incorrect.
> >
>
> It's a common usage that folks are likely to understand...
> kind of like using "data" as a mass noun instead of the
> plural of "datum."

Actually I don't think they understand the difference, but I'll be ok if you
don't change it.

> > Speaking of the operators, it would be nice to see a quick
> > synopsis of showing the 'proxy' operators in action.
> >
>
> I have the example,
>
>     euros = francs * bankers_round(conversion_rate);
>
> near the beginning of the paper.  Should I explain it better?

Yes.  What I was really should of asked for is few lines of code that show what
a user can.  Some basics like:

  decimal<2> foo(100); //construct from int
  foo++;  //foo == 101?
  decimal<2> bar(10.2); //construct from double
  decimal<4> foobar = foo * bar; //result is ?
  foobar =+ 10.1; //add a double?
  foobar = foo + (bar * foo); //is this allowed or do I need rounding proxies?
  if (foo >= bar) {}
  double barbar = to_double(bar);
  std::cout << foobar << std::endl;

I realize this seems trivial, but as the reader I'm left reading the whole paper
trying to imagine how this can and can't be used.

> > The only examples are in the policy design section which is
> > what we "can't" do.
> >
>
> I don't understand what you mean.

Sorry -- what I was trying to say is you don't have a short usage section like
the above.  But later on you have "usage example" for the policy design that
isn't implemented...

> The real issue is not the number of template parameters; that was
> just an additional argument that I threw in as an afterthought.
> The fundamental issue is whether the rounding mode should bind
> to the operation or to the operand.  If you can convince me that
> the latter is the better design, I'll be happy to change it.

Well I don't know if I can convince you -- I'm not sure I'm convinced one way or
another.  From what I understand the advantage of the current design is that I
can mix and match operations on types with different rounding modes.  I just
don't know of an application where I would want that (I'd love to hear about
some).  Mostly I would want one rounding policy for my 'money' class arithmetic
and I want to set that at compile time and forget it.  But I might also have a
'stock price class' that uses a different rounding policy.  Unless I
misunderstand, these 2 classes currently can't have different rounding policies
in the same application by default. Instead with one I will have to be explicit
because of the default rounding mode.  Put it another way -- the following would
make perfect sense to me:

  typedef decimal<2, round_down> money;
  typedef decimal<2, round_up>   stock_price;

  money my_money("1000000.1"); // just day dreaming :-)
  money your_money(1); // sorry
  stock_price tech_stock_price("1.54");
  //next line won't compile -- types not compatible -- this is good!
  double shares_i_could_buy = my_money / tech_stock_price;
  money our_money = my_money + your_money; //fine...

> >
> > I would like to see a to_string function added.
> >
>
> OK.  How about (modulo your objections to "precision" and
> the macro for the default rounding mode):
>
>     template<int Precision>
>     class decimal
>     {
>     public:
>         // ...
>
>         std::string to_string(int = Precision,
>           const rounding_base& =
>             BOOST_DEFAULT_ROUNDING_MODE< decimal<Precision> >());
>     };
>
> Would that work for you?
>(Actualy, I already have a to_string
> function in a privately inherited base class that I could just
> dispatch to.)

I was thinking of a free function like to_double, but it doesn't really
matter...

Jeff