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. Then one can take L21=0, L22=U22=0, while A12=L11 U12 
>>> >> implies U12=L11^-1 A12. 
>>&g

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

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

[Nils Bruin]

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 also see a 42 month 
window. Where does the 6-9 month difference come from?

I see NEP 29 uses the *anticipated* release date; probably so that as soon 
as a release is planned, it will be clear which python versions will be 
supported by it and that delay won't mean pulling python versions from the 
supported list. [For both Proposal 1 and Proposal 2 it may be a good idea 
to also be explicit about the way the 42 month window is pegged]

Do you anticipate Proposal 1 and 2 to differ in what they use as indicator 
date for the 42 month window?

The main difference between the wordings of the two proposals seems to be: 
"the SageMath project clarifies that it is invalid for a developer to 
demand that we drop support immediately at the stated time". So I think 
that means Proposal 2 explicitly advocates for discussion of each PR that 
drops support, rather than the default date-based accept that Proposal 1 
advocates. Can you elaborate on the advantages of that? Do you anticipate 
that the 42 month window is too short? Particularly with how easy it is 
nowadays with conda to install fresh python versions as a user, is it 
onerous for people to get a new python when they upgrade sage?

 

-- 
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/571efa0d-b0a1-42a7-9e21-d778bbc9e2f0n%40googlegroups.com.

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

[Nils Bruin]

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 summarizes the discussion we had so far. I tried to add all 
points raised as objectively as possible, but could have easily missed some 
arguments and misinterpreted others. So please have a look a the page and 
edit it as you see fit. I propose that major additions or changes to the 
wiki page are first discussed here on the mailing list so that we don't end 
in a edit war.


It looks to me that proposal 1 and proposal 2 in practice would probably 
end up with pretty much the same effect for most of the time, so the 
formulation is mainly important for edge cases and for conflict resolution.

It looks to me proposal 1 still doesn't make it *mandatory* to drop support 
outside of the NEP29-defined version window. It seems to me that it just 
defines when a support-drop PR becomes acceptable to merge, and that such a 
PR would only be issued once someone feels there's a benefit to its merge.

If that interpretation is right, it seems to me that the difference between 
proposal 1 and proposal 2 will only be relevant if there is a PR to drop a 
python version V (outside of the NEP29 window) and there is someone else 
who want to keep support for that version V. With proposal 2 we'd get a 
discussion of the relevant pros and cons. With proposal 1, there'd normally 
not be a discussion at this point: version V is fair game to be dropped. 
There could still be a discussion if someone claims there's an exceptional 
circumstance that warrants deviating from official policy, but that would 
have a much higher bar to clear.

>From the perspective above, Proposal 1 seems more attractive to me than 
Proposal 2, since it avoids extra discussion with what seems a very 
reasonable default policy (the NEP 29 window seems wide enough to me). 
Would it be possible to highlight when Proposal 2 would be beneficial? One 
scenario I can think of is: "the NEP 29 window is sometimes to narrow" 
which I don't have evidence 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/0ed36933-776a-4fc6-9a44-b4e82f5d7f33n%40googlegroups.com.

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

[Nils Bruin]

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 quota be a more sensible thing? 
It's not unusual to set such bounds by default for users on multi-user 
machines. Then the process should just die by itself before your whole 
server becomes unresponsive (if you have many processes making large memory 
demands you could still end up thrashing and triggering oom but that would 
require extreme bad luck or malice)  

-- 
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/73474344-4c96-4231-a63b-1df2dccfb993n%40googlegroups.com.

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

[Nils Bruin]

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 list of edges in the object.
Should we go for this alternative implementation ?


Perhaps useful in considerations: One contributing factor for the extensive 
usage of sort in string representations was the desire to have doctests be 
robust against changes in code, particularly hashes: print order of sets in 
Py2 was very unpredictable and driven by hash values (especially if those 
hash values end up being "id", i.e., basically a memory address).

There is the other one that Py2 started out with a tacit assumption that 
"<" was a total order on all objects, which it of course never was. It did 
mean that "sort" could often be applied to very diverse lists without error 
and with results that were relatively consistent between different runs 
(but not necessarily between different versions).

