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

Skipped test in S02-types/nan.t for 'NaN ** 0' #3804

Closed
p6rt opened this issue May 3, 2015 · 8 comments
Closed

Skipped test in S02-types/nan.t for 'NaN ** 0' #3804

p6rt opened this issue May 3, 2015 · 8 comments

Comments

@p6rt
Copy link

p6rt commented May 3, 2015

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

Searchable as RT124450$

@p6rt
Copy link
Author

p6rt commented May 18, 2015

From @usev6

There is a test for 'NaN ** 0' returning 0 in S02-types/nan.t skipped for the reason 'unspecced and inconsistent'. Also there is a comment above the test​:

# if we say that 0**0 and Inf**0 both give 1 (sse below), then for which
# number or limit whould $number ** 0 be different from 1? so maybe just say
# that NaN ** 0 == 1?

MoarVM and JVM agree with that last suggestion​:

< bartolin> r​: say NaN ** 0
<+camelia> rakudo-{moar,jvm} d8ce4c​: OUTPUT«1␤»

As far as I understand it, that is in line with the IEEE 754 Standard 2008 (e.g. http://stackoverflow.com/questions/17863619/why-does-nan0-1).

I'm inclined to change the test accordingly (expecting 1 as the result) and unfudge it. Any opinions?

1 similar comment
@p6rt
Copy link
Author

p6rt commented May 18, 2015

From @usev6

There is a test for 'NaN ** 0' returning 0 in S02-types/nan.t skipped for the reason 'unspecced and inconsistent'. Also there is a comment above the test​:

# if we say that 0**0 and Inf**0 both give 1 (sse below), then for which
# number or limit whould $number ** 0 be different from 1? so maybe just say
# that NaN ** 0 == 1?

MoarVM and JVM agree with that last suggestion​:

< bartolin> r​: say NaN ** 0
<+camelia> rakudo-{moar,jvm} d8ce4c​: OUTPUT«1␤»

As far as I understand it, that is in line with the IEEE 754 Standard 2008 (e.g. http://stackoverflow.com/questions/17863619/why-does-nan0-1).

I'm inclined to change the test accordingly (expecting 1 as the result) and unfudge it. Any opinions?

@p6rt
Copy link
Author

p6rt commented May 18, 2015

From @lizmat

On 18 May 2015, at 22​:19, Christian Bartolomaeus via RT <bugs-comment@​bugs6.perl.org> wrote​:

There is a test for 'NaN ** 0' returning 0 in S02-types/nan.t skipped for the reason 'unspecced and inconsistent'. Also there is a comment above the test​:

# if we say that 0**0 and Inf**0 both give 1 (sse below), then for which
# number or limit whould $number ** 0 be different from 1? so maybe just say
# that NaN ** 0 == 1?

MoarVM and JVM agree with that last suggestion​:

< bartolin> r​: say NaN ** 0
<+camelia> rakudo-{moar,jvm} d8ce4c​: OUTPUT«1␤»

As far as I understand it, that is in line with the IEEE 754 Standard 2008 (e.g. http://stackoverflow.com/questions/17863619/why-does-nan0-1).

I'm inclined to change the test accordingly (expecting 1 as the result) and unfudge it. Any opinions?

+1

Liz

@p6rt
Copy link
Author

p6rt commented May 21, 2015

From @masak

bartolin (>)​:

I'm inclined to change the test accordingly (expecting 1 as the
result) and unfudge it. Any opinions?

+1

@p6rt
Copy link
Author

p6rt commented May 21, 2015

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

@p6rt
Copy link
Author

p6rt commented May 21, 2015

From @usev6

On Mon May 18 13​:19​:37 2015, bartolin@​gmx.de wrote​:

There is a test for 'NaN ** 0' returning 0 in S02-types/nan.t skipped
for the reason 'unspecced and inconsistent'.
[...]
I'm inclined to change the test accordingly (expecting 1 as the
result) and unfudge it.

I changed the test (and a second test for the same thing in S32-num/power.t) with commit Raku/roast@a30ffc1ed0

I'm closing this ticket as 'resolved'.

1 similar comment
@p6rt
Copy link
Author

p6rt commented May 21, 2015

From @usev6

On Mon May 18 13​:19​:37 2015, bartolin@​gmx.de wrote​:

There is a test for 'NaN ** 0' returning 0 in S02-types/nan.t skipped
for the reason 'unspecced and inconsistent'.
[...]
I'm inclined to change the test accordingly (expecting 1 as the
result) and unfudge it.

I changed the test (and a second test for the same thing in S32-num/power.t) with commit Raku/roast@a30ffc1ed0

I'm closing this ticket as 'resolved'.

@p6rt p6rt closed this as completed May 21, 2015
@p6rt
Copy link
Author

p6rt commented May 21, 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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant