On Wed, Jun 03, 2009 at 12:51:29PM -0000, Parrot wrote: > #724: [bug] Parrot fails numeric conversion of ucs2 strings > ----------------------+----------------------------------------------------- > Reporter: pmichaud | Owner: > Type: bug | Status: reopened > Priority: normal | Milestone: > Component: core | Version: 1.2.0 > Severity: medium | Resolution: > Keywords: | Lang: > Patch: | Platform: > ----------------------+----------------------------------------------------- > > Comment(by particle): > > Replying to [comment:4 bacek]: > > Branch (misnamed) tt24_unicode_numification) ready for merge. Only one > concern: we never declared format for "NaN", "Inf" and "-Inf". Old version > based on atof supported some bizzare variants like " nAn", " inF" and " > InFiNity". Version in branch support only canonical "Inf", "-Inf" and > "NaN". Question is - should I mimic atof behaviour or we can declare > standard format for it? > > > the canonical representation for NaN and Inf are 'NaN' and 'Inf'. other > variants of capitalization or spelling are not valid; they must be > converted to the format above. don't mimic the old atof behavior.
FWIW, that's not what I remember us discussing in the Perl 6 design meeting (2009-01-28). In Perl 6 at least, "inf" is treated as infinity, not zero. In a larger sense, most groups seem to have accepted that "inf" and "nan" conversions should be case-insensitive for parsing. Displaying the mixed-case "Inf" and "NaN" on output is (afaik) a P6-only phenomenon, most other languages seem to consistently do either "inf" or "INF" (often by simply deferring to whatever atof does). Pm _______________________________________________ parrot-tickets mailing list [email protected] http://lists.parrot.org/mailman/listinfo/parrot-tickets
