At 06:32 PM 1/5/99 PST, Patrick Logan wrote:
>
>> These are annoying little details about math...
>
>Aren't these actually annoying little details of floating point
>representation?

Both floating point and fractional representation systems have the same
problem. It's one of using different precision in different areas. Like
outputing intermediate values to 2 decimal places, but doing the math
internally to FP or arbitrary rational precision and then outputing the
total rounded to 2 decimal places. See the example in my previous message.

Seems like 64-bit floating point would work for many business uses, with
appropriate rounding along the way. I believe you get 15 digits of decimal
precision, which would be 99,999,999,999.9999 (99 billion, with 4 decimal
places of fractional precision). The US government (and probably some big
corporations) doing budget calculations would need something better. Some
sort of arbitrary precision scaled integer math might be best.

>I agree with the earlier message that use of integers or fractions
>would be better. An integer can represent units of some currency or
>fractions thereof. For example, an integer can represent thousandths
>of a cent if desired.

A big advantage I see of using scaled integers or fractions is you don't
loose precision when the numbers get really big. FP numbers don't give any
warning when the mantissa starts to loose precision. Maintaining exactly
accurate fractional representation may not be the goal. Consistency of how
the numbers interact and are output and stored is.

>The, separating presentation from computation, a separate object can
>have the responsibility for printing the value multiple ways. This
>like separating a Date value from how the date is printed.
>
>I don't see the advantage of using floating point and then
>encapsulating a lot of round off rules in another class.

The round off rules, AT THE TIME OF CALCULATION, are very important to
maintaining consistent results. Taking intermediate results to some
calculation, and reducing their precision (rounding) for output will cause
the output value of later steps in the calculation to be different. The
results of every calculation need to be rounded to some defined precision,
with some possible optimizations (like if you add two decimal numbers with
two decimal digits, you don't need to round the result to two decimal).
Multiplying and dividing are among the operations than need the precision
evaluated after every operation.

I can offhand think of other areas where precision control is real
important, other than business math. For example, I write video compression
software (among other things). A piece of signal processing code written in
MMX (Intel short vectors) assembler (an inverse discrete cosine transform)
has the precision of intermediate results adjusted after many of the
operations. One of the reasons for this is to maximize the use of very
limited available precision (16-bit signed math representing scaled
integers). I also know of similar code written by Intel that adjusts the
precision, and then adds magic error correction constants to intermediate
results. The outcome in both cases are more precise final results. 

If your dealing with math on measurement systems that have intrinsically
limited precision, building this into the objects may also be appropriate.
For example, asking some result it's maximum error seems pretty desirable
is many cases. For example, suppose you have a clock that is only accurate
to 1 minute, and you have a speedometer accurate to only 5 mph. If you do
some math to calculate your distance traveled, it might be nice to know
what the error may be (let's see you travel 25,525 mph for 42 minutes, and
your... opps 425 miles off course). I think this is related to the
discussion about units a while back. 

Thinking about it, I could image the whole concept of math precision
control being represented in a generic way. Something like:

	mathUniverse := MathUniverse new.
	mathUniverse setBase:10.
	mathUniverse setPrecision:0.01.
	mathUniverse setSignificantDigits:11.
	mathUniverse setPositiveInfinity:999999999.
	
	aPrecisionControlledNumber := mathUniverse divide:1 by:3.

The concrete representation would be up to the system, it would pick one
based on what would give the best performance for the selected constraints.
Most of the mechanism to implement this may already be there.

- Jan

p.s. I'm NOT suggesting we do this fancy stuff every time you want to
calculate the screen coordinate under the mouse.
___________________________________________________________________
            Paradigm Matrix Inc., San Ramon California
   "video products and development services for Win32 platforms"
Internet: Jan Bottorff janb at pmatrix.com
          WWW          http://www.pmatrix.com
Phone: voice  (925) 803-9318
       fax    (925) 803-9397
PGP: public key  <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
     fingerprint  52 CB FF 60 91 25 F9 44  6F 87 23 C9 AB 5D 05 F6
___________________________________________________________________