Re: [perl #27690] Numeric comparison bug

2004-03-19 Thread Leopold Toetsch
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

Re: [perl #27690] Numeric comparison bug

2004-03-19 Thread mark . a . biggar
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 pro

Re: [perl #27690] Numeric comparison bug

2004-03-18 Thread Brent 'Dax' Royal-Gordon
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.

scanf (was Re: [perl #27690] Numeric comparison bug)

2004-03-18 Thread Uri Guttman
> "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

Re: [perl #27690] Numeric comparison bug

2004-03-18 Thread Leopold Toetsch
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, str

Re: [perl #27690] Numeric comparison bug

2004-03-18 Thread Brent 'Dax' Royal-Gordon
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 ha

Re: [perl #27690] Numeric comparison bug

2004-03-18 Thread Leopold Toetsch
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 th

Re: [perl #27690] Numeric comparison bug

2004-03-18 Thread Leopold Toetsch
S. Livingston <[EMAIL PROTECTED]> wrote: > Oops, use this one instead... "re"-fixes the exponent support... Thanks, applied. leo

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread Leopold Toetsch
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 poi

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread Skip Livingston
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 sen

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread Larry Wall
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

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread S. Livingston
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; !

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread S. Livingston
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 i

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread Larry Wall
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 t

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread Simon Glover
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

Re: [perl #27690] Numeric comparison bug

2004-03-17 Thread Leopold Toetsch
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 inher

[perl #27690] Numeric comparison bug

2004-03-16 Thread via RT
# New Ticket Created by Simon Glover # Please include the string: [perl #27690] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27690 > This code: new P0, .PerlNum set P0, -1.2 new P1, .PerlStri