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... :) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost