Would there be one-to-one correspondence between distribution packages and
features (for modules of sage library)?
For example, for `sage.plot`, would there be one distribution package
`sagemath-plot`?
One-to-one correspondence would make things simpler to understand.
--
You received this me
Hi George
The reason is that you are using a mutable object as a default object, but
it is only instantiated once and then reused. See e.g. here for a longer
explanation:
https://towardsdatascience.com/python-pitfall-mutable-default-arguments-9385e8265422
To briefly give the solution: use ca=None
I am not python expert, but got hurt by passing dictionary as
optional argument.
Session:
In [1]: def f(n,a,ca={}):
...: for i in range(n):
...: ca[i+a]=i+a
...: print(i,"len(cac)",len(ca))
...:
In [2]: f(2,2)
0 len(cac) 1
1 len(cac) 2
In [3]: f(2,4)
0 len(cac) 3
On Wednesday, June 14, 2023 at 5:08:11 PM UTC-7 Dima Pasechnik wrote:
On Wed, Jun 14, 2023 at 7:11 PM Matthias Koeppe
wrote:
>
> We did have sagemath/sage with branches develop and master.
> And you made releases there.
so it wasn't a good idea to rename/duplicate it.
Well, it was the o
On Wed, Jun 14, 2023 at 7:11 PM Matthias Koeppe
wrote:
>
> We did have sagemath/sage with branches develop and master.
> And you made releases there.
well, it's to understand how exactly Zenodo integration broke.
Apparently for them renaming of a repo is not a reason to turn the
integration off,
(index of previous posts: https://github.com/sagemath/sage/issues/29705)
Here I will summarize the *technological constraints of modern Python
packaging* that a design of modularized distributions must respect.
*1. *Two granularities matter for the modularization: The smallest unit is
a Python/
We did have sagemath/sage with branches develop and master.
And you made releases there.
On Wednesday, June 14, 2023 at 10:59:57 AM UTC-7 Dima Pasechnik wrote:
>
>
> On Wed, 14 Jun 2023, 18:52 Matthias Koeppe, wrote:
>
>> On Wednesday, June 14, 2023 at 10:49:14 AM UTC-7 Dima Pasechnik wrote:
>>
On Wed, 14 Jun 2023, 18:52 Matthias Koeppe,
wrote:
> On Wednesday, June 14, 2023 at 10:49:14 AM UTC-7 Dima Pasechnik wrote:
>
> I also don't understand why sage-archive-2023-02-01 repo has releases.
> Was this repo created by some kind of a GitHub-specific clonig process?
>
>
> As it says in its
On Wednesday, June 14, 2023 at 10:49:14 AM UTC-7 Dima Pasechnik wrote:
I also don't understand why sage-archive-2023-02-01 repo has releases.
Was this repo created by some kind of a GitHub-specific clonig process?
As it says in its "About" box: "This repository used to be the user-facing
mirro
The backup repo
https://github.com/sagemath/sage-archive-2023-02-01
apparently threw Zenodo integration off - now
our main repo, sage, is not associated with Zenodo any more, instead
that backup repo is the one associated with Zenodo.
Probably one had to get rid of .zenodo.* f and CITATION.cff file
On Wed, Jun 14, 2023 at 10:15 AM David Roe wrote:
>
> The problem is that Sage doesn't have a specialized type for integers mod N:
> sage: type(M3)
>
More precisely, Sage doesn't have a specialized type for matrices over
integers mod N, for N *large*. For smaller N it does, e.g.,
sage: p=next
The problem is that Sage doesn't have a specialized type for integers mod N:
sage: type(M3)
The best solution would be to create one, but of course that's a lot of
work. Another possibility would be to change the __pow__ method for
integer matrices to not ignore the modulus argument. As a worka
On Wednesday, June 14, 2023 at 8:01:29 AM UTC-7 Tobias Diez wrote:
On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:
- Some # optional annotations reduce the barrier for contributors, by
clearly signaling to developers "it's OK and definitely not your fault if
you don't unders
On Wednesday, June 14, 2023 at 7:53:25 AM UTC-7 Tobias Diez wrote:
On Wednesday, 14 June 2023 at 05:03:21 UTC+8 Matthias Koeppe wrote:
More specifically, when users of a modularized distribution make their
first steps to contributing to it, that's already difficult; and we do not
want to have t
On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:
- Some # optional annotations reduce the barrier for contributors, by
clearly signaling to developers "it's OK and definitely not your fault if
you don't understand this doctest".
To be honest, this sounds like wishful thinki
On Wednesday, 14 June 2023 at 05:03:21 UTC+8 Matthias Koeppe wrote:
More specifically, when users of a modularized distribution make their
first steps to contributing to it, that's already difficult; and we do not
want to have to tell them "if you want to make this contribution, you first
have
pari/gp appears significantly faster:
sage: time M31=M3**n
CPU times: user 11.2 s, sys: 8.11 ms, total: 11.2 s
Wall time: 11.3 s
sage: M3g=gp(M3)
sage: time M32=M3g**n
CPU times: user 617 µs, sys: 2.79 ms, total: 3.41 ms
Wall time: 119 ms
sage: M32==gp(M31)
True
--
You received this message beca
I am computing powers of matrices over the integers,
but will prefer to work over finite fields or finite rings,
first to avoid large integers and second to run faster.
Experimentally powers over the integers are faster than
finite rings and fields.
Can I do something to preserve efficiently and
And as I explained elsewhere, the # optional annotations also improve the
documentation for the benefit of the project.
The persistent optional tag that I suggested in
https://github.com/sagemath/sage/issues/35750#issuecomment-1590606293
would be explicit, visible in documentation, and at
19 matches
Mail list logo
