Skip to content
This repository has been archived by the owner on May 31, 2020. It is now read-only.

Failing macOS unittest - pow corner case(s) #827

Open
1 of 4 tasks
pzrq opened this issue Aug 6, 2019 · 2 comments
Open
1 of 4 tasks

Failing macOS unittest - pow corner case(s) #827

pzrq opened this issue Aug 6, 2019 · 2 comments

Comments

@pzrq
Copy link
Contributor

pzrq commented Aug 6, 2019

Expected Behavior

# Expected - Python 3.7.3
>>> print(pow(0.7071067811865476+0.7071067811865475j, 18446744073709551616))
(0.5092909260061389+0.8605944182295221j)

Current Behavior

# Batavia (testserver demo - copy/paste and run)
print(pow(0.7071067811865476+0.7071067811865475j, 18446744073709551616))
(0.7531061966369503+0.6578989714135652j)

Steps to reproduce

  1. At a terminal, the test which inspired my issue:
(venv) pzrq@mozzie:~/Projects/beeware/batavia$ python setup.py test -s tests.builtins.test_pow.BuiltinTwoargPowFunctionTests.test_complex_int

Your Environment

  • Python Version (list the specific version number)
    Python 3.7.3

  • Operating System and Version (select from the following and list the specific version number; if your OS is not listed, list that as well)

    • OSX 10.14.6
    • Linux
    • Windows
    • Ubuntu
@pzrq
Copy link
Contributor Author

pzrq commented Aug 6, 2019

I may have the expected/actual backwards (or at least needs more data), in an Ubuntu VM:

pzrq@pzrq-VirtualBox:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04 LTS
Release:	18.04
Codename:	bionic

pzrq@pzrq-VirtualBox:~$ python3
Python 3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print(pow(0.7071067811865476+0.7071067811865475j, 18446744073709551616))
(0.7531061966369503+0.6578989714135652j)

@swenson
Copy link
Contributor

swenson commented Aug 6, 2019

The bug looks to be here:

https://github.com/beeware/batavia/blob/master/batavia/types/Complex.js#L364

If the exponent is larger than 100, we cast it to a JavaScript 52-bit Number, so we lose the lower-order bits.

Instead we should just do the exponentiation ourselves.

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

No branches or pull requests

2 participants