Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NaN, Inf, -Inf aren't padded with spaces in sprintf in Rakudo #3019

Closed
p6rt opened this issue Jan 3, 2013 · 17 comments
Closed

NaN, Inf, -Inf aren't padded with spaces in sprintf in Rakudo #3019

p6rt opened this issue Jan 3, 2013 · 17 comments

Comments

@p6rt
Copy link

p6rt commented Jan 3, 2013

Migrated from rt.perl.org#116280 (status was 'resolved')

Searchable as RT116280$

@p6rt
Copy link
Author

p6rt commented Jan 3, 2013

From @masak

<masak> rn​: say sprintf '%12.5f', NaN
<p6eval> rakudo f5037e​: OUTPUT«NaN␤»
<p6eval> ..niecza v24-12-g8e50362​: OUTPUT« NaN␤»
* masak submits rakudobug
<masak> rn​: say sprintf '%12.5f', Inf
<p6eval> niecza v24-12-g8e50362​: OUTPUT« Infinity␤»
<p6eval> ..rakudo f5037e​: OUTPUT«Inf␤»
<masak> rn​: say sprintf '%12.5f', -Inf
<p6eval> rakudo f5037e​: OUTPUT«-Inf␤»
<p6eval> ..niecza v24-12-g8e50362​: OUTPUT« -Infinity␤»

Modulo Niecza's preference for "Infinity" instead of "Inf", I believe
Niecza's outputs are correct each time, and Rakudo's are wrong. The
default for sprintf directives is to right-justify. This works fine
with numbers, but not with the special values NaN, Inf, and -Inf.

<masak> rn​: say sprintf '%12.5f', 42
<p6eval> rakudo f5037e, niecza v24-12-g8e50362​: OUTPUT« 42.00000␤»

@p6rt
Copy link
Author

p6rt commented Jan 8, 2013

From @FROGGS

This would mean to bring over 500 lines of C code to nqp/rakudo.

And this would mean that it doesn't get faster. Is it worth it?

@p6rt
Copy link
Author

p6rt commented Jan 8, 2013

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jan 8, 2013

From @masak

On Tue Jan 08 11​:40​:37 2013, FROGGS.de wrote​:

This would mean to bring over 500 lines of C code to nqp/rakudo.

Is that an absolute claim? What about wrappers?

And this would mean that it doesn't get faster. Is it worth it?

In my mind, correctness trumps speed. The current behavior seems
obviously wrong to me. As a user, I was concerned about correctness, not
speed. Hence the bug report.

@p6rt
Copy link
Author

p6rt commented Jan 8, 2013

From @pmichaud

On Tue, Jan 08, 2013 at 11​:52​:12AM -0800, Carl Mäsak via RT wrote​:

On Tue Jan 08 11​:40​:37 2013, FROGGS.de wrote​:

This would mean to bring over 500 lines of C code to nqp/rakudo.

Is that an absolute claim? What about wrappers?

Currently Rakudo uses Parrot's sprintf features. I wouldn't
recommend wholesale copying of Parrot's sprintf code, fwiw; I
think it could be done better, and there's a lot of stuff
that Parrot does in this area that we don't want.

And this would mean that it doesn't get faster. Is it worth it?

In my mind, correctness trumps speed.

Agreed. There are rare times when "fast but incorrect" is
okay, but I'm not sure this is one of them.

Beyond that, we ultimately will have to solve the formatted
print issue in the general case for Perl 6 implementations...
and C code might not be the best answer.

I wonder what it would take to write a version of sprintf in
Perl 6 or NQP directly, ignoring all speed aspects for the time
being. Then we'd at least have something portable, provably
correct, easily modified, and that could be used as a reference
implementation. It also might give some pointers on what can
be done to ultimately deal with speed issues.

Pm

@p6rt
Copy link
Author

p6rt commented Jan 8, 2013

From @jnthn

On 1/8/2013 22​:38, Patrick R. Michaud wrote​:

I wonder what it would take to write a version of sprintf in Perl 6 or
NQP directly, ignoring all speed aspects for the time being. Then we'd
at least have something portable, provably correct, easily modified,
and that could be used as a reference implementation. It also might
give some pointers on what can be done to ultimately deal with speed
issues.
This is my preference, for what it's worth. It would also fix the
sprintf of big integer issues we currently have, and be a win for porting.

/jnthn

@p6rt
Copy link
Author

p6rt commented Jan 8, 2013

From @coke

Is now a good time to ask if we still want to use the sprintf slang in perl
6?

On Tue, Jan 8, 2013 at 4​:54 PM, Jonathan Worthington <jonathan@​jnthn.net>wrote​:

