Hi guys,
We have asin and asind, acos and acosd, atan and atand. Hence, I think it makes sense to also have atan2d or atand2, which is the degree version of atand.
atan2 is now the two argument method of atan though, so the request should rather be for a two argument method of atand.
Yes, this is what I meant :)
Yes, this seems like a simple oversight, due to the fact that atan(y, x) is a special-case function and doesn't follow the metaprogramming pattern that the other trig functions follow in that file. (e.g. see how most of the degrees functions are defined down at the bottom of the file.
I think it would be just fine to open a PR adding a line below that for loop, adding an entry for atand(y, x) = rad2deg(atan(y, x))
I will do this! thanks
@staticfloat done! I did more modifications so that we have a good docstring describing that atand have 1 and 2 argument versions, like asind for example.
Out of curiosity, if the functions with a d at the end are just calling rad2deg to the output, would it be better to just use a keyword argument rad::Bol = True now that keywords are efficient? That would simplify the code and probably be easier to document (e.g., akin to deprecating func2 for method dispatch).
I believe *d is a typical name for these kinds of functions in other programming languages too.
Most helpful comment
Out of curiosity, if the functions with a
dat the end are just callingrad2degto the output, would it be better to just use a keyword argumentrad::Bol = Truenow that keywords are efficient? That would simplify the code and probably be easier to document (e.g., akin to deprecatingfunc2for method dispatch).