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
Let the user define their own primitive element for Fq (in givaro) #20670
Comments
Replying to @dimpase:
Why do you think that?
|
Reviewer: Jeroen Demeyer |
comment:3
Do you know how to do this on C++ level? At least, that's what Macaulay2 people came up with, that patch in the ticket branch. |
comment:4
In
right above the line added by Macaulay2. Note the subtle difference: it does not take a |
This comment has been minimized.
This comment has been minimized.
comment:5
well, yes, indeed, in Macaulay2 one can specify a primitive element along with a modulus. So with this patch Sage can do the same (although I don't see how to override It seems that |
comment:6
Are you sure that Macaulay2 really requires a custom primitive element and a custom polynomial or is that just an implementation detail? |
This comment has been minimized.
This comment has been minimized.
comment:7
Replying to @jdemeyer:
Given a modulus (or not), it can certainly compute a primitive element, although it does have an option to supply a custom primitive element. And to do this it uses givaro backend with the patch in question. |
comment:8
This is one of the two patches (another one is for ffpack) needed to build and run Macaulay2 v1.9 (the current version, with an adaptation of Sage's pari/mpir workaround --- after I told them about Sage's pari/mpir workaround related to memory allocators) within Sage. |
Author: Dima Pasechnik |
comment:10
The patch should have some sort of documentation (ideally in the patch header) |
comment:11
Replying to @vbraun:
my hope is to implement a possibility to supply a primitive element to Could anyone point me to the right place in the code? |
comment:12
I am told that the patch on the branch is in givaro 4.0.2. |
Dependencies: #17635 |
comment:15
Indeed, the patch has been merged upstream in linbox-team/givaro#18 and released in 4.0.2 that is now in #17635. |
Changed reviewer from Jeroen Demeyer to Dima Pasechnik, Jeroen Demeyer |
Changed author from Dima Pasechnik to none |
comment:17
the question I asked in comment:11 is still unanswered. |
comment:18
Determined to be invalid/duplicate/wontfix (closing as "wontfix" as a catch-all resolution). |
comment:20
Replying to @embray:
I have to re-open this, but is it possible without opening a new ticket? |
comment:21
Yes, (under action). I think you have the permissions to do that but I'm not sure. I've been yelled at before for doing this but in this case I was the one who closed the ticket so I don't mind reopening it too if you think it should be. |
This comment has been minimized.
This comment has been minimized.
Changed reviewer from Dima Pasechnik, Jeroen Demeyer to none |
Changed commit from |
Changed branch from u/dimpase/givaropatch to none |
Changed dependencies from #17635 to none |
comment:25
Ping - I have been recently asked how to define a custom primitive element (Magma can do it, so they have to use Magma because of this, and better support for Zech transform) |
Sage does not allow Fq to be defined with a user-supplied polynomial together with a user-supplied primitive element. However, recent (4.0.2 or newer) givaro is able to accept such input and use it.
CC: @sagetrac-jakobkroeker @ClementPernet @malb
Component: finite rings
Issue created by migration from https://trac.sagemath.org/ticket/20670
The text was updated successfully, but these errors were encountered: