To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 4890
4889  |  4891
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

 
Verified and Trusted Team of Hackers
8 hours ago
Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR