Subject:
|
Re: FW: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 May 1999 04:50:14 GMT
|
Viewed:
|
1188 times
|
| |
|
|
stephen p spackman <stephen@acm.org> wrote:
> But what does it benefit us? *This* is creeping featurism at its worst:
> FORTRAN has it, so we should too.... In my entire professional life I've
> never had an application for floating point.
Floating point is easier to use than fixed point for many. Not that I need
floating point, I can figure out the math and use fixed point. Moreover, I
can use GCC and Librcx/LegOS and program at the lowest-level too!
My point is that some people - the ones who the byte code is being targeted
for - want the convenience of floating point. The tradeoff I mentioned
before was between space and functionality/usefulness. The amount of
usefulness is fixed; the space is not. If I can write a satisfying set of
floating point routines in very small amount of space, that might be worth
including as part of a byte code interpreter.
That's all I'm saying. This is not creeping featurism.
> And then we all switch sides for some of the features that support
> structure and engineering:
>
> > > These are all not necessary. Remember, these features exist to allow
> > > LARGE programs to be written easily. The RCX is not going to run large
> > > programs, no matter what you do. It'd be better to implement only
> > > global variables and concentrate on a fast interpreter.
> >
> > This is a possibility I had not really considered, but certainly since
> > "simple enough to get the job done" is a wonderful design philosophy in my
> > opinion, this could be a simplifying step in the right direction. I'll
> > think about it more.
>
> Ok, but I *fire* people who code like that. Do we want our children to
> learn with global variables? If all we care about is getting the job
> done, why are we messing around with lego? I must be missing something
> here.
Well, a reasonable goal - the one we have been discussing - is coming up
with a new byte code and machine model that fixes the problems of the old
one. The primary limitations there were: 32 global variables do not work
the way you want them to, task and subroutine support are not as you'd like
them to be.
My comment that "I'll think about it more" did not mean "a decision has
been made," it just meant that I'm open to thinking about this. New ideas
lead in new directions, even if the new ideas are not worth anything by
themselves. The thought of a system that uses only global variables
started me thinking about systems that are simpler than the one I had
proposed, which was, in my mind, already more complicated than it needed to
be. My first response was to express this as a step in the right
direction. Sorry for misleading you.
> (have you ever tried to write a semantics for floating point - or a spec
> for a programme using it?)?
Write specs, no. But I am familiar with IEEE and I know its good points
and its bad points. I know what aspects about it are worth preserving and
which are not, and I know which aspects take up all the implementation
space. The gist of my conclusions are that if you want to get technically
serious and you want measurably precise, gracefully degrading results from
your floating point calculations, you won't want to use the floating point
routines I am thinking of. But if you want something to alleviate the need
for fixed point, you might otherwise be interested in the routines I am
considering.
If you know more about floating point than me, and certainly there must be
many who fit into this category, please feel free to step in here and toss
out your ideas with regards to simplified floating point.
-Kekoa
|
|
Message has 2 Replies:
 | | Re: FW: Something else is needed, I think...
|
| (...) I agree with Kekoa. Floating point is simply an easier paradigm for many of us to do things that take much more effort and math knowledge to be done with fixed point. I succeeded in writing a legOS program that performs a lot of trig math with (...) (26 years ago, 5-May-99, to lugnet.robotics)
| | | Re: FW: Something else is needed, I think...
|
| (...) But suppose for instance that we were talking about a language like Java that has static typing. Why not put support for fixed point into the compiler. It would then have ZERO impact on the runtime, not even new library routines, and still let (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: FW: Something else is needed, I think...
|
| (...) But what does it benefit us? *This* is creeping featurism at its worst: FORTRAN has it, so we should too.... In my entire professional life I've never had an application for floating point. And then we all switch sides for some of the features (...) (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