On 1/8/2013 22​:38, Patrick R. Michaud wrote​:

I wonder what it would take to write a version of sprintf in Perl 6 or
NQP directly, ignoring all speed aspects for the time being. Then we'd at
least have something portable, provably correct, easily modified, and that
could be used as a reference implementation. It also might give some
pointers on what can be done to ultimately deal with speed issues.

This is my preference, for what it's worth. It would also fix the sprintf
of big integer issues we currently have, and be a win for porting.

/jnthn

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jan 9, 2013

From @pmichaud

On Tue, Jan 08, 2013 at 05​:02​:21PM -0500, Will Coleda wrote​:

Is now a good time to ask if we still want to use the sprintf
slang in perl 6?

Yes, see also Raku/old-design-docs#13 .

Pm

@p6rt
Copy link
Author

p6rt commented Jan 9, 2013

From @nwc10

On Tue, Jan 08, 2013 at 10​:54​:44PM +0100, Jonathan Worthington wrote​:

On 1/8/2013 22​:38, Patrick R. Michaud wrote​:

I wonder what it would take to write a version of sprintf in Perl 6 or
NQP directly, ignoring all speed aspects for the time being. Then we'd
at least have something portable, provably correct, easily modified,
and that could be used as a reference implementation. It also might
give some pointers on what can be done to ultimately deal with speed
issues.
This is my preference, for what it's worth. It would also fix the
sprintf of big integer issues we currently have, and be a win for porting.

I think that the right way to go is to write sprintf, or as much of it as is
possible, in NQP. Specifically, I suspect that all the parsing of the % codes
should be done in high level language, only kicking down to something lower
level for the actual formatting (and probably even then, only for the
floating point formatting, and maybe optimised versions for the most common
cases for decimals.)

It's going to end up being

a) faster to write
b) easier to maintain
c) easier to port
d) possible to optimise in ways that just can't be done via a monolithic
  call. For an example, see this PyPy blog entry​:

http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html

Nicholas Clark

@p6rt
Copy link
Author

p6rt commented Jan 9, 2013

From @nwc10

On Wed, Jan 09, 2013 at 10​:07​:21AM +0000, Nicholas Clark wrote​:

I think that the right way to go is to write sprintf, or as much of it as is
possible, in NQP. Specifically, I suspect that all the parsing of the % codes
should be done in high level language, only kicking down to something lower
level for the actual formatting (and probably even then, only for the
floating point formatting, and maybe optimised versions for the most common
cases for decimals.)

s/decimals/integers/

Which probably is just %d, or %d and %x

I'm going to quote this again :-)

http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html

Nicholas Clark

@p6rt
Copy link
Author

p6rt commented Aug 23, 2013

From @FROGGS

tests are at Raku/roast@2647c16652

@p6rt
Copy link
Author

p6rt commented Oct 25, 2014

From @usev6

Current behaviour as a status update​:

$ perl6-m -e 'say sprintf "%12.5f", NaN' ## similiar for Inf and -Inf
  0.00000

$ perl6-p -e 'say sprintf "%12.5f", Inf' ## similiar for NaN and -Inf
  0.00000

$ perl6-j -e 'say sprintf "%12.5f", -Inf' ## similiar for NaN and Inf
java.lang.NumberFormatException​: For input string​: "inf"

I'll adjusted the fudging in S32-str/sprintf.t (e.g. perl6-p no longer hangs).

@p6rt
Copy link
Author

p6rt commented Nov 10, 2015

From @usev6

With the next version bump for nqp this will be fixed​:

$ perl6-m -e 'say sprintf "%12.5f", -Inf'
  -Inf

$ perl6-m -e 'say sprintf "%12.5f", NaN'
  NaN

1 similar comment
@p6rt
Copy link
Author

p6rt commented Nov 10, 2015

From @usev6

With the next version bump for nqp this will be fixed​:

$ perl6-m -e 'say sprintf "%12.5f", -Inf'
  -Inf

$ perl6-m -e 'say sprintf "%12.5f", NaN'
  NaN

@p6rt
Copy link
Author

p6rt commented Nov 11, 2015

From @usev6

Tests were unfudged with commit Raku/roast@5c7ae5c3f5 and Raku/roast@53e1022caf.

I'm closing this ticket as 'resolved'.

1 similar comment
@p6rt
Copy link
Author

p6rt commented Nov 11, 2015

From @usev6

Tests were unfudged with commit Raku/roast@5c7ae5c3f5 and Raku/roast@53e1022caf.

I'm closing this ticket as 'resolved'.

@p6rt p6rt closed this as completed Nov 11, 2015
@p6rt
Copy link
Author

p6rt commented Nov 11, 2015

@usev6 - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant