"trans.  (T. Onoma)" <transami / runbox.com> writes:

> | Using floating point numbers, there is no way to guarantee that all
> | pairs of calculations that fit the pattern in your example will
> | yield the same results.  Sorry, but that's just the nature of the
> | beast.
>
> You are constraining the solution set to a system that can not provide
> a solution --current float-pointing representation. It's
> tautological. My point all along has been an _extension_ to the system
> to deal with the diffculties you speak-of. Which is how floating-slash
> and SLI arithmetic came up. Also, if you'll recall, Markus presented
> some points along the lines of my own train of thought on such an
> extension.

Yes, I recall.


> Floating-point is a representation, no less, or more, than any
> other. The differences lie in the pragmatics of application of that
> representation.  Roman numerals, for instance, generally suck for
> arithmetic production.  Floating-points are much better, of course,
> but they too have limitations --a beastly nature, as you put it. Just
> becasue fp is modern does not mean that there may not a another system
> that will be to fp as fp is to rn (so to speak). And in fact, as I
> pointed out above, there are already some potential candidates.

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.

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:

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.  (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)

    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))

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?



-- 
 Lloyd Zusman
 ljz / asfast.com
 God bless you.