In Py3, iteration and print order of sets is determined by insertion order. 
Therefore, the string representation of objects tends to not be dependent 
on hash values anymore. Furthermore "<" between different types of objects 
will generally raise an error. Hence, "sort" has become much more 
problematic to be used by default and one of the motivations to use it by 
default in sage has become less relevant.

Hence, in my opinion, routines in sage that give access to a set of objects 
(like edges or vertices) should just return it in the order in which they 
are encountered, leading to an O(n) algorithm. If the application calls for 
a sorted version, the O(n*log n) penalty can be incurred by sorting the 
result. For doctests that need to return the actual result *AS WELL AS* be 
consistent for checking, wrapping in a sorted(..., key=str) would work just 
fine. In general it would be better to test some guaranteed invariants of 
the return value rather than its string representation, though.
 

-- 
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/514dd1b0-f2c5-4d59-847c-1502cfe57938n%40googlegroups.com.

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

[Nils Bruin]

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 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/0deb15ac-839e-40b3-977b-424ce380b70an%40googlegroups.com.

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

[Nils Bruin]

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 the prompts, 
wouldn't you still end up relying on GPT's vague, hallucination-prone 
general memory to come up with a broader interpretation of the context 
provided? It runs a real risk of just generating harder-to-spot errors. 

-- 
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/fbec54a8-e655-44e7-912f-3c3fff4505a5n%40googlegroups.com.

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

[Nils Bruin]

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 
https://groups.google.com/d/msgid/sage-devel/a296960e-fda8-4d50-924e-179ce7934286n%40googlegroups.com.

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

[Nils Bruin]

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 involved here.

-- 
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/57c8457c-311c-420f-855b-ad7b562ec427n%40googlegroups.com.

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

[Nils Bruin]

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 
"False". 

I think this sucks.

 
Pay attention to the instructions: by explicitly specifying "sort = ..." 
you can avoid the warning. Doing so protects your code against the eventual 
change from default "True" to "False". It's correcting an earlier design 
error (vertices may not even be sortable, so defaulting to doing that can 
really be a problem).

-- 
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/a1710359-d2ce-4a9f-87f3-4be4a1c6b296n%40googlegroups.com.

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

[Nils Bruin]

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 
different systems do things differently.


simplify isn't even a mathematically well-defined notion. Different 
computer algebra systems make different choices what transformations they 
attempt. Maxima, from which sagemath still gets a significant amount of its 
symbolic capabilities, doesn't have a "simplify", but instead has several 
"simplify_*" routines that try specific rewrite strategies, focussing on 
particular special function properties. As the documentation and code show, 
presently "simplify" just consists of a round-trip to maxima, so it only 
rewrites expressions to the extent that maxima automatically rewrites 
expressions. That's a very weak kind of "simplification". The documentation 
points to several other routines. simplify_full tries a whole bunch of 
them, including some that may not be valid for all specializations of your 
variables (e.g., (1-x^)2/(1-x) :-> (1+x) )

-- 
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/78b7cc5e-127e-4dc9-b992-bd4d5b5160cen%40googlegroups.com.

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

[Nils Bruin]

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 roots are meant 
exactly, translation of these expressions to sage's internal symbolic 
system and maximalib (where it ends up judging from the ECL error) is 
problematic because neiither has a native object to represent RootOf. So 
these expressions cannot really be handled anyway and simplification is 
unnlikely to do something useful. Better simplify in fricas.

Considering memory errors from large simplification tasks: yes, 
simplification (particularly full simplification) can involve some 
algorithms with very high time and space complexities, so seeing memory 
errors is not surprising by itself.
 

-- 
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/f19fce16-f349-4d80-ba0e-d73251c1cbd8n%40googlegroups.com.

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

[Nils Bruin]

@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 disagreements. 
I hope a moderator steps in to warn you about code of conduct and making 
discussions personal. In the mean time, stepping back and let things cool 
down is probably the better thing to do, since I don't see a positive 
outcome from continuing your current back-and-forth, and it's toxic for 
other people following the thread to be confronted by such discord between 
respected members of the community.

-- 
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/42fb0b3a-3f1c-48de-9a30-377e9dcd41cfn%40googlegroups.com.

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

[Nils Bruin]

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 for this policy at 
https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which 
should hopefully clarify this point.
 
