The real problem is that you always want to use exactly the same code for
ALL cases of string-to-float conversion. The first public example of this
problem was the FORTRAN II compiler from IBM in the 60's. The compiler and
the IO library was written by two different people and so constants in
Mark A Biggar [EMAIL PROTECTED] wrote:
The real problem is that you always want to use exactly the same code for
ALL cases of string-to-float conversion.
Yep, was outlined by Larry too. That's already changed.
[ Please don't quote the whole thread, thanks ]
leo
Skip Livingston [EMAIL PROTECTED] wrote:
IMCC uses atof() because it doesn't use (need?) any of the encoding
stuff.
Well imcc used to be a standalone language compiler that converted PIR
to PASM, which got then assembled to bytecode by assembler.pl. Now
imcc is fully integrated, parrot is the
How close is string_to_num() to being adequate for Parrot_sprintf()'s
purposes? (It currently falls back to the platform sprintf for floats,
because I didn't have, and still don't have, any idea how to properly
format a float.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
How close is string_to_num() to being adequate for Parrot_sprintf()'s
purposes? (It currently falls back to the platform sprintf for floats,
because I didn't have, and still don't have, any idea how to properly
format a float.)
Well,
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT BTW sscanf() is missing too.
perl5 mever had a scanf (or variation) and for good reason IIRC. it was
never needed and it has a very nasty api. i hated using it in c because
you could never control how much to read and parse and also find out
Leopold Toetsch wrote:
BTW sscanf() is missing too.
I have never used scanf. I have no idea what it does or how.
Therefore, I'm hardly qualified to write an implementation of it.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Simon Glover [EMAIL PROTECTED] wrote:
This code:
new P0, .PerlNum
set P0, -1.2
new P1, .PerlString
set P1, -1.2
eq_num P0, P1, OK
print not
OK: print ok\n
end
[And yes, I'm well aware of the problems inherent in doing
On Wed, 17 Mar 2004, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
This code:
new P0, .PerlNum
set P0, -1.2
new P1, .PerlString
set P1, -1.2
eq_num P0, P1, OK
print not
OK: print ok\n
end
[And
On Wed, Mar 17, 2004 at 11:22:01AM -0500, Simon Glover wrote:
: OK, that suggests that there's a bug somewhere in our string-number
: conversion. Either that, or we're going to have to live with the fact
: that 1.2 and '1.2' are not the same number (which would suck).
The basic bug has to be
Its the old problem of rounding errors in floating point arithmetic.
In string_to_num() in src/string.c,
f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
Which in this case translates to 12.0*-1*0.1 which is -1.2000...2 != -1.2.
I replaced this bit of code from a block I found
Oops, use this one instead... re-fixes the exponent support...
*** tmp/parrot/src/string.c Sat Mar 6 03:00:06 2004
--- parrot/src/string.c Wed Mar 17 16:05:50 2004
***
*** 1836,1844
int exp_sign = 0;
INTVAL in_exp = 0;
INTVAL in_number = 0;
!
On Wed, Mar 17, 2004 at 04:13:40PM -0500, S. Livingston wrote:
: Oops, use this one instead... re-fixes the exponent support...
This still doesn't explain why the compiler would be using a different
routine to turn the string 1.2 into a number than the run time does.
This is not code that should
IMCC uses atof() because it doesn't use (need?) any of the encoding
stuff. (See add_const_num() in imcc/pbc.c). Packing the cstring up
in a STRING then calling string_to_num() *fixes* the problem, but it
doesn't address the issue Larry brought up. The interpreter makes
heavy use of the encoding
Larry Wall [EMAIL PROTECTED] wrote:
The basic bug has to be that it's using two different routines to
do the conversion (or possibly there's one routine that's paying
attention to some context it shouldn't be paying attention to--but
that seems less likely).
Well, that's a very good point.
15 matches
Mail list logo
