[sage-devel] rebuilding Cython files in `conda` installation

[Gareth Ma]

Hi all, my development Sage installation uses the conda instructions here 
.
 
There is a command below for how to recompile Cython files:

pip install --no-build-isolation --config-settings editable_mode=compat -v 
-v --editable src

However, it seems that it recompiles *every* Cython file, even the ones I 
haven't touched. This happens everytime, not just the first time I run the 
command. Is that normal? Is it possible to only recompile files I have 
changed?

I tried running cythonize -i a.pyx directly on the file. However, it seems 
to break something and some libraries are not loaded correctly. For 
example, I was editing sage/rings/finite_rings/element_pari_ffelt.pyx, and 
after running the cythonize command Sage complains that the ConwayDatabase 
is missing.

(I hope I am not posting in the wrong mailing group)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/745d0f34-5f69-4b3c-bace-1497d483ddb3n%40googlegroups.com.

Re: [sage-devel] rebuilding Cython files in `conda` installation

[Gareth Ma]

Thank you both for the suggestion, I went with Dima's suggestion by 
running `sage -b` once, and now it supports incremental building. I will 
try Nils' approach and see if I can figure it out - if I do, I will add 
it to the conda-forge installation documentations page :)


Best regards,
Gareth

On 24/01/2024 16:37, Dima Pasechnik wrote:


On 24 January 2024 15:58:56 GMT, Gareth Ma  wrote:

Hi all, my development Sage installation uses the conda instructions here
<https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library>.
There is a command below for how to recompile Cython files:

pip install --no-build-isolation --config-settings editable_mode=compat -v
-v --editable src

However, it seems that it recompiles *every* Cython file, even the ones I
haven't touched. This happens everytime, not just the first time I run the
command. Is that normal?

yes, this is normal if you use pip this way.
If you went for a more regular Sage installation where you can run make, then 
such rebuilds would have been much faster, as there is dependency tracking then.




Is it possible to only recompile files I have
changed?

I tried running cythonize -i a.pyx directly on the file. However, it seems
to break something and some libraries are not loaded correctly. For
example, I was editing sage/rings/finite_rings/element_pari_ffelt.pyx, and
after running the cythonize command Sage complains that the ConwayDatabase
is missing.

(I hope I am not posting in the wrong mailing group)



--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e04d411b-c1de-44d9-8e98-c95c187c4916%40gmail.com.

Re: [sage-devel] Help needed with UniqueRepresentation (of SymmetricFunctions)

[Gareth Ma]

The following should show the problem:

sage: from sage.structure.unique_representation import UniqueRepresentation
:
: class A(UniqueRepresentation):
: def __init__(self, v=1):
: self.v = str(v)
:
: A() == A()
: A() is A()
: A() == A(1)
True
True
False

My understanding is that UniqueRepresentation wraps around the class 
constructor, such that it returns a unique object if the arguments are 
exactly the same. You see that in the second check, A() is A(). However, 
A() and A(1) have different arguments (one is empty, one is [1]), so 
they return distinct objects.


To fix this, I believe you just have to implement _eq_ or __eq__. For my 
example, add def __eq__(self, other): return self.v == other.v. (If I am 
incorrect, others please correct me!)


Gareth

On 05/02/2024 13:57, 'Martin R' via sage-devel wrote:
At https://github.com/sagemath/sage/pull/37220 I am trying to provide 
a construction functor for symmetric functions. I am hitting the 
following bug, which I hope is easy to fix if one knows the right magic:


sage: P. = QQ[]
sage: S = SymmetricFunctions(P)
sage: S.jack().P() == S.jack(t=t).P()
False

Can someone help me out?

Martin
--
You received this message because you are subscribed to the Google 
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5e221666-215b-4210-8bc4-15a3744ccb26n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/47589ce9-8ffa-4545-9ba4-81bfdd806584%40gmail.com.

Re: [sage-devel] Problem extracting base B fractional digits of a number

[Gareth Ma]

I assume you should use floor division to preserve accuracy. As a 
numerical example, say you want the first 100 /decimal/ digits of 3 / 
173. That's the same as floor(10^100 * 3 / 173).


