On 2010-09-02 15:32, Jim wrote:
I was hoping I'd see some answer like... oh yeah... perl is smart enough
to handle that for you if you are willing to accept a performance hit...
My "bigrat" was meant like that. Did you already try it?
#!/usr/bin/perl
use strict;
use warnings;
use bigrat;
_
On 9/2/10 Thu Sep 2, 2010 2:00 PM, "Jim"
scribbled:
> On 9/2/2010 4:15 PM, Jim Gibson wrote:
>> My advice is to stay away from these modules unless you know what you are
>> doing. I find that double-precision floating-point arithmetic is always good
>> eno
t a time to
watch for any side effects.
Do you have any evidence that the use of either of these is warranted? So
far, you have only shown that printing floating-point numbers to some
limited precision involves rounding and can produce unexpected results. You
have not shown that the results are
> that you would advise of use of one over the other. They seem to be very
> similar.
>
> Thank you. I'll work use of one of these into a bit of code at a time to
> watch for any side effects.
Do you have any evidence that the use of either of these is warranted? So
far, yo
On 9/2/2010 2:51 PM, Ruud H.G. van Tol wrote:
On 2010-09-02 15:32, Jim wrote:
I was hoping I'd see some answer like... oh yeah... perl is smart enough
to handle that for you if you are willing to accept a performance hit...
My "bigrat" was meant like that. Did you already try it?
#!/usr/bin/
On Thu, Sep 2, 2010 at 10:03, Shawn H Corey wrote:
snip
> See `perldoc perlfaq4` and search for /Does Perl have a round() function?
> What about ceil() and floor()? Trig functions?/
snip
Or just say perldoc -q round, or go to
http://perldoc.perl.org/perlfaq4.html#Does-Perl-have-a-round()-functi
will perform in non-floating point mode
> and return precise answers up to some level of precision... just like your
> calculator. I undertand there are modules that will help, but it sounds like
> those involve significant coding changes. Or like others suggest, convert
> everything
On 10-09-02 09:32 AM, Jim wrote:
It's really not a question of it being perplexing more so than like I
said maddening in terms of why solutions just aren't intrinsic to the
programming language. If ops are slower, so what... throw some more hw
at the problem... hw is cheap... people's time isn't.
On 10-09-02 09:32 AM, Jim wrote:
It's really not a question of it being perplexing more so than like I
said maddening in terms of why solutions just aren't intrinsic to the
programming language. If ops are slower, so what... throw some more hw
at the problem... hw is cheap... people's time isn't.
l is smart enough
to handle that for you if you are willing to accept a performance hit...
just turn on so-and-so directive and perl will perform in non-floating
point mode and return precise answers up to some level of precision...
just like your calculator. I undertand there are modules that
On Thu, Sep 02, 2010 at 01:11:07AM +0200, Dr.Ruud wrote:
> On 2010-09-02 00:49, Paul Johnson wrote:
>
>> When you want to compare floating point numbers, check that their
>> difference is less than some appropriately small delta:
>>
>> $delta = 1e-8;
>>
>> if (abs($a - $b)< $delta) # numbers are
On 2010-09-01 22:46, Jim wrote:
Can anyone comment how they handle floating point precision situations
like this?
[...]
Note the lack of precision adding these simple numbers which do not have
a large number of digits to the right of the decimal.
If the line:
$total = sprintf("%.2f&quo
On 2010-09-02 00:49, Paul Johnson wrote:
When you want to compare floating point numbers, check that their
difference is less than some appropriately small delta:
$delta = 1e-8;
if (abs($a - $b)< $delta) # numbers are "equal"
Why call it delta when you can call it epsilon?
;)
It also has
On Wed, Sep 01, 2010 at 04:46:30PM -0400, Jim wrote:
> Can anyone comment how they handle floating point precision situations
> like this?
>
> Here is a basic toy program:
> #!/usr/bin/perl
>
> use strict;
>
> my $total = 0;
> my $a = 21835.30;
> my $b = -217
On 9/1/10 Wed Sep 1, 2010 1:46 PM, "Jim"
scribbled:
> Can anyone comment how they handle floating point precision situations
> like this?
>
> Here is a basic toy program:
> #!/usr/bin/perl
>
> use strict;
>
> my $total = 0;
> my $a = 21835.30;
> my
On Wed, Sep 1, 2010 at 17:32, Jim wrote:
> On 9/1/2010 5:04 PM, Chas. Owens wrote:
>>
>> On Wed, Sep 1, 2010 at 16:46, Jim wrote:
>>>
>>> Can anyone comment how they handle floating point precision situations
>>> like
>>> this?
>&g
On 10-09-01 05:32 PM, Jim wrote:
Thanks... that's the sort of answer I've been reading about... not crazy
about it... but it is what it is. This problem is more infuriating than
unsolvable in terms of why I need to even think about something like
this. My $0.99 calculator can computer those numbe
On 9/1/2010 5:04 PM, Chas. Owens wrote:
On Wed, Sep 1, 2010 at 16:46, Jim wrote:
Can anyone comment how they handle floating point precision situations like
this?
snip
I don't like either of these solutions.
How do others deal with this?
snip
Short answer: floating point numbers suck
On Wed, Sep 1, 2010 at 16:46, Jim wrote:
> Can anyone comment how they handle floating point precision situations like
> this?
snip
> I don't like either of these solutions.
>
> How do others deal with this?
snip
Short answer: floating point numbers suck, but are fast. If y
Can anyone comment how they handle floating point precision situations
like this?
Here is a basic toy program:
#!/usr/bin/perl
use strict;
my $total = 0;
my $a = 21835.30;
my $b = -21715.90;
my $c = 9652.20;
my $d = -9771.60;
print ("total = $total\n");
$total += $a;
print ("t
Hi Keith,
On Wednesday 21 Apr 2010 16:58:56 keithvb wrote:
> Shlomi Fish,
>
> Thanks for the response to my question. I'll get to work on it.
>
You're welcome. Next time, please reply to all recipients (you should have a
button for it.) I was the only one who got your reply. In the rare case
Hi Keith,
On Wednesday 21 Apr 2010 06:10:34 keithvb wrote:
> Hi,
>
> I need to create a grid, 24 cols, 16 rows on 4.5 cm centers
> on an HP laser printer. Some of the cells will be filled, some empty.
> Is there a way to do this in Perl?
>
Yes, there is. You can try generating a vector graphic
On 21 April 2010 04:10, keithvb wrote:
>
> Hi,
>
> I need to create a grid, 24 cols, 16 rows on 4.5 cm centers
> on an HP laser printer. Some of the cells will be filled, some empty.
> Is there a way to do this in Perl?
You going to have to break this project down. The actual document will
need
Hi,
I need to create a grid, 24 cols, 16 rows on 4.5 cm centers
on an HP laser printer. Some of the cells will be filled, some empty.
Is there a way to do this in Perl?
thanks,
Keith
~~~
Swim, bike, run, moo...
keit...@email.com
Keith vonBorstel
~~~
On 3/14/07, louis fridkis <[EMAIL PROTECTED]> wrote:
Why does Perl say 10.2 is 10.199
Because it is.
Within the limits of precision of your floating point format, you're
talking about the same number.
This isn't just Perl; every programming language has _something_
On 03/14/2007 11:19 AM, louis fridkis wrote:
Why does Perl say 10.2 is 10.199
Here is example code and output:
#!/usr/bin/perl -w
$add = 10.2;
print "$add\n";
printf "$add\n";
printf ("%40.35f\n", $add);
perl add1.pl
10.2
10.2
10.19928945726423989981413
If you have the
Why does Perl say 10.2 is 10.199
Here is example code and output:
#!/usr/bin/perl -w
$add = 10.2;
print "$add\n";
printf "$add\n";
printf ("%40.35f\n", $add);
perl add1.pl
10.2
10.2
10.19928945726423989981413
--
Lou Fridkis
Human Genetics
57920
27 matches
Mail list logo