(Dropping support means increasing `python_requires` and removing github 
tests for this old version, i.e. similar to 
https://github.com/sagemath/sage/pull/35404 which is modeled on the PR 
drooping Python 3.7.)


Formulated like this it would seem to me we could needlessly reduce the 
platforms that sage builds on: this suggests that the "drop Python 3.*" PR 
would get merged simply because it's time: in theory we could end up with a 
release where the sole commit is the dropping of support (in practice 
development is way too active for this). I would expect that such a PR 
would only get merged as a dependency of some other PR (that makes a fix, 
enhancement, or upgrades some other component).

I guess another reason might be because we dropped testing on that Python 
version: once we're not testing we wouldn't know when it breaks and only 
reactively upping python_requires after someone reports a failure is 
probably not so nice.

Having a policy that makes clear when such a drop PR is acceptable as a 
prerequisite for merging could save work and discussion. Numpy's schedule 
looks like a reasonable candidate for that.

-- 
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/fb01c984-560a-47cf-af3d-789cb1502342n%40googlegroups.com.

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

[Nils Bruin]

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 has been dropping versions *too soon*. From the discussion here I 
don't get the impression that's the issue.

Rather I get the impression the motivation is the perception that sage is 
presently supporting *too many* versions and that this is holding up 
development because it prevents upgrades and delays fixes because they are 
required to be adapted to be compatible with too many python versions. So 
if the latter is the case, is the proposal "sagemath does not guarantee of 
python versions beyond what is required to comply with NEP 29. No 
particular effort is made to make fixes and upgrades to sagemath work with 
python versions outside the window mandated by NEP 29."

(I doubt anyone is advocating to actively break support for python versions 
outside of the NEP 29 support window. Breakage will happen as-needed)

-- 
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/7765a4bd-9c65-472a-afad-1413cafa9c35n%40googlegroups.com.

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

[Nils Bruin]

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 to see some discussion of the pros 
and cons. Even if those discussions were had elsewhere or prior already, 
when an issue is raised on sage-devel for a general vote, some discussion 
will be required. For synchronous, in-person meetings, Robert's Rules give 
a fairly widely accepted framework for organizing discussion and then 
proceeding to voting and decision. This makes me think we need Robert's 
Rules for online forum democratic discussion and decision making as well, 
but I wasn't able to locate a concise and sensible set of recommendations.

This is certainly not the first voting process that derailed on sage-devel, 
and it tends to happen in roughly the same way every time, and more 
frequently with items that probably looked fairly uncontentious to start 
with but for which it turns out there are some different opinions after 
all. Those need to be heard close to the vote, in a place near the vote.

The vote on transitioning to github was indeed a shining example of one 
where those issues were properly managed. It probably helped that it was 
clear from the start there were strong opinions on either side and that a 
decision had to be made, so that a clear and transparent process was 
required.

I'd say the process for NEP 29 has now become so muddled that it's better 
to start clean: Set a week (is that enough? do we need more?) for 
discussion, then open a thread collecting votes *ONLY* (no comments) for 
another week, count votes -- done.

I think experience has shown we are prone to underestimating the need for 
structure in voting, leading to more work when we don't. Hopefully some 
upfront investment in a reasonable procedure (even if it costs a full two 
weeks!)  leads to faster results with less acrimony than the attempts at 
light-weight, fast and nimble voting procedures that derail.

-- 
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/833d8512-5cb5-4396-8c91-03a5b78e6878n%40googlegroups.com.

[sage-devel] Re: Segmentation Fault

[Nils Bruin]

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:

I*sin(atan2(0,q)*((1/A+1)*A-A-1))*abs(q)^((1/A+1)*A-A-1)+cos(atan2(0,q)*((1/A+1)*A-A-1))*abs(q)^((1/A+1)*A-A-1)

which indeed causes a crash when input directly into sage. More simply:

var("q A")
U=atan2(0,q)*((1/A+1)*A-A-1)
sin(U) #this crashes

It looks like an infinite recursion, so probably the constructor (of sin?) 
tries to do some simplification, which ends up trying to construct the same 
expression again. The traceback implicates Pynac.


On Monday, 29 May 2023 at 13:07:50 UTC-7 dwb...@gmail.com wrote:

