Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Nils Bruin]

On Tuesday 17 September 2024 at 07:04:18 UTC-7 dim...@gmail.com wrote:


that's the legacy of developing software in a platform-independent 
machine assembly language 
known as C or C++, or Fortran :-) 
Then, as we know, Greenspun's tenth rule states that: 

Any sufficiently complicated C or Fortran program contains an ad hoc, 
informally-specified, bug-ridden, slow implementation of half of 
Common Lisp. 


That's not actually the kind of bug I was thinking of. The memory leaks 
that have been particularly hard to find in sage were on python/cython 
level, which are generally memory-safe languages. They are about how to 
handle the essentially global data structure that arises from the coercion 
framework.

For instance, if you'd store on ZZ the coercion maps to any ring in the 
normal way, every ring now has a reference from an object that will never 
be garbage collected (ZZ) and hence will not be eligible for collection 
either. Sage doesn't do that, of course, but the coercion graph does need 
to hold this information somehow. Doing that in a way that still allows 
parts to be pruned once some objects are not referenced very much anymore 
is truly a delicate problem. The globally unique "UniqueParent"s are 
another example of such a hard-to-manage global data structure, where 
garbage removal is very delicate. From python's (or common lisp's) 
perspective these wouldn't be memory leaks: they are just globally 
accessible structures ineligible for collection.

-- 
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/adf2eec2-1512-4116-8a20-aa8db5536bdcn%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Nils Bruin]

On Monday 16 September 2024 at 06:20:37 UTC-7 Georgi Guninski wrote:

Maybe fighting leaks should start at developer level, then QA. 
Waiting to see gigabytes missing in a minute is a very crude way 
to recognize leak. 


It's very common for computer algebra packages to have memory leaks, 
particularly because useful caching in one situation can be a memory leak 
in another -- it can really depend on the use case. Some memory leaks may 
end up unavoidable with certain designs.They usually arise from scenarios 
not considered by the original authors. It's great that you find them and 
hopefully it helps educate a new generation of developers. 
 
In practice, almost all computer algebra systems seem to benefit (both in 
memory use and in performance) from frequent restarts, so from a practical 
perspective one should always look for ways to chop a computation into 
smaller blocks and extracting meaningful intermediate results so that they 
can be recreated. This matches with strategies that help in generating 
reproducible results, so this is slightly less of a burden than one might 
think initially.

Hunting memory leaks is definitely necessary to maintain a workable system 
but I don't think that completely eliminating them (or ensuring new ones 
don't appear!) is an attainable goal.

-- 
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/4e7a7e79-b71a-43cb-9ce7-a3f158a6dfban%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Nils Bruin]

On Sunday 15 September 2024 at 10:46:06 UTC-7 marc@gmail.com wrote:

> You can grab one of those objects on the heap and look at its 
backreference graph 

How does one do that? 


You can grab one of the objects:

next(a for a in gc.get_objects() if id(a) not in pre and str(type(a)) == 
"")

(if your type doesn't nail down the objects completely you may want a 
little more than just the next object from this generator)

from there, https://pypi.org/project/objgraph/ . The author has linked some 
blogposts to illustrate how to use these tools to find memory links
 

-- 
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/6ee3bba6-c843-4892-b48f-b37147f076b3n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Nils Bruin]

On Sunday 15 September 2024 at 10:08:18 UTC-7 dim...@gmail.com wrote:

For me this code is rather unpredictable, as ipython and prompt_toolkit 
kick in 
and produce extra objects. 

For consistency (at least them the output values are reproducible) 
it looks better to experiment with Sage's python (./sage --python) 
for which the code needs to be adjusted, with "^" replaced by "**", and 
two lines added as the front: 

from sage.all import * 
var('x') 


Generally, to check if there's a leak one would look how object swell on 
the heap grows with iterations. That drowns out the constant overhead of 
the shell.
Or you can just wrap the whole measuring process in a function, so that it 
gets executed in an enclosed scope. There are generally some objects whose 
creation does scale with iteration and whose type is rather specific. You 
can grab one of those objects on the heap and look at its backreference 
graph. That generally gives a pretty good pointer to where the global 
references are held. It can actually be a fairly interesting challenge for 
someone with an interest in learning the nitty gritty details of the 
sagemath memory setup. It doesn't require brilliance; mostly persistence. 

-- 
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/beacd365-e173-4ab9-a014-bb0fa89e2e54n%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Nils Bruin]

On Sunday 8 September 2024 at 13:18:40 UTC-7 marc@gmail.com wrote:

As I said above this does not happen with either cypari or cypari2 when 
using getno.

This is not a cypari issue.  The issue is that Sage creates a "unique" 
object for each new number field, where new means that the input parameters 
for the NumberField function have not been used before. The number field 
objects are stored in a cache indexed by a key generated from the input 
parameters.  Those cached objects live for the entire session.  This is by 
design. The design did not anticipate creating a billion number fields in 
one Sage session.  That was not necessarily a bad choice.

Perhaps there is a way of disabling caching or clearing the cache.


I don't think that number fields are designed to be immortal. They probably 
end up being that because of a combination of references in the coercion 
framework and the UniqueRepresentation store. The idea of 
UniqueRepresentation objects is that when an object is created *with the 
same creation parameters* as an object that already exists, then that 
identical object is returned. One main advantage (and originally one of the 
important reasons for introducing that design) is that equality can then be 
reduced to identity, which is a lightning-fast comparison. In the coercion 
framework this is quite important because arithmetic operations can easily 
end up in inner loops, so a fast path for deciding coercion doesn't need to 
do anything is important. Parent equality indicates this!

The reference dictionary that keeps track of UniqueRepresentation objects 
by itself does NOT try to make the objects immortal: if a parent gets 
created and then loses all references, it should be garbage collectible, 
and many UniqueRepresentation objects are. Once the object is garbage 
collected, a new instance would be created. This is realized by using a 
WeakValueDictionary for the UniqueRepresentation storage: the global 
reference to the object held by the UniqueRepresentation constructor does 
not count towards the reference count. So if there are otherwise no 
references (or only other weak ones) the object becomes eligible for 
garbage collection.

In practice, for such complicated objects (particularly objects that 
participate in the coercion framework), the reference count is very likely 
never zero. For one thing, rings generally cache their 0 and 1 and those 
elements hold a reference back to their parent. So parents almost always 
have to be garbage collected by the cycle-detecting mark-and-sweep.

A classic example for how an object can become immortal through this 
process is if one of the construction parameters of an object ends up 
participating in a reference chain to the constructed object. This can 
happen through caching operations, for caches that are only intended to 
survive for the lifetime of the object. Now there is a global reference 
(held by the construction parameter that is stored in UniqueRepresentation) 
to the object , so the entry from the WeakValueDict is never removed. 
Normally this key info would get dereferenced once the value gets garbage 
collected, so those keys would normally not be immortal either. But the 
cycle prevents removal.

