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

LTA and wrong results when using rational exponents #5439

Open
p6rt opened this issue Jul 9, 2016 · 5 comments
Open

LTA and wrong results when using rational exponents #5439

p6rt opened this issue Jul 9, 2016 · 5 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Jul 9, 2016

Migrated from rt.perl.org#128584 (status was 'open')

Searchable as RT128584$

@p6rt
Copy link
Author

p6rt commented Jul 9, 2016

From @titsuki

See the following results

$ perl6 -e 'say -1 ** -0.1'
-1
$ perl6 -e 'say reduce * ** *, -1, (-0.1)'
NaN

My Perl 6 version is
$ perl6 --version
This is Rakudo version 2016.05-4-g7a4ca4d built on MoarVM version 2016.05
implementing Perl 6.c.

@p6rt
Copy link
Author

p6rt commented Jul 9, 2016

From @titsuki

Sorry

"negative integers with negative decimal exponents"

is the correct expression.

On 2016-7月-09 土 05​:19​:49, cookbook_000@​yahoo.co.jp wrote​:

See the following results

$ perl6 -e 'say -1 ** -0.1'
-1
$ perl6 -e 'say reduce * ** *, -1, (-0.1)'
NaN

My Perl 6 version is
$ perl6 --version
This is Rakudo version 2016.05-4-g7a4ca4d built on MoarVM version 2016.05
implementing Perl 6.c.

@p6rt
Copy link
Author

p6rt commented Jul 9, 2016

From @pmichaud

On Sat, Jul 09, 2016 at 05​:19​:49AM -0700, Itsuki Toyota wrote​:

See the following results

$ perl6 -e 'say -1 ** -0.1'
-1
$ perl6 -e 'say reduce * ** *, -1, (-0.1)'
NaN

This is not a bug in "reduce" itself. Exponentiation has higher
precedence than unary minus, so the first expression is being
parsed and executed as -(1 ** -0.1) and not (-1) ** -0.1.
From my rakudo (ver 2016.06-50-g5a4963f)​:

$ ./perl6 -e 'say -1 ** -0.1'
-1
$ ./perl6 -e 'say (-1) ** -0.1'
NaN

So, the reduce subroutine is doing exactly the same thing as &infix​:<**> here does with a negative base.

At the moment I'm inclined to believe that a negative integer with
negative exponent should return NaN, but someone with more mathematics
sense than I would have to make that call.

Pm

@p6rt
Copy link
Author

p6rt commented Jul 9, 2016

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

@p6rt
Copy link
Author

p6rt commented Oct 7, 2016

From @zoffixznet

First a bit of deconfusion​: negative exponents just mean x⁻² = 1/x². That works just fine and is not relevant to this ticket​:

  <ZoffixW> m​: say (-2) ** -2
  <camelia> rakudo-moar 605f27​: OUTPUT«0.25␤»

Fractional exponents mean the number is raised to the power of the numerator and then the denominator-th-root is taken from it. So raising to 0.1th power simply means we take 10th root​:

  <ZoffixW> m​: say 1024 ** .1
  <camelia> rakudo-moar 605f27​: OUTPUT«2␤»

So far so good for positive base numbers, but some stuff appears to be broken for roots of negatives. First, the NaN case described in this ticket​:

  <ZoffixW> m​: say (-1) ** .5
  <camelia> rakudo-moar 605f27​: OUTPUT«NaN␤»

We're taking a square root of a negative number which "doesn't exist", so we're dealing with Complex numbers.
The NaN result matches what we'd get from sqrt(), so this case is fine​:

  <ZoffixW> m​: say sqrt(-1)
  <camelia> rakudo-moar 605f27​: OUTPUT«NaN␤»

BUT, unlike sqrt(), if we request to deal with Complex numbers, the output from the infix​:<**> is incorrect​:

  <ZoffixW> m​: say sqrt(-1+0i)
  <camelia> rakudo-moar 605f27​: OUTPUT«0+1i␤»
  <ZoffixW> m​: say (-1+0i) ** .5
  <camelia> rakudo-moar 605f27​: OUTPUT«6.12323399573677e-17+1i␤»

Moreover, if we raise a negative number to an *odd* power, the result will be negative​:

  <ZoffixW> m​: say (-5)**3
  <camelia> rakudo-moar 605f27​: OUTPUT«-125␤»

This means that taking an *odd* root doesn't have anything to do with Complex numbers and should Just Work™, but Rakudo still gives us a NaN, instead of the original -5​:

  <ZoffixW> m​: say (-125)**(1/3)
  <camelia> rakudo-moar 605f27​: OUTPUT«NaN␤»

We can try using the "Complex mode", and that doesn't give NaN, but the result is wrong, so we can't use that to perform such a computation​:

  <ZoffixW> m​: say (-125+0i) ** (1/3)
  <camelia> rakudo-moar 605f27​: OUTPUT«2.5+4.33012701892219i␤»
  <ZoffixW> m​: say (-125+0i) ** ((1+0i)/(3+0i))
  <camelia> rakudo-moar 605f27​: OUTPUT«2.5+4.33012701892219i␤»

In summation, the buggy behaviour revealed by this ticket is​:
  (a) odd roots (rational powers with odd denominators) produce NaN instead of actual non-complex result
  (b) rational powers on complex numbers produce wrong results

On Sat Jul 09 09​:51​:38 2016, pmichaud wrote​:

On Sat, Jul 09, 2016 at 05​:19​:49AM -0700, Itsuki Toyota wrote​:

See the following results

$ perl6 -e 'say -1 ** -0.1'
-1
$ perl6 -e 'say reduce * ** *, -1, (-0.1)'
NaN

This is not a bug in "reduce" itself. Exponentiation has higher
precedence than unary minus, so the first expression is being
parsed and executed as -(1 ** -0.1) and not (-1) ** -0.1.
From my rakudo (ver 2016.06-50-g5a4963f)​:

$ ./perl6 -e 'say -1 ** -0.1'
-1
$ ./perl6 -e 'say (-1) ** -0.1'
NaN

So, the reduce subroutine is doing exactly the same thing as
&infix​:<**> here does with a negative base.

At the moment I'm inclined to believe that a negative integer with
negative exponent should return NaN, but someone with more mathematics
sense than I would have to make that call.

Pm

@p6rt p6rt added the math label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant