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
Fast check for C long #24244
Comments
Branch: u/jdemeyer/fast_check_for_c_long |
Commit: |
Dependencies: #24245 |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:9
I think it would be better if |
comment:10
Also, in #24248, you do not even use the return |
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:13
Use case 2 could just become:
which feels much more natural to me. However, I agree that use case 1 is a bit more of a hassle because you could not subsequently assign the error message (this wouldn't be a problem in, e.g., C because of the looser syntax rules). Although you can get around this by expanding out the |
comment:14
Replying to @tscrim:
Sure, I can simplify use case 1 and use case 2 individually. But I see no way to simplify things in such a way that both use cases still work. Alternatively, I could simply add another layer for use case 2 and make a new function
Finally, let me stress that this complexity shouldn't affect performance since we are dealing with |
comment:16
Let me know what you would suggest to do with this ticket. |
Reviewer: Travis Scrimshaw |
comment:17
Replying to @jdemeyer:
Do you have a place on a future ticket where use case 1 applies? I see use case 2 on #24247 and this one: if integer_check_long_py(right, &value, &err):
if not err:
return (<Element>left)._pow_long(value)
else:
return (<Element>left)._pow_int(right) which could be simplified to err = integer_check_long_py(right, &value):
if not err:
return (<Element>left)._pow_long(value)
elif err == ERR_OVERFLOW:
return (<Element>left)._pow_int(right) However, if you see a clear benefit to take on the more complicated function description and return values, then you can set this to a positive review. I just am thinking a little bit about the potential future maintenance of this function (I also don't think there will be any [noticeable] performance difference) and the places where it is used. |
comment:18
Here is a concrete proposal: we keep the complicated signature for now (if anything, simply to prevent conflicts with current tickets depending on this one). Once we have a clearer idea on how these functions are used, we can revisit and change things if needed. |
comment:19
Replying to @tscrim:
Fun observation: compiler warnings can be used to get data on how the compiler is able to optimize the code. For example, in #24247 I'm writing essentially
In this case, the compiler does not give a warning that |
comment:21
Oh, I just saw this from #24293 (I don't look at every ticket opened...) As for "integer_fake" is there maybe a name for it that better reflects its purpose"? I was thinking something like "integer_proto" (for prototype) since providing early access to the Integer prototype seems to be its primary purpose for existing. "integer_fake" to me sounds like something for testing, or some other odd purpose. |
comment:22
Replying to @embray:
I think that
"odd purpose" totally applies here :-) |
comment:23
Thinking more about it, I actually like how the name sounds like it should not be used. |
comment:24
When I read |
comment:25
I mean, it should be used, just for a specific narrow case. Alright I won't push on it; just something called "fake" is a little jarring to me to see outside of, say, test code. |
comment:26
BTW, I should add, this is really cool. Definitely something we should have done in the first place, in retrospect. |
comment:27
Replying to @embray:
Thanks! |
comment:28
Okay okay, what about "integer_decl", since it's basically a forward declaration IIUC. |
comment:29
Replying to @embray:
It's a fake forward declaration which shouldn't be used. |
Changed branch from u/jdemeyer/fast_check_for_c_long to |
Changed branch from |
Changed branch from u/jmantysalo/70592a850d7677928592c022760d6183bd81364f to |
comment:32
Arghs, my typo. |
Changed commit from |
Implement a fast variant of
pyobject_to_long
, which could be used to replace checks of the formisinstance(x, int)
.The goal of these functions is to provide a single place to check for integers and convert them to a C
long
(at least in Cython code, where performance matters most). Various places in Sage check for integers in different ways. First of all, this is an inconsistency which should be fixed.In Python 3, the types
int
/long
are changed, so many of the existing checks will need to be changed anyway. So we might as well provide one function which should be able to replace most of these checks. And ideally, we want to do this without losing too much performance. For that reason, I avoidPyLong_FromLong
in favour of a hand-written implementation.The function
pyobject_to_long
has signatureIt does several things: first of all, it checks whether
x
is "integer-like". This means that it is either a Pythonint
orlong
, a SageInteger
or it supports__index__
. The return value of the function is whether or not it is an integer. If it is an integer, it tries to convert the value to a Clong
and stores it in*value
. Errors are passed through the*err
variable.This interface looks overcomplicated on first sight, but the complexity is needed to support the various use cases of this function. Also note that it is an
inline
function, so the compiler should be able to optimize away the unused variables.Use case 1: a function can take different kinds of input and want to check whether the input is an integer. Typically, this would be done with a long
if
chain likeUse case 2: convert an integer to a C
long
purely for performance. In this case, you want to treat overflow the same as the input not being an integer:Depends on #24252
Component: cython
Author: Jeroen Demeyer
Branch:
70592a8
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/24244
The text was updated successfully, but these errors were encountered: