Thanks for taking the time to reply Ken. On Sunday 08 June 2008, Kenneth Lerman wrote: > I've changed the subject of this to better reflect what it is about, and > am responding on both users and developers lists so that the original > audience will still see it.
Noted - See below as to why it is relevant for the user. > I do seem to recall a prior discussion about data types, but since I > don't keep files of such things, I don't have a pointer to it and I > could easily be mistaken. I don't recall seeing any discussion on a mailing list, so if one did take place, it was probably some little nook in cyberspace.. > While using doubles to get higher precision would be a solution, it is > aesthetically nasty for us purists. Why would one use a floating point > number for something that is inherently an integer? Primarily, it simplifies the math and avoids having to use a fixed point math library. But... > Also, one could easily imagine porting HAL to a platform where floating > point arithmetic has significantly higher cost than integer arithmetic. I don't think that is likely to happen any time soon - However, there is a strong case for moving *all* floating point math out of kernel space and performing the minimum of trivial integer math at the lower levels. > For example, some of us are thinking about a split where the HAL layer would > be moved to a remote controller using (say) an ARM processor. Sure - If it was kept as a simple low level layer for hardware configuration, I would go along with that. Dump the cruft, and you might get an acceptable level of performance out of an ARM platform.. Take a look at the latency figures under load before you commit to such an undertaking though - 100mSec and higher is quite normal. > The general answer to the issue of integer typing is that the C standard > (at least the older versions I'm familiar with) does not say that an > integer is 32 bits. I've worked on platforms where an int was 16 bits, > and I can imagine machines where it might be eight or 64 bits. ISO/ANSI only gives a minimum range for an int (-32767 to 32767), but it is generally accepted that it uses what ever size is most efficient on the host machine. So on a 32bit processor (i386 or PowerPC), it would be 32 bits, and on an x86_64, 64 bits (but never 8 bits). > My answer to the issue of more precision for encoders would be to use a > type hal_s64. That would be defined as a long long on the machines I > usually use. For users like Aram, an int32 is going to roll over at 2^31, so with a 5,000,000 count encoder, 429 rotations would be his limit. Certainly, going to a 64 bit integer would improve things, but not if the counts get scaled and truncated to a float at the higher levels - A float is only good for six decimal digits, whislt a double is good for ten - When you go converting to a double, perform some math, convert to a float, then back to a double, do some more math, and finally post the result as a float, accuracy is going to be suspect at best. > I'm aware that there are some "standard" definitions for such types that > do not have "hal" in the name. The kernel source is full of things like > int32, s32, _s32, __s32. Using hal_s32 makes more sense to me than > any of those because I can at least figure out where to go to find the > definition if I ever want to port this. The kernel developers are working to reduce the number of typedefs and the GCC team move ever closer to being "standards" compliant - int32 is portable if you need an int with a specific range. _s32 and it's ilk should not be relied upon for long term support or cross platform. Hiding behind hal_yadda typedefs sets a bad example, ignores good advice from the likes of Stroup and Torvalds, and raises questions. [Aram] If you really want to use a 5,000,000 count encoder, you'll probably need to increase the size of the count registers (not difficult on a Mesa card) and switch to using 64 bit int in the driver - You'll still suffer from limited range and errors from int<->float<->double<->float<->int conversions. --- Paul. P.S. Tom - Can't send you any emails as sbcglobal and any other part of the AT&T network bounces legit messages. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
