I've got the following script which demonstrates a problem I'm having
with floating point numbers and intval:
$times100 = (-37.12 * 100);
print $times100 . \n;
$intval100 = intval($times100);
print $intval100 . \n;
print ($intval100 / 100) . \n;
I expect the output to be:
-3712
-3712
-37.12
On Thu, 2010-05-06 at 11:24 +0100, Paul Waring wrote:
I've got the following script which demonstrates a problem I'm having
with floating point numbers and intval:
$times100 = (-37.12 * 100);
print $times100 . \n;
$intval100 = intval($times100);
print $intval100 . \n;
print
Ashley Sheridan wrote:
It's part of the rounding problem you get with most languages out there.
Why can't you compare the floating point values though? Currency should
only have one decimal place anyway.
You can't compare floating point values because if you have, for
example, a user-entered
On Thu, 2010-05-06 at 11:40 +0100, Paul Waring wrote:
Ashley Sheridan wrote:
It's part of the rounding problem you get with most languages out there.
Why can't you compare the floating point values though? Currency should
only have one decimal place anyway.
You can't compare floating
Ashley Sheridan wrote:
Why don't you store them as integer values and add in the decimal point
with something like sprintf() afterwards? Store the values as pence and
then you won't have any rounding problems.
If I was designing the system from scratch, that's what I'd do.
Unfortunately this
On 06/05/10 11:52, Paul Waring wrote:
Ashley Sheridan wrote:
Why don't you store them as integer values and add in the decimal point
with something like sprintf() afterwards? Store the values as pence and
then you won't have any rounding problems.
If I was designing the system from scratch,
On 6 May 2010 11:52, Paul Waring p...@xk7.net wrote:
If I was designing the system from scratch, that's what I'd do.
Unfortunately this is an add-on to a legacy system where currency values are
already stored as strings in the database (yes, not ideal I know, but you
have to work with what
David Otton wrote:
On 6 May 2010 11:52, Paul Waring p...@xk7.net wrote:
If I was designing the system from scratch, that's what I'd do.
Unfortunately this is an add-on to a legacy system where currency values are
already stored as strings in the database (yes, not ideal I know, but you
have to
On Thursday 06 May 2010 07:19:48 Paul Waring wrote:
David Otton wrote:
On 6 May 2010 11:52, Paul Waring p...@xk7.net wrote:
If I was designing the system from scratch, that's what I'd do.
Unfortunately this is an add-on to a legacy system where currency values
are already stored as
From: David McGlone
On Thursday 06 May 2010 07:19:48 Paul Waring wrote:
David Otton wrote:
On 6 May 2010 11:52, Paul Waring p...@xk7.net wrote:
If I was designing the system from scratch, that's what I'd do.
Unfortunately this is an add-on to a legacy system where currency
values
are
David McGlone wrote:
On Thursday 06 May 2010 07:19:48 Paul Waring wrote:
David Otton wrote:
On 6 May 2010 11:52, Paul Waring p...@xk7.net wrote:
If I was designing the system from scratch, that's what I'd do.
Unfortunately this is an add-on to a legacy system where currency values
are already
On Thursday 06 May 2010 08:39:03 Bob McConnell wrote:
From: David McGlone
On Thursday 06 May 2010 07:19:48 Paul Waring wrote:
David Otton wrote:
On 6 May 2010 11:52, Paul Waring p...@xk7.net wrote:
If I was designing the system from scratch, that's what I'd do.
Unfortunately this is
Paul Waring wrote:
I've got the following script which demonstrates a problem I'm having
with floating point numbers and intval:
$times100 = (-37.12 * 100);
print $times100 . \n;
$intval100 = intval($times100);
print $intval100 . \n;
print ($intval100 / 100) . \n;
I expect the output to be:
I think Bob has a good idea here, split the string values and the
concatenate them to make the whole value.
If the data is really stored in strings, you need to break it down into
substrings around the decimal and then convert both sides into integers
and combine them into an integer value. It
14 matches
Mail list logo
