[EMAIL PROTECTED] graced perl with these words of wisdom:
> Srt f lk wht wer dng 2 Nglsh
>.
*We*? Speak for yourself.
I find it intensely irritating to read posts on an email list like this
where people write "u" and "ur" when they're not talking about Burmese
honorifics or ancient Mesopotam
> Remember when one state (Kansas, Nebraska, or Arkansas, I think it
was)
> wanted to declare pi = 3, which would've made all the wheels in the
> state turn square overnight?
This isn't quite true, but the truth is equally weird. It was a bill
with a method to square a circle, which is to find a s
>But at some point it has to happen, whether u do it urself
>in some code or the arithmetic engine does it on its floats.
Understood. But the difference is that computers round beyond where we
humans generally care about. Not that it's actually rounding--as you
pointed out in another post--but
At 08:39 AM 3/19/2007 -0500, [EMAIL PROTECTED] wrote:
>I have a recollection from a computer math class many years ago that you
>should never, ever, round intermediate numbers in a calculation. The
>"rounding" itself then becomes part of the next step, then the next, and
>so on. While that may n
int was just that I can't think of a single practical case where
>you would be worried about whether 1.5 displayed as 1 or 2, and floating
>point numbers would have any place in your calculation. If your floating
>point answer is crud, then fiddling with it at the end of your
>calcul
all in one line instead of doing it in steps. Which is how I would have
done it too,
really, but easier for others to understand the code if it's broken down into
steps ;-). (You
also account for negtive floating point values, which I didn't -- my error!
:-P) Of course,
scaling t
>From wagnerc:
>That's all good for rounding intermediate numbers in a calculation...
I have a recollection from a computer math class many years ago that you
should never, ever, round intermediate numbers in a calculation. The
"rounding" itself then becomes part of the next step, then the next
I decided to write my own rounding algorithm that takes it out of Perl's
hands and does all the math itself using strings. Since it uses strings it
operates on the same literal value that a human would be looking at rather
than an opaque object. Floats are better thought of as opaque objects than
Chris Wagner wrote:
> OP was trying to round for display. In this case whatever rounding function
> u use has to output a string consistent with human rounding principles.
> Floating point numbers that a machine uses internally have no real relation
> to the real numbers that huma
At 05:32 PM 3/17/2007 +, Mark Dootson wrote:
>If you are using floating point arithmetic, you want unbiased rounding,
>'even' if you don't realise that this is good for you.
That's all good for rounding intermediate numbers in a calculation but the
OP was trying to r
nd results.
If you are using floating point arithmetic, you want unbiased rounding,
'even' if you don't realise that this is good for you.
It is always possible to make floating point operations look odd by
throwing specific literals into the mix.
Many folks seem to use floating
I think the safest way to round is to add 0.5, then use the
POSIX::floor function. The Perl docs warn against using int() for
just about anything (I don't have the exact quote handy):
use strict;
use POSIX qw(floor);
MAIN: {
foreach my $x (
0.0, 0.1, 0.2, 0.3, 0.4, 0.5,
At 12:48 AM 3/17/2007 -0500, [EMAIL PROTECTED] wrote:
>Incidentally, perl is a typeless language, compounding the problem even
more. That is, perl
>converts a variable or literal to an integer, a floating point double, or
text string on-the-fly as
>needed. A single line of perl code
At 08:04 PM 3/16/2007 -0400, Su, Yu \(Eugene\) wrote:
>I expect
>print sprintf("%.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f", 0.5,
1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5);
>will give me
>1 2 3 4 5 6 7 8 9 10
>but instead I get
>0 2 2 4 4 6 6 8 8 10
&g
Casteele/ShadowLord wrote:
>
> Actually, Bill's answer has an error.. Adding .05 just introduces a subtle
> error because some
> decimal floating point numbers cannot be exactly represented in binary form.
> For example:
>
> my ($i, $j);
> foreach $i (0.5, 1.5,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Actually, Bill's answer has an error.. Adding .05 just introduces a subtle
error because some
decimal floating point numbers cannot be exactly represented in binary form.
For example:
my ($i, $j);
foreach $i (0.5, 1.5, 2.5, 3.5, 4.5, 5.5, 6.5
get
>> 0 2 2 4 4 6 6 8 8 10
>>
>> How to round a floating-point value to an integer value using
>> (.5) up rule?
>
> I'd add .5 in the next place down :
>
> foreach (0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0) {
> pr
On Fri, 16 Mar 2007, Jan Dubois wrote:
> On Fri, 16 Mar 2007, Su, Yu (Eugene) wrote:
> > Interesting. Any explanation why sprintf treats 3.5 and 4.5
> > differently in rounding?
>
> It is called "unbiased rounding", which has the advantage of not
> adding an upward trend to your numbers:
>
> ht
> I expect
> > print sprintf("%.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f", 0.5,
> > 1.5, 2.5, 3.5, 4.5, 5.5,
> 6.5, 7.5, 8.5, 9.5);
> > will give me
> > 1 2 3 4 5 6 7 8 9 10
> > but instead I get
> > 0 2 2 4 4 6 6 8 8 10
> >
> >
Su, Yu (Eugene) wrote:
> Interesting. Any explanation why sprintf treats 3.5 and 4.5 differently in
> rounding?
Try adding this to the loop:
printf "%.20f", $_;
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To uns
: how to round a floating-point value to an integer value
Su, Yu (Eugene) wrote:
> I expect
> print sprintf("%.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f", 0.5, 1.5,
> 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5);
> will give me
> 1 2 3 4 5 6 7 8 9 10
> but instead I
Su, Yu (Eugene) wrote:
> I expect
> print sprintf("%.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f", 0.5, 1.5,
> 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5);
> will give me
> 1 2 3 4 5 6 7 8 9 10
> but instead I get
> 0 2 2 4 4 6 6 8 8 10
>
> How to round
I expect
print sprintf("%.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f %.0f", 0.5, 1.5,
2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5);
will give me
1 2 3 4 5 6 7 8 9 10
but instead I get
0 2 2 4 4 6 6 8 8 10
How to round a floating-point value to an integer value using (.5) up rule?
Thanks
- Original Message -
From: "David Budd" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 26, 2005 11:34 PM
Subject: Floating point
> It strikes me that a Closer_than($e,$x,$y) function that does the
suggested
> abs(1-$x/$y) <= $e
> would be a fine additi
It strikes me that a Closer_than($e,$x,$y) function that does the suggested
abs(1-$x/$y) <= $e
would be a fine addition to almost any programming language. The
compiler/interpreter writer could surely make it more efficient built-in than
leaving us to do the construction ourselves.
-Original Message-
From: James Sluka
Sent: Monday, July 25, 2005 9:11 AM
> Robert's solution (rounding with sprintf) is pretty good, except it
> requires that you know something about the numbers.
you are correct about the limitations of floating point accuracy, but in
th
Hello Mike
I just saw this site referenced today, they have a large list of other
sites:
http://www-128.ibm.com/developerworks/library/pa-bigiron1/?ca=dnt-65
Also look at the web site for Mike Cowlishaw who wrote software packages to
deal with Decimal Floating-Point. See also a Dr Dobbs
Mike wrote: [snipped]
> items that specifically referred to the floating point Error in the first
batch of Pentium chips
Sorry, I should have narrowed the search then. This is not specific to that
error, it is a consequence of
the FP number system representation. It arises in cert
Ed Chester <[EMAIL PROTECTED]> wrote:
> just a warning to be careful of subtracting or dividing similar
numbers in
> floating point and what your expectations are for the results. google
for
> 'catastrophic loss of precision' or similar, or check out the floating
point
&
this is top-posted because it doesn't follow from any one of the previous posts.
just a warning to be careful of subtracting or dividing similar numbers in
floating point
and what your expectations are for the results. google for 'catastrophic loss of
precision'
or similar, o
quot;.(1-$sum1/$sum2)."\n\n";
if ( abs(1-$sum1/$sum2) <= 1e-12 ) { ## new test
print("EQUAL\n");
} else {
print("NOT EQUAL\n");
}
-
OUTPUT:
sum1 = -237.15
sum2 = -237.15
Difference =-2.8421709430404e-014
Ratio
use "sprintf" to set the floating point field to 2 decimal places. (or
more, if you want them...)
$float1=-135.176# final values before rounding
$float2=-135.184
$float1=sprintf("%.2f",$float1);# force $float1 to be rounded at 2
de
use "sprintf" to set the floating point field to 2 decimal places. (or
more, if you want them...)
$float1=-135.176# final values before rounding
$float2=-135.184
$float1=sprintf("%.2f",$float1);# force $float1 to be rounded at 2
de
35 PM 7/24/2005, $Bill Luebkert wrote:
> >John Deighan wrote:
> > > At 02:20 PM 7/24/2005, Ed Chester wrote:
> > >
> > >
> > >>John Deighan::
> > >>
> > >>>Is there a safe way to compare 2 floating point numbers in Perl?
&
At 04:07 PM 7/24/05 -0400, John Deighan wrote:
>Sorry about the lack of sample code, but I know that people who work
>with floating point numbers know about this problem, and I was
>wondering what the best solution was. Here is sample code with
Well ur right, the easy answer is to do
At 10:40 PM 7/24/05 -0400, Ted Schuerzinger wrote:
>Ken Barker graced perl with these words of wisdom:
>> What kind of post is this?
>It was an informative help post, made especially informative and helpful
>by the fact that the relevant material was included at the relevant point
>in the code, a
Ken Barker graced perl with these words of wisdom:
> What kind of post is this?
It was an informative help post, made especially informative and helpful
by the fact that the relevant material was included at the relevant point
in the code, as opposed to being top-posted.
> I do not see that an
$bob within $range2\n");
}
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of John Deighan
> Sent: Monday, July 25, 2005 1:09 AM
> To: perl-win32-users@listserv.ActiveState.com
> Subject: comparing floating point numbers
>
gt;
>>>Is there a safe way to compare 2 floating point numbers in Perl? [snip]
>>>My debugger says that they're both '630.24' [snip]
>>>However, the == test fails and the != test succeeds
>>
>>can you post code with the comparison == that fail
John Deighan wrote:
> At 02:20 PM 7/24/2005, Ed Chester wrote:
>
>
>>John Deighan::
>>
>>>Is there a safe way to compare 2 floating point numbers in Perl? [snip]
>>>My debugger says that they're both '630.24' [snip]
>>>However, th
- Original Message -
From: "John Deighan"
> I can only think of taking their difference and checking if
> that's less than something like 0.001. Is there a better way?
>
No.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@li
ad the introduction to chapter 2 of the Perl Cookbook, 2d Ed and recipes 2.2
and 2.3. for idea of how to deal with this.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
John Deighan
Sent: Sunday, July 24, 2005 3:07 PM
To: perl-win32-users@listserv.ActiveSta
When I substituted 'eq' versus '==' it works.
Not sure why though...
Ken
At 03:07 PM 7/24/2005, John Deighan wrote:
At 02:20 PM 7/24/2005, Ed Chester wrote:
John Deighan::
> Is there a safe way to compare 2 floating point numbers in Perl? [snip]
> My debugger says
At 02:20 PM 7/24/2005, Ed Chester wrote:
John Deighan::
> Is there a safe way to compare 2 floating point numbers in Perl? [snip]
> My debugger says that they're both '630.24' [snip]
> However, the == test fails and the != test succeeds
can you post code with the compa
John Deighan::
> Is there a safe way to compare 2 floating point numbers in Perl? [snip]
> My debugger says that they're both '630.24' [snip]
> However, the == test fails and the != test succeeds
can you post code with the comparison == that fails ?
if the debugger says t
Is there a safe way to compare 2 floating point numbers in Perl? I
have 2 numbers, one of which was created by accumulating a series of
other numbers into it - the other was entered directly. My debugger
says that they're both '630.24', and when I print them, they both
p
> 1100
> If the approach is correct, then what are the rules for setting the bits
> in floating point numbers ?
IEEE standard 754. there's a sign bit, an offset exponent (11 bits) and
the rest is the mantissa (withou
$Bill Luebkert wrote:
use strict;
my $little_endian = unpack ('c', pack ('s', 1));# check for x86
foreach my $num (-3.0, -2.0, -1.0, 0.0, 1.0, 2.0, 3.0, 4.5,
-2.2250738585072014e-308, 1.7976931348623146e+308) {
my $x = unpack ('b*', pack 'd', $num);
$x = join '', reverse s
Sisyphus wrote:
> Hi,
>
> Trying to view the internal "native" representation of floating point
> numbers, so I tried:
>
> perl -e "print unpack('B*', pack('d', 1.0))"
> perl -e "print unpack('B*', pack('d',
Hi,
Trying to view the internal "native" representation of floating point
numbers, so I tried:
perl -e "print unpack('B*', pack('d', 1.0))"
perl -e "print unpack('B*', pack('d', 2.0))"
perl -
Just the same, ought to do it
$x = 50.50;
$y = 36.45;
if ($x > $y) { print "$x is greater than $y\n" }
else { print "$x is less than or equal to $y\n" }
prints out "50.5 is greater than 36.45" on my machine...
HTH,
Deane
"Krishna, Hari" <[EMAIL PROTECTED]>
Sent by: [EMAIL PR
51 matches
Mail list logo