> I was shown the following way of getting a segmentation fault in Sage.
>
> sage: var("q A")
> sage: p = A*(1+1/A)-A-1
> sage: (q^p).full_simplify()
>
> This consistently causes a crash. The person who found it was doing some 
> actual work, got a crash, and boiled it down to a minimal example.
>
> Daniel Bump
>

-- 
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/8ad4b6f1-c697-4af1-90eb-f41ec9d4f3a9n%40googlegroups.com.

[sage-devel] Re: Ideals in LaurentPolynomialRing

[Nils Bruin]

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 with an 
indication why you think the performance could be significantly improved. 
That doesn't guarantee someone will work on it but it at least gives them a 
place to start if they want to, including you yourself! You could file it 
as an "enhancement" or even as a "bug" if you can convincingly show it's a 
regression. In the latter case you would probably end up identifying a 
version in which performance was significantly better. A git diff on some 
of the relevant files could then perhaps very quickly show what's happening.



On Monday, 29 May 2023 at 09:07:07 UTC-7 enriqu...@gmail.com wrote:

> Some time ago I had some computations on ideals in Laurent polynomial 
> rings, namely looking for minimal associated primes. Basically, I converted 
> any generator into a polynomial, study the ideal in the polynomial ring, 
> and forget the prime ideals containing monomials. From some time ago, it is 
> much easier since it can be done directly in the ring of Laurent 
> polynomials. 
> Yesterday these computations on an ideal with 80 generators were really 
> slow, but for some reason I checked that if the generators were converted 
> to elements in the associated polynomial ring, and then the ideal in the 
> Laurent polynomial ring is constructed, then those computations were solved 
> really fast. 
> I checked the code but I was not able to isolate the reason. Best, Enrique.
>

-- 
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/653205f9-b420-452a-ae38-4b9f855fce4cn%40googlegroups.com.

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

[Nils Bruin]

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 to build a bleeding-edge sage on an older 
stable distro -- an undertaking unsupported by most projects. Anyone 
bothered by this can of course send us patches that extend 
compatibility to older PARI. The burden of universal support would 
however be transferred from the sage developers to the distros where 
it rightfully lies. 


It may be that the situation about packaging math software has genuinely 
improved; in which case this likely thanks to sage: it took a whole bunch 
of math software, made it so that it could build in a coherently working 
whole, raised the profile to such a level that people with good connections 
to distributions stood up willing to support it as package distributions.

But another problem before was that the different packages would not 
develop in lockstep. Some components might need one specific version of 
prerequisites and others another. So one could run into genuine version 
conflicts. Sagemath was in a position to then resolve to conflict in the 
best way *for sage*. It's not clear to me that distributions, that have to 
serve other interests as well, will be able to do the same. It's also not 
entirely clear to me that distribution maintainers will always be able to 
catch erroneous behaviour due to mismatched components. So that's where 
sage-the-distribution still serves as an insurance policy -- something to 
fall back on when the version requirements make it impossible to run a set 
of packages together on a system-wide distribution.

it may be an option to provide a reference VM/docker image rather than a 
"sage-the-distribution" if that is easier to maintain, but at the moment, 
since we're not providing that, it would be more 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/1a5e37ce-b740-49a1-a7cb-43995c779c18n%40googlegroups.com.

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

[Nils Bruin]

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)')
 hypergeometric((3/2,), (5/2, 3), -1/4*3^2)

You could use the python parser instead, via something like:

 SR(sage_eval(' hypergeometric((3/2,), (5/2, 3), -1/4*3^2)'))

but note that SR will happily define symbols it doesn't know, whereas 
sage_eval will complain:

sage: SR("my_function(var1,var2)")
my_function(var1, var2)
sage: SR(sage_eval("my_function(var1,var2)"))
NameError: name 'my_function' is not defined



On Tuesday, 25 April 2023 at 23:08:02 UTC-7 Nasser M. Abbasi wrote:

