IEEE 754

Sai Hertz And Control Systems wrote:

Dear all ,

I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .

Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .

For all monetary values the PostgreSQL datatype NUMERIC should be used.
It is a builtin datatype using arbitrary precision math.

Jan

If you would like to know whats IEEE 754 read this
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Regards,
Vishal Kashyap.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Sai Hertz And Control Systems wrote:

Dear all ,

I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .

Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .

If you would like to know whats IEEE 754 read this
http://docs.sun.com/source/806-3568/ncg_goldberg.html

No sane human being would use floating point for monetary values.
NUMERIC is an arbitrary precision type capable of effectively limitless
scale and precision, although it is currently defined as having a limit
of 1000:

#define NUMERIC_MAX_PRECISION 1000

As far as rounding is concerned, it depends on the application. For
example, in the United States at least, each state has devised their own
rounding rules with respect to sales and use taxes. For a look at how
very bad sausage is made:

http://www.ecommercetax.com/official_docs/SSTP%20-%20Rounding.pdf

Mike Mascari
mascarm@mascari.com

On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:

I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .

What specifically are your concerns regarding floating point handling
and PostgreSQL? I'm not in a position to address your concerns, but I
would like to know what they are.

Michael Glaesemann
grzm myrealbox com

The answer is simple. Don't use floating point for money.

Sai Hertz And Control Systems wrote:

Hi Vishal,

usage of floating poing arithmetic is a taboo in financial calculations.
This what the decimal type has been created for. Never ever use float.

Ciao, Toni

Sai Hertz And Control Systems wrote:

Michael Glaesemann wrote:

On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:

I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .

What specifically are your concerns regarding floating point handling
and PostgreSQL? I'm not in a position to address your concerns, but I
would like to know what they are.

Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Jan 4, 2004, at 6:51 PM, Bruce Momjian wrote:

Michael Glaesemann wrote:

On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:

I would like to share my concerns about the IEEE 754 specification
and
floating point handling by PostgreSQL .

What specifically are your concerns regarding floating point handling
and PostgreSQL? I'm not in a position to address your concerns, but I
would like to know what they are.

Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.

Thanks, Bruce. I assume the arbitrary precision arithmetic Jan
mentioned which is used for the NUMERIC type takes care of this.

Michael Glaesemann
grzm myrealbox com

Michael Glaesemann wrote:

On Jan 4, 2004, at 6:51 PM, Bruce Momjian wrote:

Michael Glaesemann wrote:

On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:

I would like to share my concerns about the IEEE 754 specification
and
floating point handling by PostgreSQL .

What specifically are your concerns regarding floating point handling
and PostgreSQL? I'm not in a position to address your concerns, but I
would like to know what they are.

Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.

Thanks, Bruce. I assume the arbitrary precision arithmetic Jan
mentioned which is used for the NUMERIC type takes care of this.

That was the whole intention. Although Bruce is wrong, since most of the
time money is approximated. It is only in "bookkeeping" where this is
not allowed.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Dear Jan Wieck ,

Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.

Thanks, Bruce. I assume the arbitrary precision arithmetic Jan
mentioned which is used for the NUMERIC type takes care of this.

That was the whole intention. Although Bruce is wrong, since most of
the time money is approximated. It is only in "bookkeeping" where this
is not allowed.

Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and rounding
the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2);
This takes care of the rounding factor in money as per Indian standards
ok, how will you verify it simple just use log and you will get the
correct output.

Regards,
Vishal Kashyap

Sai Hertz And Control Systems wrote:

Dear Jan Wieck ,

Floating point math itself is not precise, but rather an approximation,
usually of 8 or 14 digits. You can't approximate money. This isn't a
PostgreSQL issue but rather a general programming issue.

Thanks, Bruce. I assume the arbitrary precision arithmetic Jan
mentioned which is used for the NUMERIC type takes care of this.

That was the whole intention. Although Bruce is wrong, since most of
the time money is approximated. It is only in "bookkeeping" where this
is not allowed.

Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and rounding
the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2);
This takes care of the rounding factor in money as per Indian standards
ok, how will you verify it simple just use log and you will get the
correct output.

What most people do not understand is the fact that real bookkeeping
only uses the 4 basic mathematical operators, and multiplication and
division even only when dealing with interest-, customs- or tax-rates.

Everything that uses any higher functions like power, logarithms and the
like is controlling and financial anlysis, maybe using accounting data,
but never feeding anything back into the bookkeeping.

People are often under the impression that effective APR's and all that
stuff fall into the same category as your bank or credit card account
balance. But that is not true.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Sai Hertz And Control Systems wrote:

Dear Jan Wieck ,

Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and
rounding the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2);
This takes care of the rounding factor in money as per Indian
standards ok, how will you verify it simple just use log and you will
get the correct output.

People are often under the impression that effective APR's and all
that stuff fall into the same category as your bank or credit card
account balance. But that is not true.

What are you suggesting thattruncing and rounding is not good in
financial terms

If that is what Indian accounting rules require, that is what you do.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Dear Jan Wieck ,

Yes I agree with you Jan , most of the time we round the amount and
this is done by truncating greater than 3 decimal digits and
rounding the 3 digit to 2 in other words :
select trunc(1000.236897,3);
then
selecr round(1000.236,2);
This takes care of the rounding factor in money as per Indian
standards ok, how will you verify it simple just use log and you will
get the correct output.

People are often under the impression that effective APR's and all
that stuff fall into the same category as your bank or credit card
account balance. But that is not true.

What are you suggesting thattruncing and rounding is not good in
financial terms

Regards,
Vishal Kashyap