-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
ENH: __trunc__
for floating and integer types
#28949
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
base: main
Are you sure you want to change the base?
Conversation
__trunc__
for floating types__trunc__
for floating types
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.
don't forget about the stubs :)
I think it would make sense to also do this for >>> float.__trunc__
<method '__trunc__' of 'float' objects>
>>> int.__trunc__
<method '__trunc__' of 'int' objects> The other rounding dunders are currently also present in both |
the type-test at |
Oh for sure, since the implementation is small, I'll squeeze it in here. Thanks for the info!
Ah that makes sense. |
__trunc__
for floating types__trunc__
for floating and integer types
- Added edgcases for float - Added TCs for integer
Co-authored-by: Joren Hammudoglu <jhammudoglu@gmail.com>
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.
any reason in particular why you defined it on the individual subclasses, and not directly on floating
and integer
, like __round__
?
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.
oh like in floatingtype_methods
? I was actually very curious on how it's getting picked up as it's not referenced anywhere else in numpy/
. How does that work?
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.
note that integer
also includes timedelta64
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.
oh like in
floatingtype_methods
? I was actually very curious on how it's getting picked up as it's not referenced anywhere else innumpy/
. How does that work?
I have minimal knowledge of the C codebase actually haha. Maybe some macro magic, or in some generated C sources?
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.
It works magically :). Let me ask in slack, it feels like magic as I'm not finding it in the generated source as well. Thanks for catching it though!
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.
Ok so it's in
Py@NAME@ArrType_Type.tp_methods = @name@type_methods; |
numpy/_core/_add_newdocs_scalars.py
Outdated
f""" | ||
{float_name}.__trunc__() -> int | ||
|
||
Return the floating point number with the fractional part removed, | ||
leaving the integer part. | ||
{'\n .. versionadded:: 2.3\n' if float_name != 'double' else ''} | ||
Examples | ||
-------- | ||
>>> np.{float_name}(np.pi).__trunc__() | ||
3 | ||
>>> import math | ||
>>> math.trunc(np.{float_name}(-np.pi)) | ||
-3 | ||
""")) |
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.
a classic .format
might be a bit cleaner here, also for the triple {float_name}
@jorenham a basic query on integer's typing: How did it get added? There is no diff indicating it's added:
|
I'm not sure I understand you question. Are you asking how to verify that the method you added in the stubs actually works? Because if so, you could do that by adding a type-test in |
Changes
Add
__trunc__
for floating and integer typesTesting
Related
part of #13375
Todo
gentype_int
is slower than an explicitPyLong_FromDouble
, etc for floats