In [105]: from decimal import Decimal, getcontext
 ...: getcontext().prec = 300
 ...: print(10**100 * 91 // 173)
 ...: print(int(str(Decimal(91) / Decimal(173)).split(".")[1][:100]))
5260115606936416184971098265895953757225433526011560693641618497109826589595375722543352601156069364
5260115606936416184971098265895953757225433526011560693641618497109826589595375722543352601156069364

Gareth

On 10/02/2024 16:24, Georgi Guninski wrote:

Given SR constant, I want to extract the first L base B digits
of the fractional part.

So far the best solution I found is:
floor((SR(expression)*B**L).numerical_approx(digits=L)).digits(B)

Can I do better?

Why the following approach fails numerically:

```
def base_B_digits(A, B,prot=False):
 digits=[]
 fractional_part = A - int(A)
 while fractional_part != 0:
digit = int(fractional_part * B)
digits.append(digit)
fractional_part = fractional_part * B - digit
if prot:  print(fractional_part)
 return digits
```
tt=base_B_digits(SR(1/3).numerical_approx(digits=10),10,1)

The fractional part starts:

0.33
0.31
0.14
0.333139
0.331393
...
0.781250
0.812500
0.125000
0.25
0.50
0.00

I am not sure the program must terminate.

For A=1/4, the base 10 digits are computed correctly.



--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4ca77049-3bed-45b6-8e62-5fbda28285e3%40gmail.com.

Re: [sage-devel] add transformation matrix interface for BKZ

[Gareth Ma]

Regarding fplll and flatter, Sage already has an interface with fplll 
(via fpylll), and issue #37207 is adding an interface call to flatter 
(the new pari implementation).


On 11/02/2024 23:48, user ctf wrote:

Hi. sage-devel members.
I am kiona. I want to contribute devel for some math/crypto packages.

[background]
I created Coppersmith small root method packages: 
kionactf/coppersmith(github.com) 

I am considering the package would be included in Sagemath tree.
But I am not welcomed if my codes affect Sagemath devel.
Actually, my codes depend on external packages(fplll, flatter).
It might violate Sagemath philosophy: should not reinvent wheel.

So I am starting to contribute Sagemath with a few related things.
My code uses some transformation matrix interface for BKZ,
so firstly I itry to add the feature on Sagemath code.

[main issue]
I want to add the feature that we can compute a transformation matrix 
on BKZ computation.
If I want to use the recent merge on fpylll(add transformation 
interface to bkz_reduction #267 · fplll/fpylll (github.com) 
) for adding the feature on 
Sagemath,

how could we start?
We need to wait next release on fpylll?

---
Best regards,
kiona
--
You received this message because you are subscribed to the Google 
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9009f60a-bd2b-409a-8540-ac7c37d20c38n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f85c29d8-8f3b-49c9-ad2e-e50935f14373%40gmail.com.

Re: [sage-devel] Re: Problem extracting base B fractional digits of a number

[Gareth Ma]

Yes, because 1 / 2 is mathematically infinite in base 3, just like how 
A=1/3 and B=10 doesn't terminate.


On 12/02/2024 07:31, Georgi Guninski wrote:

On Sat, Feb 10, 2024 at 6:24 PM Georgi Guninski  wrote:


```
def base_B_digits(A, B,prot=False):
 digits=[]
 fractional_part = A - int(A)
 while fractional_part != 0:
digit = int(fractional_part * B)
digits.append(digit)
fractional_part = fractional_part * B - digit
if prot:  print(fractional_part)
 return digits
```

I am not sure the program must terminate.


Just for the record, this this digit extraction algorithm doesn't terminate
for A=0.5 and B=3 in sage and pari/gp.



--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cd9f2832-5511-41a1-8abd-23df7326ab47%40gmail.com.

[sage-devel] Question about coercion model

[Gareth Ma]

Hi all,

I am currently torturing myself by looking at the coercion model. I saw 
this line 
 
which I have questions about, in particular about its interaction with 
Python objects. Take the following code for example:


sage: class Number:
: def __init__(self, x): self.x = x
: def __repr__(self): return f"Number({self.x})"
: def _acted_upon_(self, other, _): return Number(self.x * 
ZZ(other))

: a = Number(5)
: a
: a * ZZ(3)
: a * int(3)
Number(5)
Number(15)


It goes through the coercion model and arrives at the line I linked to, 
where Y is `ZZ` in the first case and `int` in the second. Then the 
`int` fails because the `isinstance(Y, Parent)` call fails, whereas the 
first succeeds.


My question is whether this behaviour is desirable, and whether there is 
any reason why Sage doesn't also check for actions with Python objects. 
More directly, will adding a check for say `or (isinstance(Y, type) and 
Y != type)` directly break anything conceptually?


For a more realistic example, currently multiplying an elliptic curve 
point by a Python `int` uses a slow binary addition method, whereas 
multiplying by a Sage `Integer` uses an optimised pari call, due to the 
behaviour.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7fd704a3-bccf-4ef5-9862-fdce2b9d95b8%40gmail.com.

Re: [sage-devel] Re: Question about coercion model

[Gareth Ma]

I see, thanks for the clear explanation, indeed "100" * a is absurd.

Still, should there at least be some mechanism to handle `int` in this 
code path? Since the path for `_mul_` works:


```
sage: class Number(Parent):
: def __init__(self, x): self.x = x
: def __repr__(self): return f"Number({self.x})"
: def _mul_(self, other): return Number(self.x * ZZ(other))
:
: a = Number(5)
: a * ZZ(3)
: a * int(3)
Number(15)
Number(15)
```

On 12/02/2024 17:43, Nils Bruin wrote:



On Monday 12 February 2024 at 03:21:36 UTC-8 Gareth Ma wrote:

sage: class Number:
: def __init__(self, x): self.x = x
: def __repr__(self): return f"Number({self.x})"
: def _acted_upon_(self, other, _): return Number(self.x *
ZZ(other))


I think that would have horrible side effects. With that code and your 
proposed change, I think


"100" * a

should succeed and hence lead to the discovery (and caching!) of an 
action of "str" on "Number". I would expect that _acted_upon_ should 
be pretty sure of the objects it handles and not rely on generic "try 
and convert this" operations.


Another place where Parent may be needed is in the caching code 
itself: some of it happens in (partially weak) global dictionaries, 
but some of it happens *on the parent*. So `int` would probably fail 
to have the appropriate infrastructure for caching.


--
You received this message because you are subscribed to the Google 
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a7ae43b1-d186-4ca1-a754-c669eec7b6e5n%40googlegroups.com 
<https://groups.google.com/d/msgid/sage-devel/a7ae43b1-d186-4ca1-a754-c669eec7b6e5n%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/33de7ced-d088-47ae-a216-ea1886e14bbb%40gmail.com.

[sage-devel] Opinions needed from cryptographers

[Gareth Ma]

Hi all, I have created issue #37305 
 to collect ideas about 
cryptography in Sage. If you have used Sage (or Python) for cryptography 
before, or just has any opinions about the prompt, please discuss them 
there. Thanks!



--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9465ad6f-18cb-49db-8a4f-47c6a9c73f02%40gmail.com.

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Gareth Ma]

