Skip to content

use generic isogeny call to opportunistically use velusqrt #40422

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Jul 25, 2025
Merged

use generic isogeny call to opportunistically use velusqrt #40422

merged 1 commit into from
Jul 25, 2025
+1 −1

Conversation

GiacomoPope
Copy link
Contributor

Before only velu formulas were used for this codomain, but for points with large or composite order we have better options within the E.isogeny method, so we should use these.

@GiacomoPope GiacomoPope requested a review from yyyyx4 July 16, 2025 14:18
yyyyx4
yyyyx4 approved these changes Jul 16, 2025
View reviewed changes
Copy link
Member

@yyyyx4 yyyyx4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

@user202729
Copy link
Contributor

user202729 commented Jul 17, 2025 •
edited
Loading

This is semantically wrong (what returned by _isogeny_determine_algorithm is not used that way by the caller).

I suggest splitting _isogeny_determine_algorithm into _is_point_list and _is_coefficient_list, then modify the caller accordingly. Currently the error message raised by _isogeny_determine_algorithm in case of incorrect algorithm is wrong too.

Alternatively, we may as well eliminate the logic inside isogeny_codomain_from_kernel entirely and just return E.isogeny(kernel).codomain(). Optionally with deprecating the method too (the latter method is always shorter).

vbraun pushed a commit to vbraun/sage that referenced this pull request Jul 18, 2025
935876e 
sagemathgh-40422: use generic isogeny call to opportunistically use velusqrt
    
Before only velu formulas were used for this codomain, but for points
with large or composite order we have better options within the
E.isogeny method, so we should use these.
    
URL: sagemath#40422
Reported by: Giacomo Pope
Reviewer(s): Lorenz Panny
@yyyyx4
Copy link
Member

yyyyx4 commented Jul 21, 2025

@user202729 Sorry, I only saw your comment just now. I think this is now in the process of being merged, so it'd be better not to interfere with that. I would suggest to open a new issue/PR to streamline all this. Indeed, the way the EllipticCurveIsogeny class is set up could use some broader refactoring...

@user202729
Copy link
Contributor

user202729 commented Jul 21, 2025 •
edited
Loading

Technically you can without any issue (happened to me a few times), but then it may only get merged in the next release. Either way, doesn't matter too much (I don't think anyone uses this function anyway, E.isogeny(⟨kernel⟩).codomain() is strictly shorter).

@vbraun vbraun merged commit 55f907f into sagemath:develop Jul 25, 2025
26 of 28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@yyyyx4 yyyyx4 yyyyx4 approved these changes

Assignees
No one assigned
Labels
c: algebraic geometry p: minor / 4
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@GiacomoPope @user202729 @yyyyx4 @vbraun
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy