-
-
Notifications
You must be signed in to change notification settings - Fork 221
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
Use generic named variables in coordinates module #656
base: main
Are you sure you want to change the base?
Use generic named variables in coordinates module #656
Conversation
This commit addresses the first point on issue einsteinpy#650 by replacing named variables for each coordinate type with generic variable names
Hello @TONYOG12! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2024-06-18 12:27:02 UTC |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #656 /- ##
==========================================
- Coverage 97.33% 97.13% -0.21%
==========================================
Files 68 68
Lines 2515 2336 -179
==========================================
- Hits 2448 2269 -179
Misses 67 67 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is not tested. Is mypy giving issues?
return cartesian_to_spherical(t, x, y, z, v_x, v_y, v_z) | ||
return cartesian_to_spherical_novel(t, x, y, z) | ||
@jit | ||
def calculate_coordinates(r, th, p, alpha): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the refactoring approach in #644 (comment) causing any issues ? (Apart from not any
) ? That way should lead to clearer and more compact code. The idea is that the position and velocity conversions are jit
-compiled, and these function names (cartesian_to_spherical
vs cartesian_to_spherical_novel
) are changed to something more comprehensible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright thanks for the pointers, will refactor based on that approach
Notes for posterity:
|
added the base classes to eliminate code repetition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TONYOG12 Thank you for the updated commit. I have reviewed the changes again. Besides these, the utils
changes are left (function names change, see #656 (comment) & #644 (comment)).
"system": self.system, | ||
} | ||
self._dimension_order = ("t", "x", "y", "z") | ||
self._dimension_order = ("e0", "e1", "e2", "e3") | ||
|
||
def __str__(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can add the __str__
and __repr__
methods in the Base class itself. Instead of child-class name, like "Cartesian Coordinates", you can use f"{self.__class__.__name__} Coordinates \n ..."
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, __getitem__
and position
can also be part of the Base class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for member variables, self._dimension
and self._dimension_order
are the same across the 3 classes and can kept in the Base class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved
z-Component of 3-Position | ||
v_x : float, optional | ||
u0 : float, optional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
u0
should correspond to the temporal component of velocity, like how e0
is the temporal component for (4-)position. So, here, you can start at u1, u2, u3
and rename v_t
to u0
elsewhere (e.g., in differential.py
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved
e0=u.s, e1=u.m, e2=u.m, e3=u.m, u0=u.m / u.s, u1=u.m / u.s, u2=u.m / u.s | ||
) | ||
def __init__(self, e0, e1, e2, e3, u0, u1, u2): | ||
super().__init__(e0, e1, e2, e3, u0, u1, u2) | ||
self.system = "Cartesian" | ||
|
||
def __str__(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As with BaseCoordinate
in core.py
, the __str__
and __repr__
methods can be moved to the BaseDifferential
class using the {self.__class__.__name__}
trick.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, position
and velocity
methods can be in the Base class, as they do not change for the child-classes. The same also applies to the v_t
(rename to u0
) property and its setter. Both can be moved to the Base class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
src/einsteinpy/coordinates/utils.py
Outdated
def cartesian_to_bl_fast(e0, e1, e2, e3, e4, u0=None, u1=None, u2=None): | ||
vel = [u0, u1, u2] | ||
if all(u is not None for u in vel) and any(u != 0 for u in vel): | ||
return cartesian_to_bl(e0, e1, e2, e3, e4, u0, u1, u2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e4
is actually u0
(v_t
). Refer to the comment in src/einsteinpy/coordinates/conversion.py
.
This commit addresses the first point on issue #650 by replacing named variables for each coordinate type with generic variable names
Addresses #650
@JeS24