Can someone from this list confirm that the PR Matthias linked (#37411) is 
okay i.e. not the topic of the debate in this thread? The added 
documentation seems harmless to me, advertises using git worktree, and can 
be updated when the discussion in this thread has a conclusion e.g. if 
upstream is moved or something.

Also, I suggest everyone to take a short break from Sage infra issues and 
go for a hike when possible.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ca9e531e-724b-4f38-8e36-7470ff0a5f0en%40googlegroups.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Gareth Ma]

I lean towards setting it to -∞.

While we are at this, how should `R.random_element` be called? The 
method currently takes a `degree` argument, which is a tuple of lower 
and upper bound, and if the user sets the lower bound to -1, then `0` is 
a possible outcome. Would the user call it with `degree=(-oo, 
upper_bound)` instead in the future?


Best regards,
Gareth

On 01/03/2024 09:07, 'Martin R' via sage-devel wrote:
I'd be OK with raising an exception or with -oo, but it should be 
uniform, and I think it should be the same for polynomials, Laurent 
polynomials and in the same spirit for degree and valuation.


It might be best to raise an exception, because this ensures that the 
zero polynomial gets special treatment.


Martin
On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:

On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:

How about using something like
https://github.com/NeilGirdhar/extended_int ?
(Even better, do a PEP to have such a thing in Python proper...)
In old, totally duck-typed, Python this didn't really matter,
but nowadays it does make
a perfect sense.

At the moment, I think most degree functions do their best to
return sage Integer objects; mainly so that coercion works well
with them. So whatever solution we use should probably be based on
objects that naturally live in the sage hierarchy. We do have an
infinity object in sage and it already gets used for valuations.

Incidentally:

 sage: R.=LaurentSeriesRing(QQ)
sage: z=R(0)
sage: z.valuation()
+Infinity
sage: z.degree()
-1

I don't quite know why laurent series have a degree defined at
all, but they're keeping to the deg(0)=-1 convention.

Incidentally:

sage: A.=QQ[]
sage: B.=LaurentPolynomialRing(QQ)
sage: x.valuation(oo)
-1
sage: y.valuation(oo)
1
so polynomial rings have a valuation (that will return +oo when
appropriate), but on LaurentPolynomialRing this gets silently
broken: the argument simply gets ignored and the valuation at 0 is
returned. So I guess you can get a well-behaving degree with

f=0*y
-f(1/y).valuation()

--
You received this message because you are subscribed to the Google 
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ec50bffa-37ef-4bee-9095-09e738be1842n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6e66f617-3cc4-4657-a880-c3494a28decb%40gmail.com.

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

[Gareth Ma]

And that will be a problem when `R` is a laurent polynomial ring.

On 01/03/2024 09:12, Gareth Ma wrote:

I lean towards setting it to -∞.

While we are at this, how should `R.random_element` be called? The 
method currently takes a `degree` argument, which is a tuple of lower 
and upper bound, and if the user sets the lower bound to -1, then `0` 
is a possible outcome. Would the user call it with `degree=(-oo, 
upper_bound)` instead in the future?


Best regards,
Gareth

On 01/03/2024 09:07, 'Martin R' via sage-devel wrote:
I'd be OK with raising an exception or with -oo, but it should be 
uniform, and I think it should be the same for polynomials, Laurent 
polynomials and in the same spirit for degree and valuation.


It might be best to raise an exception, because this ensures that the 
zero polynomial gets special treatment.


Martin
On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:

On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:

How about using something like
https://github.com/NeilGirdhar/extended_int ?
(Even better, do a PEP to have such a thing in Python proper...)
In old, totally duck-typed, Python this didn't really matter,
but nowadays it does make
a perfect sense.

At the moment, I think most degree functions do their best to
return sage Integer objects; mainly so that coercion works well
with them. So whatever solution we use should probably be based
on objects that naturally live in the sage hierarchy. We do have
an infinity object in sage and it already gets used for valuations.

Incidentally:

 sage: R.=LaurentSeriesRing(QQ)
sage: z=R(0)
sage: z.valuation()
+Infinity
sage: z.degree()
-1

I don't quite know why laurent series have a degree defined at
all, but they're keeping to the deg(0)=-1 convention.

Incidentally:

sage: A.=QQ[]
sage: B.=LaurentPolynomialRing(QQ)
sage: x.valuation(oo)
-1
sage: y.valuation(oo)
1
so polynomial rings have a valuation (that will return +oo when
appropriate), but on LaurentPolynomialRing this gets silently
broken: the argument simply gets ignored and the valuation at 0
is returned. So I guess you can get a well-behaving degree with

f=0*y
-f(1/y).valuation()

--
You received this message because you are subscribed to the Google 
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ec50bffa-37ef-4bee-9095-09e738be1842n%40googlegroups.com 
<https://groups.google.com/d/msgid/sage-devel/ec50bffa-37ef-4bee-9095-09e738be1842n%40googlegroups.com?utm_medium=email&utm_source=footer>.




--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/18c66bb0-b11f-48b8-9de6-403ebc5cb2d5%40gmail.com.

Re: [sage-devel] weirdest bug ever

[Gareth Ma]

You typed `mononomials` instead of `monomials`. That's a nono.

