Subject:
|
Re: FW: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 May 1999 21:01:28 GMT
|
Original-From:
|
Paul Speed <pspeed@augustschell.com^stopspam^>
|
Viewed:
|
1268 times
|
| |
| |
Kekoa Proudfoot wrote:
>
> Paul Speed <pspeed@augustschell.com> wrote:
> > Mario Ferrari wrote:
> > > ... I succeeded in writing a legOS program that performs a lot of trig
> > > math with fixed point (four decimals). ...
> >
> > So far every discussion I've seen about fixed point math
> > that's gone to any detail to explain the implementation has had it
> > a little off. Usually, trying to impose the decimal system onto
> > your fixed point routines makes them both harder to code and slower
> > to run.
>
> The one advantage to working with radix 10, on the RCX at least, is that
> the display routines use this radix, so even if you prefer working with
> some power of two radix, you might find yourself stuck converting in the
> end. Not that this is bad; I prefer to work in radix 2 for the same
> reasons you mentioned.
>
> Also, as far as explaining fixed point goes, the analogy to base 10 is
> certainly easier to understand, even if it is misleading when it comes to
> implementation.
That's true. My very first fixed point implementation was in
radix 10. At the time I didn't even know what I was doing was called
fix point. Later, in graphics work, it just seemed obvious to use
radix 2 since there are several tricks that give you hidden
advantages. (Automatically wrapping array bounds is one.)
>
> It is also not clear what Mario meant by four decimals. Maybe he meant
> four fractional places?
Ah, yeah, I guess that's true.
>
> Regarding what is needed in the byte code for fixed point: the processor
> has everything you need; the byte code has bit operations but is missing
> shifts; those would need to be added if you do not want to have to use
> multiplies instead. Also, 16-bit fixed point requires 32-bit temporaries;
> these would have to be added too.
If supporting 32-bit values becomes a pain then I seem to
also remember there being a simple way to promote each piece to a
16 bit number and then recombine them. This would also be the only
way you could support 32-bit fixed point without using 64-bit
temporaries. Of course, I could be remembering things wrong but I
seem to remember doing it once.
-Paul (pspeed@progeeks.com)
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message is in Reply To:
| | Re: FW: Something else is needed, I think...
|
| (...) The one advantage to working with radix 10, on the RCX at least, is that the display routines use this radix, so even if you prefer working with some power of two radix, you might find yourself stuck converting in the end. Not that this is (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
32 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
Active threads in Robotics
|
|
|
|