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

Improve coordinate conversion speed #328

Merged
merged 5 commits into from Sep 5, 2019

Conversation

Varunvaruns9
Copy link
Member

  • Combine core and velocity coordinates into one.
  • Make base conversion classes which operate only on the values without astropy.

@pep8speaks
Copy link

pep8speaks commented Aug 21, 2019

Hello @Varunvaruns9! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

Line 66:9: W503 line break before binary operator
Line 68:13: W503 line break before binary operator
Line 110:9: W503 line break before binary operator
Line 111:9: W503 line break before binary operator
Line 115:9: W503 line break before binary operator
Line 116:9: W503 line break before binary operator
Line 155:9: W503 line break before binary operator
Line 156:9: W503 line break before binary operator
Line 160:9: W503 line break before binary operator
Line 161:9: W503 line break before binary operator

Comment last updated at 2019-09-05 19:40:54 UTC

@codecov
Copy link

codecov bot commented Aug 23, 2019

Codecov Report

Merging #328 into master will decrease coverage by 0.34%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #328      +/-   ##
==========================================
- Coverage   94.42%   94.08%   -0.35%     
==========================================
  Files          41       43       +2     
  Lines        1560     1673     +113     
==========================================
+ Hits         1473     1574     +101     
- Misses         87       99      +12
Impacted Files Coverage Δ
...rc/einsteinpy/plotting/senile/geodesics_scatter.py 94.33% <ø> (ø) ⬆️
src/einsteinpy/coordinates/conversion.py 100% <100%> (ø)
src/einsteinpy/metric/kerrnewman.py 91.66% <100%> (ø) ⬆️
src/einsteinpy/coordinates/velocity.py 100% <100%> (ø) ⬆️
src/einsteinpy/coordinates/utils.py 100% <100%> (ø)
src/einsteinpy/metric/schwarzschild.py 94.52% <100%> (ø) ⬆️
src/einsteinpy/coordinates/core.py 92.95% <100%> (-1.85%) ⬇️
src/einsteinpy/coordinates/__init__.py 100% <100%> (ø) ⬆️
src/einsteinpy/metric/kerr.py 91.02% <100%> (ø) ⬆️
src/einsteinpy/symbolic/stress_energy_momentum.py 95.83% <0%> (-4.17%) ⬇️
... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a3bf6ac...79ec505. Read the comment docs.

@Varunvaruns9
Copy link
Member Author

Here is what I've been able to get by switching to conversions for converting coordinates:
Screenshot 2019-08-23 at 3 12 25 PM

For comparison, this is how much time it took before:
Screenshot 2019-08-23 at 11 45 41 AM

@shreyasbapat

@Varunvaruns9 Varunvaruns9 changed the title [WIP] Improve coordinate conversion speed Improve coordinate conversion speed Aug 23, 2019
@ritzvik
Copy link
Member

ritzvik commented Aug 23, 2019

Woah! That's a huge PR!

Copy link
Member

@shreyasbapat shreyasbapat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. I will still make some changes, break up methods to use them with numba!

@@ -0,0 +1,7 @@
frame module
===============
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmmmm, less number of '='s

145.45557 * u.km/u.s, 251.93643748389 * u.km/u.s, 0 * u.km/u.s)

bl_coord = pos_vel_coord.bl_differential(a)
bl_coord = pos_vel_coord.to_bl(a)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:/ .to(BoyerLindquist)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all API breaking changes!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ritzvik Yes they are, should I change it to to(classname) or use the old methods?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ritzvik Yes they are, should I change it to to(classname) or use the old methods?

to(classname) seems a good solution. You can add it but we do need to preserve the old methods also, atleast before 0.3.0

:/ .to(BoyerLindquist)

.to(BoyerLinduist, a) because a is definitely required to change other systems into BL. Maybe we can make the .to function like this?
to(coordinate_class, *args) or to(coordinate_class, **kwargs)

@ritzvik
Copy link
Member

ritzvik commented Aug 23, 2019

@Varunvaruns9 this is really a great PR. Wait a little bit, I will be reviewing and may be I can point out where the changes can be made, so that it does not break any APIs

@Varunvaruns9
Copy link
Member Author

@ritzvik @shreyasbapat Merged the changes.

@ritzvik
Copy link
Member

ritzvik commented Aug 24, 2019

@Varunvaruns9 Well, you can now implement the .to(CoordinateClass) method as suggested by @shreyasbapat

Also, tests are taking just one and a half minutes now as opposed to 10 mins earlier :)

@Varunvaruns9
Copy link
Member Author

I will start working on that after 29th, maybe we can merge this first and I'll make another PR for the new changes.

@ritzvik
Copy link
Member

ritzvik commented Aug 24, 2019

I will start working on that after 29th, maybe we can merge this first and I'll make another PR for the new changes.

That's okay! There's currently 25 commits in this PR, can you scale them down a bit, maybe 4-5 commits?

@shreyasbapat
Copy link
Member

I messed up the mathematics somewhere. Atleast that's what I feel



def cartesian_to_spherical_fast(
x, y, z, v_x=None, v_y=None, v_z=None, velocities_provided=False
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this function is calling cartesian_to_spherical() & cartesian_to_spherical_novel(), shouldn't this function be defined below the other two. I know it doesn't matter in python but anyways, it's a commonly accepted practice in programming.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is when we deal with compiled languages. ;D

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a commonly accepted practice in programming

It's good to follow certain conventions, although!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will fix it. Don't worry

"""
r = np.sqrt(x ** 2 + y ** 2 + z ** 2)
theta = np.arccos(z / r)
phi = np.arctan2(y, x)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could have done r, theta, phi = cartesian_to_spherical_novel(x, y, z). Otherwise, there is code duplication.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure which versions of numba people might have.

):
if velocities_provided:
return cartesian_to_bl(x, y, z, a, v_x, v_y, v_z)
return cartesian_to_spherical_novel(x, y, z, a)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Silly mistake! cartesian_to_bl_novel(x, y, z, a)

@ritzvik
Copy link
Member

ritzvik commented Aug 28, 2019

@shreyasbapat I think you should revert the last two commits made by you as we have only 3 coordinate systems as of now, and adding computational graph would just complicate the code base. Let's aim it for 0.3.0.

@Varunvaruns9
Copy link
Member Author

@shreyasbapat Can we merge the first two commits? Then I can start working on adding new features to plotly plotter.

@shreyasbapat
Copy link
Member

@ritzvik last two commits are not computational graph stuff :)

@shreyasbapat
Copy link
Member

@Varunvaruns9 I guess yes. It's possible. Revert the commits

@shreyasbapat
Copy link
Member

Or rather, give me 15 mins

@Varunvaruns9
Copy link
Member Author

@shreyasbapat Any progress?

@shreyasbapat
Copy link
Member

Yeah, some minor patches

@Varunvaruns9
Copy link
Member Author

@shreyasbapat Fixed it. Theta and phi were switched 🤣

@shreyasbapat
Copy link
Member

@shreyasbapat Fixed it. Theta and phi were switched rofl

Oh man! I was too frustrated!

Copy link
Member

@shreyasbapat shreyasbapat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Methods lack docstrings, but let's tackle that in another PR.

@shreyasbapat
Copy link
Member

Manually Merged with 9ccf6d6

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

Successfully merging this pull request may close these issues.

None yet

4 participants