On 09/03/2024 22:22, 'Martin R' via sage-devel wrote:

If I store this in a file "bug.sage" I can do:

sage: load('/home/martin/bug.sage')
sage: c = bug()
sage: c.coefficients_mononomials()


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/34bc487f-5956-4f57-832f-935598f3b66c%40gmail.com.

[sage-devel] Question about Morphism and SchemeMorphism (Issue 14711)

[Gareth Ma]

I'm currently working on stuff related to `EllipticCurveHom` and 
`SchemeMorphism` at #37705. While working on it, I realised there's a 
fundamental difference between the two `EllipticCurveHom` inherits from 
`sage.categories.morphism.Morphism`, while `SchemeMorphism` inherits 
from `sage.schemes.generic.morphism.SchemeMorphism`, and no neither 
inherits from the other. Tracing back, there's this TODO:


```
.. TODO::

    For historical reasons, :class:`SchemeMorphism` copies code from
    :class:`~sage.categories.map.Map` rather than inheriting from it.
    Proper inheritance should be used instead. See :issue:`14711`.
```

I tried reading through the thread of #14711, but it's quite hard to 
understand, since I don't have background in the structural part of 
Sage. I don't even understand how the title "Weak references in the 
coercion graph" relate to the problem. Does anyone know about this 
issue? (It seems at least three participants are still active in Sage 
dev.) Can this be resolved in 2024?


/This is not an April-Fools joke./

Best regards,

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0ad0ec50-5a96-4f3e-8cd1-27732c2f60dc%40gmail.com.

[sage-devel] Re: Question about Morphism and SchemeMorphism (Issue 14711)

[Gareth Ma]

I have looked into some of the issues and TODOs discussed in #14711, and 
put my thoughts under #37705. In particular, to merge `SchemeMorphism` 
with `Morphism` (or at least make SchemeMorphism inherit from Morphism), 
I think the coercion model should be tweaked, so opinions from experts 
are very much needed. In particular, the current (heuristic) algorithm 
for `cm.discover_action` behaves badly when there is a "type diamond" (a 
terminology borrowed from Lean), i.e. multiple type inheritance. Take 
this for example,


         SageObject (coercion model)
  ^  ^
  |  |
 /       Map
    /          \
  ModuleElement     Morphism
    ^  ^
 \    /
  \  /
   SchemeMorphism

The coercion model has a special path for multiplying ModuleElement by 
another Element, meaning the operation defined in Morphism/Map will be 
ignored, which is undesirable since well a SchemeMorphism should be more 
like a morphism not a module element I guess


(Sorry for the spam on Easter holidays)


On 01/04/2024 04:34, Gareth Ma wrote:
I'm currently working on stuff related to `EllipticCurveHom` and 
`SchemeMorphism` at #37705. While working on it, I realised there's a 
fundamental difference between the two `EllipticCurveHom` inherits 
from `sage.categories.morphism.Morphism`, while `SchemeMorphism` 
inherits from `sage.schemes.generic.morphism.SchemeMorphism`, and no 
neither inherits from the other. Tracing back, there's this TODO:


```
.. TODO::

    For historical reasons, :class:`SchemeMorphism` copies code from
    :class:`~sage.categories.map.Map` rather than inheriting from it.
    Proper inheritance should be used instead. See :issue:`14711`.
```

I tried reading through the thread of #14711, but it's quite hard to 
understand, since I don't have background in the structural part of 
Sage. I don't even understand how the title "Weak references in the 
coercion graph" relate to the problem. Does anyone know about this 
issue? (It seems at least three participants are still active in Sage 
dev.) Can this be resolved in 2024?


/This is not an April-Fools joke./

Best regards,


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3a2fc1fc-9d13-4ddc-9703-e7eedb22ae74%40gmail.com.

[sage-devel] Projective Spaces are not not cached

[Gareth Ma]

In the documentation of `ProjectiveSpace` constructor, it says

> Projective spaces are not cached, i.e., there can be several with
> the same base ring and dimension (to facilitate gluing
> constructions).

However, that doesn't seem to be true, since (1) it's a `UniqueRepresentation`,
and (2) `ProjectiveSpace(3, ZZ) is ProjectiveSpace(3, ZZ)` returns `True`. Is
this a bug? And I guess more importantly, is this a problem in practice?

@Kwankyu since I believe you are familiar with algebraic geometry in Sage

Best regards,
Gareth

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/aceb8f08-80bc-48f6-a5b4-fbcdf511b84f%40gmail.com.

Re: [sage-devel] Re: Vote: Removing Automatic PR Size Labels

[Gareth Ma]

I vote for (A1) and no other options.

In fact, I don't think size related labels should be a thing at all, so the
second half of (A1), i.e. "the[y] must be added manually (like most other
labels)", should preferably be removed as well. (The wording suggests they will
be kept and added manually.)

On 6/15/24 7:49 AM, Vincent Delecroix wrote:
> On the material side I vote (A1).
> 
> On the human side I vote (B). Matthias raised a delicate point: this
> feature was introduced by a newcomer to sage development. The feature
> might have been wrongly guided or badly thought. Nevertheless, it
> would be very unwelcoming to just revert it.
> 
> Ideally, there would be a "make the feature even nicer" solution
> rather than "get rid of that s***". Though, this requires a concrete
> proposal more than a vote, and I have nothing magical to share at this
> stage.
> 
> Best
> Vincent
> 
> On Fri, 14 Jun 2024 at 13:56, Kwankyu Lee  wrote:
>>
>> +1 to (A1)
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/cd9f975b-3605-4e98-a165-2a2e1d4ab2b9n%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/54953f8f-fca6-4f79-8ba2-e87546f0ba24%40gmail.com.

