Обсуждение: IEEE 754

Поиск
Список
Период
Сортировка

IEEE 754

От
Sai Hertz And Control Systems
Дата:
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.


Re: IEEE 754

От
Mike Mascari
Дата:
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




Re: IEEE 754

От
Jan Wieck
Дата:
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 #


Re: IEEE 754

От
Michael Glaesemann
Дата:
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


Re: [ADMIN] IEEE 754

От
Toni Schlichting
Дата:
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
>
>



Re: [ADMIN] IEEE 754

От
Bruce Momjian
Дата:
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

Re: [ADMIN] IEEE 754

От
Michael Glaesemann
Дата:
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


Re: [ADMIN] IEEE 754

От
Jan Wieck
Дата:
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 #


Re: [ADMIN] IEEE 754

От
Sai Hertz And Control Systems
Дата:
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


Re: [ADMIN] IEEE 754

От
Jan Wieck
Дата:
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 #


Re: [ADMIN] IEEE 754

От
Sai Hertz And Control Systems
Дата:
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


Re: [ADMIN] IEEE 754

От
Jan Wieck
Дата:
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 #