Обсуждение: IEEE 754
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 Regards, Vishal Kashyap.
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
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 #
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
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: > 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 > > > Regards, > Vishal Kashyap. > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > >
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 #
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
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 #