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
Remove rad2deg
and deg2rad
from Base
#54144
Comments
I agree, but why single those out? What about sin, cos, floating-point in general... Array (as opposed to Memory), OpenBLAS... so why single those out? They are small and the least of our problems? |
sin/cos -> yes. They should be removed from Base, though it's a harder sell because more people use them. floating-point in general -> no. No plausible, nontrivial program doesn't depend on floating point addition/multiplication. It's probably not worth the effort to excise it. If floating point math becomes less pervasive or approaches to basic floating point arithmetic become more diverse then maybe reconsider. Array -> yes, though that does require changing the default return type of collect, list comprehensions, etc to Memory. OpenBLAS -> absolutely!
I single these two out because they are easy. |
I don't think we can drop them, annoying people (until 2.0), breaking change but neither should we expand it. @aplavin where else can that go in a package? I though/still think those are trivial functions on just Float64 (and smaller, and BigFloat...?! that I want to get rid of anyway). They are hopefully not costly in the sysimage, I might want them out o if it, just not Base. {Floats were just an impossible example, just not needed by Base itself, except possibly few divisions? Unlike rad2deg and deg2rad, sin/cos are actually non-trivial, unless done with assembly instructions, but I believe not done that way because of accuracy; also neither on matrices, I want LinearAlgebra out too, NOT needed for Julia itself... I just think we should start with the big stuff.] I'm all for getting this all out and the small stuff with ENV var (not yet by default), but my suggestion was closed: |
Not sure, what exactly are you asking about? As for dropping anything that Base doesn't need itself: yeah, would be nice, but with consistency. I don't see a fundamental difference between deg2rad, sin, sind, sincos in this regard. And also stuff like LogRange (it's going to be included into Base soon). And many more stuff, potentially. |
Is the proposal to move I would be fine implementing |
Almost all proposed excisions are Base => package, not Base => nowhere. We definitely don't expect or want users to roll their own trig implementations. This case could go either way, but I lean toward putting them in a library. |
A separate package just for two functions seems absurd. When prioritizing removal of items from Moreover, code which resides in Or, another way to take on it: If we apply the proposed logic, then |
Agreed. This would live with
These functions are surprisingly nontrivial (e.g. #45947) |
"easy" was from:
|
Things that don't need to be in Base should not be in Base.
The text was updated successfully, but these errors were encountered: