Skip Menu |
Report information
Id: 85750
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: Pascal.Stumpf [at] cubes.de
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Test failures on OpenBSD
Date: Wed, 9 Mar 2011 19:38:12 +0100
To: rakudobug [...] perl.org
From: Pascal Stumpf <Pascal.Stumpf [...] cubes.de>
Download (untitled) / with headers
text/plain 719b
The following test failures have so far been confirmed for all tested architectures (amd64, macppc, mips64el): Test Summary Report ------------------- t/spec/S02-builtin_data_types/instants-and-durations.t (Wstat: 0 Tests: 13 Failed: 1) Failed test: 9 t/spec/S03-operators/arith.rakudo (Wstat: 0 Tests: 135 Failed: 1) Failed test: 107 t/spec/S19-command-line/dash-e.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/spec/S32-num/power.rakudo (Wstat: 0 Tests: 40 Failed: 1) Failed test: 11 Files=542, Tests=27334, 4180 wallclock secs ( 9.85 usr 88.48 sys + 3471.31 cusr 488.01 csys = 4057.65 CPU) Result: FAIL
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 949b
On Wed Mar 09 10:38:06 2011, Pascal.Stumpf@cubes.de wrote: Show quoted text
> The following test failures have so far been confirmed for all tested > architectures (amd64, macppc, mips64el): > > Test Summary Report > ------------------- > t/spec/S02-builtin_data_types/instants-and-durations.t (Wstat: 0 > Tests: 13 Failed: 1) > Failed test: 9 > t/spec/S03-operators/arith.rakudo (Wstat: 0 > Tests: 135 Failed: 1) > Failed test: 107 > t/spec/S19-command-line/dash-e.t (Wstat: 0 > Tests: 3 Failed: 2) > Failed tests: 2-3 > t/spec/S32-num/power.rakudo (Wstat: 0 > Tests: 40 Failed: 1) > Failed test: 11 > Files=542, Tests=27334, 4180 wallclock secs ( 9.85 usr 88.48 sys + > 3471.31 cusr 488.01 csys = 4057.65 CPU) > Result: FAIL >
I know it's been a while, but can you confirm that these failures are still occurring with rakudo HEAD? -- Will "Coke" Coleda
Subject: Re: [perl #85750] Test failures on OpenBSD
Date: Mon, 27 May 2013 18:36:54 +0200
To: perl6-bugs-followup [...] perl.org
From: Pascal Stumpf <Pascal.Stumpf [...] cubes.de>

Message body is not shown because it is too large.

Subject: Re: [perl #85750] Test failures on OpenBSD
Date: Wed, 29 May 2013 13:53:40 +0200
To: perl6-compiler [...] perl.org
From: Tobias Leich <email [...] froggs.de>
Download (untitled) / with headers
text/plain 21.9k

Message body is not shown because it is too large.

CC: Will Coleda via RT <perl6-bugs-followup [...] perl.org>
Subject: Re: [perl #85750] Test failures on OpenBSD
Date: Wed, 29 May 2013 08:41:19 -0400
To: Pascal Stumpf <Pascal.Stumpf [...] cubes.de>
From: Will Coleda <will [...] coleda.com>
Download (untitled) / with headers
text/plain 22.3k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/html 25.3k

Message body is not shown because it is too large.

Subject: Re: [perl #85750] Test failures on OpenBSD
Date: Wed, 29 May 2013 16:29:31 +0200
To: perl6-bugs-followup [...] perl.org
From: Pascal Stumpf <Pascal.Stumpf [...] cubes.de>

Message body is not shown because it is too large.

CC: Will Coleda via RT <perl6-bugs-followup [...] perl.org>
Subject: Re: [perl #85750] Test failures on OpenBSD
Date: Thu, 30 May 2013 11:58:10 -0400
To: Pascal Stumpf <Pascal.Stumpf [...] cubes.de>
From: Will Coleda <will [...] coleda.com>
Download (untitled) / with headers
text/plain 846b





On Wed, May 29, 2013 at 10:29 AM, Pascal Stumpf <Pascal.Stumpf@cubes.de> wrote:
Show quoted text
On Wed, 29 May 2013 05:42:27 -0700, "Will Coleda via RT" wrote:
> How are you running the spec tests? - it looks like you've included some
> that are not marked as runnable by rakudo.

I think I did a "gmake spectest_full".  Shall I run just the spectest
target again or can you just ignore the tests that are not marked as
runnable?

spectest_full is only useful if you're a developer looking for more tests to run.

If you could rerun with just 'gmake spectest' that'll give us a much better idea of what's actually broken. And for those tests that fail, please provide the verbose output when running each of those test files.

You can get verbose output for a single test file with: 'make t/spec/S02-types/bool.t'

Thanks. 


--
Will "Coke" Coleda
Subject: Re: [perl #85750] Test failures on OpenBSD
Date: Sat, 01 Jun 2013 08:51:05 +0200
To: perl6-bugs-followup [...] perl.org
From: Pascal Stumpf <Pascal.Stumpf [...] cubes.de>
Download (untitled) / with headers
text/plain 10.1k
On Thu, 30 May 2013 08:58:50 -0700, "Will Coleda via RT" wrote: Show quoted text
> On Wed, May 29, 2013 at 10:29 AM, Pascal Stumpf <Pascal.Stumpf@cubes.de>wrote: >
> > On Wed, 29 May 2013 05:42:27 -0700, "Will Coleda via RT" wrote:
> > > How are you running the spec tests? - it looks like you've included some > > > that are not marked as runnable by rakudo.
> > > > I think I did a "gmake spectest_full". Shall I run just the spectest > > target again or can you just ignore the tests that are not marked as > > runnable?
> > > spectest_full is only useful if you're a developer looking for more tests > to run. > > If you could rerun with just 'gmake spectest' that'll give us a much better > idea of what's actually broken. And for those tests that fail, please > provide the verbose output when running each of those test files. > > You can get verbose output for a single test file with: 'make > t/spec/S02-types/bool.t' > > Thanks.
Hi, here's the test summary and output from failed tests: Test Summary Report ------------------- t/spec/S02-literals/char-by-name.rakudo (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: No plan found in TAP output t/spec/S03-operators/arith.rakudo (Wstat: 0 Tests: 143 Failed: 1) Failed test: 112 t/spec/S05-mass/named-chars.rakudo (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: No plan found in TAP output t/spec/S05-mass/properties-block.rakudo (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: No plan found in TAP output t/spec/S05-mass/properties-derived.rakudo (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: No plan found in TAP output t/spec/S05-mass/properties-general.rakudo (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: No plan found in TAP output t/spec/S19-command-line/dash-e.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 t/spec/S32-hash/delete-adverb.rakudo (Wstat: 0 Tests: 108 Failed: 0) TODO passed: 17, 22-23, 25, 28-29, 31, 34-37, 39, 54 68 t/spec/S32-num/int.rakudo (Wstat: 256 Tests: 86 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 107 tests but ran 86. t/spec/S32-num/power.rakudo (Wstat: 0 Tests: 50 Failed: 1) Failed test: 18 Files=738, Tests=25798, 5896 wallclock secs (11.98 usr 118.69 sys + 4175.85 cusr 1257.87 csys = 5564.39 CPU) Result: FAIL t/spec/S03-operators/arith.rakudo .. 1..143 ok 1 - 1 == 1 ok 2 - 3 == 3 ok 3 - -3 == -3 ok 4 - -1 == -1 ok 5 - 1 == 1 ok 6 - 3 == 3 ok 7 - -3 == -3 ok 8 - -1 == -1 ok 9 - 0 == 0 ok 10 - 0.5 == 0.5 ok 11 - modulo with negative divisor (1) ok 12 - modulo with negative divisor (2) ok 13 - ok 14 - ok 15 - ok 16 - ok 17 - 2 == 2 ok 18 - 2 == 2 ok 19 - 90 == 90 ok 20 - -16 == -16 ok 21 - -61 == -61 ok 22 - 3 == 3 ok 23 - 0 == 0 ok 24 - 0 == 0 ok 25 - 3 == 3 ok 26 - -13 == -13 ok 27 - 2 == 2 ok 28 - -12 == -12 ok 29 - 10 == 10 ok 30 - -161 == -161 ok 31 - -151 == -151 ok 32 - 7 == 7 ok 33 - 0 == 0 ok 34 - 0 == 0 ok 35 - 2147483647 == 2147483647 ok 36 - 2147483647 == 2147483647 ok 37 - 1 == 1 ok 38 - -1 == -1 ok 39 - 4294967290 == 4294967290 ok 40 - -4294967290 == -4294967290 ok 41 - 4294967297 == 4294967297 ok 42 - -4294967297 == -4294967297 ok 43 - -1 == -1 ok 44 - 1 == 1 ok 45 - 4294967290 == 4294967290 ok 46 - -4294967290 == -4294967290 ok 47 - -4294967297 == -4294967297 ok 48 - 4294967297 == 4294967297 ok 49 - 3 == 3 ok 50 - -6 == -6 ok 51 - -9 == -9 ok 52 - 12 == 12 ok 53 - 2147395599 == 2147395599 ok 54 - -2147395599 == -2147395599 ok 55 - -2147395599 == -2147395599 ok 56 - 2147395599 == 2147395599 ok 57 - 2 == 2 ok 58 - 2 == 2 ok 59 - 1.2 == 1.2 ok 60 - -1.2 == -1.2 ok 61 - 2 == 2 ok 62 - -4 == -4 ok 63 - -7 == -7 ok 64 - 14 == 14 ok 65 - 9 div 4 == 2 not ok 66 - -9 div 4 == -3# TODO negative div # got: '-2' # expected: '-3' not ok 67 - 9 div -4 == -3# TODO negative div # got: '-2' # expected: '-3' ok 68 - -9 div -4 == 2 ok 69 - 13 mod 4 not ok 70 - -13 mod 4# TODO negative mod # got: '-1' # expected: '3' not ok 71 - 13 mod -4# TODO negative mod # got: '1' # expected: '-3' ok 72 - -13 mod -4 ok 73 - 1.25 == 1.25 ok 74 - -1.75 == -1.75 ok 75 - -2.25 == -2.25 ok 76 - 2.75 == 2.75 ok 77 - ok 78 - ok 79 - ok 80 - ok 81 - ok 82 - ok 83 - ** is right associative ok 84 - infix:<**> is right associative ok 85 - i^2 == -1 ok 86 - sqrt(-i)**4 ==-1 ok 87 - (-1+0i)**0.5 == i ok 88 - ok 89 - ok 90 - ok 91 - ok 92 - ok 93 - ok 94 - ok 95 - ok 96 - ok 97 - ok 98 - ok 99 - ok 100 - ok 101 - ok 102 - ok 103 - ok 104 - ok 105 - ok 106 - ok 107 - ok 108 - 100**Inf ok 109 - Inf**Inf ok 110 - 0.9**Inf converges towards 0 ok 111 - 1.1**Inf diverges towards Inf not ok 112 - # got: 'NaN' # expected: '1' ok 113 - ok 114 - ok 115 - ok 116 - ok 117 - ok 118 - ok 119 - ok 120 - ok 121 - ok 122 - ok 123 - ok 124 - ok 125 - ok 126 - ok 127 - ok 128 - ok 129 - NaN**NaN ok 130 - NaN**Inf ok 131 - Inf**NaN 0 not ok 132 - Modulo zero dies and is catchable# TODO modulo by zero 0 not ok 133 - Modulo zero dies and is catchable with VInt/VRat variables# TODO modulo by zero 0 not ok 134 - Modulo zero dies and is catchable with VRef variables# TODO die or fail? ok 135 - Division by zero dies and is catchable ok 136 - Division by zero dies and is catchable with VInt div VRat variables ok 137 - Division by zero dies and is catchable with VRef variables ok 138 - Can calcualte 25! without loss of precision ok 139 - Can calcualte 2**65 without loss of precision ok 140 - no more Rat literals, infix:</> has normal left assoc ok 141 - infix:<+> is not iffy enough ok 142 - -Inf warns (and yields 0) but does not give an error ok 143 - infix:<-> produces a proper Int, even if some of the types invovled have mixins # Looks like you failed 1 tests of 143 # FUDGED! Failed 1/143 subtests Test Summary Report ------------------- t/spec/S03-operators/arith.rakudo (Wstat: 0 Tests: 143 Failed: 1) Failed test: 112 Files=1, Tests=143, 20 wallclock secs ( 0.11 usr 0.04 sys + 12.86 cusr 2.65 csys = 15.66 CPU) Result: FAIL t/spec/S19-command-line/dash-e.t .. 1..3 ok 1 - -e print $something works not ok 2 - -e print $something works with non-ASCII string literals # got out: "ȧ" # expected out: "ȧ" not ok 3 - -e works with non-ASCII program texts # got status: 1 # got out: "" # expected out: "23" # got err: "\x[1b][31m===\x[1b][0mSORRY!\x[1b][31m===\x[1b][0m\nTwo terms in a row\nat -e:1\n------> \x[1b][32mprint <1 2> \x[1b][33m⏏\x[1b][31m»+« <1 1>\x[1b][0m\n expecting any of:\n postfix\n infix stopper\n infix or meta-infix\n statement end\n statement modifier\n statement modifier loop\n" # expected err: "" # Looks like you failed 2 tests of 3 Failed 2/3 subtests Test Summary Report ------------------- t/spec/S19-command-line/dash-e.t (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3 Files=1, Tests=3, 27 wallclock secs ( 0.05 usr 0.53 sys + 17.48 cusr 7.31 csys = 25.37 CPU) Result: FAIL t/spec/S32-num/power.rakudo .. 1..50 ok 1 - 0 ** 0 == 1 ok 2 - 0 ** 1 == 0 ok 3 - 1 ** 2 == 1 ok 4 - 4 ** 0 == 1 ok 5 - 4 ** 1 == 4 ok 6 - 4 ** 2 == 16 ok 7 - 0 ** 4553535345364535345634543534 == 0 ok 8 - 1 ** 4553535345364535345634543534 == 1 not ok 9 - -1 ** 4553535345364535345634543534 == 1# TODO Simple bigint optimizations NYI # got: '-Inf' # expected: '1' not ok 10 - -1 ** 4553535345364535345634543534 == -1# TODO Simple bigint optimizations NYI # got: '-Inf' # expected: '-1' ok 11 - 2 ** 4553535345364535345634543534 == Inf not ok 12 - -2 ** 4553535345364535345634543534 == Inf# TODO Simple bigint optimizations NYI # got: '-Inf' # expected: 'Inf' ok 13 - -2 ** 4553535345364535345634543534 == -Inf ok 14 - 4 ** .5 == 2 ok 15 - 4 ** (1/2) == 2 ok 16 - 4 ** (-1/2) == 1/2 ok 17 - -2 ** 2 = 4 not ok 18 - 1**Inf=1 # got: 'NaN' # expected: '1' ok 19 - 0**Inf=0 ok 20 - Inf**2 = Inf ok 21 - (-Inf)**3 = -Inf ok 22 - Inf**Inf = Inf ok 23 - NaN propagates with integer powers ok 24 - NaN propagates with numeric powers ok 25 - 0**NaN=NaN ok 26 - # SKIP NaN**1i should be NaN ok 27 - # SKIP 1i**NaN should be NaN ok 28 - # SKIP NaN**0 should be NaN ok 29 - NaN**NaN=NaN ok 30 - Inf**NaN=NaN ok 31 - NaN**Inf=NaN ok 32 - e ** .5 == exp(.5) ok 33 - e ** 2.5 == exp(2.5) ok 34 - (4+0i) ** 2 == 16 ok 35 - i ** 4 == 1 ok 36 - (4+0i) ** .5 == 2 ok 37 - i ** 2 == -1 ok 38 - i ** 3 == -i ok 39 - 5i ** 3 = -125i ok 40 - 3i ** 3 = -27i ok 41 - -3i ** 3 = 27i ok 42 - # SKIP i ok 43 - quartic root of 8i ** 4 = 8i ok 44 - quartic root of 8i ** 4 = 8i ok 45 - quartic root of 8i ** 4 = 8i ok 46 - quartic root of 8i ** 4 = 8i ok 47 - e ** pi i = -1 ok 48 - (4+0i) ** (2+0i) == 16 ok 49 - 1.015 ** 200 is not NaN ok 50 - 1.015 ** 200 == 19.6430286394751 # Looks like you failed 1 tests of 50 # FUDGED! Failed 1/50 subtests (less 4 skipped subtests: 45 okay) Test Summary Report ------------------- t/spec/S32-num/power.rakudo (Wstat: 0 Tests: 50 Failed: 1) Failed test: 18 Files=1, Tests=50, 8 wallclock secs ( 0.10 usr 0.41 sys + 5.31 cusr 1.72 csys = 7.54 CPU) Result: FAIL Thank you for looking at this! Show quoted text
> > > -- > Will "Coke" Coleda > > > > On Wed, May 29, 2013 at 10:29 AM, Pascal Stumpf > <Pascal.Stumpf@cubes.de> wrote: > > On Wed, 29 May 2013 05:42:27 -0700, "Will Coleda via RT" wrote:
> > How are you running the spec tests? - it looks like you've
> included some
> > that are not marked as runnable by rakudo.
> > I think I did a "gmake spectest_full".  Shall I run just the > spectest > target again or can you just ignore the tests that are not > marked as > runnable? > > spectest_full is only useful if you're a developer looking for more > tests to run. > If you could rerun with just 'gmake spectest' that'll give us a > much better idea of what's actually broken. And for those tests > that fail, please provide the verbose output when running each of > those test files. > You can get verbose output for a single test file with: 'make > t/spec/S02-types/bool.t' > Thanks. > -- > Will "Coke" Coleda
RT-Send-CC: will [...] coleda.com, email [...] froggs.de, perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 782b
Hi, again it's been a while. I installed a current Rakudo on OpenBSD 5.5 (amd64) and happily most of the test failures didn't occur anymore. On Moar I had a clean spectest. On Parrot I had only one failure. (Please note, that I had to install ICU ("pkg_add icu4c"). Without that package some of the last mentioned failed tests produced failures with Parrot as well.) t/spec/S19-command-line/dash-e.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 AFAIU this is expected since Parrot on OpenBSD does not support command line arguments other than ASCII. (Support for UTF-8 and ISO-8859-1 was added for Linux in 2011: http://irclog.perlgeek.de/parrot/2011-01-09#i_3167081.) I didn't try to build and run Rakudo on JVM.
RT-Send-CC: perl6-compiler [...] perl.org, will [...] coleda.com
Download (untitled) / with headers
text/plain 606b
Just for the records: Looking a bit closer I saw that the failing tests in S03-operators/arith.t and S32-num/power.t (reported on 2013-06-03) where identical. Both test whether "1**Inf" equals 1. Interestingly I got exactly those test failures on a current version of NetBSD (6.1.4): netbsd-6.1.4$ ./perl6-m -e "(1**Inf).say" NaN Last years OpenBSD also answered "NaN" (see above). A current version of OpenBSD (5.5) gives 1: openbsd-5.5$ ./perl6-m -e "(1**Inf).say" 1 I'm not sure how to interpret this difference. Maybe it's related to (differing/changing) functionalities of the operating system?
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
<masak> p6: say 1 ** Inf # [RT #85750] <camelia> niecza: OUTPUT«Cannot open assembly './run/Niecza.exe': No such file or directory.␤» <camelia> ..rakudo-jvm d60a8f: OUTPUT«Can't call method "syswrite" on an undefined value at /home/p6eval/jvm-rakudo/eval-client.pl line 32.␤» <camelia> ..rakudo-{parrot,moar} d60a8f: OUTPUT«1␤» <masak> the RT ticket says there are tests expecting this to be 1, but it's NaN on some systems. <masak> I was curious to find out what IEEE 754 stands on the matter. <masak> haven't found out yet. <masak> my *expectations* of these regions of arithmetic, of the concepts 1/Inf/NaN, and of IEEE 754, though, tell me that either 1 or NaN are acceptable answers, but I don't know which. I'm pretty sure IEEE 754 has an opinion, and unless there's a really good reason to deviate, we shouldn't. <masak> it's easy to argue for either: <masak> (it should be 1) -- because 1 ** $anything is 1 <masak> (it should be NaN) -- because there's an inherent conflict between 1 ** $anything being 1 and $at_least_1 ** Inf being Inf, and so rather than resolve that, the sysstem has to give NaN. <masak> this could be more formally argued using limits, but my hand-wavy argument shows the way, approximately. <masak> fwiw, Python (both 2 and 3) has 1 ** Inf as 1. https://gist.github.com/masak/675fbe68a6474a94b722 <masak> it doesn't have a reified symbol for Inf, hence the workaround with 1e3000. <masak> http://steve.hollasch.net/cgindex/coding/ieeefloat.html lists a number of "Special operations", which is something like I was looking for. pow(1, Inf) -- or anything involving pow -- is notably absent. <masak> ditto http://users.tkk.fi/jhi/infnan.html
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 655b
<bartolin> masak: S03-operators/arith.t mentions http://mathworld.wolfram.com/Indeterminate.html, as I understand it this argues in favour of 1 ** Inf == NaN <masak> bartolin: sure, I'm already concinced that *math* makes the argument for 1 ** Inf == NaN. <masak> but IEEE 754 deviates from math in some places where it finds doing so convenient in a computing environment. <masak> for example, 0 ** 0 <masak> m: say 0 ** 0 <camelia> rakudo-moar d60a8f: OUTPUT«1␤» <masak> m: say Inf ** 0 <camelia> rakudo-moar d60a8f: OUTPUT«1␤» <bartolin> ok, just wanted to note the link <masak> bartolin: yes -- thank you. <masak> bartolin: adding to ticket.
Download (untitled) / with headers
text/plain 906b
I ran a full spectest with no failures on OpenBSD 5.7 on Mar 22 2015 - Steve Mynott On Wed Mar 09 10:38:06 2011, Pascal.Stumpf@cubes.de wrote: Show quoted text
> The following test failures have so far been confirmed for all tested > architectures (amd64, macppc, mips64el): > > Test Summary Report > ------------------- > t/spec/S02-builtin_data_types/instants-and-durations.t (Wstat: 0 > Tests: 13 Failed: 1) > Failed test: 9 > t/spec/S03-operators/arith.rakudo (Wstat: 0 > Tests: 135 Failed: 1) > Failed test: 107 > t/spec/S19-command-line/dash-e.t (Wstat: 0 > Tests: 3 Failed: 2) > Failed tests: 2-3 > t/spec/S32-num/power.rakudo (Wstat: 0 > Tests: 40 Failed: 1) > Failed test: 11 > Files=542, Tests=27334, 4180 wallclock secs ( 9.85 usr 88.48 sys + > 3471.31 cusr 488.01 csys = 4057.65 CPU) > Result: FAIL
RT-Send-CC: cmasak [...] gmail.com
Download (untitled) / with headers
text/plain 2.6k
On Wed Oct 01 22:51:30 2014, masak wrote: Show quoted text
> <masak> p6: say 1 ** Inf # [RT #85750] > <camelia> niecza: OUTPUT«Cannot open assembly './run/Niecza.exe': No > such file or directory.␤» > <camelia> ..rakudo-jvm d60a8f: OUTPUT«Can't call method "syswrite" on > an undefined value at /home/p6eval/jvm-rakudo/eval-client.pl line > 32.␤» > <camelia> ..rakudo-{parrot,moar} d60a8f: OUTPUT«1␤» > <masak> the RT ticket says there are tests expecting this to be 1, but > it's NaN on some systems. > <masak> I was curious to find out what IEEE 754 stands on the matter. > <masak> haven't found out yet. > <masak> my *expectations* of these regions of arithmetic, of the > concepts 1/Inf/NaN, and of IEEE 754, though, tell me that either 1 or > NaN are acceptable answers, but I don't know which. I'm pretty sure > IEEE 754 has an opinion, and unless there's a really good reason to > deviate, we shouldn't. > <masak> it's easy to argue for either: > <masak> (it should be 1) -- because 1 ** $anything is 1 > <masak> (it should be NaN) -- because there's an inherent conflict > between 1 ** $anything being 1 and $at_least_1 ** Inf being Inf, and > so rather than resolve that, the sysstem has to give NaN. > <masak> this could be more formally argued using limits, but my hand- > wavy argument shows the way, approximately. > <masak> fwiw, Python (both 2 and 3) has 1 ** Inf as 1. > https://gist.github.com/masak/675fbe68a6474a94b722 > <masak> it doesn't have a reified symbol for Inf, hence the workaround > with 1e3000. > <masak> http://steve.hollasch.net/cgindex/coding/ieeefloat.html lists > a number of "Special operations", which is something like I was > looking for. pow(1, Inf) -- or anything involving pow -- is notably > absent. > <masak> ditto http://users.tkk.fi/jhi/infnan.html
I've found some references pro "1**Inf returns 1": * bug report for NetBSD saying "C99 and IEEE 754 revised 2008(?) reportedly state that this should be 1" http://mail-index.netbsd.org/netbsd-bugs/2014/10/01/msg038454.html * Quote from Wikipedia (http://en.wikipedia.org/wiki/NaN): Show quoted text
> "The 2008 version of the IEEE 754 standard says that > pow(1,qNaN) and pow(qNaN,0) should both return 1 since they > return 1 whatever else is used instead of quiet NaN. > > To satisfy those wishing a more strict interpretation of > how the power function should act, the 2008 standard > defines two additional power functions; pown(x, n) where > the exponent must be an integer, and powr(x, y) which > returns a NaN whenever a parameter is a NaN or the > exponentiation would give an indeterminate form."
* The Open Group Base Specifications Issue 7, IEEE Std 1003.1, 2013 Edition: http://pubs.opengroup.org/onlinepubs/9699919799/
RT-Send-CC: steve.mynott+bitcard [...] gmail.com
Download (untitled) / with headers
text/plain 356b
On Sun Mar 22 11:57:34 2015, steve.mynott+bitcard@gmail.com wrote: Show quoted text
> > I ran a full spectest with no failures on OpenBSD 5.7 on Mar 22 2015 > - Steve Mynott
Thanks! I'm closing this ticket as 'resolved'. For the test failures on NetBSD (1**Inf not returning 1) there is a separate ticket now: https://rt.perl.org/Ticket/Display.html?id=124147 Christian


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org