Re: [sage-devel] Bug in `discrete_log(...,bounds=(1,p.isqrt()))`

[Gareth Ma]

I think so too. Here's a more minimal version (note a == 1 in your example):

p = 31
g = GF(31)(3)
discrete_log(1, g, bounds=(1, 6), algorithm="lambda", operation="*")
# 6
g^6
# 16

It seems there's some serious bugs going on, as the return value isn't in the
bounds:

K = GF(2^61 - 1)
d = discrete_log(K(1), K(3), bounds=(1,2^30), algorithm="lambda", operation="*")
d <= 2^30
# False

Instead, the algorithm should error out, since number theory shows there's no
non-zero (mod 2^61 - 2) solution to 3^a = 1 mod (2^61 - 1)

On 6/30/24 4:10 PM, Georgi Guninski wrote:
> I think this is bug:
> 
> p=2**61-1;Kp=GF(p);g=Kp(3);X=p//3;a=g**X
> dl=discrete_log(a,g,bounds=(1,p.isqrt()),algorithm="lambda",operation="*")
> dl2=discrete_log(a,g,bounds=(1,p),algorithm="lambda",operation="*")
> (g**dl==a,g**dl2==a)
> 
> #(False, True)
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5dbc76b5-c354-49b2-b721-ef29e7461716%40gmail.com.

[sage-devel] fflas-ffpack install fail

[Gareth Ma]

Hi, I'm running `make build` on latest dev branch, and I get the following 
error:

```
Error building Sage.

The following package(s) may have failed to build (not necessarily
during this run of 'make all-build'):

* package: fflas_ffpack-2.5.0+sage-2024-05-18b
  last build time: Jul 31 18:53
  log file:
/home/grhkm/git/sage/logs/pkgs/fflas_ffpack-2.5.0+sage-2024-05-18b.log
  build directory:
/home/grhkm/miniforge3/envs/sage-dev/var/tmp/sage/build/fflas_ffpack-2.5.0+sage-2024-05-18b
```

I have linked the log file below. In particular I see that these are the
erroring lines:

```
[spkg-install]
/home/grhkm/miniforge3/envs/sage-dev/bin/../lib/gcc/x86_64-conda-linux-gnu/12.3.0/../../../../x86_64-conda-linux-g
nu/bin/ld: /home/grhkm/miniforge3/envs/sage-dev/lib/libfflas.a(fflas_L1_inst.o):
relocation R_X86_64_PC32 against symbol `_ZSt4co
ut@@GLIBCXX_3.4' can not be used when making a shared object; recompile with 
-fPIC
[spkg-install]
/home/grhkm/miniforge3/envs/sage-dev/bin/../lib/gcc/x86_64-conda-linux-gnu/12.3.0/../../../../x86_64-conda-linux-g
nu/bin/ld: final link failed: bad value
```

Does anyone know what these means? *What* should I be recompiling with `-fPIC`,
and how do I enable that?

fflas_ffpack log: 
https://gist.github.com/grhkm21/58e1de21b9a2db85bf35149ec6b8c46b



Also I have fflas-ffpack installed on the system (from
`g...@github.com:linbox-team/fflas-ffpack.git` directly), is it possible to tell
Sage to use that instead?

```
$ ls -la /usr/include/fflas-ffpack | head -n 5
drwxr-xr-x- root 16 Jul 21:29 checkers
.rw-r--r--  25k root  1 Jul 23:22 config-blas.h
.rw-r--r-- 6.6k root  1 Jul 23:22 config.h
drwxr-xr-x- root 16 Jul 21:29 fflas
.rw-r--r-- 5.0k root  1 Jul 23:22 fflas-ffpack-config.h
```

(Cross-posted from Zulip)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ae2c13e6-664a-4fd0-b674-51aab18dff39%40gmail.com.

[sage-devel] Re: fflas-ffpack install fail

[Gareth Ma]

Bumping this thread, since it's stopping me from reviewing tickets :)

On Wednesday 31 July 2024 at 20:11:42 UTC+1 Gareth Ma wrote:

> Hi, I'm running `make build` on latest dev branch, and I get the following 
> error:
>
> ```
> Error building Sage.
>
> The following package(s) may have failed to build (not necessarily
> during this run of 'make all-build'):
>
> * package: fflas_ffpack-2.5.0+sage-2024-05-18b
> last build time: Jul 31 18:53
> log file:
> /home/grhkm/git/sage/logs/pkgs/fflas_ffpack-2.5.0+sage-2024-05-18b.log
> build directory:
>
> /home/grhkm/miniforge3/envs/sage-dev/var/tmp/sage/build/fflas_ffpack-2.5.0+sage-2024-05-18b
> ```
>
> I have linked the log file below. In particular I see that these are the
> erroring lines:
>
> ```
> [spkg-install]
>
> /home/grhkm/miniforge3/envs/sage-dev/bin/../lib/gcc/x86_64-conda-linux-gnu/12.3.0/../../../../x86_64-conda-linux-g
> nu/bin/ld: 
> /home/grhkm/miniforge3/envs/sage-dev/lib/libfflas.a(fflas_L1_inst.o):
> relocation R_X86_64_PC32 against symbol `_ZSt4co
> ut@@GLIBCXX_3.4' can not be used when making a shared object; recompile 
> with -fPIC
> [spkg-install]
>
> /home/grhkm/miniforge3/envs/sage-dev/bin/../lib/gcc/x86_64-conda-linux-gnu/12.3.0/../../../../x86_64-conda-linux-g
> nu/bin/ld: final link failed: bad value
> ```
>
> Does anyone know what these means? *What* should I be recompiling with 
> `-fPIC`,
> and how do I enable that?
>
> fflas_ffpack log: 
> https://gist.github.com/grhkm21/58e1de21b9a2db85bf35149ec6b8c46b
>
>
>
> Also I have fflas-ffpack installed on the system (from
> `g...@github.com:linbox-team/fflas-ffpack.git` directly), is it possible 
> to tell
> Sage to use that instead?
>
> ```
> $ ls -la /usr/include/fflas-ffpack | head -n 5
> drwxr-xr-x - root 16 Jul 21:29 checkers
> .rw-r--r-- 25k root 1 Jul 23:22 config-blas.h
> .rw-r--r-- 6.6k root 1 Jul 23:22 config.h
> drwxr-xr-x - root 16 Jul 21:29 fflas
> .rw-r--r-- 5.0k root 1 Jul 23:22 fflas-ffpack-config.h
> ```
>
> (Cross-posted from Zulip)
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7b2d0cd7-05ef-42bb-a681-583fe283f161n%40googlegroups.com.

