On Sunday 31 October 2004 10:31 am, Lloyd Zusman wrote:
|
| It's clear that you agree that we can't use floating point numbers to
| achieve the goal that you mentioned. That's one of the main points of
| the message of mine from which you culled the above quotes.
Sure. Although I never really disagreed. I've merely suggested that I believe
that it may be possible to expand fp to accommodate. Whether you still call
it fp or something else. So I'm not sure why you were making it, just to
clarify my position? Anyway...
| In that same message of mine, I offered two characteristics of a new,
| hypothetical computer language which on the surface might appear to
| provide a solution to the issues that you raise. What comments do you
| have about these characteristics? I will repeat them here:
Okay, I'm not sure how your language helps, but maybe you have a point to
this? If so I'd prefer you'd just say what it is. This sort of smack of
trying to lead me blindly in order drop me over a cliff. But maybe not, and I
could care less if so, so I'll honestly give you my thoughts.
| 1. No floating point arithmetic is done by default; rather, all
| arithmetic involving values with decimal points is done with
| something like Rationals, BigDecimals, etc.
Okay.
| (although note that
| rounding and truncation will still have to be done even in this
| case, and there will be cases where precision is lost in ways that
| are similar to the ones we've been discussing in this thread)
(Right, I do understand that we have limited storage capacity, so obviously we
can't store more information then we have room for. And this does lead to the
necessity of truncing or rounding _informationally abundant_ results. But one
of the things I have argued is that this doesn't apply to a number like 1/3,
it is quite reasonable to store this exactly by simple storing the fact of
repetition.)
| Perhaps this hypothetical language would convert decimal numbers to
| rationals, as follows:
|
| (134.45 * (1.0/0.1))
| becomes: ((134 + (45/100)) * (1 / (1/10)))
|
| This could be algebraicly reduced before anything is evaluated:
|
| ((134 + (45/100)) * (1 / (1/10)))
| => ((13400 + 45) * 10) / 100
| => (13445 / 10)
| => (2689 / 2)
| => 1344 + 1/2
|
| Of course, how would you algebraicly reduce this statement
| if the values of X, Y, and Z aren't known until run time?
|
| (X * (Y/Z))
Okay you want to reduce to separate out the integer part and the fractional
part.
[XY/Z] + {XY/Z}
Assuming X, Y and Z are always integers, maybe you can do some generalized
expansion, but I don't readily see an _algebraic_ solution. I suspect it
might not be possible. Nonetheless without knowing X, Y, and Z at all, all I
think we can really do is create a sort of continution on a computational
solution (AFIKT)
q = fn { |a,b| i = a; while b <= i; i=i-b; c++; end; return c }
r = fn { |a,b| i = a; while b <= i; i=i-b; c++; end; return i }
s = fn { |x,y,z| q(xy,z) + r(xy,z)/z) }
But I'm not sure what you after here. So maybe you can fill me in.
| 2. Parentheses around expressions are suggestions only and no longer
| specify strict evaluation order.
|
| For example, statement A might be transformed to statement B by the
| compiler:
|
| A. (134.45 * (1.0/0.1))
| B. ((134.45 * 1.0) / 0.1)
|
| But what would you do in this case?
|
| (X * (Y/Z))
|
| Should the order of evaluation be changed at run time, depending on
| the values of X, Y, and Z at the time that the statement is
| encountered? If so, what algorithm would you use for deciding when
| and how to change the evaluation order?
A set of identities for moving parentheses around. They seems doable. As long
as they're strict identities.
Okay so now what?
By the way, this looks promising:
http://www.cse.lehigh.edu/~caar/papers/mikes-phd.ps
T.
