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

+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

[sage-devel] Re: SingularError in rational_parameterization

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

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

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

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

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

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

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

Re: [sage-devel] Mysterious .sage behavior

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)

[sage-devel] Re: Bug in quadratic_defect

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

[sage-devel] Re: Bug in quadratic_defect

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

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

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

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

+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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11 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 >>> >> perm

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

epend 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.

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

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

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

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

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

: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: >>

[sage-devel] int vs long in cython

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()

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

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

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

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

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

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

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

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

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

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,

[sage-devel] Re: Question about coercion model

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

[sage-devel] Re: Ring of undetermined coefficients

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

[sage-devel] Re: Desparate for help

s, 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) sa

[sage-devel] Re: Desparate for help

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

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

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.

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

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. (

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

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

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

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

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

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

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

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

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

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?

[sage-devel] Name mangling in Cython 3

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

On Thursday, 6 July 2023 at 14:55:35 UTC-7 Matthias Koeppe wrote: I don't think so; I think there is an effective difference of about 6–9 months. Just O(1), of course, but so are the release cadences of OS distributions and major packages. In NEP 29 I see a 42 month window; in Proposal 2 I

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

On Thursday, 6 July 2023 at 09:36:25 UTC-7 Tobias Diez wrote: Thanks David for your suggestions! I've now created a wiki page at https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy that on the one hand clarifies a few questions that were raised before and on the other hand

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

On Wednesday, 5 July 2023 at 08:29:44 UTC-7 Edgar Costa wrote: Hi Gonzalo, I highly recommend using https://github.com/rfjakob/earlyoom instead of waiting for OOM to kick in. Wouldn't setting ulimit with -m (memory) or -v (virtual memory) for the process that is liable to exceed its memory

Re: [sage-devel] Graph([('A','B'),(1,2)]).edges() raises weird traceback

On Wednesday, 5 July 2023 at 21:54:03 UTC-7 David Coudert wrote: The current design choice in `EdgesView` is to sort only when asking for the list of edges, that is when calling `__repr__` if `sort=True`. The alternative is to sort at the initialization of the object and to cache the sorted

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

The leak does not seem to be on the python heap, so Pynac is the next likely candidate (I don't think this code should be hitting maxima_lib) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: Ask about the SageMath codebase using ChatGPT

On Friday, 30 June 2023 at 20:41:51 UTC+2 William Stein wrote: The point is that instead of using GPT's vague memory of what it might have seen, this instead uses the actual Sage source code, and mainly uses GPT to make sense of it. Given that only some select code fragments are included in

Re: [sage-devel] Re: Voting: Block-scoped optional tag and the keyword

I vote for (A) -- 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

[sage-devel] Re: issue with division in fraction field of univ poly

With your data, we get: sage: K=parent(1/D2) sage: r=K(D1) sage: s=K(1/D2) sage: r.numerator().gcd(s.denominator()) 0 and I think that's the zero which leads to the division-by-zero error. Of course, a 0 returned as gcd is just a bug. It doesn't look like the coercion framework is really

Re: [sage-devel] Re: DeprecationWarning on sagecell in Graph([(0,1)]).vertices()

On Monday, 26 June 2023 at 16:30:20 UTC+2 Georgi Guninski wrote: > As of https://github.com/sagemath/sage/issues/22349, this argument must be explicitly specified (unless a "key" is given); otherwise a warning is printed and "sort=True" is used. The default will eventually be changed to

Re: [sage-devel] Re: ECL says: Memory limit reached calling expr.full_simplify()

On Saturday, 24 June 2023 at 05:38:35 UTC+1 Nasser M. Abbasi wrote: I think simplify should have been able to do it? in Mathematica Simplify can and no need to use its FullSimplify which also uses more resources than Simplify. But I understand, simplification is not an easy problem and

Re: [sage-devel] Re: ECL says: Memory limit reached calling expr.full_simplify()

On Friday, 23 June 2023 at 17:28:03 UTC+1 Dima Pasechnik wrote: This looks suboptimal and unclear - there are e.g. several occurrences of rootOf((625*%%E0^4*a ^12+(-125)*%%E0^3*a^9+25*%%E0^2*a^6+(-5)*%%E0*a^3+1)/(625*a^12),%%E0) Apart from parsing problems inherent in not knowing which

Re: [sage-devel] Re: ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

@dima, @matthias : this public forum is not an appropriate venue to discuss personal disagreements. From what you both write I get the impression you actually have a lot of common ground and only a few differences in opinion, but that personalities and discussion styles exaggerate the

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

On Tuesday, 30 May 2023 at 11:13:27 UTC-7 tobia...@gmx.de wrote: that we normally drop support for older versions right after this support window (i.e. also adapt the drop schedule https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've formulated an improved formulation

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

Can we please clearly formulate what the motion is that is being discussed and voted on? As Volker pointed out, NEP 29 guarantees what versions are supported, i.e., it gives a lower bound to what we support. If we are adopting that, it would seem that we are trying to solve a problem that sage

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

On Tuesday, 30 May 2023 at 07:17:17 UTC-7 Dima Pasechnik wrote: While in my "ballot" I added a couple of sentenses, they were meant to rectify the original post requesting the vote. I think it's clear that the vote was called prematurely -- there was clearly a need for people on the forum

[sage-devel] Re: Segmentation Fault

Localized a bit further: var("q A") p = A*(1+1/A)-A-1 V=(q^p)._maxima_().rectform() after this, V._sage_() crashes, and I think it's the same crash as above. Transcribing what V is in maxima, we get:

[sage-devel] Re: Ideals in LaurentPolynomialRing

Dear Enrique, >From what you write I get the impression you may be talking about a regression in performance relative to earlier versions of sage. If you want to make an actionable item out of this, you'll probably have to file a ticket with explicit code on it that can be profiled; preferably

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Thursday, 27 April 2023 at 03:59:22 UTC-7 Michael Orlitzky wrote: It's not the end of the world if users on a distro with old dependencies have to stick to an older version of sage. Ideally, they would be getting sage from their distro in the first place. A problem only arises when you try

[sage-devel] Re: Why SR('expression') fail on some but not others?

I think the problem is that the SR exression parses does not know about python's "(a,b)" tuple notation. If you replace the round brackets with square brackets, it does seem to work; at least for the example you give: sage: SR('hypergeometric([3/2,], [5/2, 3], -1/4*3^2)')

Re: [sage-devel] RealField isn't doing it right

On Tuesday, 18 April 2023 at 14:59:30 UTC-7 aw wrote: On Tuesday, April 18, 2023 at 3:29:03 PM UTC-6 Dima Pasechnik wrote: It is a problem, as e^1.1 cannot be represented exactly, and it is evaluated eagerly. To what precision should it be evaluated? To 200 bits? Then you will complain that you

Re: [sage-devel] RealField isn't doing it right

On Tuesday, 18 April 2023 at 11:33:38 UTC-7 aw wrote: On Monday, April 17, 2023 at 6:24:13 PM UTC-6 Nils Bruin wrote: On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote: If properly implemented, it can emulate exact computation followed by a truncation to finite precision. When I say a very

Re: [sage-devel] RealField isn't doing it right

On Monday, 17 April 2023 at 20:44:36 UTC-7 David Roe wrote: So I think a concrete version of Dima's suggestion would be 1. Implement a new field that stores elements internally as rationals, printing as decimals to some precision (you could get a higher precision by casting explicitly to

Re: [sage-devel] RealField isn't doing it right

On Monday, 17 April 2023 at 16:39:01 UTC-7 aw wrote: If properly implemented, it can emulate exact computation followed by a truncation to finite precision. When I say a very high precision environment is for doing exact computation, I don't mean that it should handling infinite digit strings.

Re: [sage-devel] RealField isn't doing it right

On Monday, 17 April 2023 at 14:58:49 UTC-7 aw wrote: fixing a typo: it should be "exact irrationals like sqrt(2)" Ah, NOW I see what the problem likely is: I think you're misled by the field being called "RealField". So ... yeah ... it's not. It should probably be called RealFloats or

Re: [sage-devel] RealField isn't doing it right

On Monday, 17 April 2023 at 14:12:43 UTC-7 aw wrote: (A), exact vs inexact: The purpose of a very high precision environment like RealField(200) is to compute with exact quantities - some combination of ints, rationals, exact rationals like sqrt(2), or exact transcendentals like pi. But you

Re: [sage-devel] RealField isn't doing it right

On Monday, 17 April 2023 at 05:04:00 UTC-7 Emmanuel Briand wrote: Real literals are created in preparsing and provide a way to allow casting into higher precision rings. Shouldn't RR(11/10) have the same fate? No, because RR(11/10) is not a literal. In principle 11/10 could be a "rational

Re: [sage-devel] RealField isn't doing it right

On Monday, 17 April 2023 at 04:13:51 UTC-7 John Cremona wrote: Even in the light of the detailed explanations already given, I do find it hard to see how these outputs are so different: sage: RealField(200)(RR(11/10)) 1.100088817841970012523233890533447265625000 sage:

[sage-devel] Re: RealField isn't doing it right

On Sunday, 16 April 2023 at 21:42:01 UTC-7 Nils Bruin wrote: old_RealNumber=RealNumber def RealNumber(*args,**kwargs): return QQ(old_RealNumber(*args,**kwargs)) Apologies, typos corrected in code above (note the double star in **kwargs) -- You received this message because you

[sage-devel] Re: RealField isn't doing it right

On Sunday, 16 April 2023 at 19:47:15 UTC-7 aw wrote: Here's what users expect when they type an expression into a higher-precision environment: they expect the answer to be the exact answer, truncated to the precision of that environment. Period. This is not negotiable. There is no latitude

Re: [sage-devel] RealField isn't doing it right

On Sunday, 16 April 2023 at 14:31:43 UTC-7 aw wrote: Awesome, let's talk about floating point semantics. [...] We zero-pad the 1.1 to whatever length is needed to match the other number. Because we see 1.1 as a shorthand for 1.1 (infinitely many zeros) That's the

Re: [sage-devel] RealField isn't doing it right

On Sunday, 16 April 2023 at 04:40:50 UTC-7 Michael Orlitzky wrote: It's reasonable to expect that multiplying by one won't cause a viable alternative to Mathematica et al. to go bonkers. I haven't declared a float variable, and I haven't type-cast anything to float. The expression "0.5" is, a

[sage-devel] Re: RealField isn't doing it right

On Saturday, 15 April 2023 at 14:39:40 UTC-7 aw wrote: Here's one: RealField(200)(2*1.1) 2.20017763568394002504646778106689453125 Let's check the types: type(2) type(1.1) type(2*1.1) The type on that last result gives you a hint that something has changed by

Re: [sage-devel] RealField isn't doing it right

On Saturday, 15 April 2023 at 16:25:27 UTC-7 Michael Orlitzky wrote: sage: A = matrix([[-3, 2, 1 ], : [ 2,-4, 4 ], : [ 1, 2,-5 ]]) sage: B = (2 * 0.5 * A) sage: B == A True sage: B.rank() == A.rank() False I promise you that I know what a floating point number is, and that they

  1   2   3   4   5   6   7   8   9   10   >