There are other such side-effects of some of the global WeakValueDicts that 
are use, as well as the MonoDicts and TripleDicts used in the coercion 
framework. For UniqueRepresentation, it means one needs to be very 
disciplined about the way the construction parameters are stored. For the 
most part, these should be rather simple objects that cannot hold 
references to the kinds of objects that are instantiated from the 
parameters. But this is a very difficult and non-local thing to establish, 
so it's almost impossible to get programmers to adhere such discipline 
[partly because it's difficult to properly codify into simple-to-apply 
rules, and hence this hasn't been done].

-- 
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/ad214e52-23aa-45ed-a03b-1f5778f981bdn%40googlegroups.com.

[sage-devel] Re: Memory leak in `NumberField().class_group().order()`

[Nils Bruin]

This example is definitely leaving loads of stuff on the python heap, so if 
there is a leak onto the cython heap then it is not the only one. My guess 
would be an interaction with the coercion system or UniqueRepresentation, 
which both keeps global weak references to objects. If the key information 
ends up containing objects that hold a reference to the values in a weakly 
valued dictionary, the garbage collector can not remove the cycle. These 
things are hellish to debug. The code below does find the relevant objects 
on the heap, though, so you can plot the backwards reference graphs of some 
of these objects to see what kinds of links are involved. We have resolved 
some of these bugs in the past.

```
import gc
from collections import Counter

gc.collect()
pre={id(a) for a in gc.get_objects()}

for A2 in range(1, 1000):
Kn=NumberField(x^2+A2,'w')
m=Kn.class_group().order()
del Kn, m

gc.collect()
gc.collect()
T=Counter(str(type(a)) for a in gc.get_objects() if id(a) not in pre)
T
```
Notes for the code above:
 - if you run it twice you get a nearly empty list from T, which is 
consistent with UniqueRepresentation objects remaining (they would not be 
recreated if they already exist).
 - this is confirmed by rerunning the loop but now with another name than 
'w' for Kn. Now new objects do get created!

On Wednesday 4 September 2024 at 06:09:37 UTC-7 Georgi Guninski wrote:

> Probably this shares the same bug as [1]
>
> Calling `NumberField().class_group().order()` in a loop of size N:
> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>
> The leak appears to be in the pari heap.
>
> Code .sage:
> 
> #Author Georgi Guninski Wed Sep 4 12:58:18 PM UTC 2024
> #10^3 leaks: 40.03 MB 40026112 pari= [7950, 1451665]
> #10^4 leaks: 338.49 MB 338493440 pari= [83505, 19297360]
>
> import psutil,gc,sys
>
> from sage.all import EllipticCurve
> ps = psutil.Process()
> num=10**3 #10**5 // 2
> x=var('x')
> def leaknf5(N=10**3):
> gc.collect()
> base = ps.memory_info().rss
> for A2 in range(1, N):
> Kn=NumberField(x^2+A2,'w')
> m=Kn.class_group().order()
> gc.collect()
> mem = ps.memory_info().rss - base
> print(f"{mem/1e6 :.2f} MB ",mem," pari=",pari.getheap())
>
> leaknf5(10**4)
> 
>
> [1]: https://groups.google.com/g/sage-devel/c/fWBls6YbXmw
> Memory leak in |EllipticCurve([n,0]).root_number()| and problem in
> algebraic geometry
>

-- 
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/d0195683-29e8-4b6a-b81d-3384407a944an%40googlegroups.com.

Re: [sage-devel] Re: QQbar(-1)^(1/3) != AA(-1)^(1/3)

[Nils Bruin]

On Tuesday 3 September 2024 at 23:53:33 UTC-7 john wrote:

Indeed, Magma's AlgebraicallyClosedField is not embedded into CC; it also 
has no version of AA.  And Nils meant what he said about large *finite* 
fields being used to keep track.  I find QQbar easier to use -- but 
when Magma's AlgebraicallyClosedField was first developed it was a really 
original idea and state of the art, there is at least one paper describing 
how it works (Nils, I cannot remember the author -- is it Allan Steele?).


Yes, Allan Steel. ANTS 2002:
https://link.springer.com/chapter/10.1007/3-540-45455-1_38
Super elegant idea. And no precision issues to take care of ... until your 
randomly chosen 30 digit prime ends up dividing a denominator or a 
discriminant of one of the algebraic numbers you happen to reference.

-- 
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/1c5985d6-4771-46cf-a89a-8d51b59bc9cdn%40googlegroups.com.

Re: [sage-devel] Re: QQbar(-1)^(1/3) != AA(-1)^(1/3)

[Nils Bruin]

On Tuesday 3 September 2024 at 20:52:04 UTC-7 Kwankyu Lee wrote:

If you mean "branch choice" in mathematical sense, the branch choice of 
Qbar (and CC and RR)

ln(z) = ln(r) + i * theta for z = r * exp(i * theta) with r > 0,  -pi < 
theta <= pi

(note <= at the end) is most natural for maximal continuity. I think this 
is more mathematical than choosing a "branch" that "does not require an 
extension of the parent".


I think the opinion about what is "mathematical" is where the difference 
lies here and it may well depend on whether you're more algebraically or 
analytically oriented. As an algebraist, one does not tend to think of Qbar 
or AA explicitly embedded in CC, so there is no natural extension of 
exponents beyond QQ. Hence, QQ does not come with a particular topology on 
it, so there is no continuity to consider. Exponentiation on Qbar embedded 
in the p-adic C_p would work out *very* differently.

For many (most?) applications of Qbar, its embedding into CC is only used 
to tell conjugates apart. Indeed, Magma's algebraic closure of QQ does not 
use an embedding into CC but instead tracks conjugate labels using a large 
finite field.

-- 
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/e0dbc77b-2978-492b-93c2-4b1866519795n%40googlegroups.com.

Re: [sage-devel] Re: QQbar(-1)^(1/3) != AA(-1)^(1/3)

[Nils Bruin]

On Tuesday 3 September 2024 at 19:44:43 UTC-7 Kwankyu Lee wrote:

I think that only valid argument for AA(-1)^(1/3) = -1 is that it is the 
status quo. It is just human that likes what she/he used to. Removing 
inconsistency is for the future.


The fact that powers with odd denominator do not leave AA is also a 
documented design decision:

https://doc.sagemath.org/html/en/reference/number_fields/sage/rings/qqbar.html#sage.rings.qqbar.AlgebraicNumber_base

(thanks to hgranath 
https://github.com/sagemath/sage/pull/38362#issuecomment-2325700870 for 
finding that one)

There is good precedent that the parent of a power depends on the value of 
the exponent. For instance, parent(3^2) is ZZ and parent(3^-1) is QQ. So 
I'd add as a valid argument for the branch choice in AA that it makes sense 
to choose a branch that does *not* require an extension of the parent, if 
possible. Yes, it's a different branch choice than the one made in Qbar, 
but AA and Qbar are different objects, with AA coercible into Qbar.

Once again, the design decisions for powering for floats in Python are made 
in the absence of representable non-integer rationals.

OTOH, it seems the coercion system may force our hand here (at least I 
think what happens below is a consequence of an overeager coercion system):

sage: parent(AA(-2)^(1/3))
Algebraic Real Field
sage: a=AA(2)^(1/2)
sage: a^a
TypeError: unsupported operand parent(s) for ^: 'Algebraic Real Field' and 
'Algebraic Real Field'

sage: parent(AA(-2)^(0.333))
Complex Field with 53 bits of precision
sage: parent(AA(-2)^RealField(1000)(1/3))
Complex Field with 1000 bits of precision

I don't think there are many people who would be unhappy if the last two 
would raise an error, but here we are: algebraic numbers CAN be raised to 
"non-rational" exponents (represented as floats) and the result is a 
floating point result, with the precision gleaned from the exponent. So 
there IS a continuity concept for the exponent when the base is an element 
of AA. Unfortunately, by that argument, we're forced to take the principal 
branch.

I'd much rather see that exponentiation on AA with a 
not-explicitly-rational exponent would yield an error on account of the 
result not being (reliably) algebraic. Then there's not an obvious topology 
on QQ that needs to be respected with continuity for exponentiation and 
then it would be reasonable to choose a branch that does not need a larger 
parent. But curtailing the mechanics of coercion around exponentiation 
would be an even bigger change.
 

-- 
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/12fba54d-aa64-4d64-b866-6d97e5dd133an%40googlegroups.com.

Re: [sage-devel] Re: QQbar(-1)^(1/3) != AA(-1)^(1/3)

[Nils Bruin]

On Tuesday 3 September 2024 at 09:08:06 UTC-7 Kwankyu Lee wrote:


That in Python one has non-real value for (-1)**(1/3) is 
two things: 1/3 is actually a float, and absence of typing. 
These are artifacts of the programming language, and make little sense 
mathematically.


Do you mean that the value of (-1)**(1/3) is arbitrarily chosen, regardless 
of the mathematical value of (-1)^(1/3)? 


The thing is: in Python you cannot *ask* for (-1)^(1/3) because you don't 
get to pass in 1/3. The function evaluated here really is

exp(log(x)*y), with x=-1 and y=6004799503160661/2^54 [where it's left to 
python to choose a branch for log(x) ]

Because of the duck typing conventions in python, they also cannot really 
make a distinction between -1 the integer, -1 the real number and -1 the 
complex number. So they have to settle for one unifying definition.

In sage we actually do have rational numbers that can be used for 
exponents. That's important because in Qbar and AA we can choose a result 
for raising things to a fractional power, but not for raising elements to a 
float/real power in general.  We already have precedent for the parent 
being relevant for the result. For instance GF(5)(3)^(-1) and QQ(3)^(-1) 
(but GF(5)(1/3) does agree, so at least we have that)

Incidentally, (GF(5)(-1))^(1/2) leads to an error.

-- 
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/4b7fed22-320b-4ee1-bd11-82b27b2af47dn%40googlegroups.com.

Re: [sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Nils Bruin]

On Thursday 29 August 2024 at 09:51:04 UTC-7 Georgi Guninski wrote:

I observe that the following does not leak: 

E=EllipticCurve([5*13,0]) #no leak 
rn=E.root_number() 


How do you know that doesn't leak? Do you mean that repeated execution of 
those commands in the same session does not swell memory use?
 

The size of the leak is suspiciously close to a power of two. 


I don't think you can draw conclusions from that. Processes generally 
request memory in large blocks from the operating system, to amortize the 
high overhead in the operation. It may even be the case that 128 Mb is the 
chunk size involved here! The memory allocated to a process by the 
operating system isn't a fully accurate measure of memory allocation use in 
the process either: a heap manager can decide it's cheaper to request some 
new pages from the operating system than to reorganize its heap and reuse 
the fragmented space on it. I think for this loop, memory allocation 
consistently swells with repeated execution, so there probably really is 
something leaking. But given that it's not in GC-tracked objects on the 
python heap, one would probably need valgrind information or a keen look at 
the code involved to locate where it's coming from.

-- 
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/e63e2ec9-106a-4ddd-ab16-5c6db4fe83b4n%40googlegroups.com.

[sage-devel] Re: Memory leak in |EllipticCurve([n,0]).root_number()| and problem in algebraic geometry

[Nils Bruin]

The leakage does not seem to be happening on the python heap. A next step 
could be to see if cypari's stack is swelling.
On Thursday 29 August 2024 at 02:34:06 UTC-7 Georgi Guninski wrote:

> In short:
> ```
> for A2 in range(1, 10**5):
> E=EllipticCurve([A2,0])
> rn=E.root_number()
> ```
> leaks nearly 128MB of memory on sage 10.4
>
> The same code in pari passes with very little memory.
>
> This is related to the following problem in algebraic geometry [1]
>
> Let $k,k_1,k_2$ be squarefree pairwise coprime integers.
>
> Assume $|k|>1$ and $|k_1|>1$ and $|k_2|>1$.
>
> Define the elliptic curves over the rationals:
>
> $$E_0:x^3+k x=y^2, E_1: x^3+k k_1^2 x,E_2: x^3+k k_2^2 x =y^2,
> E_3: x^3+k k_1^2 k_2^2 x=y^2$$
> <
>
> Then at least one of the root numbers of E_i is -1.
>
> [1] https://mathoverflow.net/q/476863/12481
> On the root numbers of quadruples of quadratic twists of elliptic curves
>

-- 
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/6ddbef14-ded4-4a42-805b-28f63b9114d0n%40googlegroups.com.

Re: [sage-devel] Re: QQbar(-1)^(1/3) != AA(-1)^(1/3)

[Nils Bruin]

On Tuesday 27 August 2024 at 05:42:55 UTC-7 vdelecroix wrote:

This is indeed annoying. For further input, notice that python gives 
the complex principal root rather than the real root 

>>> (-1.) ** 0.33 
(0.5090414157503712+0.8607420270039436j)

 
I'm not sure that's a completely fair comparison. Here you're really 
looking at raising a float to a float power, whereas in the the question 
was about raising a (negative real) algebraic number to a fractional power 
with odd denominator.

However, the fact that Qbar( (AA(-1))^(1/3)) != (Qbar( (AA(-1)))^(1/3) is 
problematic, I think. Add to that that currently even

RR(AA(-1)^(1/3)) != (RR(AA(-1))^(1/3)

(which is undoubtedly a corollary of the design decision in python) and I 
think there's a good reason to change. It's just hard to find analogous 
situations in python/sage where another branch choice is made.

There's a question of parent, though:
RR(3)^(1/3).parent() != RR(-3)!(1/3).parent(), so on real fields, raising 
to a power is treated differently between positive and negative bases. It 
would stand to reason that we do keep doing that on real algebraics.

-- 
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/8ef5c846-38ef-48cc-a069-0029df7cb74dn%40googlegroups.com.

Re: [sage-devel] Re: Proposal: Policy for standard packages from binary wheels

[Nils Bruin]

Dear Matthias,

Dima has already pointed out a substantial similarity between the proposals.

Kind regards,

Nils 

On Friday 23 August 2024 at 08:44:03 UTC-7 Matthias Koeppe wrote:

> Well, Nils? Please be specific.
>
> On Wednesday, August 21, 2024 at 2:38:59 PM UTC-7 Matthias Koeppe wrote:
>
>> On Wednesday, August 21, 2024 at 1:48:39 PM UTC-7 Nils Bruin wrote:
>>
>> On the google groups comment linked to by the second reference you give, 
>> Dima does link to a very explicit proposal that does share substantial 
>> features with the proposed policy change discussed here.
>>
>>
>> Nils, what are these "substantial features"?
>>
>>

-- 
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/8e013a52-36b5-4101-93e1-23f07ccceed6n%40googlegroups.com.

[sage-devel] Re: Package upgrade PRs waiting for review

[Nils Bruin]

On Wednesday 21 August 2024 at 15:29:05 UTC-7 Matthias Koeppe wrote:

On Wednesday, August 21, 2024 at 2:12:30 PM UTC-7 tobia...@gmx.de wrote:

> the version constraints of the packages that happen to be build 
dependencies of the Sage library (enumerated in 
https://github.com/sagemath/sage/blob/develop/bootstrap#L36) are set in 
https://github.com/sagemath/sage/blob/develop/src/pyproject.toml#L3 

Right (adhering to the standard of modern python libs)

> The tighter version constraints are needed by the Sage distribution 

Then please specify these version constraints in sage distribution and not 
in sage-lib (eg by providing a version_constraint.txt file that is 
compatible with the version constraints of sage-lib and the tighter 
constraints set by other packages).


No, I will not start maintaining two sets of constraints.


I don't think *you* would need to maintain that set. It would just be 
something to maintained. If Tobias argues convincingly that there is 
benefit to maintaining a different set of constraints, he'll probably be 
able to find people (himself maybe?) who are willing to maintain such 
constraints. If at all possible, no maintenance task should fall to any 
single person.

-- 
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/caab6cfc-2f9c-47a0-bedb-1761425f8bc8n%40googlegroups.com.

Re: [sage-devel] Re: Proposal: Policy for standard packages from binary wheels

[Nils Bruin]

On Wednesday 21 August 2024 at 13:16:48 UTC-7 Matthias Koeppe wrote:

On Wednesday, August 21, 2024 at 7:33:26 AM UTC-7 Dima Pasechnik wrote:

I don't consider this approved, as my complaint about the previous 
discussions and related proposals and credits due is not addressed


I'll note that extraordinary claims such as those that Dima Pasechnik made 
above in https://groups.google.com/g/sage-devel/c/vFsNl87zLxo/m/YjRMdBUQAQAJ 
and  https://groups.google.com/g/sage-devel/c/vFsNl87zLxo/m/JxIf6CAQAQAJ, 
as well as https://github.com/sagemath/sage/issues/38475, need at least a 
hint of substantiation. Such substantiation has not been provided.


On the google groups comment linked to by the second reference you give, 
Dima does link to a very explicit proposal that does share substantial 
features with the proposed policy change discussed here. So substantiation 
is definitely provided. In Nathan's response you can actually read his take 
on the difference between the proposals (just the version pinning, as far 
as I can tell).

-- 
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/4fc9cd2c-2918-4681-83be-fb8ea5cc669fn%40googlegroups.com.

Re: [sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Nils Bruin]

On Wednesday 21 August 2024 at 12:36:02 UTC-7 GMS wrote:


I think the clash is much more basic than that.

It is developers versus users.  Users who hoped to do (some) mathematics 
with a computer.

So far, it seems to me most discussions are developer-centric, Marc being 
among the exceptions giving another POV.


well, the list is called "sage-devel". I definitely appreciate Marc's 
perspective and it is a useful one to add to the mix, because there are 
definitely different compromises in the linux and OSX ecosystems.

I'm pretty sure that previously people did have problems with running 
cython successfully on installed-from-binary sage on linux platforms. Note 
that having a functional cython is not just important for having "%%cython" 
work. It's also relevant for third party extensions such as 
https://github.com/nbruin/RiemannTheta. So I think that presently 
installing sage from binary *without* a C toolchain is producing a hobbled 
install. It may be a reasonable compromise for people who don't need it, 
but the design of sagemath (and one of its strengths!) does require the 
ability to seamlessly move from python to cython. And this is not just a 
user/developer divide.

-- 
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/256e38b9-d3ed-4649-b7c1-c1bc0cd2bd71n%40googlegroups.com.

[sage-devel] Re: build ok but fails to start

[Nils Bruin]

On Wednesday 21 August 2024 at 09:09:22 UTC-7 Frédéric Chapoton wrote:


TypeError: C function sage.misc.randstate.current_randstate has wrong 
signature (expected struct __pyx_obj_4sage_4misc_9randstate_randstate *(int 
__pyx_skip_dispatch), got struct __pyx_obj_9randstate_randstate *(int 
__pyx_skip_dispatch))


>From the error I'd say that the file got recompiled at "top level" rather 
than as part of "sage.misc" and the shared library in question got 
overwritten. 

-- 
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/daefab82-3bb0-4e6c-9a56-7e5ede1d7aa2n%40googlegroups.com.

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Nils Bruin]

On Wednesday 21 August 2024 at 08:03:03 UTC-7 marc@gmail.com wrote:

On Tuesday, August 20, 2024 at 8:22:35 PM UTC-5 Kwankyu Lee wrote:

 it is not a bad idea for a non-developer user to install sage from source.


I disagree.  It *is* a bad idea, for so many reasons:
* It requires a lot of time and work which is completely unrelated to using 
Sage.
* It will almost certainly fail.
* Even if it does succeed, it provides no benefit to a user who only wants 
to use Sage.  But it does have lots of negative side effects, including 
creating a 10GB subdirectory of the user's home which becomes totally  
useless if it is moved, and forcing the installation of many packages and, 
possibly, package managers, which are useless to someone who is not 
interested in writing code.


Using sage may include using cython. Sage and Jupyter have excellent 
support for writing little snippets of cython code and have them integrate 
with python instructions around them with virtually no overhead, via 
"%%cython". I have definitely talked to people who use sage who (wanted to) 
use cython for mathematical inner loops that have to be fast and have no 
inclination to contribute code changes to sagemath. Those are 
(sophisticated) users. 

At least building sagelib is a great way of certifying that cython works 
correctly. I agree that compiling the other parts of sage has very little 
practical benefit even for a developer. Because full functionality of sage 
implies a working compiler tool chain, compiling sage from source even for 
users is a much more reasonable proposition than for most other software.

-- 
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/5d921aad-8117-4656-a635-af599e4df9f5n%40googlegroups.com.

Re: [sage-devel] Proposal: Demote jupyter-jsmol and tachyon to optional

[Nils Bruin]

On Tuesday 20 August 2024 at 06:54:00 UTC-7 Michael Orlitzky wrote:

[...]
As a distro package, tachyon is mildly annoying, but all that it really 
needs is a sane build system. The existing one is a case study in what 
happens when you try to recreate autotools in undocumented Makefile 
fragments. Ultimately it's not a complicated program to build. 

The author doesn't have a bug tracking / PR system in place or an 
obvious way to accept contributions. Has anyone tried contacting him? 
If we spent a day collectively writing configure.ac and Makefile.am, it 
seems to me that we could solve all of the problems shared by Sage, 
Debian, Arch, Gentoo, etc. 


Regardless of Tachyon's status in sagemath, such an action would be of 
great benefit to the open source community at large. The author of Tachyon, 
John Stone, is now part of the group that develops VMD, so I imagine 
packaging tachyon in a standalone fashion is not necessarily a priority for 
him. Even with the build process updated, the package would require someone 
committing to maintain it (which hopefully would be a minor task). Ideally 
this would happen in collaboration with the original author, but the code 
is licensed BSD-3, so I don't think it's technically necessary.
 

-- 
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/5f876047-afa2-4724-81c9-0e66b3008e2dn%40googlegroups.com.

[sage-devel] Re: Proposal: Policy for standard packages from binary wheels

[Nils Bruin]

On Tuesday 20 August 2024 at 10:03:59 UTC-7 Matthias Koeppe wrote:

On Tuesday, August 20, 2024 at 9:02:14 AM UTC-7 julian...@fsfe.org wrote:

I consider this approved. 


While I don't think I would be opposed to the proposal here, I believe that 
our policy says that for a disputed PR to be "approved," a vote needs to 
happen here or on the PR.


Julian, you snipped away what "this" is what I consider approved -- namely 
the proposed policy (not the PR).


Thank you for the clarification. I certainly read the message as the 
presumed approval pertaining to both the policy and the PR, because they 
were tied together and discussed together from the start.

In any case, I would think that in this case it is really the policy change 
that needs the vote anyway; not the implementing PR (there review should 
take care of technical issues).

We have seen several examples where we really want functionality from 
software that is developed in languages that we don't want to support the 
build environment for (I think we now have examples of javascript and rust 
for this), so I think we're going to need a policy along the lines of what 
you and/or Dima have proposed. What is currently not clear to me is *where* 
those binary wheels are going to come from and how we're going to 
test/ensure that they are available for the platforms that we commit to 
supporting. It would also be good to think about what we're going to do if 
at some point we find that for one of our supported platforms such wheels 
are not available. Are we going to just drop that platform? We might have 
to. Or perhaps it's more advantageous to then "gracefully" reduce 
functionality and still provide sagemath for that platform; just not with 
the functionality that relies on the unavailable binary. But then it 
becomes more like an optional prerequisite for enhancing functionality.

I think the discussion is the important part here: by the looks of it 
reality is forcing the something like the policy on us, and we can't really 
vote that away. 

-- 
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/28cc7921-1038-4a9d-9976-5baecb0bb13an%40googlegroups.com.

[sage-devel] Re: Proposal: Demote jupyter-jsmol and tachyon to optional

[Nils Bruin]

It's unfortunate that tachyon isn't maintained properly. It's a nice piece 
of software. It looks like it has been adopted by VMD (software developed 
by the biophysics group at Illinois -- it looks like the software is 
opensource and available without cost, but is under a restrictive licence, 
so can never be widely supported/distributed by distributions), so based on 
that it doesn't look good for tachyon becoming properly supported.

I can see how "Playwright" is an  attractive option since it co-opts the 
renderer that is already available in modern browsers. It is definitely a 
nice option to have because it should produce pictures that exactly match 
what people are producing in the browser. While currently it is probably 
well-supported, I could see how longer term this is going to be a rather 
fragile solution, because we'd be dependent on an interface to communicate 
with a browser. I assume the proposal wouldn't mean that we'd ship a 
browser with sagemath?

I almost never use 3D plotting machinery myself (the last time I tried to 
use threejs it was for a demo and it was flaky in the browser -- it ended 
up not working when I needed it, but it did work afterwards), but it would 
seem to me one would mainly want an export method to write a scene so that 
well-established rendering software like blender (which I think can run 
from the commandline) can process it. It would then not be sagemath's role 
to provide the rendering software, much in the same way that we don't 
package a pdf viewer either -- we could provide functionality to produce 
images assuming "blender" is available on the path, though. That would 
replace one role that tachyon could be used for (although I'm not sure how 
many people have used sagemath+tachyon to produce publication-quality 
pictures.

On Monday 19 August 2024 at 17:13:29 UTC-7 Matthias Koeppe wrote:

> jupyter-jsmol 
> 
>  
> is the current standard package providing javascript version of Jmol (which 
> I proposed to demote to optional in 
> https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg, 
> https://github.com/sagemath/sage/pull/38504). I propose to demote it to 
> "optional". (In 
> https://groups.google.com/g/sage-devel/c/qKqTmLzHAbg/m/OwGjF4GiBQAJ 
> (2020), Antonio Rojas already asked if there is any reason for not making 
> jsmol optional too because three.js 
>  
> is our default 3d renderer.)
>
> tachyon 
>  
> is a standard package providing a raytracer, dating back to 1994. It has a 
> precarious maintenance status. Fedora has orphaned this package, and it is 
> not available in the current release 40 (
> https://src.fedoraproject.org/rpms/tachyon), Debian has an extensive set 
> of patches that have not been upstreamed (
> https://sources.debian.org/patches/tachyon/0.99~b6+dsx-12/). The Arch 
> Linux package (https://archlinux.org/packages/extra/x86_64/tachyon/) is 
> maintained by Antonio Rojas; sage is listed as the only package depending 
> on it. I propose to demote this package to optional as well.
>
> Jmol (not jupyter-jsmol) and Tachyon serve the purpose of saving 3d 
> graphics as png files, in particular for our PDF documentation. 
> I propose to replace this function (exclusively provided by these two 
> packages in Sage) by using the tool Playwright, which installs a browser 
> such as Chromium and screenshots an arbitrary webpage as a PNG file. By 
> using it on a three.js rendering of 3d graphics, we can thus save the 3d 
> graphics as a PNG file. This is PR 
> https://github.com/sagemath/sage/pull/38509 (needs review). This is much 
> heavier-weight technology than tachyon, but it has excellent mainstream 
> maintenance status.
>
>

-- 
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/25152eb8-763d-4905-85ad-b25232bd23fcn%40googlegroups.com.

Re: [sage-devel] Re: Bug or feature in Jacobian of hyperelliptic curve?

[Nils Bruin]

Did you mean you want your name mentioned in the reference to the 
sage-devel discussion in the issue description? Done.

Concerning "licenses" for test cases: anything that's not GPL2+ does not 
get included in sagemath. If the bug is important enough to be fixed, it 
will be discovered independently and get its own non-derivative tests. So I 
don't think many people bother to specify licenses for bug reports.

On Wednesday 31 July 2024 at 09:52:27 UTC-7 Georgi Guninski wrote:

On Wed, Jul 31, 2024 at 7:32 PM Nils Bruin  wrote: 
> 
> This is now: 
> 
> https://github.com/sagemath/sage/pull/38459 
> 

You are missing the `Author` from the original report. 

Which license pisses off most SageMath, Inc to 
include in future testcases (if any)? 

-- 
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/b05c9ab6-6000-4e0b-ad1f-3eb97efb329an%40googlegroups.com.

[sage-devel] Re: Bug or feature in Jacobian of hyperelliptic curve?

[Nils Bruin]

This is now:

https://github.com/sagemath/sage/pull/38459

On Wednesday 31 July 2024 at 08:46:14 UTC-7 Nils Bruin wrote:

> On Wednesday 31 July 2024 at 07:33:47 UTC-7 Georgi Guninski wrote:
>
> I need non-torsion element of Jacobian of hyperelliptic curve, 
> would someone give example? 
>
> IIRC something very close to the following worked about 
> 5 years ago, but now I get trivial result. 
>
> Session: 
> #Author: Georgi Guninski 
> K.=QQ[] 
> C=HyperellipticCurve(x^5+x+5^2-2); 
> J=C.jacobian(); 
> P=J(1,5); 
> 2*P 
> #(1) ##is this correct? 
>
>
> Yes, it is correct. To get a non-torsion element:
>
> D=J(x-1,5) 
>
> For your other report:
>
> K.=QQ[] 
> C=HyperellipticCurve(u^5+u+5^2-2); 
> J=C.jacobian(); 
> print("J=",J); 
> P=J(1,5); #error here
>
> If you change the last line to P=J(1*u^0,5*u^0) then it does work. It 
> looks like there is some preprocessing on the arguments that changes 
> constants into polynomials and it looks like this has been hardcoded to 
> J.base_ring()['x']. It should use 
>
> J.curve().hyperelliptic_polynomials()[0].parent()
>
> instead.
>
>

-- 
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/057e7637-9f4a-44f5-9f61-32cb769ffbd8n%40googlegroups.com.

[sage-devel] Re: Bug or feature in Jacobian of hyperelliptic curve?

[Nils Bruin]

On Wednesday 31 July 2024 at 07:33:47 UTC-7 Georgi Guninski wrote:

I need non-torsion element of Jacobian of hyperelliptic curve, 
would someone give example? 

IIRC something very close to the following worked about 
5 years ago, but now I get trivial result. 

Session: 
#Author: Georgi Guninski 
K.=QQ[] 
C=HyperellipticCurve(x^5+x+5^2-2); 
J=C.jacobian(); 
P=J(1,5); 
2*P 
#(1) ##is this correct? 


Yes, it is correct. To get a non-torsion element:

D=J(x-1,5) 

For your other report:

K.=QQ[] 
C=HyperellipticCurve(u^5+u+5^2-2); 
J=C.jacobian(); 
print("J=",J); 
P=J(1,5); #error here

If you change the last line to P=J(1*u^0,5*u^0) then it does work. It looks 
like there is some preprocessing on the arguments that changes constants 
into polynomials and it looks like this has been hardcoded to 
J.base_ring()['x']. It should use 

J.curve().hyperelliptic_polynomials()[0].parent()

instead.

-- 
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/2d1ea007-7a24-40ac-b6bc-9320eb7341c6n%40googlegroups.com.

[sage-devel] Re: Positive genus for a scheme that doesn't define curve

[Nils Bruin]

The irreducible_components gives an answer that is consistent with magma: C 
is a complete intersection of two hypersurfaces in A4 and hence of 
dimension 2 itself. Looks like "Curve" over QQ doesn't check dimension or 
delegates to a routine that doesn't check properly.

On Tuesday 23 July 2024 at 05:26:20 UTC-7 Georgi Guninski wrote:

> #Author Georgi Guninski
>
> K.=QQ[]
> t1=x^2*z^2 + y*t;
> t2= y*z^2 + x^2*t;
> C=Curve([x^4-y^2-19,z^4-t^2-23,t1^2-t2^2-19*23]);
> C.genus()
> #93 #Wrong
>
> C.irreducible_components()
> [
> Closed subscheme of Affine Space of dimension 4 over Rational Field 
> defined by:
> z^4 - t^2 - 23,
> x^4 - y^2 - 19
> ]
>
> Magma raises error when trying to construct Curve()
>
> When I work over GF(113) instead of QQ, I get error:
>
> RuntimeError: error in Singular function call 'genus':
> This is not a curve
> leaving normal.lib::genus (0)
>

-- 
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/fc53331a-4ea9-47fe-bc9b-393983270ba8n%40googlegroups.com.

[sage-devel] Re: Pollard Lambda fails to find valid discrete logarithm

[Nils Bruin]

That's an ... interesting ... way to do a division, but sure: also in prime 
cyclic groups represented as an additive group discrete log algorithms 
should work.

When I try your example on a version that is reported as 10.3.beta3, I'm 
not getting an error, so you'll probably have to include version 
information and quite likely the random seed to make this error reliably 
reproducible.

Looking at the implementation, there is a low probability that the routine 
produces this error even if there is a discrete log to be found: it tries 
10 random walks and then just errors out. That's by design, so one solution 
would be to just document the implementation as a random algorithm with a 
non-zero probability of failure.
On Tuesday 2 July 2024 at 10:15:53 UTC-7 Georgi Guninski wrote:

> I think this is a bug:
>
> ```
> #Author Georgi Guninski
>
> p=90887;Kp=GF(p);g=Kp(2);X=46712;a=X*g
> print(a==X*g)
> Y=discrete_log_lambda(a,g,operation="+",bounds=(1,p))
>
> -> 1076 raise ValueError("Pollard Lambda failed to find a log")
> ValueError: Pollard Lambda failed to find a log
> ```
>

-- 
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/317c5b47-f2c3-453c-ae05-b5d17bc4fc92n%40googlegroups.com.

[sage-devel] Re: SEGV Crash in `numerator(f(t)/g(t)-const)`

[Nils Bruin]

On Saturday 11 May 2024 at 09:58:38 UTC-7 Georgi Guninski wrote:

The following hurt my computations. 

``` 
#Author Georgi Guninski, Sat May 11 04:53:23 PM UTC 2024 
p=101; 
Kt.=Integers(p)[] 
c5,s5=((100*t^10 + 45*t^8 + 93*t^6 + 8*t^4 + 56*t^2 + 1)/(t^10 + 5*t^8 
+ 10*t^6 + 10*t^4 + 5*t^2 + 1), (10*t^9 + 82*t^7 + 50*t^5 + 82*t^3 + 
10*t)/(t^10 + 5*t^8 + 10*t^6 + 10*t^4 + 5*t^2 + 1)) 
f1=numerator(c5+99/101);f2=numerator(s5-20/101) 
print("Done",f1,f2) 
``` 
Unhandled SIGSEGV: A segmentation fault occurred

 
The system should of course not segfault on this, but I doubt that this 
fault kept you from getting a valid result. The fractions 99/101 and 20/101 
cannot be coerced into Kt. So the problem is probably that for convenience 
the system pretends there is a coercion map Q -> GF(101), but it's actually 
only a partial map. It may be as simple as an uncaught exception (because 
the code didn't expect an exception to occur here.

To work around this bug, coerce your constants into Kt before doing the 
arithmetic:

 f1=numerator(c5+Kt(99/101));f2=numerator(s5-Kt(20/101)) 

That will give you an appropriate error instead of a segfault.


-- 
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/df71fb00-791a-4aa4-9390-ba8f8e05a737n%40googlegroups.com.

Re: [sage-devel] Unreasonably slow piecewise function

[Nils Bruin]

On Wednesday 1 May 2024 at 16:45:36 UTC-7 Kwankyu Lee wrote:


I wonder if they, maintainers of maxima, would regard this as a bug... 


I'm pretty sure the piecewise functions are NOT borrowed from maxima. It 
probably gets called because there are some inequalities concerning the 
symbolic ring. So the performance observed here is not reduced to something 
that could be reported as a bug to maxima. I'd expect that performance can 
be significantly improved by optimizing the sage code.

-- 
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/2331637e-f9f3-4ee7-8697-2e55b1358ea3n%40googlegroups.com.

Re: [sage-devel] Unreasonably slow piecewise function

[Nils Bruin]

Working on *why* it might be so slow a bit:

%prun for i in range(100r): f(0.1)
 798103 function calls (791903 primitive calls) in 1.327 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 80000.5560.0000.6280.000 maxima_lib.py:438(_eval_line)
  1000.2990.0031.3180.013 piecewise.py:188(_subs_)
160000.0590.0000.0670.000 {method 'random_element' of 
'sage.rings.real_mpfi.RealIntervalField_class' objects}
 17000.0540.0000.0600.000 
maxima_lib.py:298(max_to_string)
   2322000.0320.0000.0480.000 calculus.py:2204(_is_function)
  9000.0280.0000.0500.000 calculus.py:2319()
 27000.0240.0000.0240.000 {built-in method 
sage.libs.ecl.ecl_eval}
  9000.0210.0000.0470.000 calculus.py:2317()
   2737000.0180.0000.0180.000 {built-in method 
builtins.isinstance}
  9000.0150.0000.0330.000 {method 'parse_sequence' of 
'sage.misc.parser.Parser' objects}

so, most stuff is happening in maxima and in _subs_, and somehow random 
elements of an intervalfield are needed ...
I don't think the design was primarily focused on numerical evaluation 
speed but rather on having symbolic piecewise functions.
On Wednesday 1 May 2024 at 06:38:36 UTC-7 David Joyner wrote:

> For another data point, on an ubuntu laptop:
>
> sage: time [f(0.1*i) for i in range(1,10)]
> CPU times: user 136 ms, sys: 0 ns, total: 136 ms
> Wall time: 99.1 ms
> [1, 1, 1, 1, 1, 1, 1, 1, 1]
> sage: time f(0.1)
> CPU times: user 13.6 ms, sys: 0 ns, total: 13.6 ms
> Wall time: 13.5 ms
> 1
> sage: version()
> 'SageMath version 10.3.rc1, Release Date: 2024-02-29'
>
> On Wed, May 1, 2024 at 5:21 AM Kwankyu Lee  wrote:
> >
> > Hi,
> >
> > I get
> >
> > sage: f = piecewise([((0,1),1)])
> > sage: time f(0.1)
> > CPU times: user 135 ms, sys: 4.23 ms, total: 140 ms
> > Wall time: 146 ms
> > 1
> > sage: time f(0.2)
> > CPU times: user 133 ms, sys: 3.56 ms, total: 136 ms
> > Wall time: 137 ms
> > 1
> >
> > This is painfully slow. Is this normal?
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/af2161ba-1ee9-4636-9cea-98ea6031796bn%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/e01afcef-943f-4f58-8978-882f807f763en%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Nils Bruin]

On Friday 26 April 2024 at 15:44:22 UTC-7 marc@gmail.com wrote:

I don't see what difference the choice of port makes to a user.  It is not 
possible to guarantee that the same port will always be used, since ports 
are assigned on a first-come first-served basis.  Consequently it is not 
possible to "bookmark" the address of either a jupyter server or a 
cocoserver.  The port should be viewed as arbitrary and unpredictable.  The 
address is always 127.0.0.1 in either case, by necessity.


The port number that jupyter tries to use is configurable and there can be 
reasons why you'd want to care about it. For instance, if you have a beefy 
linux server that students in various locations want to use from windows 
workstations. Ideally you'd run jupyterhub on it, but it's a complete 
headache to figure out authentication and file system access and probably 
impossible to find sysadmins capable and willing to make that setup secure.

Instead, one could just assign a port number to each individual so that 
they can set up a script to start their jupyter server on the right port on 
localhost. They then just need to learn to use ssh (via PuTTY, for 
instance) to tunnel the particular port from their desktop to the server 
and then they can point the browser *on their own machine* to the right 
address. It gets around the problem of getting people to install jupyter on 
a windows box and it shows them an environment in which they could graduate 
to useful work on the server themselves. And mainly, it gets around the 
very real problem of getting a JupyterHub server set up. The price you pay, 
of course, is that the port number is now very well-defined and actually 
quite important. In that setup, it would be nice if the documentation were 
served through the web server that jupyter is already running, because 
that's the only port that's tunnelled. Or if the documentation just lives 
on the internet; that's fine too (because if one weren't in an 
internet-facing environment, setting up JupyterHub would at least be less 
problematic from a security point of view).

So, yes, if you're really just running it locally, the port number isn't so 
important, but if any port forwarding comes into play, it becomes very 
important to know the port number! 

-- 
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/d96f03ed-51a8-464b-9412-7af5825507acn%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Nils Bruin]

On Friday 26 April 2024 at 12:29:14 UTC-7 marc@gmail.com wrote:

There are other issues with viewing local documentation files in a 
browser.  On Ubuntu, Chrome and Firefox are packaged as snaps.  A snap is 
not allowed to read a file:// url which is not in the user's home 
directory.  As long as sage is installed in the user's home directory this 
is not an issue.  But if the documentation is elsewhere then Firefox and 
Chrome will refuse to show it.  Using the cocoserver works around this 
because it is allowed to use a url with the loopback interface as the host 
address.  (I think it is safer to use 127.0.0.1 instead of localhost 
because, in principle, a rogue DNS server would be able to provide any IP 
address as an A record for localhost). 


The most flexible would be to serve it from would be whatever address the 
jupyter server is serving on. That's why it might be easier to get this to 
behave properly as a jupyter extension, because it could even serve it on 
the same port in that case. I guess the OSX app has hardcoded that it 
serves on 127.0.0.1 then? How do you work around port availability there? 
Does coco listen on a separate port from the jupyter server?

-- 
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/cdd187bb-4387-4b4d-8bab-44c3c3770775n%40googlegroups.com.

[sage-devel] Re: help menu in jupyter notebook

[Nils Bruin]

On Friday 26 April 2024 at 06:53:28 UTC-7 marc@gmail.com wrote:

I have a suggestion to improve the situation, which is to do what the 
Sage_macOS app does.

The app provides access to a local copy of the documentation stored inside 
the application bundle.  The files are reorganized slightly to remove 
duplication and then compressed with gzip.  The app views the files using 
cocoserver , which provides a 
slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior 
of that server is modified so that it adds a gzip header to any file named 
*.gz.  The browser automatically decompresses gzipped files served with 
such a header.  ("Coco" stands for "compressed content".)


Yes, I was thinking in that direction too. Is there perhaps already a 
jupyter server extension that can serve files in a local directory? I bet 
we can instruct jupyterlab to point at a "localhost" url rather than at 
"doc.sagemath.org"
 

Compressing the documentation reduces the size (of the English 
documentation) from about 600 GB to about 100 GB.


You meant MB probably?
 

-- 
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/4e33bc5d-ba8e-419d-92a3-87977765ad86n%40googlegroups.com.

[sage-devel] Re: VOTE: Revert merged PR with unreviewed dependencies

[Nils Bruin]

+1 to merge #37796.

-- 
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/3390b9f2-ec6d-48eb-870f-4d357103bd32n%40googlegroups.com.

[sage-devel] Re: SingularError in rational_parameterization

[Nils Bruin]

Thanks. It looks like the error occurs in integralbasis.lib. It's last 
version data is fairly recent, so the file may be under active maintenance.

sagemath has grown enough divisor machinery that it can probably compute a 
conic model of a genus 0 curve, which would be more standard to try and 
parametrize. Alternatively, with point searching methods (which may not be 
implemented comprehensively in sage) one could perhaps find a degree 1 
place on the genus 0 curve directly and use Riemann-Roch machinery to 
compute the parametrization without going through a conic model.

So, if this functionality in integralbasis.lib in singular is not 
comprensive enough, it may be a doable project to do it in sage directly 
now.

Note that algcurves is sometimes a little too eager in finding a 
parametrization: it might just adjoin a point over an extension to get a 
parametrization (also when that's not required). If you need the 
parametrization for arithmetic applications, that's a problem. But indeed, 
Mark van Hoeij did an amazing job on that maple package!

On Wednesday 17 April 2024 at 08:12:35 UTC-7 ypf...@googlemail.com wrote:

The following code raises a SingularError in SageMath version 10.4.beta3 
(with system singular enabled), and the same at 
https://sagecell.sagemath.org/ :

R. = QQ[]
f = -2*x^2*y^2 - x^3 - x^2*y + x*y^2 + y^3 + 2*x^2 + 2*y^2 - 2
C = Curve(f)
assert C.genus() == 0
print(C.rational_parameterization())

The polynomial f is absolutely irreducible, and the given curve is 
rationally parametrized e.g. by (x, y) = 
(1/2*(t^3+t^2+t-1)/t^2, 1/2/t*(t^3+t^2-t+1)).

-- Peter Mueller

PS: To me as a naive end user, it looks like Singular has had recurring 
problems with basic things for many years that have worked smoothly in 
systems like Maple (and its algcurves package) for more than 30 years.

-- 
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/4c71470a-aba1-4808-b5d1-a00118edc661n%40googlegroups.com.

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[Nils Bruin]

Also not that there is plenty of code that, in the course of computation, 
writes into attributes of objects. If you're doing multiple of those it's 
very hard in python to make such a modification atomic. So if an interrupt 
ends up splitting an update, you may leave the system in an inconsistent 
state that could affect future computations. It's a nice aspirational goal 
to have Ctrl-C work decently, but if you want your results with a 
reasonably degree of confidence in correctness, you should probably avoid 
interruptions anyway.

Most code is hopefully written defensively: work on a local copy and only 
in the last bit modify the attribute by a single assignment. That minimizes 
the chance for getting inconsistent states from interrupts, but I don't 
think you'll get it to zero, because of the non-atomicity of multiple 
attribute assignments.

On Wednesday 10 April 2024 at 11:03:13 UTC-7 Vincent Delecroix wrote:

> I do not remember anything specific about solve_mod. Though, there are
> many places in Cython source code where sig_on/sig_off is not handled
> carefully enough (and many that were fixed).
>
> The fact that it is not reproducible is not necessarily a huge problem. 
> However,
> - Could you share the code (as minimal as possible) that provokes this
> on your machine?
> - Do you have the complete (C) trace of the crash? You might need to
> install gdb depending on your setup.
>
> Vincent
>
> On Wed, 10 Apr 2024 at 16:18, Georgi Guninski  wrote:
> >
> > I don't have reproducible testcase, but my pain is that sometimes if I
> > press CTL-C e.g. when solve_mod() is called in a loop, I get SEGV and
> > abort.
> > I suspect besides signals, it is hitting race condition.
> > Is this a known issue?
> >
> > Very long ago there was vulnerability in sendmail, where it did
> > printf() or similar in signal handler and this was documented in the
> > literature.
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAGUWgD_7t9OTNdo6Ovrt%3DJdNqmGJLPGsZHVoJK0mNPQhuz1CKQ%40mail.gmail.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/b7d35f4e-7301-4ac4-8cf1-561ba86493e0n%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Nils Bruin]

Dima,

I am writing as a member of the Code of Conduct concerning one particular 
phrase from your message 
https://groups.google.com/g/sage-devel/c/Wjw2wcvgf8k/m/ynwiz66_AQAJ :

> This will force Matthias to reconsider his priorities, and enable other 
voices to be heard. So far, Matthias refuses to reassess the priorities of 
the project - instead he puts away the criticism as "abuse" directed at him.

Such allegations will have no effect other than to antagonize the other 
party. This is not helpful in fostering constructive debate. Please keep 
this thread to a simple explanation of the issues at hand, so that 
interested community members can make an informed decision on their vote 
(or on whether to vote at all).

Sincerely,
Nils, on behalf of the code of conduct committee.

-- 
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/8b339612-1118-457d-afcb-13bf17e72fd3n%40googlegroups.com.

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

[Nils Bruin]

Thank you, Matthias, for drawing attention to votes on tickets that have 
gained "disputed" state and were not getting much attention. If we're going 
to decide these tickets by voting, then having a more representative voting 
population should help in getting a more representative result.

Thank you, Dima and Gareth for providing opposing opinions to Matthias' 
interpretation of the matter. These are "disputed" tickets after all, so in 
the discussions of these tickets no arguments arose that convinced all 
sides on the best road forward. It makes sense that potential voters 
receive "campaign materials" from all sides.

I am happy to see Matthias and Dima agreeing that this voting procedure has 
draw-backs. It's only meant as a band-aid solution to get items unstuck in 
the absence of consensus. Shall we just give it a try? It may not lead to 
technically optimal solutions in all cases, but at least it's a procedure 
that is easily seen as "fair". None of the decisions made are definitive -- 
perhaps finding consensus on a different solution is easier once another 
has been tried and new patches can be made.

I think Dima has a good point that a clearer roadmap for sagemath would 
probably help in making it easier to reach consensus instead. A technical 
committee with some authority could help, but only if *they* can reach 
consensus. From my perspective as a member of the CoC committee, I would 
urge the community to have a bit of patience. We are making our way through 
a backlog of issues that quite probably have a root cause in lack of 
agreed-upon direction in the sagemath project and we do hope to come with 
some recommendations for improving the situation in the near future.

I am writing this as a community member, but informed by my service on the 
CoCC and a desire to not see the workload of the CoCC increase.

Nils

-- 
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/31facf11-39cd-4246-97fa-cc75584602ban%40googlegroups.com.

Re: [sage-devel] Mysterious .sage behavior

[Nils Bruin]

One scenario where I could see this being beneficial:
These configurations are written into `$HOME/.sage` (normally), so that is 
not a location that is predicated by a venv or a localized subdir. If a 
user is using two different sagemath installs (e.g., one system, the other 
for development) that have incompatible ipython configs, they need to live 
in places that allow peaceful co-existence. This would do it. I agree the 
version number can look confusing, It seems like a historic artifact that 
we didn't need to change our ipython configs since version 5.0.0, probably. 
It looks to me like a fairly arbitrary choice how to mark that directory 
name. Not changing it would be the easiest solution, but if someone wants 
to make an argument that another naming convention has benefits (following 
common practices that have since evolved?) it could be changed, at the 
expense of everyone with an install needing to change locations of files 
they already customized. So based on that, I think the best time to change 
it (if at all) would be when an incompatible change in config is happening 
anyway.


On Monday 1 April 2024 at 12:20:16 UTC-7 Dima Pasechnik wrote:


I must say I don't know what kind of problems these versioned names are 
meant to solve. 

 

>On 31 March 2024 15:23:24 CEST, Marc Culler https://groups.google.com/>> wrote :  

>if [ -z "$IPYTHONDIR" ]; then 
> # We hardcode a version number in the directory name. The idea is 
> # that we keep using the same version number as long as that is 
> # possible. Only when some future IPython version really requires 
> # a new structure for the $IPYTHONDIR should this version number be 
> # changed to the new IPython version. 
> export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0" 
>fi 

-- 
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/5ff12336-204d-4119-b776-3d2f2251b80dn%40googlegroups.com.

[sage-devel] Re: Bug in quadratic_defect

[Nils Bruin]

On Sunday 24 March 2024 at 04:41:25 UTC-7 Przemysław Koprowski wrote:

Let me just comment on your words "searching the source, this routine isn't 
actually used elsewhere in sage" (here: 
https://github.com/sagemath/sage/pull/37657). It is not entirely true, 
because, as far as I know, the method is_padic_square (in the class of a 
number field element) internally relies on the quadratic_defect.

Thanks! I based my assessment on the search result that github returned for 
`quadratic_defect`. It only returned two hits for me.
Lesson: Don't rely on github search. It's far from exhaustive. 

-- 
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/62cecc92-463f-4211-b26f-b80d89ad6fc3n%40googlegroups.com.

[sage-devel] Re: Bug in quadratic_defect

[Nils Bruin]

Thanks! this is now 

https://github.com/sagemath/sage/issues/37656

or

https://github.com/sagemath/sage/pull/37657

(I'm still a bit murky on what issues are used for)

-- 
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/ef63a7c8-845f-4cee-90c9-beca953568ban%40googlegroups.com.

Re: [sage-devel] pari-jupyter 1.4.3 release candidate

[Nils Bruin]

On Friday 22 March 2024 at 11:22:12 UTC-7 Matthias Koeppe wrote:

10 days ago, the previous maintainer, Vincent Delecroix, announced that he 
steps down from maintaining it. 
https://groups.google.com/g/sage-devel/c/fy1ei6bLtmc
I did some emergency maintenance and on that occasion I added the 
"Maintainers" field in the metadata. Nobody specifically committed to 
maintaining it or made a plan, as far as I know.


Thanks for that. Obviously, when a maintainer steps down, some follow-up 
should happen and by the location of the repository, the sagemath community 
inherits the project in this case by default.

It looks to me like a project that can easily not be offered as an spkg, 
with minimal effect, but I might be overlooking something. So removing the 
spkg could make sense.

Judging from the thread here:

https://pari.math.u-bordeaux.fr/archives/pari-dev-2305/msg2.html

this kernel is very much the basis for whatever Bill is considering. 
Further down the thread, there is also a reference to Edgar Costa's kernel:

 https://github.com/edgarcosta/gp_kernel

it looks like the discussion there may lead to a new home for the project 
eventually (or another project to take its place).

-- 
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/a0c2c036-f880-4606-9d39-2386e184ae23n%40googlegroups.com.

[sage-devel] Re: Vote: changes to Sage's Code of Conduct

[Nils Bruin]

+1.

Thank you for taking the time and effort to compile a coherent document.

On Thursday 21 March 2024 at 09:51:40 UTC-7 John H Palmieri wrote:

> Dear Sage community,
>
> As announced at 
> https://groups.google.com/g/sage-devel/c/Xf6dbPLmKPY/m/p88auKlBAwAJ, I 
> propose some changes to the Code of Conduct. Those changes have been 
> discussed and modified based on feedback from several developers: visit 
> https://github.com/sagemath/sage/pull/37501 for details. Those changes 
> are now ready for a vote here on sage-devel. 
>
> Please vote: do you approve the changes to the Code of Conduct proposed at 
> https://github.com/sagemath/sage/pull/37501? Please vote on or before 
> March 31.
>
> In case you want a summary: the old code of conduct was pretty short, so 
> some details were added, and whole new sections were added. The proposed 
> changes were greatly inspired by similar documents from the SciPy and 
> NumFOCUS projects, and the proposed code now includes sections on 
> diversity, how to report potential violations,  names of the committee 
> members, and what is necessary to amend the document. There is also a new 
> document, a manual for the Code of Conduct Committee, which describes what 
> that committee does and what actions it might take to respond to reports. 
> That document is a modified version of SciPy's corresponding document.
>
> -- 
> John
>
>

-- 
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/4851e156-9ce9-48bc-b2ff-ba111459590an%40googlegroups.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Nils Bruin]

One thing that may deserve a cursory check is the overhead involved in 
inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
structures are optimized for prolonged use *after* creation and may do a 
lot of caching/precomputation. There may be scenarios where one wants to 
construct *lots* of hyperelliptic curves (for instance, when computing 
reductions of hyperelliptic curves mod lots of primes). An expensive parent 
may then add undue overhead. In that case it may be better to spin off the 
functionality required into a "lightweight" structure that gets wrapped in 
the expensive, full functionality parent. After all, for core algorithms a 
hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
the coefficients of the defining equation.

There are of course also odd genus hyperelliptic curves that cover a genus 
0 curve that is not isomorphic to a P^1, but computing in their Jacobians 
has its own problems, so you should probably not try to include them in 
your current design.

One thing that may be worthwhile: hyperelliptic curves do inherit some 
interesting functionality from plane curves (particularly via their affine 
patch) in the form of "riemann_surface". It may be worth keeping that, even 
if the particular code there could be expanded to work much more 
efficiently on hyperelliptic curves.

On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote:

> Thanks David, there's a bunch of nice things we could do for genus two in 
> various cases which would be worth including. The inert case, where all 
> degree zero divisors (except the identity element) have u with degree 2 
> would probably allow something particularly nice. 
>
> As another update I have done a fairly brutish refactoring of the proof of 
> concept code to follow the design decisions of the previous implementation. 
> https://github.com/GiacomoPope/HyperellipticCurves
>
> Hyperelliptic curves are created from a dynamic class constructor on top 
> of the AlgebraicScheme_subscheme_toric class (before this was a curve over 
> the plane projective curves)
> A generic class offers most features, but other classes will cover the 
> case of finite fields, rational fields and padic fields
> The Jacobian is a small class built on top of `jacobian_generic` which is 
> built from the curve
> The set of rational points of the Jacobian is built on top of SchemeHomSet 
> and the elements (divisors) are morphisms built on top of SchemeMorphism
>
> I will do my best to clean up and refactor code to the standard of code 
> which is included into Sage now, but I would love to know any feedback 
> advice on whether this structure is still the one to use. The older version 
> of this code dates back to the beginning of Sage so it's very possible we 
> have new ideas of how things should be done and if we're doing the work or 
> rewriting the whole set of classes I may as well do a good job.
>
> Giacomo
>
> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:
>
>> There is also this old trac ticket 
>>  about implementing fast 
>> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
>> Mike Jabobson, who worked on it.
>> David
>>
>>
>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:
>>
>>> Thank you for linking this and I agree this is a great way to 
>>> cross-compare the work we have been doing. I am not an expert in this area 
>>> so I am not sure I should do a full review but I'm happy to look over it if 
>>> this helps.
>>>
>>> As a small update on this work, I now have 
>>>
>>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>>>
>>> So this new class builds on top of AlgebraicScheme_subscheme_toric and 
>>> the smooth projective model is built using a toric variety. The points on 
>>> the curve are currently SchemeMorphism_point_toric_field, potentially I 
>>> will need to make a child class of these if methods on the points 
>>> themselves are required.
>>>
>>> With the working arithmetic and this new inheritance my work is now 
>>> going to be the rather slow and painful rewrite of all hyperelliptic 
>>> methods from the current implementation to ensure everything works on the 
>>> smooth degree model.
>>>
>>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>>>
 On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:

 As a small update, the repository now contains code to

 - perform arithmetic for
   - the imaginary model (ramified, one point at infinity) for all cases
   - the real model (split, two points at infinity) for all cases
   - the real model (inert, zero points at infinity) for even genus
   Which allows us to do "as much" as Magma does for Jacobians of 
 hyperellipticc curves from the perspective of arithmetic. 

 My current "test" for the arithmetic is that D - D = 0 for all cases, 
 that jacobian_order 

[sage-devel] Re: VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

[Nils Bruin]

On Monday 11 March 2024 at 15:04:50 UTC-7 Giacomo Pope wrote:

I chose the weighting (1 : g + 1 : 1) following Galbraith's textbook 
https://www.math.auckland.ac.nz/~sgal018/crypto-book/ch10.pdf when 
implementing the arithmetic on the Jacobian. This is not a "good" answer 
though.

I would love to hear from more people about what they use / would want to 
use. 


I think it makes sense because at least it means the representation of most 
points is still compatible.
 

As for deprecations, I won't know exactly how much will change before I 
start working on this but if anyone's code fundamentally uses the fact it's 
a projective variety and the functions coming from this then I suppose 
everything will simply have to exist as a second class with deprecation 
warnings. I don't know what's best here.


Yes, with a change as fundamental as this, I think you may be best of just 
copying over the class and make your adjustments there. We'll have two 
underlying "implementations" of hyperelliptic curves, with different 
projective closures. We'll start out with the bad backward compatible one 
as default. At some point, we deprecate that. Then you can change the 
default. Then we can delete the old implementation. And then you can 
reintroduce the old naming as an alias/default.

I suspect most code that relies on non-weighted projective closures is 
broken anyway, but you'd need pretty strong arguments to deviate from 
normal deprecation.
 

Ultimately (even if I wait 2 years) I think it would be good for sage to 
have more functioning arithmetic on Jacobians but this is obviously a very 
small slice of pie in the whole meal of hyperellptic curves.


We can have the functionality without delay. It might just not be available 
on "default" objects until 2 years down the road. That's a little 
unfortunate and makes it less discoverable, but I think we do need to take 
backward compatibility seriously. 

Also note that with this course of action, there is hardly anything 
controversial to the first steps: you're just adding functionality. So a 
sagedevel vote might not even be necessary.

-- 
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/6435d9b1-d566-495b-af5a-1d7619830ff7n%40googlegroups.com.

[sage-devel] Re: VOTE: use the smooth model instead of the plane projective model for hyperelliptic curves

[Nils Bruin]

The change makes sense, but you should investigate if it is at all possible 
to do this going through normal deprecation procedures, which would 
probably involve having both functionalities for some time (likely via 
differently named methods or via a flag implemented in a backward-compatime 
way), then having a deprecation period on the "old" functionality. After 
that the deprecated functionality can be removed. After a suitable wait 
period, the vacated space in the namespace can now be used for the new 
method. You'll be taking a couple of years before you're there.

If it's not possible, you'd better have very good reasons to probably break 
people's code out there with very little warning.

Once you find a way to do this, there's another choice in convention to 
consider: do you go with (1:1:g+1) weights or with (1:g+1:1) ? I.e., with 
[X:Z:Y] or [X:Y:Z]. Both have precedent and people who are used to the 
other convention will find it really annoying to adjust.

-- 
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/66264550-7c09-42f0-8a23-0f083538e3f9n%40googlegroups.com.

[sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Nils Bruin]

On Wednesday 6 March 2024 at 04:52:16 UTC-8 Giacomo Pope wrote:


I think aside from maybe needing additional methods on the hyperelliptic 
curve, once the projective model is right and points on the curve are well 
defined for all cases. I do not have any intuition on whether the balanced 
model will for example have issues with the p-Adic implementation as I have 
no experience in this area.

Tiny bit of feedback on the p-adic bit: as far as I know, things like 
Cantor's algorithm use euclidean division, wwhich is a big problem 
p-adically: coefficients may vanish unexpectedly and p-adically you cannot 
distinguish that from loss of precision. I think that's already a problem 
in the existing implementation and I think it will be in yours as well. So 
I think you can ignore p-adics to begin with. If you can get it working 
usefully and reliably for p-adic base fields as well then that's a real 
win! 

-- 
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/f4de3410-1d9e-4cc7-b518-7471f6c1ecean%40googlegroups.com.

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

[Nils Bruin]

On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:

Following this discussion, I have made a draft PR to change the degree for 
*only* the LaurentPolynomialRing and I will see if the CI detects anything.

https://github.com/sagemath/sage/pull/37513

I agree that if we change the LaurentPolynomialRing we should also change 
the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
method `degree()` but *does* have a `valuation()` method... so this is odd.


OK, let's keep it that way then! I don't think there is a notion on 
LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
one in. I thought it existed. And I think it does:

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

but if it's not documented, perhaps we can just ignore it.

-- 
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/8b712294-c7bd-451d-ab77-1771d48b820an%40googlegroups.com.

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

[Nils Bruin]

On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
 

It seems that exactly the same algorithm will work (I didn't check this!) 
for Laurent polynomials (they still form a Euclidean domain), and there you 
better set degree(0)=-oo, otherwise it's going to be a problem.

I think it's been established 
that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic. 
With the definition that (1/x).degree() == -1 it clearly is.

I think the question is more: do we have enough evidence that setting 
degree(0) == -oo for *all* polynomial rings is significantly better (if 
better at all) that it's worth the pain and incompatibilities that would 
ensue from changing the rest of sage as well? That's not so clear to me. 
>From the perspective of multivariate polynomials, the whole valuation 
interpretation of "degree" goes out of the window, so there "-1" is largely 
available and quite possibly used extensively by the underlying libraries.

I guess one could see what happens if the change is made to Laurent 
polynomials (and Laurent series as well, perhaps?). Based on how that goes 
one could re-evaluate degrees of 0 polynomials in other polynomial rings.

Alternatively, we could deprecate degree on them in favour of using 
valuation-inspired terms instead, where the extension val(0)=oo is more 
universal. As Oscar's example in Matlab shows, the concept of degree gets 
(mis)used for other, more implementation-oriented definitions as well, so 
perhaps the term should just be avoided for Laurent polynomials.

-- 
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/60c42d22-28dc-4221-96a0-b174585c9c23n%40googlegroups.com.

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

[Nils Bruin]

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/053266d4-6fa6-4ac4-8ea0-61a3bf136758n%40googlegroups.com.

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

[Nils Bruin]

On Wednesday 28 February 2024 at 08:03:45 UTC-8 Giacomo Pope wrote:


I don't know the history of this choice or what we should be doing 
generally. -1 for polynomials with only positive degree seems like a 
computer science workaround, but for the LaurentPolynomialRing it just 
seems wrong?


I think it's more than just a CS workaround. It has its roots in dimension 
considerations: the space of polynomials of degree at most d is 
(d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect 
sense.

For deg = - ord_infty it should definitely be -oo, though, and for Laurent 
polynomials the dimension argument doesn't work.

-- 
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/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Nils Bruin]

As Dima points out, SPLU decomposition is probably more useful in practice, 
so it's great to expose it. It should probably be exposed through a 
different method than PLU decomposition, though.

For the return format: permutations are much more compact and efficient to 
describe permutations than permutation matrices. Also because of the 
parent: a permutation matrix is a {0,1}-valued matrix so it can be well 
represented over ZZ, rather than floats. So primarily the routine should 
expose that scipy exposes. Whether other bells and whistles are required is 
another matter.

Is this only for system floats/complex numbers? or will you also be 
implementing multiprecision versions? 

-- 
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/f680547f-33dc-4c43-be78-6f54ed11e798n%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Nils Bruin]

On Tuesday 27 February 2024 at 18:09:42 UTC-8 Travis Scrimshaw wrote:

I am not sure it is purely about Python types since it gets changed into C 
code.


well ... code dealing with python ints in Py3 needs to deal with 
multi-precision PyInt objects, so it can't unwrap these. Whether they are 
internally represented as "compact" integers is an implementation detail 
(see https://docs.python.org/3/c-api/long.html#c.PyUnstable_Long_IsCompact)

I have no succeeded in finding the exact place where the bindings for the 
`int` and `long` names are made for the cython namespace -- but we've 
already established that they refer in runtime to identical objects. This 
was a reasonable indication:

https://github.com/cython/cython/blob/03d982be010b7b94a3c3317c462b2b803ce916af/Cython/Compiler/Code.py#L46-L47

and for pure python mode, there are the type wrappers:

https://github.com/cython/cython/blob/03d982be010b7b94a3c3317c462b2b803ce916af/Cython/Shadow.py#L426-L427
 
(where we also see the instructive comment for `py_long` "# for legacy Py2 
code only" -- so I think cython is indeed only keeping "long" bound for 
legacy reasons)

On the original ticket we actually found that `int_to_Z` was really just 
literally kept from Py2, so was actually buggy! (in Py2, a py_int was 
guaranteed to fit in a system integer, but in Py3 it's just a multiprec 
integer) So removing it was actually beneficial (although it was only used 
in a dead branch of the code, so can code that is guaranteed to be never 
called be buggy?)

-- 
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/34d80bc9-c77b-4c74-a758-510ad4595c6dn%40googlegroups.com.

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

[Nils Bruin]

On Tuesday 27 February 2024 at 10:50:55 UTC-8 John H Palmieri wrote:


As Nathan points out, this will likely lead to instability. Someone will 
upgrade some component, and most of the time that will be fine, but 
occasionally it will break something on some platform, and it could be 
annoying to track down the cause. If this leads to Sage failing to build, 
that's not great, but it would be *far worse* if Sage built and ran but 
produced some mathematically incorrect answers. Being able to control all 
of the versions means that our doctests are pretty robust. If we really 
want to go down the road of unpinning version requirements, I propose that 
we *always* pin version requirements for the mathematical components of 
Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the 
mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
want a pip package), people could be getting different answers on different 
platforms and we might not know about it for a while. To maintain the 
mathematical integrity of the project, we should keep very careful control 
of the mathematical components of Sage.

+1 to this. There is another difference: The jupyter notebook server - 
notebook kernel interface is not a binary one: it's a protocol. As such, 
it's hopefully narrower in its definition and a bit more stable. So 
offering that sagemath offers a notebook kernel that a separately 
distributed notebook server can connect to is a different dependency 
structure than depending on libraries being provided. There are some super 
stable libraries for which external dependencies are OK, but generally 
(especially components under active development) they are a lot more 
sensitive.

For full functionality we depend on more than vanilla jupyter notebook, 
though: at some point, jupyter notebook server shipped with a pared-down 
mathjax and I have not been able to to get proper mathjax working in my 
system-provided jupyter notebook. We have other components, such as 
documentation and various plug-ins that we need in jupyter notebook too. 
This has made the shipped-with-sage jupyter notebook server more reliable 
to me, even if I'd prefer the system notebook server if that would be 
reliable to get working.

Sphinx is another part of such tooling: it should be able to just read and 
process markup. We tend to not ship a latex installation with our 
preprints. However, I don't have experience with how stable sphinx on its 
own is to judge how much trouble one would get from relying on an external 
sphinx. Personally, I don't bother building the sage documentation and rely 
on what is available online instead, so that one wouldn't affect me.  

-- 
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/88accdbb-7d2a-4860-8791-787bf52a8a89n%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Nils Bruin]

See the documentation:

https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html

As you can see there it computes permutation matrices Pr and Pc and lower 
and upper triangular matrices L,U such that

Pr*A*Pc = L*U

so it's not computing a normal LU decomposition of a PLU decomposition: 
it's doing both row- and column permutations on A; presumably to condition 
it to get  a more numerically stable L,U.

It's a different decomposition. You may be able to solve similar problems 
with it, but you'll have to expose the computed data to the user. I don't 
think it's suitable for wrapping as a normal LU-decomposition, as it won't 
be a drop-in substitute for it.

You do get

A = Pr^(-1) *L*U * Pc^(-1)




On Tuesday 27 February 2024 at 10:02:19 UTC-8 Animesh Shree wrote:

> Sorry for multiple messages
>
> I just want to say
>
> >sage: p,l,u = a.LU(force=True)
> >sage: p
> >{'perm_r': [1, 0], 'perm_c': [1, 0]}
>
> It  (  {'perm_r': [1, 0], 'perm_c': [1, 0]}  )  represents transpose and 
> it cannot be represented as permutation matrix.
> Similar cases may arise for other matrices.
>
> On Tuesday, February 27, 2024 at 11:29:44 PM UTC+5:30 Animesh Shree wrote:
>
>> For transpose :
>>
>> In  the example we can see permutations are provided as arrays for rows 
>> and cols.
>> The permutation is equivalent of taking transpose of matrix.
>> But we cant represent transpose as a permutation matrix.
>>
>>
>> >>> a = np.matrix([[1,2],[3,5]])
>> >>> # a * perm = a.T
>> >>> # perm = a.I * a.T
>> >>> a.I*a.T
>> matrix([[-1., -5.],
>> [ 1.,  4.]])
>> >>>
>>
>> the output is not permutation matrix. 
>>
>> On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik 
>> wrote:
>>
>>>
>>>
>>> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
>>> sage-...@googlegroups.com> wrote: 
>>> >I tried scipy which uses superLU. We get the result but there is little 
>>> bit 
>>> >of issue. 
>>> > 
>>> > 
>>> >--For Dense-- 
>>> >The dense matrix factorization gives this output using permutation 
>>> matrix 
>>> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True) 
>>> >sage: a 
>>> >[1.0 0.0] 
>>> >[2.0 1.0] 
>>> >sage: p,l,u = a.dense_matrix().LU() 
>>> >sage: p 
>>> >[0.0 1.0] 
>>> >[1.0 0.0] 
>>> >sage: l 
>>> >[1.0 0.0] 
>>> >[0.5 1.0] 
>>> >sage: u 
>>> >[ 2.0 1.0] 
>>> >[ 0.0 -0.5] 
>>> > 
>>>
>>> you'd probably want to convert the permutation matrix into a 
>>> permutation. 
>>>
>>>
>>> >--For Sparse-- 
>>> >But the scipy LU decomposition uses permutations which involves taking 
>>> >transpose, also the output permutations are represented as array. 
>>>
>>> It is very normal to represent permutations as arrays. 
>>> One can reconstruct the permutation matrix from such an array trivially 
>>> (IIRC, Sage even has a function for it) 
>>>
>>> I am not sure what you mean by "taking transpose". 
>>>
>>> >sage: p,l,u = a.LU(force=True) 
>>> >sage: p 
>>> >{'perm_r': [1, 0], 'perm_c': [1, 0]} 
>>> >sage: l 
>>> >[1.0 0.0] 
>>> >[0.0 1.0] 
>>> >sage: u 
>>> >[1.0 2.0] 
>>> >[0.0 1.0] 
>>> > 
>>> > 
>>> >Shall I continue with this? 
>>>
>>> sure, you are quite close to getting it all done it seems. 
>>>
>>>
>>> >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik 
>>> wrote: 
>>> > 
>>> >> Non-square case for LU is in fact easy. Note that if you have A=LU as 
>>> >> a block matrix 
>>> >> A11 A12 
>>> >> A21 A22 
>>> >> 
>>> >> then its LU-factors L and U are 
>>> >> L11 0 and U11 U12 
>>> >> L21 L22 0 U22 
>>> >> 
>>> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22 
>>> >> 
>>> >> Assume that A11 is square and full rank (else one may apply 
>>> >> permutations of rows and columns in the usual way). while A21=0 and 
>>> >> A22=0. Th

[sage-devel] Re: int vs long in cython

[Nils Bruin]

Hi Travis,

No, these routines are about the python types. They get used as `type(x) is 
int` and `type(x) is long`. They are used in a different namespace from 
`cdef int x` and `cdef long x` and cdef long long x` (well, the `x` is in 
the cython object namespace. The C-types don't make it into the cython 
object namespace. They are in a C type namespace).

 The cython test routine above confirms that the objects `int` and `long` 
(not the cdef type names!) are indeed the same object in cython
The code below confirms they are the python `int` type object:

sage: cython("""
: def test(x):
: return (x is long, x is int)
: """)
sage: test(int)
(True, True)
On Sunday 25 February 2024 at 01:48:09 UTC-8 Travis Scrimshaw wrote:

> Sorry for the delayed response.
>
> If the C compiler can't tell the difference between an int and a long, 
> then that suggests that there is still a difference. I am not sure that 
> Cython has any specification that these are different. My understanding is 
> Cython treats these as C types. Can we be certain that an int that is not a 
> long will not find its way in? Could it also depend on someone's version of 
> C/Python?
>
> Best,
> Travis
>
>
> On Thursday, February 22, 2024 at 2:52:25 PM UTC+9 Nils Bruin wrote:
>
>> I tried removal here:
>> https://github.com/sagemath/sage/pull/37420
>> and as expected it looks like it's working fine.
>>
>> On Wednesday 21 February 2024 at 19:06:50 UTC-8 Nils Bruin wrote:
>>
>>> well, I don't expect the C compiler to be smart enough to recognise the 
>>> second is an "elif False:", so the "hurt" would be in additional code 
>>> executed. Plus, having hidden "elif False:"s in a code base is a really bad 
>>> code smell, so I think there is a penalty. What do you want to guard 
>>> against? "int" and "long" becoming not synonyms in cython again? There will 
>>> be probably other py2/3 relics in our code base. I think we should clean 
>>> them up when encountered, unless we have a good reason not to.
>>>
>>> On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:
>>>
>>>> I think so, but it might not hurt to have it.
>>>>
>>>> Best,
>>>> Travis
>>>>
>>>> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>>>>
>>>>> I noticed the following cython code
>>>>>
>>>>> if S is long:
>>>>> return sage.rings.integer.long_to_Z()
>>>>> elif S is int:
>>>>> return sage.rings.integer.int_to_Z()
>>>>>
>>>>>
>>>>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>>>>
>>>>> However, in cython with python3 we now have:
>>>>>
>>>>> sage: cython("""
>>>>> : def tst():
>>>>> : return int is long
>>>>> : """)
>>>>> sage: tst()
>>>>> True
>>>>>
>>>>> so I think the `elif` can be deleted. Is that correct?
>>>>>
>>>>

-- 
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/5fc40a24-e369-4751-931d-fbf3e66ca0f5n%40googlegroups.com.

[sage-devel] Re: Help with coercion / action for tensor product

[Nils Bruin]

On Friday 23 February 2024 at 06:44:39 UTC-8 Martin R wrote:

Dear all!

I badly need help to make the following work. Let M be a module over a ring 
Q, and let R be a ring with a coercion from Q to R.  Then I want to be able 
to multiply elements in R with elements in tensor products of M.


It looks to me you should first base extend M to M_R, a module over R, 
using the coercion map Q->R.  So I don't think R acts on M. It acts on M_R.

Do you want the coercion system to be smart enough to construct that base 
extension for you? I'm not sure I'd expect the system to do that or even be 
in favour of the system doing that on its own.

-- 
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/27a09e05-f454-4f7b-b955-b888f01ab48cn%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Nils Bruin]

I tried removal here:
https://github.com/sagemath/sage/pull/37420
and as expected it looks like it's working fine.

On Wednesday 21 February 2024 at 19:06:50 UTC-8 Nils Bruin wrote:

> well, I don't expect the C compiler to be smart enough to recognise the 
> second is an "elif False:", so the "hurt" would be in additional code 
> executed. Plus, having hidden "elif False:"s in a code base is a really bad 
> code smell, so I think there is a penalty. What do you want to guard 
> against? "int" and "long" becoming not synonyms in cython again? There will 
> be probably other py2/3 relics in our code base. I think we should clean 
> them up when encountered, unless we have a good reason not to.
>
> On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:
>
>> I think so, but it might not hurt to have it.
>>
>> Best,
>> Travis
>>
>> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>>
>>> I noticed the following cython code
>>>
>>> if S is long:
>>> return sage.rings.integer.long_to_Z()
>>> elif S is int:
>>> return sage.rings.integer.int_to_Z()
>>>
>>>
>>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>>
>>> However, in cython with python3 we now have:
>>>
>>> sage: cython("""
>>> : def tst():
>>> : return int is long
>>> : """)
>>> sage: tst()
>>> True
>>>
>>> so I think the `elif` can be deleted. Is that correct?
>>>
>>

-- 
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/c1bc68c4-8b5a-47f1-9a53-39528aa852b4n%40googlegroups.com.

[sage-devel] Re: int vs long in cython

[Nils Bruin]

well, I don't expect the C compiler to be smart enough to recognise the 
second is an "elif False:", so the "hurt" would be in additional code 
executed. Plus, having hidden "elif False:"s in a code base is a really bad 
code smell, so I think there is a penalty. What do you want to guard 
against? "int" and "long" becoming not synonyms in cython again? There will 
be probably other py2/3 relics in our code base. I think we should clean 
them up when encountered, unless we have a good reason not to.

On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:

> I think so, but it might not hurt to have it.
>
> Best,
> Travis
>
> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>
>> I noticed the following cython code
>>
>> if S is long:
>> return sage.rings.integer.long_to_Z()
>> elif S is int:
>> return sage.rings.integer.int_to_Z()
>>
>>
>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>
>> However, in cython with python3 we now have:
>>
>> sage: cython("""
>> : def tst():
>> : return int is long
>> : """)
>> sage: tst()
>> True
>>
>> so I think the `elif` can be deleted. Is that correct?
>>
>

-- 
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/c6fe238f-9640-4c97-a861-d56fe6e87494n%40googlegroups.com.

[sage-devel] int vs long in cython

[Nils Bruin]

I noticed the following cython code

if S is long:
return sage.rings.integer.long_to_Z()
elif S is int:
return sage.rings.integer.int_to_Z()

https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1

However, in cython with python3 we now have:

sage: cython("""
: def tst():
: return int is long
: """)
sage: tst()
True

so I think the `elif` can be deleted. Is that correct?

-- 
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/29f587a2-d399-4e0c-a38a-49a6781de877n%40googlegroups.com.

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

[Nils Bruin]

As far as I understand, the proposal is to allow sage "packages" to be 
closer to more standard python prerequisites by letting them be resolved by 
pip packages. By default the package content would be fetched, as pip does, 
and that would mean the default configuration for sage would require 
internet at install time.

I also understand that there are people who are concerned that this may not 
reflect all scenarios where people want to install sagemath and they would 
prefer if there is a clear method to install sagemath from a well-defined 
set of archives (one big one?) that need to be transferred to the target 
machine, after which the install can proceed without internet access.

Searching for "pip without internet" gives various hits. One that at least 
superficially looks like a reasonable starting point:

https://thilinamad.medium.com/install-python-packages-via-pip-without-an-internet-connection-b3dee83b4c2d

but there are also stackoverflow answers that look relevant.

It looks like, with a bit of work, pip can be convinced to look at local 
files to satisfy prerequisites and packages. Hence, if we keep that in mind 
it seems to me that having an archive of "pip packages" would be doable if 
we ensure pip gets used in a way that makes it easy to reconfigure the 
place to look for prereqs. Then it may be fairly easy to make an offline 
installable version of sagemath, either by packing a big tarball that 
includes the pip content or by making that available in a separate ball, 
with an easy switch (or perhaps we can configure pip to first look locally 
and then try the internet? Or the other way around? that it could 
transition gracefully between different ways of satisfying requirements).

So, perhaps we can have our pips and networkless installs too? 

-- 
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/db063109-24ab-4b0b-abf1-eac3d1a8003en%40googlegroups.com.

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

[Nils Bruin]

On Thursday 15 February 2024 at 17:02:14 UTC-8 Dima Pasechnik wrote:

but that's sphinx (Python), not jupyter.

I see. The page I linked to is from Jupyter{book} which is, despite the 
similarity in name, not the jupyter notebook server. 

-- 
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/f1f66402-bb16-4854-957e-870f9e7c61c2n%40googlegroups.com.

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

[Nils Bruin]

On Thursday 15 February 2024 at 13:19:47 UTC-8 Michael Orlitzky wrote:


The notebook release process minifies all of its javascript code. The 
bit that sets the MathJax options is in there somewhere but good luck 
finding it. 

Well, the text in the tip looks more like config file content than 
javascript, so whoever wrote the tip probably didn't propose to change 
javascript. Supposedly, they had a config file in mind somewhere, which 
would not be minified. I have very limited knowledge of the configuration 
mechanics of jupyter. 

The snippet looks like this:

sphinx:
config:
mathjax_path: 
https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js  
---
(that's the URL that should change to mathjax 3. Supposedly one might be 
able to change that to a local resource)

Hopefully jupyter can provide a more obvious way to tweak this option, but 
even knowing where one can change this option effectively might already be 
useful (especially in cases where the default doesn't do what one wants).

-- 
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/d4823c77-7dba-4210-9192-e286d4f109abn%40googlegroups.com.

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

[Nils Bruin]

According to the jupyter notebook documentation:

https://jupyterbook.org/en/stable/content/math.html

it should be possible to switch jupyter from using mathjax 2 to mathjax 3 
by some configuration option (no clue where those configuration options 
would go, and no indication is given in the tip either). I would think that 
if one can switch to a different mathjax by just changing a URL in the 
config, one should be able to point that at local resources (a "file:" URL 
instead) to avoid any use of https, and hence hopefully the internet.

I'd be interested in hearing if someone figures out how to do that, since 
on my own (system) jupyter mathjax is severely hobbled: at some point 
jupyter decided to ship a stripped-down mathjax, so I don't get any 
dedicated mathfont goodness; only unicode approximations. I've tried to 
convince the server to use proper mathjax but failed. The jupyter server 
that comes packaged with sagemath does work well -- a small case where 
we're getting a benefit from sage-the-distribution.

-- 
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/b3de134a-3bb4-43d4-b4ed-0fc187dc09f4n%40googlegroups.com.

Re: [sage-devel] One year of Sage development on GitHub

[Nils Bruin]

On Monday 12 February 2024 at 15:58:11 UTC-8 Dima Pasechnik wrote:

What's rotten and decaying - well, the most obvious points are: 

* pynac (memory leaks, bugs, sketchy or no docs, authors left long time 
ago) 

* commutative algebra, in particular Singular-based (memory leaks, 
bugs, no docs, authors either left or are not willing to look into it 
much), etc. 

* maxima (bugs, bugs, bugs) 

* broken optional packages, e.g. p_group_cohomology 


Each of those components could definitely use attention. However, the skill 
set required to work on those components is quite different from that on 
working on (re)packaging existing, maintained python projects. People 
choose what they work on. I think we have a problem if we don't have anyone 
willing/able to work on pynac or singular or maxima. But I'm not sure this 
has very much to do with people working on (re)packaging other software.

The discussion about whether a sage-the-distribution should exist and how 
it relates to sage-the-library definitely needs to be resolved at some 
point and, whatever decision is made, people need to accept that's the 
consensus and move on until the next time it needs to be reconsidered, but 
I don't think that the resolution of that issue will alleviate the lack of 
maintainers of pynac etc.

-- 
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/2bf356de-c6be-402e-9278-55e901469ec7n%40googlegroups.com.

[sage-devel] Re: Question about coercion model

[Nils Bruin]

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.

Re: [sage-devel] Re: Exception in floor(tanh(91))

[Nils Bruin]

On Friday 9 February 2024 at 08:16:03 UTC-8 Georgi Guninski wrote:

When I try to extract digits of tanh(91) via floor, I still get error 

sage: floor(10^4*tanh(91)) 
ValueError 

The sage code doesn't use gp for this. The error you're encountering 
happens in

sage.functions.other._eval_floor_ceil

and it happens because the system tries to evaluate the expression using 
interval arithmetic. It iteratively increases the precision until it find 
an interval that doesn't straddle an integer or it gives up after a set 
number of trials. You're hitting that second condition. You don't make it 
easier by multiplying by 10^4. In fact, you make it harder: you now need 
more digits to get the interval to not include an integer.

Without more information, this code basically has to give up after a fixed 
number of tries: it could be evaluating an expression that actually does 
evaluate to 1. In that case, no amount of increased precision will result 
in an interval that doesn't contain an integer. It's a well-known problem 
in numerical approximation: discontinuous functions are basically not 
computable in that model.
 

gp computes it both ways :) 

sage: gp.default('realprecision',10^5) 
0 
sage: gp('floor(tanh(91))') 
0 


so does sage if you tell it to use the same approach gp uses:

 sage: tanh(91).n(30).floor()
1
sage: tanh(91).n(300).floor()
0

-- 
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/7c4fbdd1-b925-48ed-b9e4-4b1a970d4b3en%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

[Nils Bruin]

The main relevance of classifying errors properly in python is for 
try/except. Generally, a try/except should be tight both in code guarded 
and in errors caught. An `except RuntimeError` is almost certainly a bad 
idea. `except ZeroDivisionError` looks quite reasonable. `except 
ValueError` or `except ArithmeticError` can already easily catch a little 
too much. `except TypeError` looks very suspicious when what is intended to 
be caught is an object (of the right type) to which a (partial) "inversion" 
map cannot be applied. "NotImplemented" should probably not be caught 
either: implementing the missing functionality is ideally the way to avoid 
that error from occurring.

Error objects do have more info than just their type and an except clause 
can investigate this and decide to reraise. That's a huge pain to program 
(and potentially slow), so in practice that's almost never done. The type 
of an error is in practice the only granularity for try/except.

Reclassifying errors should probably happen with an eye towards the utility 
for try/except. That means that reclassifying existing error will break 
existing code, so you better have a very good reason. For "RuntimeError" I 
agree, because there the developer (unintentionally?) signals "this 
shouldn't be caught". So you'll have to go in, analyse the intent and 
reassess if that error should indeed not be caught.

For the other ones it depends: if it's an object that can end up in 
polymorphic code then aligning errors makes sense, but otherwise the pain 
of breakage probably means the change is not worth it.

On Friday 9 February 2024 at 01:00:45 UTC-8 Travis Scrimshaw wrote:

> You're misunderstanding what a catch-all means. It means *any* type (of 
> error) is reasonable. To put it mathematically, catch-all means union (of 
> sets), but the Python doc means difference (of sets).
>
> An assertion is slightly different. It can (in principle) be turned off 
> and is just used for internal checking. While there is large overlap, it is 
> not quite the same (e.g., if code is assuming a certain conjecture, it 
> should not use assert to check validity of assumptions).
>
> Best,
> Travis
>
>
> On Friday, February 9, 2024 at 1:44:23 PM UTC+9 dmo...@deductivepress.ca 
> wrote:
>
>> Description of RunTimeError from docs.python.org: "Raised when an error 
>> is detected that doesn’t fall in any of the other categories. The 
>> associated value is a string indicating what precisely went wrong."
>>
>> It is for exceptions that cannot be categorized, so I believe it is 
>> indeed just a catch-all error (but must have a description), and there is 
>> no expectation that such an error is particularly serious. (A situation 
>> where "an assumption that I never expected to be violated fails" can raise 
>> AssertionError.)
>>
>> On Thursday, February 8, 2024 at 10:14:33 PM UTC-5 David Roe wrote:
>>
>>> On Thu, Feb 8, 2024 at 8:18 PM 'Travis Scrimshaw' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
 For RuntimeError, I would make it sound like it tells you there is 
 serious error occurring as it doesn't fall into any other error 
 categories. 
 This actually makes it the opposite of a catchall error.

>>>
>>> The main scenario when I use a RuntimeError is when an assumption that I 
>>> never expected to be violated fails.  I agree with Travis that catchall is 
>>> not the right description for this error type.
>>> David
>>>
>>

-- 
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/30baa52d-5784-4db4-818a-cd9a571298b4n%40googlegroups.com.

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

[Nils Bruin]

I second that response. More specifically, what you're running into is:

sage: S.jack(t=t) == S.jack(t='t')
False

which is indeed within UniqueRepresentation design parameters: returned 
values are cached on construction parameters 't' and '"t"' hash to 
different values. If you need better processing, you'd need to normalize 
the input parameters further before calling the UniqueRepresentation 
constructor. In your case, I think jack.Jack (which is what ends up being 
called) actually does expect a string. Perhaps this keyword should be 
renamed to "names" to comply with uses elsewhere? e.g., would 
R.=S.jack() make sense? If so, then the following should probably be 
made to work:

sage: preparse("R.=S.jack()")
"R = S.jack(names=('t',)); (t,) = R._first_ngens(1)"
On Monday 5 February 2024 at 05:57:40 UTC-8 Martin R 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/eb3e2b59-9f43-4f9a-9c37-cf7719691eebn%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Nils Bruin]

On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote:


it is the matter of adding extra zero rows or columns to the matrix you 
want to decompose. This could be a quick fix. 

(in reference to computing LU decompositions of non-square matrices) -- in 
a numerical setting, adding extra zero rows/columns may not be such an 
attractive option: if previously you know you had a maximal rank matrix, 
you have now ruined it by the padding. It's worth checking the 
documentation and literature if padding is appropriate/desirable for the 
target algorithm/implementation. 

-- 
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/622a01e0-9197-40c5-beda-92729c4e4a32n%40googlegroups.com.

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

[Nils Bruin]

By the looks of it, the routines you'd be using would be coming from 
umfpack. cvxopt has chosen to package the details of LU factorization in 
opaque objects and instead offer routines to use these decompositions (via 
taking the opaque object as input). In scipy, umfpack is also used: 
https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.spsolve.html#scipy.sparse.linalg.spsolve
 
. Scipy also offers LU decomposition routines: 
https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.splu.html#scipy.sparse.linalg.splu
 
but that uses a different library. It looks suspicious that two packages 
offer umfpack for solving sparse problems, but don't give explicit access 
to LU factorizations produced in the process, when using UMFPACK. Perhaps 
UMFPACK isn't suited to provide the explicit factorization (but it may be 
very good at using its internally computed data).



-- 
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/b852bb80-ffe9-44bd-b104-74e1bfdac9e2n%40googlegroups.com.

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

[Nils Bruin]

On Wednesday 24 January 2024 at 08:22:21 UTC-8 Gareth Ma wrote:

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

I think with these options, you'd end up with the installed files living 
right in src. Once they're there you can use whatever procedure to rebuild 
them. It may well be that a "make build" with the right environment set up 
does the right thing in the sage library. At that point, "src" could even 
be a git repo. I'm not so sure if dependency/change tracking will still 
work across package boundaries, but getting proper incremental rebuilding 
for sagelib should be attainable (and quite frankly required for a 
conda/pip install to be a viable way for sage development)

I've certainly used "pip --editable" installs for smaller python/cython 
packages and was able to incrementally rebuild on them. The "pip" part is 
to get the files in place and linked up with a python environment. After 
that you're down to the build/make tools coming with the package.

-- 
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/87c28440-96af-4bae-a8b8-0dcb0c7aee0an%40googlegroups.com.

[sage-devel] Re: Bug in integration on a Riemann surface

[Nils Bruin]

More importantly, the error also doesn't occur with

S = Curve(f).riemann_surface(integration_method="heuristic")

so it's indeed in the newer code. The fact that swapping x,z makes the 
error disappear is also unsurprising: entirely different path integrals are 
executed.

As an indication for what is likely happening, on line 2211:

delta_z and rho_z seem to be indistinguishable, forcing Delta and M to be 
+infinity. Path splitting should definitely happen here. I think delta_z 
should have been smaller than rho_z when you reach this point, so I think 
the code should have bailed before.
On Monday 22 January 2024 at 03:03:20 UTC-8 Linden Disney wrote:

> In Sage 9.8 I ran the following code:
>
> R. = QQ[]
> f = x*(1^5+z^5) + (x*1*z)^2 - x^4*1*z - 2*1^3*z^3
> S = Curve(f).riemann_surface()
> S.riemann_matrix()
>
> and got a ValueError occurring inside rigorous_line_integral. This error 
> doesn't occur if instead for the first line I used "R. = QQ[]" 
> (swapping the order of x and z). Can anyone replicate the error? If so 
> please let me know and I will open a ticket about this and have a look, as 
> I wrote the rigorous_line_integral code. 
>
>

-- 
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/d9cdbad8-f6bb-4eb1-bfd7-696d876d2d28n%40googlegroups.com.

[sage-devel] silencing github workflow "Build Docker images and push to DockerHub "

[Nils Bruin]

Since a while I've started getting notifications " Run failed: Build Docker 
images and push to DockerHub - develop". I don't recall asking for those or 
setting something up to trigger these workflows/builds. It looks like it's 
something that's happening in my github account so I should be able to turn 
it off. Does someone know where to turn off github workflows?

(or if this is something that belongs to sage development and cannot be 
turned off, I'd like to turn notification off -- or otherwise install a 
filter to trash the notifications on receipt. But I figured it would be 
better to check in case it's burning trees for no reason)

-- 
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/94512e4b-0cfe-4708-94a0-af9a30f247b8n%40googlegroups.com.

[sage-devel] Re: Ring of undetermined coefficients

[Nils Bruin]

On Wednesday 17 January 2024 at 23:51:05 UTC-8 Martin R wrote:

Over at https://github.com/sagemath/sage/pull/37033 I am hitting the 
following question:

Is it possible to have a ring UndeterminedCoefficientRing(R) which, for 
every functorial construction F(R) has pushout 
F(UndeterminedCoefficientRing(R)).


I suspect that for QQ['x']['x'] you'll run into trouble. 

Also, I'd expect quotient constructions will have trouble commuting with 
your new functor:

sage: R.=QQ[]
sage: I=R.ideal(a^2+b^2-1)
sage: S=R.quo(I)
sage: S.construction()
(QuotientFunctor, Multivariate Polynomial Ring in a, b over Rational Field)

although I don't think that's a fundamental obstruction.

Another obstacle may be noncommutative group rings etc. Or (hinting at what 
you're describing later on already) when completions have been taken -- 
i.e., certain variables may occur as power series variables somewhere in 
the tower.

A best effort attempt probably gives you a ring extension functor such that 
it has a pushout for many functorial constructions F.
 

-- 
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/da483529-1a6e-4ef0-b228-10cf9e6c0b1en%40googlegroups.com.

[sage-devel] Re: Desparate for help

[Nils Bruin]

This might be at fault:

sage: coercion_model.analyse(q,e)
(['Action discovered.',
  Left scalar multiplication by Multivariate Polynomial Ring in z, q over 
Rational Field on Multivariate Polynomial Ring in z, q over Infinite 
polynomial ring in F over Rational Field],
 Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F 
over Multivariate Polynomial Ring in z, q over Rational Field)

it looks like somehow an action is found before "common parent" 
multiplication is used.



On Friday 12 January 2024 at 17:24:00 UTC-5 Martin R wrote:

I am not quite sure I understand how this works / what is used:

sage: pushout(e.parent(), z.parent())
Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F 
over Multivariate Polynomial Ring in z, q over Rational Field
sage: coercion_model.common_parent(z, e)
Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F 
over Rational Field

Martin
On Friday 12 January 2024 at 22:47:49 UTC+1 Martin R wrote:

Hm, that's somewhat unfortunate - I don't see how to work around it.  I 
guess I would have to force all elements to be in P (using the notation of 
the example), but this is, I think, not possible.

Do you know where this behaviour is determined?

On Friday 12 January 2024 at 22:09:41 UTC+1 Nils Bruin wrote:

On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote:

I made a tiny bit of progress, and now face the following problem:

sage: I. = InfinitePolynomialRing(QQ) 
sage: P. = I[] 
sage: e = z*q 
sage: Q. = QQ[] 
sage: z*e
z*z*q 

Is this correct behaviour?

I don't think it's desperately wrong. To sage, these structures look like:

sage: P.construction()
(MPoly[z,q], Infinite polynomial ring in F over Rational Field)
sage: Q.construction()
(MPoly[z,q], Rational Field)
sage: parent(z*e).construction()
(MPoly[z,q],
 Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q 
over Rational Field)

Note that an "infinite polynomial ring" is a different object than an 
MPoly, and obviously it has different rules/priorities for finding common 
overstructures.
 

-- 
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/52d111fa-9539-46c0-8c16-a8f775a88bd3n%40googlegroups.com.

[sage-devel] Re: Desparate for help

[Nils Bruin]

On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote:

I made a tiny bit of progress, and now face the following problem:

sage: I. = InfinitePolynomialRing(QQ) 
sage: P. = I[] 
sage: e = z*q 
sage: Q. = QQ[] 
sage: z*e
z*z*q 

Is this correct behaviour?

I don't think it's desperately wrong. To sage, these structures look like:

sage: P.construction()
(MPoly[z,q], Infinite polynomial ring in F over Rational Field)
sage: Q.construction()
(MPoly[z,q], Rational Field)
sage: parent(z*e).construction()
(MPoly[z,q],
 Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q 
over Rational Field)

Note that an "infinite polynomial ring" is a different object than an 
MPoly, and obviously it has different rules/priorities for finding common 
overstructures.
 

-- 
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/de2e4b15-54d8-46e7-b10e-0e5eacd39aean%40googlegroups.com.

Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Nils Bruin]

On Wednesday 10 January 2024 at 16:59:22 UTC-5 Dima Pasechnik wrote:

When it was discussed whether we wanted to use it, the main objection was 
that it needs root (once, explicitly, to set up, then implicitly), thus 
unsafe. 
Conda was mentioned as a better option. But Conda is much bigger. 


Conda is also multi-platform. A packaging of sagemath through conda is (or 
at least should be) usable on both linux and OSX. Doesn't that make it a 
more attractive target than homebrew?

Also, why not package sage in multiple ways if there's a taste for it? Like 
the packaging in linux distributions¸ it doesn't all need to be done by the 
core sage team, but probably at least one or a few should be, to guarantee 
that there's actually a way to get sage working for many people. As long as 
someone volunteers to maintain a packaging method, what's the downside of 
having it?

If there are people to maintain both homebrew and conda, can't we just do 
both?

-- 
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/adb84226-f0ca-4007-be6f-705ac0f59a9cn%40googlegroups.com.

[sage-devel] Re: Regarding deprecation of a property

[Nils Bruin]

On Friday 12 January 2024 at 14:50:54 UTC-5 Ruchit Jagodara wrote:

Okay, so I will make a new function named coefficient_monomials and will 
implement the functionality that Lorenz Panny suggested.
Thank you for your help : ) .


I think "coefficients_monomials" is a little clearer. ( 
coefficient_monomials could be interpreted as "monomials of the 
coefficient", which wouldn't make sense). 

-- 
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/ed37694f-3945-4b2e-adbb-255ca4cf2bf4n%40googlegroups.com.

[sage-devel] Re: Regarding deprecation of a property

[Nils Bruin]

On Wednesday 10 January 2024 at 03:03:09 UTC-8 Martin R wrote:

... What would be a good name?  Brainstorming: `coefficient_system`, 
`coefficients`, `coefficients_monomials`, 
`coefficient_matrix_monomial_vector`...


I think coefficients_monomials() is the most descriptive, as it tells you 
what you get back and in what order.

C, m = PS.coefficients_monomials()
assert PolynomialSequence(C*m) == PS

(incidentally, the assert also holds true with the return values of 
coefficient_matrix)

Also, thinking about whether C should be transposed: I think it's logical 
that the rows of C are the coefficients of members of the sequence (since 
matrices are closest to sequences of rows in sage), so C is already correct 
in that sense. Therefore, m should indeed be a "column" vector, but sage is 
ambivalent about whether vectors are rows or columns and therefore we can 
safely return it as a vector.

-- 
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/fb1b95b7-8ac1-42b0-b02d-bfdd10844077n%40googlegroups.com.

[sage-devel] Re: Regarding deprecation of a property

[Nils Bruin]

deprecation in a way that allows code to be adapted gradually would mean:
 - introduce a new method with a different name that implements the desired 
behaviour
 - deprecate old method
 - after appropriate deprecation period remove old method
 - possibly, at this point introduce the now-vacated name as a synonym for 
the method with the desired method.
Quite frankly I think "coefficient_matrix" is the wrong name anyway: I'd 
expect such a method to return a matrix, but it returns a tuple (both in 
the old and the new version). So I think step 4 can be skipped in this case.

Note that often deprecation remains the state for very long: the motivation 
for actually removing functionality is pretty minimal.


On Tuesday 9 January 2024 at 23:49:37 UTC-8 Ruchit Jagodara wrote:

> Currently, the PolynomialSequence.coefficient_matrix() function returns a 
> matrix of monomials as the second element of a tuple. However, as discussed 
> in issue [#37027](https://github.com/sagemath/sage/issues/37027), it has 
> been suggested that returning a vector of monomials would be more logical. 
> I am uncertain about the correct approach to deprecate the current 
> behavior. I have submitted a pull request with the proposed changes at PR 
> [#37035](https://github.com/sagemath/sage/pull/37035), but I would 
> appreciate guidance on whether this is the appropriate way to deprecate the 
> property.
>

-- 
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/09fd753c-606f-4d84-8557-8a2798daf5ccn%40googlegroups.com.

[sage-devel] Re: crash with coredump in `crt` for polynomials over finite rings

[Nils Bruin]

In case someone wants to follow up, the crash is due to an unsurprising:

Flint exception (Impossible inverse):
Cannot invert modulo 13*13

so perhaps a bit more extensive error catching/processing needs to happen 
in the flint wrapper.

On Friday 5 January 2024 at 23:03:48 UTC-8 Georgi Guninski wrote:

> def testcrtcrash1():
> """
> crash with coredump in `crt` for polynomials over finite rings
> author: Georgi Guninski
> """
> A=13
> Kx.=Integers(A**2)[]
> mods=[x^2+A,x^4+A]
> resi=[x,x^2]
> g=crt(resi,mods)
> return g
>
>
> Aborted (core dumped)
>

-- 
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/3d1ced08-01cb-4e51-8e30-a758b5e28d92n%40googlegroups.com.

[sage-devel] Re: PolynomialRing().random_element() returns 0 rather often.

[Nils Bruin]

This is documented (almost). The routine generates polynomials with degrees 
in a given range, with by default is -1..2 . It chooses the degree 
uniformly (the documentation doesn't specify this), so one would expect 33% 
degree -1, i.e., the 0 poly. I have a hard time thinking of situations 
where this is the distribution one would want.

Over a finite field perhaps you're more interested in the uniform 
distribution on polynomials of degree at most N. Then 
Kx([GF(p).random_element() for _ in range(N+1)]) would be better.

On Saturday 30 December 2023 at 04:43:44 UTC-8 Georgi Guninski wrote:

> Just FYI:
>
> def testquotient2():
> set_random_seed(1);p=next_prime(10**120);Kx=Integers(p)['x']
> l=[Kx.random_element() for _ in range(100)]
> return l.count(0)
> testquotient2()
> 27
>

-- 
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/61b0120b-9d2a-4470-a00a-d64cd65707f7n%40googlegroups.com.

[sage-devel] Re: Name mangling in Cython 3

[Nils Bruin]

Ah OK. Thanks. That explains why the attribute has been renamed to _prec . 
That's unfortunate for compatibility across versions of sage.

The "prec()" function is not cdef'd by the looks of it, so on cython level 
one should really use the attribute rather than the accessor function, to 
avoid the huge penalty of a python function call.

On Monday 25 December 2023 at 12:31:01 UTC-8 Matthias Koeppe wrote:

> On Monday, December 25, 2023 at 11:49:24 AM UTC-8 Nils Bruin wrote:
>
> I don't think double-underscore prefixed names get mangled in python, do 
> they?
>
>
> They do:
> https://docs.python.org/3/tutorial/classes.html#tut-private
>
>

-- 
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/94ab30ed-0ec9-40d3-b96f-c875e8a48206n%40googlegroups.com.

[sage-devel] Name mangling in Cython 3

[Nils Bruin]

I think a lot of you may have run into similar issues with transitioning 
from Cython 0.* to 3.0, so I'm asking here as well. As a reference, I've 
also asked it on cython-users:

https://groups.google.com/g/cython-users/c/Kvjbt4fTfN8/m/8RhFrd8bAgAJ

but perhaps a sage-specific perspective from here may help.

In the RiemannTheta package the instruction

  mpfr_init2(self.r1, self.RR.__prec)

used to work just fine but now gets the error:

AttributeError: 'sage.rings.real_mpfr.RealField_class' object has no 
attribute '_RiemannTheta__prec'

(where RR is, as you can see, a sage RealField). I suspect there are two 
things in the way of this functioning:

 * the name now gets mangled by prefixing "_RiemannTheta"
 * the actual name of the attribute may get mangled as well; presumably to 
"_RealField_class__prec".

This must have come up in other libraries as well. How did you deal with 
that? Can we turn off mangling?

It seems to me cython might be a little too eager to mangle here. I don't 
think double-underscore prefixed names get mangled in python, do they?

-- 
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/4480-06b1-49e6-a469-a764e69f6311n%40googlegroups.com.

Re: [sage-devel] Poll: deprecate backslash operator

[Nils Bruin]

On Wednesday, 4 October 2023 at 10:41:36 UTC-7 Thierry Dumont wrote:

In "Computational Mathematics with SageMath" we have some backslash... 


Indeed, I found on page 43 the example:

sage: 123 + \
: 345
468

which does not work presently. The first mention of "\" as an operator is 
on page 162, where it's given as a shorthand for solve_right in a table 
(with "/" as a shorthand of solve_left)
It also occurs on p168 (sect. 8.2.2) [twice] , p281, p283 (with 
explanation), p302 (in a summary table). Even in the sections where it is 
used, `\` is used much more often as a line continuation .

As far as the book is concerned, I think certainly fixing "\" to work as 
line continuation is definitely more important for its correctness, since 
that's used in much more places in the book (and also in all the chapters 
where `\` is used as an operator). In all the places except the summary 
table on p302, I saw the alternative solve_right spelling explicitly 
mentioned. So impact of deprecating the notation is rather limited. You 
could just add it to an errata/updates list.
 

-- 
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/5f938913-7a14-4ac0-b44f-5fea4aa53b5bn%40googlegroups.com.

Re: [sage-devel] Poll: deprecate backslash operator

[Nils Bruin]

Deprecate please.

-- 
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/699f7d70-4222-4f64-8ce4-e606478377a9n%40googlegroups.com.

Re: [sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

[Nils Bruin]

I'm quite strongly against because it collides with a well-established 
meaning of `\` in python: escape character. It's used to avoid command 
termination by newline in things like formulas (as "\ On Wed, Sep 27, 2023 at 2:32 PM John H Palmieri  
> wrote:
>
>> The github issue #36060 (https://github.com/sagemath/sage/issues/36060) 
>> proposes adding a backslash operator for Sage integers, so that "2 \ 3" 
>> will return the same as "3 / 2". Do you support this?
>>
>>
> I'm not for or against. However, I don't see the problem that implementing 
> this "\" is going to solve. The ticket suggests that users will naturally 
> type 2\3 instead of 3/2, if I am reading between the lines correctly. 
>  
>
>> BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
>> converts "A \ b" to the appropriate Python code. The docstring for 
>> BackslashOperator says "Implements Matlab-style backslash operator for 
>> solving systems A \ b". 
>>
>> It seems pretty innocuous to me — in fact I don't care much either way — 
>> but since Sage integers are so ubiquitous, it seems like a good idea to ask 
>> before implementing it.
>>
>> -- 
>> John
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/3f157aa4-74cd-4c5c-bc76-f198c6417432n%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/f7a940bd-ced4-4441-b57c-059b8f65e704n%40googlegroups.com.

[sage-devel] Re: Remove unnecessary docstring warnings?

[Nils Bruin]

I think that warning is not formulated optimally, regardless of when it 
gets shown. Aren't the docstrings meant as user documentation? The average 
user probably doesn't care about whether "doctests pass" and may not even 
know what that means. Presumably, the marker is there because the module 
needs sage.graphs to function properly. So a warning about a missing stated 
prerequisite is more in order, possibly with a pointer to documentation how 
to get it.

It seems a strange warning to me anyway, since sage.graphs is a standard 
module. Sage is seriously defective if it's missing.

On Thursday, 21 September 2023 at 13:57:01 UTC-7 John H Palmieri wrote:

When running Sage, if I look at some docststrings by doing foo.bar?, I see 
at the top

WARNING: the enclosing module is marked 'needs sage.graphs', so doctests 
may not pass.

 


Of course my copy of Sage has (as far as I know!) a working copy of 
sage.graphs. Should this warning only be printed conditionally when the 
module is missing? I took a quick look and didn't see a relevant ticket, 
but I might very well have missed it.

-- 
John

-- 
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/ff945050-ff4f-4be9-ab73-4dd5bb93303an%40googlegroups.com.

Re: [sage-devel] Re: Issue with orders in number fields

[Nils Bruin]

Hm, interesting. The current code for ZZ.__getitem__ (i.e., ZZ[a]) does 
this:

if isinstance(x, NumberFieldElement_base):
K, _ = parent(x).subfield(x)
return K.order(K.gen())

However, this functionality is also available in K.order:

sage: K.order(a,allow_subfield=True)
Order in Number Field in a with defining polynomial x^4 - 2
sage: K.order(a^2,allow_subfield=True)
Order in Number Field in beta with defining polynomial x^2 - 2*x - 1 with 
beta = -a^2 + 1

so the code could actually just be:
 
 if isinstance(x, NumberFieldElement_base):
return K.order(x,allow_subfield=True)

and then Justin's problem would be solved. It's more economical in that no 
(isomorphic) copy of the field is created. It looks like it does cause 
different problems, though: it looks like K.order wants a standardised 
basis, so:

 sage: K.order(a+1).gens()
(1, a, a^2, a^3)
sage: K.order(a^2+a+1).gens()
(1, 7*a^3 + a, 2*a^3 + a^2, 9*a^3)

So K.order(a) does not need to return an order with a power basis on a. 
Perhaps that's the deeper reason why ZZ[a] does its trickery: certainly one 
would expect an order with power basis on a from that construction.


-- 
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/24916bb3-be70-49fc-a278-1af859a0401fn%40googlegroups.com.

[sage-devel] Re: Issue with orders in number fields

[Nils Bruin]

Hi Justin,

You can see the problem from:

sage: O.ambient()
Number Field in a0 with defining polynomial x^2 - 10 with a0 = a

As you can see, the ambient field of O is not identical to K (which is the 
ambient field of OK). It is a field with an *embedding* into K, though, and 
it happens to be an isomorphism here.

Mathematically, I think sage is right to have some reservation here. If we 
do

sage: K.=NumberField(x^4-2)
sage: OK=K.ring_of_integers()
sage: b=a^2
sage: O=ZZ[b]
sage: O.ambient()
Number Field in a0 with defining polynomial x^2 - 2 with a0 = a^2

I think you see the problem: the field of fractions of ZZ[b] does not need 
to be (and in the above example isn't) equal to the parent of b.

In this case, O wouldn't have a finite index in OK.

For programmatic consistency, we generally avoid programming in "shortcuts" 
based on specific values: while ZZ[a] happens to be an order in the parent 
K of a if a generates it over QQ, we'd generally *not* special case that to 
then create ZZ[a] as an order in K, but still create this separate field 
with generator a0.

It's perhaps inconvenient and pedantic, but I would think this one may even 
still be on the instructive side for having to explain to a student.

On Wednesday, 6 September 2023 at 17:21:12 UTC-7 Justin C. Walker wrote:

> Hi, all,
>
> I think I understand what’s going wrong, but I don’t understand how to fix 
> the following problem:
>
> sage: K.=NumberField(x^2-10)
> sage: OK=K.maximal_order()
> sage: O=ZZ[a]
> sage: a in OK
> True
> sage: a in K
> True
> sage: a in O
> True
> sage: O.index_in(OK)
> ---
> ValueErrorTraceback (most recent call last)
> ...Blooie
> ValueError: other must have the same ambient number field as self.
>
> Have we just painted ourselves into a (figurative) corner?
>
> Pointers?  Suggestions?
>
> Thanks for any help.
>
> Justin
>
> --
> Justin C. Walker, Curmudgeon at Large
> Institute for the Absorption of Federal Funds
> ---
> While creating wives, God promised men
> that good and obedient wives would be
> found in all corners of the world.
> Then He made the earth round.
> --
>
>
>
>
>
>
>
>
>

-- 
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/91b7f3ea-fd89-446e-8a26-3e474414d32cn%40googlegroups.com.

[sage-devel] Re: opinions requested on x + y behaviour for polynomials

[Nils Bruin]

On Saturday, 26 August 2023 at 00:22:39 UTC-7 Frédéric Chapoton wrote:

I propose in https://github.com/sagemath/sage/pull/36138 a sketch of 
changes that would build a common polynomial ring by taking the union of 
variables. This does not break too many things. Instead many doctests 
checking for coercion failure now report coercion success. There are still 
a few problematic things to solve, in particular about infinite polynomials 
rings.

 
I think that creating new parents to satisfy coercion is generally not a 
good idea. It's really a step further than figuring out (canonical) maps 
between "known" parents (that is, the ones that are directly presented in 
the context)
 

Question: what does magma do ?


In magma, variable names are NOT important. They are just for printing. So 
coercion is not led by variable names at all. That means it's generally 
more restrictive in what it can do. It also has a concept of "non-global" 
polynomial rings [the default for multivariate]. So a univariate polynomial 
in one variable cannot be added to a multivariate polynomial in two 
variables; not even between QQ['x'] and QQ['x,y']. So sage is already much 
more permissive. It can do so because generator names are part of the 
identity of a parent and also to some extent because parents are mostly 
globally unique. Both of these properties come with a significant price as 
well (you can't change generator names, or any properties, and you get an 
extra problem that generator names may be repeated in the tower, which you 
now either have to deal with or forbid (which is expensive and inconvenient 
in its own way). 

-- 
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/776ba9ef-d4d0-4d42-91ba-e72f55f58ff5n%40googlegroups.com.

[sage-devel] Re: opinions requested on x + y behaviour for polynomials

[Nils Bruin]

On Saturday, 26 August 2023 at 08:51:26 UTC-7 John H Palmieri wrote:

In principle it seems okay, but to be honest, I don't think I understand 
Sage's polynomial rings. It seems like anything goes:

sage: R. = GF(2)[]
sage: S. = R[]
sage: S
sage: R.0 + S.0
x + x

Why am I allowed to construct S?


Because someone may write a function 

def eigenvectors_over_base_field(M):
f = M.charpoly()
rts = f.roots(multiplicities=False)
V = []
for r in rts:
V.append((M-r).kernel().basis())
return V

The charpoly gets produced in M.base_ring()['x']. If you'd execute this 
code with

k=QQ['x'].fraction_field(); x=k.0
M=matrix([[x,1],[0,x-1]])

and the ring Q('x')['x'] is NOT allowed to exist, you'd get a mysterious 
error. You'd need rather expensive code that analyses the ring construction 
to find the required info to generate a variable name that does not clash. 
And you'd need similarly expensive code to generate the error in the first 
place.

Short version: There are cases where it genuinely doesn't matter what the 
name of a variable is. It seems wrong to have to do hard work to find an 
accepted name for something you'd rather leave unnamed.

-- 
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/693d6873-9123-4bb3-880c-67213b1d705dn%40googlegroups.com.

[sage-devel] Re: WANTED: mathjax3 installation path in your linux distro

[Nils Bruin]

I'm actually having trouble with mathjax on Fedora 38 in the Jupyter 
notebook at the moment. With the system-provided jupyter notebook I'm 
getting really poor typesetting results (it looks like it's just trying to 
approximate typesetting without any specific math fonts). When I run `sage 
--notebook` things are fine. I suspect I could do some analysis and see 
where sage's mathjax lives (and which extension jupyter is using for that) 
and then point my system jupyter at that, but it sounds that would go in 
exactly the opposite direction of where the ticket is going.

Googling a bit leads me to believe this is a wider problem: jupyter seems 
to have decided to ship a stripped-down mathjax to save space and people 
are having trouble convincing it to use a proper mathjax. If your 
investigations lead to instructions on how to do this, I think a lot of 
people will be thankful (quite frankly, I'd hope someone can just package 
mathjax-full as a jupyter extension that people can just install to get 
proper typesetting).

On Monday, 21 August 2023 at 08:19:25 UTC-7 Kwankyu Lee wrote:

> Hi,
>
> Please inform us of the path to mathjax3 installed in your linux platform. 
> Just give a comment at
>
> https://github.com/sagemath/sage/pull/36098#issuecomment-1686421277
>
> 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/5d53939f-1cf8-4fee-9fcc-b39f8cdcafden%40googlegroups.com.

[sage-devel] Re: Python PEP 703: no more Interpreter lock

[Nils Bruin]

On Wednesday, 16 August 2023 at 04:20:21 UTC-4 Thierry Dumont wrote:

With PEP 703, Cpython will move (slowly) to a non GIL implementation, 
allowing true multi-threading. It will take time (-> 3.15) and will be 
optional at the beginning. See: 
https://peps.python.org/pep-0703/ 
Which consequences for the Python part of Sage ? Are there many parts 
which could be multi-threaded ? 


For each library used, we'll need to assess if it can operate in a 
thread-safe way and if it currently is used in a thread-safe way. 

There are some parts that will be fundamentally very hard to make 
multi-threaded: maxima through the ECL binary interface, for instance, will 
probably fundamentally be problematic. The design of maxima is rather 
fundamentally not multi-threaded, but even if you lock maxima to only run 
in one thread, there will be problems to let it operate in a multi-threaded 
process: ECL itself does support multi-threaded operation, but requires 
signal handling control (*particularly* when it's multi-threaded, because 
signals are used to coordinate critical sections garbage collection), so 
currently upon entry of ECL, it swaps the signal handlers and upon exit 
swaps them back. As far as I know, signal handlers are on process level; 
not thread-local. So I don't think we'll be able to allow multiple threads 
safely whenever ECL is entered. Perhaps the ECL people are willing to 
consider developing other designs that are more appropriate for supporting 
ECL as a library (it is "embedded common lisp" after all) in a 
multi-threaded environment or perhaps we can integrate ECL's signal 
handling requirements more closely with those of sagemath so that switching 
the handlers is no longer required.

Note that in sage it is very hard to predict which libraries get invoked 
when running high-level code, because operations may get dispatched 
depending on implementation details of objects (which, for instance, for 
finite fields, may depend on the field size!)

-- 
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/297ca580-2f4e-4436-9d16-221625d9f027n%40googlegroups.com.

[sage-devel] Re: How to use maxima 5.47 with sagemath 10.1 beta?

[Nils Bruin]

On Saturday, 15 July 2023 at 19:23:37 UTC-7 Matthias Koeppe wrote:

On Saturday, July 15, 2023 at 7:05:42 PM UTC-7 Nasser M. Abbasi wrote:

What does a user needs to do to make sagemath 10.1 beta use maxima 5.47? 


To upgrade the Maxima package in Sage, see chapter "Packaging Third-Party 
Code for Sage"
(https://doc.sagemath.org/html/en/developer/packaging.html) in the Sage 
developer manual.


and, a little more specific, packages have their own additional 
instructions as well:

https://github.com/sagemath/sage/blob/1ca4a47dbd7c59f09b4840d66f6ced9edde9686a/build/pkgs/maxima/SPKG.rst

(this file also lives in your local install)

-- 
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/fd877d7d-de01-4205-b492-10e7c404b150n%40googlegroups.com.

[sage-devel] Re: How to use maxima 5.47 with sagemath 10.1 beta?

[Nils Bruin]

On Saturday, 15 July 2023 at 16:10:38 UTC-7 Nasser M. Abbasi wrote:

I see that current beta version of sahemath 10.1 supports maxima 5.47.  It 
says

https://groups.google.com/g/sage-release/c/9kYG2vryie8

"29daacb7579 gh-35707: Make Sage work with maxima 5.47"

So I downloaded sagemath 10.1  beta 6.

I have already installed maxima 5.47 on my system.


Since sage integrates rather closely with maxima, it is rather picky in 
what it can work with. It must be maxima running on ECL and there must be a 
maxima.fas lisp package for ecl (which isn't built in the vanilla maxima 
build). So there are ways in which you can have maxima installed on your 
system that doesn't satisfy the needs of sagemath. I don't know if sage can 
properly detect if the system-provided maxima meets its needs. 

-- 
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/0ad8ce09-1d07-4b3a-9141-672675e7c238n%40googlegroups.com.

[sage-devel] Re: Renaming multivariate polynomial ring objects

[Nils Bruin]

On Sunday, 9 July 2023 at 21:36:38 UTC-7 Kwankyu Lee wrote:


This argument is independent from python/cython distinction. Hence allowing 
renaming only for univariate case (python class) and disallowing for 
multivariate case (cython class) is a bug, which perhaps no one would 
bother to fix.


Yes, indeed. I think it's a bug that the univariate class allows it:

sage: A=QQ['x']
sage: A.rename('Ax')
sage: B=QQ['x']
sage: B.rename('Bx')
sage: A  #this has an unexpected result
Bx
 

-- 
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/21e8c258-d6dd-4d92-bc74-a58190af30f5n%40googlegroups.com.

[sage-devel] Re: Renaming multivariate polynomial ring objects

[Nils Bruin]

On Sunday, 9 July 2023 at 14:48:55 UTC-7 Kwankyu Lee wrote:

sage: P. = PolynomialRing(QQ, 5, order='lex'); P.rename("P")

gives an error.

I wonder if this was an intentional change or there was a regression that 
no one cared. Does any one know what happened?

The P you construct is a cython class and the documentation of P.rename has 
something to say about why rename is not supported by default for those.

Even though P itself is not "UniqueRepresentation", it is the case that 
PolynomialRing produces identical objects when called twice. That means 
that P must be immutable (otherwise changing attributes about P may affect 
other code using an unrelatedly-constructed reference to the same object P. 
Changing the print name for P would be quite a visible change, so should 
not be allowed.

I don't know if the change was intentional, but it should be :-). 

-- 
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/3fc95723-e75a-4985-ad5d-c847f6326835n%40googlegroups.com.

Re: [sage-devel] Memory leak (quite bad)

[Nils Bruin]

On Friday, 7 July 2023 at 07:53:22 UTC-7 Edgar Costa wrote:

I'm okay with a user using 90% of the ram, if that becomes an issue, I can 
always email them or kill their process, but more often than not, until I 
started to use earlyoom is that the memory usage slowly creeps to 100% and 
the culprit process only gets killed by oom or a power cycle.

 
In that case, would you get the desired result by setting the relevant 
ulimit to 90% ? I'm trying to understand what earlyoom offers over the 
quota system that posix offers out of the box.

-- 
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/83c2002f-c1fc-4a99-8b07-cc7d0957bb33n%40googlegroups.com.