On Thu, 27 Feb 2003, Jason House wrote:
> 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 ). 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...
OK well I think guaranteeing a true integer like behavior would be tricky.
> > 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 }
>
> /* more specializaions here */
>
> Would allow at least some support for a check.
> There's probably a better way than what I wrote though...
Yes that would work.
Also you keep talking about an integer complex class. However
FixedPoint > doesn't really make sense.
Complex > does however. It would be even more useful to
allow the real and imaginary parts to be of a different EXP.
> > 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...
I defiantly agree with you here.
> > > (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...
I wasn't trying to imply that it shouldn't be done. Just that my class as
is, is of limited usefulness for serious fixed point work when the goal
is to avoid floating point for performance reasons.
> > > I think op
