On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
On Mon, 8 Aug 2005, John Siracusa wrote:
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are the performance/memory implications? I don't object to the
prereq,
On Mon, Aug 08, 2005 at 09:02:06AM -1000, Joshua Hoblitt wrote:
On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
On Mon, 8 Aug 2005, John Siracusa wrote:
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are
Since nobody has commented on this patch does that mean everybody agrees
that it's a good idea? :)
-J
--
On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote:
Hi Folks,
I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.
One of 'epoch' test
On Mon, 25 Jul 2005, Joshua Hoblitt wrote:
a) do nothing... nobody else seems to have noticed
b) document the limited precision issue
c) change the API to some awful Fortranish a part + b part to preserve
precision
d) turn the epoch parameter into a Math::BigFloat so a high resolution
'string'
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are the performance/memory implications? I don't object to the prereq,
but I would like to know if we're in for any new speed/bloat issues. (I
only really care about per-object
On Mon, 8 Aug 2005, John Siracusa wrote:
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are the performance/memory implications? I don't object to the prereq,
but I would like to know if we're in for any new speed/bloat issues.
On Mon, 25 Jul 2005, Joshua Hoblitt wrote:
a) do nothing... nobody else seems to have noticed
b) document the limited precision issue
c) change the API to some awful Fortranish a part + b part to preserve
precision
d) turn the epoch parameter into a Math::BigFloat so a high resolution
On Mon, Aug 08, 2005 at 09:31:10AM -0500, Dave Rolsky wrote:
On Mon, 25 Jul 2005, Joshua Hoblitt wrote:
a) do nothing... nobody else seems to have noticed
b) document the limited precision issue
c) change the API to some awful Fortranish a part + b part to preserve
precision
d) turn the
Here's a quick demonstration of the issue...
--
#!/usr/bin/perl
use Math::BigFloat;
use Math::BigInt;
myfunc(1045469647.198189);
myfunc('1045469647.198189');
sub myfunc {
my $n = shift;
my $fraction = Math::BigFloat-new( $n ) - int( $n );
printf %s\n, int ( $fraction * 1e9
Hi Folks,
I stumbled across a limited precision issue while working on
DateTime::Format::DateParse.
One of 'epoch' test values used in Date::Parse is 1045469647.198189,
which is just beyond the precision of an IEEE 754 64bit value (a C
double). So internally (on all IEEE 754 compliant
10 matches
Mail list logo
