Sanford Aranoff wrote:
>
> I am a university professor,and I teach my students rounding
> is bankers rounding. What you call normal rounding does not
> make sense. If this is what you learned in school, you
> learned the wrong thing. It is not just for bankers. It is
> also for large data evaluations.
>

Regardless of what you teach at university, most people don't get
there.  What they get taught is "normal" rounding (5 or more round up,
less than 5 round down) and if they find someone is "cheating" them
because they went to university, then they complain about not being
given that extra cent.  In three countries I have lived in, "bankers"
rounding would be consider wrong by the average man.  Our users are
average men and women and expect our programs to work the same way they
think - otherwise it is a "computer error".

Then there is Swedish rounding!

> The scary part is that round in sql is not correct! If so,
> this bug needs fixing!

What bug?


--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
Joan and Jeff Cook
The Cooks Oasis
www.cookislandsoasis.com

Hi Sanford,
<<If this is what you learned in school, you learned the wrong thing.>>

Actually the only rounding I learned in primary school is simple rounding
(always round up). Things haven't changed since my time. I looked at my
daughters school mathematics books last year and she is also only thought
simple rounding . She doesn't know anything about bankers rounding. I
only came to know about bankers rounding a couple of years ago when
developing financial software.

<<The scary part is that round in sql is not correct! If so, this bug
needs fixing!>>

In that case you need to put up a case to MS Excel and Lotus 1-2-3 as well
. Last time I checked both products are also using simple rounding. My
electonic calculator also uses simple rounding. Many government tax
authorities also want vendors to always round up when preparing tax
invoices. Why not, it works better for them when computing tax amounts .

<< I am a university professor,and I teach my students rounding is bankers
rounding. What you call normal rounding does not make sense. If this is what
you learned in school, you learned the wrong thing>>

But this statement is not true. I tend to agree with Sean too. There is no
right or wrong method but we as software authors need to recognize that
there are 2 standards out there and both are also recognized by different
parties as correct.

I feel that bankers rounding is statistically more accurate when positive
and negative numbers are used. Trouble is, end-user will compare your apps
computation with what they learnt in school and compare with Excel or their
calculator and you'd end up with have some explaining to do.

Regards
Gregory Sebastian

Sanford

> I am a university professor,and I teach my students rounding
> is bankers rounding. What you call normal rounding does not make sense.

There are many rounding methods, and some methods are better under
certain circumstances. The word "round" is not a scientific therm, nor
an SQL or programming standard; it's just a set of different methods to
reduce the precision of a number, and there are plenty of them, for all
tastes
I implemented my own rounding functions, so I don't really care, but the
method I use more often is the "normal" rounding as implemented in
DBISAM and EDB.

> The scary part is that round in sql is not correct!

Don't panic
With DBISAM (and EDB too) you can write your own rounding functions, so
that's not a problem.

Also, if you consider positive and negative numbers, and a symmetric
rounding method, I can't really understand why bankers rounding is
better... Statistically, it only reduce rounding errors if you have only
positive or only negative numbers. If you have both, there is no difference.

--
Fernando Dias

Let's talk about positive numbers. Bankers rounding makes
sense, the others do not. Delphi uses bankers rounding. If
SQL does not, then we have an inconsistency. I do not care
what Excel does. When I write Delphi code, I expect SQL to
be the same as Delphi code.

We do not have to feel responsible for schools teaching
wrong things, or for Excel doing things the wrong way. Our
responsibility is for consistency. Since dbisam is written
in Delphi, SQL should be done the same way as Delphi does
it.

I cannot see how you can accept a difference between Delphi
code and sql in dbisam.

"Sanford Aranoff" <aranoff@analysis-knowledge.com> wrote in message
news:47D06ED8.9AFFC7E7@analysis-knowledge.com...
> Let's talk about positive numbers. Bankers rounding makes
> sense, the others do not. Delphi uses bankers rounding. If
> SQL does not, then we have an inconsistency. I do not care
> what Excel does. When I write Delphi code, I expect SQL to
> be the same as Delphi code.
>

