Math issue, isn't it?

[Kay C Lan]

On Tue, May 12, 2009 at 4:48 AM, Bob Sneidar <bobs at twft.com> wrote:

> Well it looks for all the world then, that in order to write any kind of
> accounting application in Revolution, one would have to write their own
> functions...


Not just Rev but as explained above, every application has to deal with this
anomaly. I wont bore you with the DAYS of hair pulling I've been going
through with xCode at the moment just to achieve something similar;
something I can solve in 2 sec in Rev!!!! (to be fair I'm sure an xCoder,
which I'm defiintely not, could do it in 2 sec too:-)

>
> I must say however that real accounting or math based applications
> obviously have some way to deal with this.
>

Yes, and this is where the Developer comes in, that's what your job is;-) I
think one of the many 'side-effects' of Rev is that because it's so easy to
work with many people think its a Finished App, they compare Rev with
PowerPoint, a Web Browser, Excel etc, and although you can do all these
things in Rev what the comparison should be is Rev and xCode or whatever the
code is that underlines these apps and how quick and easy was ALL THAT CODE
to produce:-(

Guaranteed, whatever app you are thinking of that can come up with the
correct answer to your math problem, some Developer specifically tweaked the
code to account for a binary machine that doesn't think like a human.

Elsewhere you wrote:


> It should be doing math on the displayed value not the stored value,
> because that is what a human being who doesn't know about processor math
> errors would expect.
>

NO! That is so NOT what every other program does and I'll susggest not what
you expect either. Start up Excel, Numbers or whatever your preferred
spreadsheet and try this:

In the first row, first cell put 1, in the second cell put 3 and in the
third cell put =A1/B1.
The answer your are going to get is something like 0.333333 (depending on
cell width)
Now set up the Display Precision to 1 decimal point so it displays 0.3
Copy the above into two more rows below, so you have three lines of the same
thing.
In cell C4 put =sum(C1:C3) and presto the answer is 1.0

If it worked the way you wanted it to it should say 0.9?

Change the first column from 1s to 2s and you get 3 displayed 0.7s adding up
correctly to 2.0, not your 2.1

The concept that the 'machine' is working with a different number (normally
more precise) than what is displayed I believe is a commonly accepted
standard.

The fact that Excel displays the correct answer in the above case is not a
function of C, C++ or whatever code it may have been written in, but the
fact that some Developer took the appropriate steps to ensure the underlying
Code did what was necessary with what numbers that were available to come up
with an answer a human really was expecting. Specifically, if you increase
the precision of the SUM field to it's maximum (28 decimal places for
Numbers) it still wont say 0.9999999999999999999999999999, so someone
somewhere added some tricky code to deal with repeating decimals so that at
full precision it wouldn't display the machine's limitation but be corrected
to display the human acceptable answer.

At the end of the day you are the Developer, you are now aware of a
limitation that exists in binary thinking, now it's up to you to develop
your app so whatever numbers your human Users put into it, will come out the
way you believe they want it to come out - if that's 0.9 and 2.1 in the
above case, IMO that's your prerogative, not RunRevs.