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
>> enough. I have been programming in scient
On 9/2/2010 4:15 PM, Jim Gibson wrote:
On 9/2/10 Thu Sep 2, 2010 12:52 PM, "Jim"
scribbled:
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 ac
On 9/2/10 Thu Sep 2, 2010 12:52 PM, "Jim"
scribbled:
> 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...
>
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
On Thu, Sep 2, 2010 at 09:32, Jim wrote:
snip
> 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...
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.
On 9/2/2010 8:53 AM, Paul Johnson wrote:
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)
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
20 matches
Mail list logo