Uh, calm down. Our customers are used to Excel, it is the standard, so there
is a lot of merit to doing things as per the standard. We all program per
Windows stndard, even though we might not like it.

SQL standards are not determined by Delphi, or by Elevate.

> We do not have to feel responsible for schools teaching
> wrong things, or for Excel doing things the wrong way. Our
> responsibility is for consistency.

No. Our responsibility is to be practical problem solvers. And if my
customers check my calculations with Excel, I'll be damn sure to make my
progrm conform to Excel. Anyway, we are talking about differences of a
fraction of a penny. Not material, accountants would say.

Since dbisam is written
> in Delphi, SQL should be done the same way as Delphi does
> it.
>

I suggest if you feel so strongly about it, that you expand SQL with your
own round function.

Robert

<<Delphi uses bankers rounding. If
SQL does not, then we have an inconsistency>>

OK I can see your point too.

Perhaps the best solution is 2 standard implementations of Rounding in
DBISam. 1. Round -> performs bankers rounding and 2. SimpleRound -> performs
simple or normal rounding. This will make DBISam Round functions consistant
with Delphi and potentially save us a lot of grief when performing rounding
to DBISam tables with Delphi on the one hand and DBISam Round function on
the other.

Wonder what the other compilers C++ etc uses for default rounding. Anyone
knows ?

Regards
Gregory Sebastian

..

Sanford

> I cannot see how you can accept a difference between Delphi
> code and sql in dbisam.

I can't actually accept nor reject nothing, since I don't run Elevate
Software, so I can't decide how rounding is implemented. Also, I don't
expect it to be implemented in some particular way because SQL standard
does not specify how to implement rounding methods.
Since it's not difficult to add the rounding methods we wish, I don't
feel this as a problem.

Anyway, maybe in a future version Tim can implement both (I suggest
round() and bround() for "round" and "better round" .

Regards

--
Fernando Dias

Sanford,

You have tunnel vision here. "Normal" rounding may not make sense for
your particular purposes, but for calculating things like taxes and
commissions it makes perfect sense and may even be the law. Here's
Virginia's sales tax calculation table:

http://www.tax.virginia.gov/web_pdfs/busForms/st_table_5percent.pdf

You'll note that it uses "normal" rounding. Can you imagine the fun
explaining to a client that the legislature, auditor, and everyone he
knows learned the wrong way to round? Do you think the client will find
comfort in the fact that he is now enlightened as he submits all his
records for a full audit and pays a hefty fine for improperly collecting
sales tax?

Sean

Sanford Aranoff wrote:
> Let's talk about positive numbers. Bankers rounding makes
> sense, the others do not. Delphi uses bankers rounding. If
> SQL does not, then we have an inconsistency. I do not care
> what Excel does. When I write Delphi code, I expect SQL to
> be the same as Delphi code.
>
> We do not have to feel responsible for schools teaching
> wrong things, or for Excel doing things the wrong way. Our
> responsibility is for consistency. Since dbisam is written
> in Delphi, SQL should be done the same way as Delphi does
> it.
>
> I cannot see how you can accept a difference between Delphi
> code and sql in dbisam.

Sean McCall wrote:
>
> Sanford,
>
> You have tunnel vision here. "Normal" rounding may not make sense for
> your particular purposes, but for calculating things like taxes and
> commissions it makes perfect sense and may even be the law. Here's
> Virginia's sales tax calculation table:
>
> http://www.tax.virginia.gov/web_pdfs/busForms/st_table_5percent.pdf
>
> You'll note that it uses "normal" rounding.

Well, if this is the law, then it is the law. The code must
refer to the law.

When I mentioned standards, I meant IEEE. The law does not
always agree with standards.

Again, there must be consistency. We must have two options
in Delphi and in SQL.

This has been a most diverting discussion.  Thank you Andrej for kicking
it off, however unintentionally.


  Oliver