Re: [sage-devel] Re: fflas-ffpack install fail

[Gareth Ma]

My `conda list`:
  https://gist.github.com/grhkm21/ac89913f1b168d96b3ffa67f37bcc2d5

config.log and package logs:
  https://gist.github.com/grhkm21/6146c6da5c884687b28c4de07e6567fb

@Dima: As you can see from the output, I *did* install fflas-ffpack via Conda
using `conda install fflas-ffpack`. IIRC this command is also suggested after I
run ./configure. But it isn't used somehow.

@Matthias: Linked above.

Also the output of `fflas_ffpack-2.5.0+sage-2024-05-18b.log` gives me a command
to cd into the build directory and load a subshell to setup environment
variables. Confusingly when I build manually there (`make`) it compiles
successfully.

On 8/2/24 2:48 PM, Dima Pasechnik wrote:
> is there a reason for not using fflas-ffpack from Conda?
> (as far as I understand, you're building under Conda)
> 
> fflas-ffpack from the system might not be compatible (e.g. if a
> different C++ compiler was used)
> 
> 
> On Fri, Aug 2, 2024 at 1:24 PM Gareth Ma  wrote:M
>>
>> Bumping this thread, since it's stopping me from reviewing tickets :)
>>
>> On Wednesday 31 July 2024 at 20:11:42 UTC+1 Gareth Ma wrote:
>>>
>>> Hi, I'm running `make build` on latest dev branch, and I get the following 
>>> error:
>>>
>>> ```
>>> Error building Sage.
>>>
>>> The following package(s) may have failed to build (not necessarily
>>> during this run of 'make all-build'):
>>>
>>> * package: fflas_ffpack-2.5.0+sage-2024-05-18b
>>> last build time: Jul 31 18:53
>>> log file:
>>> /home/grhkm/git/sage/logs/pkgs/fflas_ffpack-2.5.0+sage-2024-05-18b.log
>>> build directory:
>>> /home/grhkm/miniforge3/envs/sage-dev/var/tmp/sage/build/fflas_ffpack-2.5.0+sage-2024-05-18b
>>> ```
>>>
>>> I have linked the log file below. In particular I see that these are the
>>> erroring lines:
>>>
>>> ```
>>> [spkg-install]
>>> /home/grhkm/miniforge3/envs/sage-dev/bin/../lib/gcc/x86_64-conda-linux-gnu/12.3.0/../../../../x86_64-conda-linux-g
>>> nu/bin/ld: 
>>> /home/grhkm/miniforge3/envs/sage-dev/lib/libfflas.a(fflas_L1_inst.o):
>>> relocation R_X86_64_PC32 against symbol `_ZSt4co
>>> ut@@GLIBCXX_3.4' can not be used when making a shared object; recompile 
>>> with -fPIC
>>> [spkg-install]
>>> /home/grhkm/miniforge3/envs/sage-dev/bin/../lib/gcc/x86_64-conda-linux-gnu/12.3.0/../../../../x86_64-conda-linux-g
>>> nu/bin/ld: final link failed: bad value
>>> ```
>>>
>>> Does anyone know what these means? *What* should I be recompiling with 
>>> `-fPIC`,
>>> and how do I enable that?
>>>
>>> fflas_ffpack log: 
>>> https://gist.github.com/grhkm21/58e1de21b9a2db85bf35149ec6b8c46b
>>>
>>>
>>>
>>> Also I have fflas-ffpack installed on the system (from
>>> `g...@github.com:linbox-team/fflas-ffpack.git` directly), is it possible to 
>>> tell
>>> Sage to use that instead?
>>>
>>> ```
>>> $ ls -la /usr/include/fflas-ffpack | head -n 5
>>> drwxr-xr-x - root 16 Jul 21:29 checkers
>>> .rw-r--r-- 25k root 1 Jul 23:22 config-blas.h
>>> .rw-r--r-- 6.6k root 1 Jul 23:22 config.h
>>> drwxr-xr-x - root 16 Jul 21:29 fflas
>>> .rw-r--r-- 5.0k root 1 Jul 23:22 fflas-ffpack-config.h
>>> ```
>>>
>>> (Cross-posted from Zulip)
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/7b2d0cd7-05ef-42bb-a681-583fe283f161n%40googlegroups.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4c36f644-b67c-488e-88a2-eff300fbf442%40gmail.com.

Re: [sage-devel] Re: meson build doesn't find cysignals?

[Gareth Ma]

Content of /home/grhkm/git/sage/build/cp311/meson-logs/meson-log.txt:

https://gist.github.com/grhkm21/21dea0c9b2f3b712f91f926757863045

(The conda environment is now called `sage-dev-2`)

Yes, importing `cysignals.signals` works in the conda python. I guess because
it's installed in `$CONDA_PREFIX/lib/python3.11/site-packages`.

On 1/1/25 7:29 PM, 'tobia...@gmx.de' via sage-devel wrote:
> Can you please also post the output of 
> /home/grhkm/git/sage/build/cp311/meson-logs
> 
> Does `import cysignals.signals` from python in the activated conda env work?
> 
> On Wednesday, January 1, 2025 at 6:08:04 PM UTC+8 grh...@gmail.com wrote:
> 
> I am trying to use the `meson` build method instead of conda-forge for
> dependencies. I installed the build dependencies following
> [prerequisites](https://doc.sagemath.org/html/en/installation/
> source.html#section-prereqs 
>  source.html#section-prereqs>),
> then run these commands
> 
> ```sh
> conda remove -n sage-dev --all # remove the entire conda environment
> 
> ./bootstrap # docs tell me to run ./bootstrap-conda but it's removed in 
> #37447
> mamba env create --file environment-3.11-linux.yml --name sage-dev # same 
> as
> above
> conda activate sage-dev
> 
> pip install --no-build-isolation --editable . -v 2>&1 | tee build.log
> ```
> 
> https://gist.github.com/grhkm21/26584abf9ae7faa83c376535ad8dc10d  gist.github.com/grhkm21/26584abf9ae7faa83c376535ad8dc10d>
> 
> All of the errors seem to be related to cysignals missing somehow, even 
> though
> it's clearly installed in my Conda environment:
> 
> Also I have the required `cysignals/signals.pxd` somewhere on my system...
> ```sh
> $ fd signals.pxd /
> /home/grhkm/miniforge3/envs/sage-dev/lib/python3.11/site-packages/
> memory_allocator/signals.pxd
> 
> /home/grhkm/miniforge3/envs/sage-dev/lib/python3.11/site-packages/cysignals/
> signals.pxd
> 
> /home/grhkm/miniforge3/envs/sage-dev/lib/python3.11/site-packages/cysignals/
> pysignals.pxd
> /home/grhkm/miniforge3/pkgs/memory-allocator-0.1.3-py311h9ecbd09_1/lib/
> python3.11/site-packages/memory_allocator/signals.pxd
> /home/grhkm/miniforge3/pkgs/memory-allocator-0.1.3-py311h459d7ec_0/lib/
> python3.11/site-packages/memory_allocator/signals.pxd
> 
> /home/grhkm/miniforge3/pkgs/cysignals-1.11.2-py311h82528dc_3/lib/python3.11/
> site-packages/cysignals/signals.pxd
> 
> /home/grhkm/miniforge3/pkgs/cysignals-1.11.2-py311h82528dc_3/lib/python3.11/
> site-packages/cysignals/pysignals.pxd
> ```
> 
> I am on Linux Fedora.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-
> devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to sage-devel+unsubscr...@googlegroups.com  devel+unsubscr...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/sage-
> devel/340879d6-7f86-47b7-81f4-4eafed4e3b7an%40googlegroups.com  groups.google.com/d/msgid/sage-
> devel/340879d6-7f86-47b7-81f4-4eafed4e3b7an%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sage-devel/e659285c-8b6f-4a1c-8d71-35792d52de45%40gmail.com.

[sage-devel] meson build doesn't find cysignals?

[Gareth Ma]

I am trying to use the `meson` build method instead of conda-forge for
dependencies. I installed the build dependencies following
[prerequisites](https://doc.sagemath.org/html/en/installation/source.html#section-prereqs),
then run these commands

```sh
conda remove -n sage-dev --all # remove the entire conda environment

./bootstrap # docs tell me to run ./bootstrap-conda but it's removed in #37447
mamba env create --file environment-3.11-linux.yml --name sage-dev # same as 
above
conda activate sage-dev

pip install --no-build-isolation --editable . -v 2>&1 | tee build.log
```

https://gist.github.com/grhkm21/26584abf9ae7faa83c376535ad8dc10d

All of the errors seem to be related to cysignals missing somehow, even though
it's clearly installed in my Conda environment:

Also I have the required `cysignals/signals.pxd` somewhere on my system...
```sh
$ fd signals.pxd /
/home/grhkm/miniforge3/envs/sage-dev/lib/python3.11/site-packages/memory_allocator/signals.pxd
/home/grhkm/miniforge3/envs/sage-dev/lib/python3.11/site-packages/cysignals/signals.pxd
/home/grhkm/miniforge3/envs/sage-dev/lib/python3.11/site-packages/cysignals/pysignals.pxd
/home/grhkm/miniforge3/pkgs/memory-allocator-0.1.3-py311h9ecbd09_1/lib/python3.11/site-packages/memory_allocator/signals.pxd
/home/grhkm/miniforge3/pkgs/memory-allocator-0.1.3-py311h459d7ec_0/lib/python3.11/site-packages/memory_allocator/signals.pxd
/home/grhkm/miniforge3/pkgs/cysignals-1.11.2-py311h82528dc_3/lib/python3.11/site-packages/cysignals/signals.pxd
/home/grhkm/miniforge3/pkgs/cysignals-1.11.2-py311h82528dc_3/lib/python3.11/site-packages/cysignals/pysignals.pxd
```

I am on Linux Fedora.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sage-devel/b270c5a1-de5c-437d-8d07-daa295de40f9%40gmail.com.

[sage-devel] GSoC 2025 Applications

[Gareth Ma]

Are we applying to become a GSoC organisation this year? Have we done so?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sage-devel/b3cae782-d4ed-4737-94e5-772eb38bf0e2%40gmail.com.

[sage-devel] Patching Sage's Python's packages

[Gareth Ma]

Not sure how to title the subject because I am not familiar with Sage's build
system at all, but hope the body explains what it means.

===

Usually, I build Sage with `./bootstrap && ./configure && make build`, but I
believe the same problem below happens for conda install as well (the setuptools
part should be the same.) In the build log / output, there's occasionally these
lines:

[*] building 'sage.schemes.hyperelliptic_curves.hypellfrob' extension
... (The $CC ... commands)
[*] building 'sage.rings.polynomial.polynomial_modn_dense_ntl' extension
[*] building 'sage.schemes.elliptic_curves.descent_two_isogeny' extension
[*] building 'sage.schemes.elliptic_curves.mod_sym_num' extension
[*] building 'sage.schemes.hyperelliptic_curves.hypellfrob' extension
[*] building 'sage.schemes.elliptic_curves.period_lattice_region' extension
[*] building 'sage.schemes.toric.divisor_class' extension
[*] building 'sage.rings.polynomial.polynomial_modn_dense_ntl' extension

([*] is [spkg-install]) But the issue for the user / developer is that this
doesn't show what is the progress of the build, i.e. how many extensions has
been built and how many are there left. Another annoyance would be lines such as

dependency  won't ... included in the manifest: the path must be relative

These are annoying mainly because running `make build` from an already built
directory still prints 9054 of these, so it would be nice to mute them, or at
least have the option to mute them.

I think I can set the logging level to be > INFO (how do I do that? Is there an
environment variable? I can't find it in the Sage docs,) but then I also lose
other logging.info informations.



I traced down where these are printed. In two places:

https://github.com/pypa/setuptools/blob/main/setuptools/command/build_ext.py#L289-L294
https://github.com/pypa/setuptools/blob/main/setuptools/_distutils/command/build_ext.py#L530-L535

So (from what I know) there are two options if we want to mute these lines:

- I submit a PR to setuptools directly
  -> but I doubt they would think the above reasoning is sufficient for a change
- Alternatively, I believe that Sage builds a Python from source currently, or
at least that's what I believe, since I see a path
`/home/grhkm/git/sage/local/var/lib/sage/venv-python3.12/lib/python3.12/site-packages/setuptools/...`
which contains the setuptools package used for building. Is it possible to apply
a patch to the setuptools, similar to other .patch files I see in `build/...`?
If so, where should I put the patch file?

Even if this is a bad idea, I hope someone can answer the "where should I put
the patch file" question, I think it will help me understand the Sage build
system a lot better.

Thanks in advance!

Gareth

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sage-devel/ab451ac4-8b12-4ea0-9211-e85f5ee31a9c%40gmail.com.

Re: [sage-devel] Subgroups of automorphism groups of graphs

[Gareth Ma]

It seems that this is intended? The correct equivalent code is:

sage: gens = [[(2, 4)], [(1, 2)]]
sage: pg = PermutationGroup(gens=gens); pg
Permutation Group with generators [(2,4), (1,2)]
sage: pg._libgap_()
Group([ (2,4), (1,2) ])
sage: pg = PermutationGroup(gens=gens, domain={1, 2, 4}); pg
Permutation Group with generators [(2,4), (1,2)]
sage: pg._libgap_()
Group([ (2,3), (1,2) ])

Which is what's done at
https://github.com/sagemath/sage/blob/develop/src/sage/graphs/generic_graph.py#L24161-L24170.
But I'm not an expert in this part of the code.

Also, I didn't know we have a 25k lines file.

On 1/28/25 10:27 AM, 'Peter Mueller' via sage-devel wrote:
> The following code shows that subgroups of automorphism groups of graphs are
> handled wrongly:
> 
> sage: g = Graph([[1, 2, 4], []])
> sage: a = g.automorphism_group()
> sage: print(a)
> Permutation Group with generators [(2,4), (1,2)]
> sage: print(a.commutator())
> Permutation Group with generators [(1,2,3)]
> 
> Note that  a.commutator() moves 3 though 3 is not a vertex of the graph.
> Somewhat strangely, if one defines directly a = PermutationGroup([[(2, 4)], 
> [(1,
> 2)]]), then a.commutator() returns the correct subgroup.
> 
> By the way, it doesn't help if the n vertices of the graph consist of the list
> [1..n]. I have a complicated example where the automorphism group is computed
> correctly, but the action of the commutator subgroup is with respect to a
> different labeling of the vertices.
> 
> -- Peter Mueller
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-
> devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to sage-devel+unsubscr...@googlegroups.com  devel+unsubscr...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/
> fec1df7a-9db7-43b2-9af2-8dcdf6658585n%40googlegroups.com  groups.google.com/d/msgid/sage-devel/
> fec1df7a-9db7-43b2-9af2-8dcdf6658585n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sage-devel/dfa81010-69db-4ccb-a4a1-804d89c14968%40gmail.com.