> I read integrals from a file. They all are stored as strings.
>
> Then use SR('expression') inside sagemath to convert them to sagemath 
> symbolic  expression before calling integrate.
>
> Some give parsing error. 
>
> Is using SR('expression') not the correct way to convert string to a 
> symbolic expression?
>
> I am using 9.8 on Linux. Here is an example
>
> >sage
> │ SageMath version 9.8, Release Date: 2023-02-11 │
> │ Using Python 3.11.1. Type "help()" for help.   │
>
> sage: hypergeometric((3/2,), (5/2, 3), -1/4*3^2)
> hypergeometric((3/2,), (5/2, 3), -9/4)
>
> You see, there is no error. But now if put the expression inside string 
> and use SR, it gives error:
>
>
> sage: SR('hypergeometric((3/2,), (5/2, 3), -1/4*3^2)')
> ---
> SyntaxError   Traceback (most recent call last)
> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13706, in 
> sage.symbolic.expression.new_Expression()
>   13705 from sage.calculus.calculus import 
> symbolic_expression_from_string
> > 13706 return parent(symbolic_expression_from_string(x))
>   13707 except SyntaxError as err:
>
> File ~/TMP/sage-9.8/src/sage/calculus/calculus.py:2578, in 
> symbolic_expression_from_string(s, syms, accept_sequence, parser)
>2576 parser._callable_constructor().set_names({k[0]: v for k, v in 
> syms.items()
>2577   if _is_function(v)})
> -> 2578 return parse_func(s)
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:556, in 
> sage.misc.parser.Parser.parse_expression()
> 555 
> --> 556 cpdef parse_expression(self, s):
> 557 """
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:568, in 
> sage.misc.parser.Parser.parse_expression()
> 567 cdef Tokenizer tokens = Tokenizer(s)
> --> 568 expr = self.p_expr(tokens)
> 569 if tokens.next() != EOS:
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:792, in 
> sage.misc.parser.Parser.p_expr()
> 791 cdef int op
> --> 792 operand1 = self.p_term(tokens)
> 793 op = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:826, in 
> sage.misc.parser.Parser.p_term()
> 825 cdef int op
> --> 826 operand1 = self.p_factor(tokens)
> 827 op = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:869, in 
> sage.misc.parser.Parser.p_factor()
> 868 tokens.backtrack()
> --> 869 return self.p_power(tokens)
> 870 
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:897, in 
> sage.misc.parser.Parser.p_power()
> 896 """
> --> 897 operand1 = self.p_atom(tokens)
> 898 cdef int token = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:952, in 
> sage.misc.parser.Parser.p_atom()
> 951 func = self.callable_constructor(name)
> --> 952 args, kwds = self.p_args(tokens)
> 953 token = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:989, in 
> sage.misc.parser.Parser.p_args()
> 988 while token == c',':
> --> 989 arg = self.p_arg(tokens)
> 990 if isinstance(arg, tuple):
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:1039, in 
> sage.misc.parser.Parser.p_arg()
>1038 tokens.backtrack()
> -> 1039 return self.p_expr(tokens)
>1040 
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:792, in 
> sage.misc.parser.Parser.p_expr()
> 791 cdef int op
> --> 792 operand1 = self.p_term(tokens)
> 793 op = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:826, in 
> sage.misc.parser.Parser.p_term()
> 825 cdef int op
> --> 826 operand1 = self.p_factor(tokens)
> 827 op = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:869, in 
> sage.misc.parser.Parser.p_factor()
> 868 tokens.backtrack()
> --> 869 return self.p_power(tokens)
> 870 
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:897, in 
> sage.misc.parser.Parser.p_power()
> 896 """
> --> 897 operand1 = self.p_atom(tokens)
> 898 cdef int token = tokens.next()
>
> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:964, in 
> sage.misc.parser.Parser.p_atom()
> 963 if token != c')':
> --> 964 self.parse_error(tokens, "Mismatched parentheses")
> 965 return expr
>
> 

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

[Nils Bruin]

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 can't get what you want at 400 bits. Etc 
etc.


"1.1" doesn't need to be evaluated, it needs to be replaced by "11/10", in 
pre-processing.


That's not going to change by default. There is already a way to spell 
11/10: as "11/10". The present default is to use "1.1" as a designation of 
a floating point literal, with in implied precision derived from the number 
of digits used to write down the mantissa. There are definitely people who 
are happy with that default, so incentive to change it is rather low. In 
fact, I've never heard before the expectation that 1.1 would signify an 
exact quantity and it was always drilled into me that one should write the 
appropriate number of significant digits when writing a decimal fraction, 
to indicate the number of digits that are claimed to be correct. It's 
unfortunate that you're not among the people who are happy with the 
convention used in sagemath (and maple, and maxima, and magma).

It may not be the default, but you can still have it! As referenced before, 
just execute upon startup:

old_RealNumber=RealNumber
def RealNumber(*args, **kwargs):
return QQ(old_RealNumber(*args, **kwargs))

You can place it in a startup file so that it is in force for all your 
subsequent sessions. See: 
https://doc.sagemath.org/html/en/reference/repl/startup.html

-- 
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/9b8e390d-baec-46a0-91da-660f90b4c81en%40googlegroups.com.

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

[Nils Bruin]

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 high precision environment is for doing exact 
computation, I don't mean that it should handling infinite digit strings. I 
mean that the input-output function for such an environment should be 
identical to the input-output function of a hypothetical environment that 
*does* do the full exact computation and then truncates the answer to the 
requested precision.

In other words, a very high precision environment should emulate an 
environment that does the full exact computation and truncates the result 
to finite precision before giving it to the user. And, this emulation 
should be perfect.


Unfortunately, not for a fixed precision. If you're working with 200 bits 
precision, then you cannot express the roots of
x^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too 
close for that.


In that case the environment sees the two roots as having the same value, 
which to 200 bits may be absolutely correct. In that case the environment 
*is* perfectly emulating an exact calculation truncated or rounded to 200 
bits, as it is required to do.

I think your comment here is based on a subtle mistake in thinking about 
the precision parameter. You're thinking of it as the precision of the 
internal calculations in the implementation of the environment. In effect, 
you're assuming a certain kind of implementation, something like a fixed 
grid of binary fractions. But the environment can use any implementation, 
not just that one.


In such a computational model, there is no reason to carry around the 200 
through the computations. In that case you just compute with the objects 
"lazily" and once you want to get 200 digits approximating the number 
you're interested in, you just ask "what is the 200 digit approximation to 
this number". You can then turn around and ask for the 400 digit 
approximation as well and instead of having to start from scratch, the 
system can just continue refining its approximation using the work it's 
already done. This is implemented already. In AlgebraicField for algebraic 
numbers and in RealLazyField for loads of computable transcendental numbers 
too.

The difficult question in computation doesn't tend to be "what is the 200 
digit approximation to this number" it's "are these two quantities obtained 
through different computations actually equal". AlgebraicField and 
RealLazyField try to do that as well (but I suspect with limitations for 
the latter).

What is presently called RealField is fundamentally not that. In the medium 
future, it may well be the case that RealLazyField will feature much more 
prominently in sagemath as a computational model for real numbers, but the 
current implementation is still under quite active development and, while 
usable, not quite ready to be a *default* in sagemath.

Example:

sage: R=RealLazyField()
sage: a=cos(R.pi()/13)
sage: a.numerical_approx(200)
0.97094181742605202715698227629378922724986510573900358858764
sage: a.numerical_approx(400)
0.970941817426052027156982276293789227249865105739003588587644526477041708760006676932574606408384261554438205497500991925
sage: a.numerical_approx(800)
0.97094181742605202715698227629378922724986510573900358858764452647704170876000667693257460640838426155443820549750099192544630484969304641347324930136179166290724598721026150846791024698868142304028116956960541355031116767265861274416574

Once again, someone who's looking for standard scientific computation tools 
and gets confronted with this instead will be very disappointed because 
performance will be way different and generally MUCH slower. So a general 
purpose computer algebra system would need both, as sagemath has. 

-- 
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/ffec5ae8-3500--a8b4-bf2e71bf8bc7n%40googlegroups.com.

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

[Nils Bruin]

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 RealField(prec), or by using .n(prec)).
2. Real literals would land in this field, which would have coercion maps 
from Z and Q so arithmetic would be exact under the hood.
3. Coercion would go to the symbolic ring, so e^1.1 would live in the 
symbolic ring (rather than RealField(53) where it lives now).  For lack of 
annoyance it should probably still print as a 53-bit decimal, but you could 
cast it to RealField(200) and it would give the correct result.  I guess 
other transcendental functions (log, trig) would also land in the symbolics.
4. Live with the performance implications.  As Dima says, you can use RDF 
if you want fast floating point arithmetic.  But it's already the case that 
the symbolic ring is a performance trap for unwary users, and I'm not sure 
it's a good idea encouraging more use of it implicitly.


We don't need to implement something new for this. AlgebraicField() does 
this for algebraic (and hence rational) numbers and RealLazyField tries to 
do this for a reasonable class of computable real numbers. 
AlgebraicRealField is not a reasonable field to use for a default "real 
field" because it misses common transcendental elements. But RealLazyField 
might be. I'm not so sure floating point literals should land in it, 
though, because to me writing a number as a decimal fraction implies it is 
meant as an imprecise quantity (and the number of digits written is an 
indication of how many significant digits it has). I'm pretty sure I'm not 
alone in that expectation, so there is going to be a subset of users who 
would be upset that their floats end up not being floats any more. I don't 
think there are interesting elements in RealLazyField that could be easily 
constructed from a decimal fraction that can't easily be constructed in a 
different way and a lot of basic elements (like 1/3) cannot be constructed 
via decimal fractions, so I don't think using decimal fraction literals for 
RealLazyField elements makes sense. You'd teach people antipatterns that 
will paint them in a corner fairly soon. 

It's certainly reasonable to not call a floating point field "RealField". C 
and python don't even do that: they call such elements floats. I'm less 
sure whether such a RealFloats field should be any less prominent than it 
is now. Plus the whole renaming transition would be super painful.

-- 
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/416a3fc5-5875-4c4a-84a2-4d622be9e4d0n%40googlegroups.com.

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

[Nils Bruin]

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. I 
mean that the input-output function for such an environment should be 
identical to the input-output function of a hypothetical environment that 
*does* do the full exact computation and then truncates the answer to the 
requested precision.

In other words, a very high precision environment should emulate an 
environment that does the full exact computation and truncates the result 
to finite precision before giving it to the user. And, this emulation 
should be perfect.


Unfortunately, not for a fixed precision. If you're working with 200 bits 
precision, then you cannot express the roots of
x^2-3 and x^2-(3+2^-200) as different floating point numbers. They are too 
close for that. If you know that two numbers are roots of polynomials with 
integer coefficients, you can compute a lower bound (in terms of the 
coefficients) on their difference if they are distinct at all. With such a 
bound you can indeed conclude the numbers are equal if their approximations 
to the required accuracy agree. This has been implemented in 
AlgebraicField. So if you're interested in exact arithmetic with algebraic 
numbers you should use that. To some extent these techniques can be 
extended to certain transcendental number as well. This is more 
experimental, but an implementation is available in RealLazyField.

Fixed precision floating point is fundamentally unable to do this: the 
number of real numbers it can represent in the interval [1,2] is bounded 
(by the set precision), whereas that interval contains infinitely many 
rational, algebraic, and transcendental real numbers. So there are pairs of 
numbers in there it won't be able to represent with distinct 
representations.

(of course computers have only finite memory so they can only represent 
finitely many numbers as well, so things like AlgebraicField() will run out 
of memory for some computations. But the bounds floating point sets are 
much more rigid).

-- 
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/6c707636-0c83-4162-a887-8f61f5b36e81n%40googlegroups.com.

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

[Nils Bruin]

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 something like that. This has come up 
before, but would be a painful change to make : 
https://groups.google.com/g/sage-devel/c/ba9u_As3T4s/m/oXNgGozmAQAJ

With modern developments like RealLazyField, eventually sage *may* actually 
have something that actually models computations in the real numbers. If 
you're interested in algebraic numbers you can already have them with 
AlgebraicField() and AlgebraicRealField() -- those actually work pretty 
well. Do be aware that testing equality in such fields may be unexpectedly 
expensive (but since in floats testing for equality is generally 
nonsensical, that's probably still a win).

These things are still rather experimental, though, so probably not quite 
ready to be defaults in SageMath.

Note that "real literals" like "1.1" are not suitable vehicles to enter any 
interesting exact real number anyway: you can';t specify sqrt(2) exactly in 
that way. So you end up writing things like AA(2).sqrt(). Or AA(sqrt(2)) 
(the latter making intermediate use of SR). So I'm not so sure that decimal 
literals would coerce to exact decimal fractions even in a system where a 
"true" real field is available: quick and dirty floating point is 
historically just something that a lot of people expect to be available and 
people might start complaining if arithmetic with 1.1 starts blowing up in 
memory use.

-- 
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/f6ff35d5-f87a-4991-894b-78c3b4f76d17n%40googlegroups.com.

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

[Nils Bruin]

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 WON'T be computing with exact quantities in RealField(200) unless 
your number can be expressed as +- an unsigned 200-bit integer times a 
power of two, so you're very fundamentally using the wrong tool if you're 
interested in exact computation.

If you're interested in exact arithmetic then do so! Go for symbolic in SR 
or go for RealLazyField. The ideas behind RealLazyField come a lot closer 
to what you seem to want: it uses (fast) floating point approximations when 
that allows it to decide what is asked and keeps symbolic relations at hand 
to use when those are required. Of course, bear in mind that not all 
questions are decidable symbolically; much less so by a specific 
implementation.

The main place where I know high-precision computation really finds an 
application is in transcendental computations where, for some reason, you 
know the number comes out algebraic. With very high precision computation 
you can then recognize the algebraic number. See for instance 
https://github.com/nbruin/RiemannTheta.

A baby example:

sage: pi200=RealField(200).pi()
sage: cos(pi200/13).algdep(8)
64*x^6 - 32*x^5 - 80*x^4 + 32*x^3 + 24*x^2 - 6*x - 1

This shows that cos(pi200/13) is remarkably close to satisfying a sextic 
equation with remarkably small coefficients (and the routine found a sextic 
equation even though it was asked to find one of degree at most 8). Doing 
this example with 53 bits of precision does not yield enough bits to 
recover the sextic relation given here.

---
Concerning your literal example: Just write 2*RealField(200)(1.1) and 
you're good to go. You're still not representing 11/5 exactly because 
RealField(200) does not admit an exact representative,  but at least you'll 
have all the bits you can.

By writing RealField(200)(2*1.1) you're forcing python's hand to choose a 
precision, because 2*1.1 is NOT going to be a literal anymore. If you're 
not interested in getting floating point approximations then don't involve 
RealField(200). 

-- 
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/f367a91f-539a-4ab3-8990-0861a470bd5dn%40googlegroups.com.

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

[Nils Bruin]

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 literal" but we don't have that in sage: rational numbers have no 
benefit. By the time you apply a conversion to it (and in this case the 
conversion needs to do something!) it's definitely not a literal any more.

If you want a "real number" 11/10 that has these kinds of exact properties, 
RealLazyField()(11/10) is probably the way to go, but that field will have 
quite a different performance profile than RR does.

-- 
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/d9bbb936-36ad-4466-9852-712236ec46dfn%40googlegroups.com.

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

[Nils Bruin]

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: RealField(200)(RR(1.1))
1.10

You can increase 200 to 1000: the second one gives all zeros (hooray!) 
while the first one gives those extra digits which are exactly 1/(5 * 
2^51).  Both RR(11/10) and RR(1.1) have parent  Real Field with 53 bits of 
precision, where they compare equal, but pushing them into RealField(200) 
gives different results.  And the "better" result (all 0s) somes from the 
input with the literal 1.1, not from the "rational" input 11/10.   To me, 
that is mysterious.  Can someone explain?


That one is surprising to me as well. The mechanism is easy to uncover:

sage: type(RR(1.1))

 
I suspect it's because the literal 1.1 advertises its "default" precision 
as 53 (as you remark) and therefore the coercion system probably concludes 
that for the conversion R(1.1) no further action is required. Hence, the 
same literal is returned with the funny side-effect that you mention.

We can ruin this effect quite easily by specifying the literal in such a 
way that it reports a different parent:

sage: RealField(200)(RR(1.100))
1.100088817841970012523233890533447265625000

and now it occurs with a different "magic intermediate precision"":

sage: RealField(200)(RealField(54)(1.100))
1.10

This is a rather complicated edge case that follows from the way literals 
are implemented. I'm not sure it's worth fixing; especially because the 
edge case is probably caused by the coercion framework: the implementation 
of RealLiteral probably doesn't even get a chance to do something.

One possible fix would be to change the reported parent of a RealLiteral. 
That might have performance consequences.

-- 
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/d5455027-a77e-41dd-b8f5-7503c5eb1f88n%40googlegroups.com.

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

[Nils Bruin]

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 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/f67310d1-0ebe-473e-93da-6fb7f195d4afn%40googlegroups.com.