Add new physical types and parametrize physical type tests#11200
Closed
namurphy wants to merge 20 commits into
Closed
Add new physical types and parametrize physical type tests#11200namurphy wants to merge 20 commits into
namurphy wants to merge 20 commits into
Conversation
Previously, the unit m ** 2 / s was given a physical type of kinematic viscosity. This unit is used for other physical types (e.g., in plasma astrophysics). This is also the unit for magnetic diffusivity (resistivity divided by mu0), and this unit can represent a thermal diffusivity coefficient too. Length squared per time can be considered more generally as a diffusivity.
This is an application of the second golden rule of astrophysics, as learned from Chuck Cowley in astronomy 402: the density of wombats times the velocity of wombats equals the flux of wombats. This is units of energy density times units of velocity.
The volumetric rate is the rate at which something happens per unit volume per unit time. This unit is used sometimes to represent a collision rate or an ionization or recombination rate.
Power density is power per unit volume, at least according to the Wikipedia article on the topic. This unit is also used more specifically as a volumetric heating rate (e.g., eta * J ** 2 as ohmic heating in a plasma).
Pascals are equivalent to joules per cubic meter, which is also the units of energy density. This similarity shows up, for example, when the expression for magnetic energy density, B ** 2 / (2 * mu0), is equivalent to the expression for magnetic pressure. This commit modifies existing functionality.
Member
|
Thank you! I feel like perhaps this PR could be split into 2 PRs -- One for new addition, and one for changing things. For the part where you change things, I worry about backward incompatibility, especially given that such changes do not emit deprecation warning first (and probably impossible to do so). Does the benefit of these changes justify the possibility of breaking existing code? Maybe @mhvk could advise.
Yes, please. |
Contributor
|
Thanks very much! I agree with @pllim that we should split the PR, since the additions I'd be happy to just get in, but for the changes, I also worry that they could break existing code. For instance, if someone has decorated a function with Note that I do agree very much with the suggested changes in principle, the example of pressure and energy density is a very good one. I wonder if somehow we can allow a unit to be associated with multiple physical types?! (Redefining equality to make things still work?) Could you raise an issue where we can discuss this? What is needed also depends a little on how exactly the types get used. For instance, for |
Contributor
Author
That makes sense — I was also thinking about backward compatibility for conditionals where
I was just thinking I should raise an issue about this! |
This is to help split the pull request between the backward compatible and incompatible parts.
b35de12 to
1d0f969
Compare
Contributor
Author
|
After adding the tests, I decided to parametrize the tests for |
4 tasks
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Jan 6, 2021
Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). This commit was brought to you by needing an excuse to procrastinate for an hour on Wikipedia.
Contributor
Author
|
Closing this, since this PR has been superseded by #11204. |
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Add tests of new physical types Some of these tests are failing at the moment, partially because of the weirdness between K, °C, and °F. Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
namurphy
added a commit
to namurphy/astropy
that referenced
this pull request
Feb 21, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
nstarman
pushed a commit
to nstarman/astropy
that referenced
this pull request
Apr 26, 2021
Parametrize and expand unit physical type tests Now pretty much all of the existing unit/physical type pairs are being tested in advance of the impending refactoring. These tests will check backward compatibility. Define __eq__, __ne__, and __contains__ in PhysicalType __eq__ and __ne__ are being written so as to preserve the current API to the extent that is possible. For example, if we do `PhysicalType(u.m, "length") == "length"`, it will return True. Similarly, we are now additionally able to do things like `"length" in PhysicalType(u.m, "length")` and have it return True also. Define __repr__ and __str__ for PhysicalType This too is to preserve backward compatibility. If there is only one physical type, then these methods will return the string of the physical type. If there is more than one physical type, then these methods will stringify the set containing the multiple physical types. Define __mul__, __truediv__, & __pow__ for PhysicalType Multiplication, division, and exponentiation can be done for physical types analogously to units, like volume = length * area or density of wombats times velocity of wombats equals flux of wombats. This would enable a form of dimensional analysis. Add new physical types Thermal conductivity, heat capacity, specific heat capacity, energy flux, molar volume (had been previously misdefined), electrical resistivity, electrical conductivity, magnetic dipole moment, volumetric rate, jerk, snap, crackle, pop, temperature gradient, specific energy, reaction rate, moment of inertia, catalytic activity, molar heat capacity, molality, absement, volumetric flow rate, frequency drift, compressibility. These changes were already proposed in astropy#11200, which was supplanted by the current pull request (astropy#11204). Update class that represents physical types - Use kelvin to represent all temperatures internally. Celsius, Fahrenheit, and Rankine temperatures are not directly convertible to kelvin, but these all represent the same physical type. - Updated docstrings of PhysicalType. Add a warning banner that PhysicalType is not intended to be instantiated by the user. - Allow string representations of physical types to have underscores instead of spaces. If someone is working with an object that has an attribute that is named after a physical type, then the words in that physical type will probably be separated by underscores. Using underscores will simplify the code for this a bit. (I'm planning on using this feature in PlasmaPy). - Allow string representations of physical types to contain multiple physical types that are separated by a backslash or a comma. This is to maintain backward compatibility (for example with "momentum/impulse" which was a physical type before this pull request). and to contain multiple physical types that are separated by a backslash or a comma. Expand and refine physical type tests - Include more tests of temperature - Test that string representations of different physical types work (e.g., that underscores are treated as spaces and that strings can have multiple physical types separated by commas or backslashes). Refinements following code review - Change Jansky physical type back - Clean up docstrings - Remove type annotations - Make PhysicalType iterable over different physical type names (sorted) - Test iteration over PhysicalType - Remove `as_string` attribute in favor of using str(physical_type) - Remove `as_set` attribute in favor of using set(physical_type) - When necessary, use `_as_set` attribute internally - Remove duplication in parametrized test - Remove fixtures from tests - Test that a physical type name cannot be used for multiple units, except for unknown Clean up PhysicalType class & tests This includes changing an exception being raised with a warning being issued when a unit's physical type is being redefined. Update physical types and tests - Expanded definitions of physical types - Edited PhysicalType docstring to include discussion of comparisons and how physical type names are processed. Also revised examples. - No longer allow physical type names in a single string to be separated by a comma, while stating that the slash separator is kept for backwards compatibility. - Removed `_get_physical_type_id` method. Now using a private attribute instead. - Remove feature of allowing PhysicalType instances to be compared with sets that may contain strings representing physical types. Clean up PhysicalType class - Simplify `__iter__` by using `yield` - Rename some private attributes Raise ValueError when trying to redefine unit Also added a note to docstrings of `get_physical_type` and `def_physical_type` that these are not intended for use by users.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This pull request adds new physical types and generalizes two existing physical types.
The physical types I added are:
The physical types changes are:
"pressure and energy density"instead of just"pressure", since pressure has units of energy per unit volume"kinematic viscosity"to"diffusivity", since those units are used for multiple reasons in addition to kinematic viscosity.I put more detail about these in each commit message, occasionally with analogies involving wombats. I still need to add some tests and presumably a change log entry.