What is it worth?

[Gunther]

Paul,

There's no reason binary can't give results just as exactly as BCD.

That's right for integer numbers. But you should try to convert 0.1 (decimal) into the binary system. That effect happens with 0.1 and all multiple of it.

Gunther

[Antariy]

That's right for integer numbers. But you should try to convert 0.1 (decimal) into the binary system. That effect happens with 0.1 and all multiple of it.

Yes, for example, nice results can happen when you are multiply something for that number:

Code Select Expand


3FFB E3 8E 38 E3 8E 38 E3 8E


There is binary form of 0.(1) for 80bit number.




Alex

[Gunther]

Here is some equipment, which I use  :bg



That's the MADAS (stands for Multiplication, Automatic Division, Addition and Subtraction) of the company Egli in Zurich from 1936. Please have a special look at the long accumulator at the top of the machine, to accumulate interim results without accuracy loss.



That's the Monroe, Model Monochromatic, produced by Monroe Calculating in Orange, New Jersey from 1956. It has a long accumulator, too.

With that both machines I've calculated the right vector sum. Unfortunately, Antariys new memory tool won't work with that equipment  :(.

But joke apart, that are old principles (long accumulator) and should give us the idea.

Gunther

[Antariy]

Here is some equipment, which I use  :bg
....
With that both machines I've calculated the right vector sum. Unfortunately, Antariys new memory tool won't work with that equipment  :(.

Well, that is question of instruction sets only :green2

These machines have bigger accuracy than 80bit FP.  :bg



Alex

[Gunther]

These machines have bigger accuracy than 80bit FP.

That's for sure, Alex.

Gunther

[dioxin]

Gunther,

That's right for integer numbers. But you should try to convert 0.1 (decimal) into the binary system. That effect happens with 0.1 and all multiple of it.

The same applies when using BCD.
In binary 1/256 = 0.00000001 (1 byte after the point)
In decimal it's 0.00390625  (4 BCD bytes after the point)
If you're restricted to 1 byte after the point then binary gets it right and BCD fails.
And for calculation results, look at 1/3.
In binary 1/3 = 0.01010101 to 1 byte (an error of 0.39%)
In BCD 1/3 = 0.33  to 1 byte (an error of 1.01%)


1/3 is not representable in BCD either so why drop binary because it can't represent all numbers and then choose BCD which not only can't represent all numbers but on average represents them less accurately than binary and has the additional huge calculation overhead?

It's not binary that is at fault.


And I didn't mean to just use binary at the FPU does. Use it as fixed point binary after all BCD is just a modified fixed point binary.

Paul.

[jj2007]

Attached archive contain updated source (© Gunther), where I insert FINIT in main function.

Yep, that explains the differences. Note that you can also manipulate results by choosing the FPU rounding mode - depending on the values to sum up, results can differ quite a bit.

[Antariy]

Attached archive contain updated source (© Gunther), where I insert FINIT in main function.

Yep, that explains the differences. Note that you can also manipulate results by choosing the FPU rounding mode - depending on the values to sum up, results can differ quite a bit.

Rounding mode have meaning with conversions of numbers.
But, rougly, more bits of precision, gives an opportunity to accumulate much bigger numbers. This have drastically effect with division, root, for example.

But, again, this is NOT good approach, of course. Moreover, in big project this is makes unpredictability of work of program.



Alex

[dioxin]

Gunther,
both IEEE and Cray formats do include a more accurate formats. IEEE defines Quadruple precision giving 34 decimal digits (although it needs to be implemented in software as the FPU doesn't support it) and Cray defines a Double precision giving about 30 decimal digits.
It's up to the programmer to use a suitable format for the task.

Paul.

[raymond]

stands for Multiplication, Automatic Division, Addition and Subtraction

It's also possible to extract square roots with those mechanical calculators. Have you ever learned how to do it? :wink

[Antariy]

Note that results are much closer to 137 than Alex' second VC version attached above (while the first version posted as reply #1 yields the same results as the MB code below - why is the second version less precise???). Most probably, VC uses only the 53 bit mode of the FPU.

Yes, Win32 MSVC uses 64bit FPs. This is big discuss - just search on MS's site.

That is reason why I addeded reinitialization of FPU at main function. After do that simple optimized MSVC code behaves like BCC (at least 5.0 which I have) - which uses 80bit mode.



Alex

[dioxin]

It's also possible to extract square roots with those mechanical calculators

I learned that at school when I was about 15.It's a lot of subtracts and shifts.
I then programmed a PET computer to calculate square roots in the same way using 256 digit registers in screen memory so you could see the calculation in progress, it took about 2 seconds to do the full 256 digit result.

The exact same principle can be used in binary to calculate square roots. It's slightly easier in binary as each step either succeeds or fails and gives the next bit of the result  and you then move on to the next bit but in decimal each digit may need a number of successive subtractions to yield the digit.

Paul.

[MichaelW]

The attachment contains a test based on Alan Miller's quadruple precision arithmetic module ( link). A FreeBASIC port of the module ( link), using the FPU version instead of the SSE2 version, produced virtually identical results. I'm not sure that the Fortran compiler does the additions in the order listed, but I know that the FreeBASIC compiler does.

[Gunther]

Paul,

And I didn't mean to just use binary at the FPU does. Use it as fixed point binary after all BCD is just a modified fixed point binary.

That's clear, we're talking about fixed point arithmetic. But it's not native supported by our processors. I won't argue against floating point arithmetic in binary. Floating point numbers have a large importance in scientific calculations. But everyone should know that in some cases the entire calculation crashes down. And the "modern" compiler design in the 64 bit world will lead to much more crashes.

1/3 is not representable in BCD either so why drop binary because it can't represent all numbers and then choose BCD which not only can't represent all numbers but on average represents them less accurately than binary and has the additional huge calculation overhead?

Yes, and 1/7 is another example for that. These are infinite periodic decimal fractions and can't be represented exactly inside a finite state machine. But you know that 1/10, 2/10, 3/10, ... etc. will give infinite periodic binary fractions and can't be represented exactly, too. Those fractions are very common in our decimal number system. Therefore has the BCD arithmetic also a large importance. I haven't enough information about the situation in overseas or Australia, but in Europe is 85 - 90% financial sector software written in COBOL with BCD arithmetic.

both IEEE and Cray formats do include a more accurate formats. IEEE defines Quadruple precision giving 34 decimal digits (although it needs to be implemented in software as the FPU doesn't support it) and Cray defines a Double precision giving about 30 decimal digits.

That's clear. Super computers have a lot of other data formats. But the problems with floating point arithmetic remain. We've only a tool which is like a comb with less and lesser tooth and try to run through the hair.

Gunther