[boost] Re: Is there any Interest in a Fixed Point Library?

From: Jason House (jhouse_at_[hidden])
Date: 2003-02-27 15:33:07

Kevin Atkinson wrote:
> 
> On Thu, 27 Feb 2003, Jason House wrote:
> > One thought... It looks like the template parameter should be an integer
> > type (of course, right?)...   I think that there is some way to cause a
> > non integer type to generate a compiler error.  Of course, considering
> > other types might have some value (ie. complex numbers, a double that
> > overflows due to adding of large numbers?, and probably others that
> > don't come to mind at the moment)
> 
> Be careful that you are not overly restrictive.  For example what about a
> class that supports very large integers.  What about a class that is a
> wrapper around an integers, such as one that is designed  to guarantee
> atomic operations, etc...

  I unfortunately am not familiar enough with all the aspects of boost
(yet <g>).  I believe there is a type traits library, which in general
is used for determining fundamental characteristics of template
parameters that are passed in.  If such an animal as "integer
compatible" is there, I suspect that new class implementations such as
large integers are somewhat obligated to ensure that their type traits
come out correct...
  One thing is for sure, if someone tried to get clever and extend the
large number support of their float/double (at the sacrifice of small
number support), the code, as is, won't even come close to working
properly.
  All I was going for was that there is only a subset of types that
would work, and I believe that boost has some resources for dealing with
that.  I personally am not familiar enough with them i order to give a
clearer prescription...  A couple of my comments earlier were in the
hope that somebody else would pick up the thought and run with it
further...

> > The problem I had was that a case of shifting by
> > 32 bits logically come up in my code... instead of clearing the number,
> > it gave me the original number back!
> >
> > I would have to assume that there is some kind of type trait that would
> > help with enabling some kind of error check.  Even if it is just some
> > kind of assert.  The fixed point to fixed point conversion is the most
> > likely candidate for hitting this kind of a bug.  A base of 20 converted
> > to a base of -15 would have a shift by 35...  (in effect, on my
> > compiler/processor, that would only shift by 3)
> 
> Yes a check would be useful.  I think an assert to check the the shift
> size is not equal to or larger than the integer it is shifting in bits
> would work.  But what about an variable length integer class where the
> sizeof() operator won't work?

Well, sizeof() definitely won't work for anything other than the most
basic types.  A integer complex number class won't support sizeof()*8
won't work either.  Something like the following:

template < T >
shift_bounds_check{int x}{};

template< int >
shift_bounds_check(int x){
  x = x<0?-x:x;
  assert (x<sizeof(int)*8);
}

/* more specializaions here */

Would allow at least some support for a check.  
There's probably a better way than what I wrote though...

> Also, please not that It IS possible to have a fixed point number with the
> radix larger or smaller than the size of the integer in bits.  You just
> have to be careful.  Some of my methods (like the frac one) also need to
> be written more carefully.

I agree that when the radix goes to either extreme, caution is
necessary.  It is good to avoid problems due to internal implementation
and NOT even alert the user...  A lot of the problems can probably be
caught at compile time (and the rest at run time).  The worst is when
something compiles without error/warning and runs without
error/warning... and everything looks good except for the output...

> > (Although, the conversion to double and back probably allows for the
> > fixed point number to be used as a floating point number, and just cause
> > higher math operations to operate on doubles, and then convert back.
> > I believe that the code fragment "x = sqrt(x)" would compile fine.)
> 
> Yes, that would work.  But if your goal is to avoid floating point math
> for speed (for a processor that doesn't have a FPU) than fixed point math
> functions would be useful.  Of course the software emulation for the
> floating point version of the math function may be just as fast.  I really
> don't know.

  Well, I agree that in some environments, such functionality might not
exist, but on those where it does exist, a fixed point library can still
be useful.  It would be a shame to not use fixed point simply because
there's no way to perform a  square root or a sine... even if they are
called OUTSIDE a double nested loop or something...  It would also be a
shame to have to code in a special work around to force use of
float/double for the one specific call, and then convert the rest to
fixed point...  
  It's just nice that the back door is there.  How much it gets used is
another story.

> > I think operators like += -= etc... would also be nice... they could
> > actually be written to accept all bases, and possible be specialized for
> > the same base...
> 
> Yes, I agree.  I just haven't written them.  Also currently
>   FixedPoint <operation> integer will not work since the compiler has no
> clue what FixedPoint to convert the integers into.  Thus overloaded
> operators where one operand is an integer (or for that matter double)
> should also be written.

Hmmm... it seems like there could be a way to code it right, so that
they are converted into the same type of FixedPoint as the left-hand
operator...  And then just call the standard operators...  Again, I am
not confident enough on how to right stuff in order to guarantee that is
the case.

> I did say it was rudimentary ;)

Yes.  I'm just adding my comments, as requested ;)  I like it, and it's
highly usable in it's current state.  The trick is going from usable to
some kind of idiot proof, highly generic, templated, fixed point library
that coexists perfectly with everything else in boost and stuff that
nobody has even thought of yet... :)