[sage-devel] Re: QQbar(-1)^(1/3) != AA(-1)^(1/3)
Dima Pasechnik wrote: > the function 1/n : AA->AA is 1-1 on all AA, and I don't see why this > property should be broken. Mathematically it makes perfect sense as > is. Because the ** operator is part of the coercion system, and AA coerces into QQbar, CC, etc. > In fact, it should also work like this for any real field, not only > AA. I agree that there should be an internal nth root method, but I don't think it can be the same as the standard exponentiation operator without leading to all kinds of inconsistencies. -- Marc -- 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/varoab%24dg5%241%40ciao.gmane.io.
[sage-devel] Re: Error in I.variety(algorithm='msolve', proof=False)
Hi Dima, Dima Pasechnik wrote: > So this is due to "0 < char <= 2**17 and deg != elim.degree()" - added > by you - which does not make sense to me. > Is this "Criterion" no longer applicable? I don't know. This criterion was suggested to me by Mohab after I complained that msolve -P 1 often returned nonsense in small characteristic. (As far as I understand, there is always a tiny probability that the output is incorrect, but at the time and in this case the probability was not small at all.) I know the developers have made many improvements since, but I don't know if this particular issue is solved or not. -- Marc -- 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/v5thjl%249g3%241%40ciao.gmane.io.
[sage-devel] Re: Error in I.variety(algorithm='msolve', proof=False)
'Peter Mueller' via sage-devel wrote: > I guess that in your snippet, you manually typed the `enter` key after > the `cat` command in the console. Hmm, no, there is a newline at the end: ~$ hexdump -c /tmp/tmprcz_zw9l 000 a , b \n 2 \n a ^ 2 + a , \n b ^ 2 010 + b \n 013 -- Marc -- 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/v5rbtt%2411l0%241%40ciao.gmane.io.
[sage-devel] Re: Error in I.variety(algorithm='msolve', proof=False)
'Peter Mueller' via sage-devel wrote: > R. = GF(2)[] > L = [a^2+a, b^2+b] > I = ideal(L) > V = I.variety(algorithm='msolve', proof=False) > > raises a `ValueError: positive-dimensional ideal`, which of course is > nonsense. Exporting the system to an msolve-readable file and using > msolve directly (with the -P 2 flag) returns the correct result. What exact command are you using to run msolve, and what does your input file contain? On my system: ~$ cat /tmp/tmprcz_zw9l a,b 2 a^2+a, b^2+b ~$ msolve -P 2 -f /tmp/tmprcz_zw9l [1, 3, -1, []]: -- Marc -- 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/v5r01d%24t1l%241%40ciao.gmane.io.
[sage-devel] flint/bootstrap.sh on the github CI workers
Hi, At https://github.com/sagemath/sage/pull/35848 I'm trying to make sage build with flint3. It does build on my laptop, but autoreconf seems to behave differently locally and on the CI VMs, and I have no idea why. It would be great if someone with more knowledge of autotools and/or our CI infrastructure could take a look. Thanks, -- Marc -- 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/u7kgjh%24mde%241%40ciao.gmane.io.
[sage-devel] Re: Migration to GitHub complete
Marc Mezzarobba wrote: > Maybe related: search patterns of the form mentions:someone (including > the default filter 'Everything mentioning you') seem to only return > issues created after the migration. ...However, involves:@me seems to work. -- Marc -- 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/trrf2b%24uho%241%40ciao.gmane.io.
[sage-devel] Re: Migration to GitHub complete
Marc Mezzarobba wrote: > Another one (more of a warning to other users actually): apparently > subscriptions to issues have not been migrated; you need to > re-subscribe to issues you are interested in. Maybe related: search patterns of the form mentions:someone (including the default filter 'Everything mentioning you') seem to only return issues created after the migration. ('author:someone' works fine.) -- Marc -- 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/trre3g%24175h%241%40ciao.gmane.io.
[sage-devel] Re: Migration to GitHub complete
Marc Mezzarobba wrote: > A minor point: the PR template still says "we are not accepting pull > requests yet". Another one (more of a warning to other users actually): apparently subscriptions to issues have not been migrated; you need to re-subscribe to issues you are interested in. -- Marc -- 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/trqhcv%2417p3%241%40ciao.gmane.io.
[sage-devel] Re: Migration to GitHub complete
Thank you all for your work! A minor point: the PR template still says "we are not accepting pull requests yet". -- Marc -- 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/trqfvc%2473j%241%40ciao.gmane.io.
[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies
John H Palmieri wrote: > I like the idea of mimicking the trac setup, but moving away from trac > also lets us reconsider parts of the trac interface. I personally do > not find the "Priority" label very helpful, other than whether it's a > blocker or not. What do others think? I agree about the Priority field. I also find the Type and Component fields useless most of the time. (Regarding Component, many of the possible values don't map well IMO to either actual code components or developer interests, but a few do. In any case, I don't think it should be mandatory.) More generally, I see little benefit in trying to stay close to the format of trac tickets. I would just start with a few labels for ticket properties that are widely used now (bug, blocker, maybe a couple of well-defined components...), allow people to create labels and projects as they see fit, and let new conventions emerge. -- Marc Mezzarobba -- 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/tiocsv%24h5c%241%40ciao.gmane.io.
[sage-devel] Re: DISCUSS: move Sage development to Github
Nils Bruin wrote: > Speaking of backups ... do we backup the sage-devel, sage-support news > groups? They are on gmane, and presumably some sage developers have more or less complete archives on their own computers... > In fact, they are sometimes referred to on trac, via > super-opaque URLs. I suppose the "right" way to refer to ML posts would be by Message-Id, but nobody does that, and many people apparently do not understand such references or have no convenient tools to follow them... (I once had someone complain when I used a Message-Id to refer to sage-devel on trac.) -- Marc -- 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/thefq9%2413t8%241%40ciao.gmane.io.
[sage-devel] Re: DISCUSS: move Sage development to Github
John H Palmieri wrote: > You would think that this would be a solved problem: others in the > open source community must have be in the practice of backing up their > GitHub info. The following tools seem fairly complete: - https://github-backup.branchable.com/ (but I'm getting timeouts with it), - https://github.com/josegonzalez/python-github-backup (not tested). IMO we should at the very least have something like that running before making the switch. We should also refrain from using features of github not supported by our backup tool. -- Marc -- 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/th67k9%246eq%241%40ciao.gmane.io.
[sage-devel] Re: is there a convention for _bool_ was: is it intentional that prod does not stop when it hits 0?
Vincent Delecroix wrote: > Though these are specifications for SR and does > not apply to the entire library. It is not clear to me what global > specification we could have for bool(algebraic expression). Something like "bool(x) iff x is not trivially zero" would make sense to me, where "not trivially zero" means "not exactly identical to the most simple representation of zero of the given type". Something that can be used to decide whether a coefficient of a polynomial should be displayed, for instance. (And that is cheap to test.) -- Marc -- 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/tgunmp%2415pl%241%40ciao.gmane.io.
[sage-devel] Re: VOTE: move Sage development to Github
Emmanuel Charpentier wrote: > +1 for Github > > Also wishing for contingency plan for re-migrating to self-hosted > Gitlab. Same here. -- Marc -- 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/tgk2jf%24nm6%241%40ciao.gmane.io.
[sage-devel] Re: Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
William Stein wrote: > Perhaps this is a bad criteria, e.g., > it excludes our webmaster (Harald Schilly), since he's done a lot to > support Sage, but I don't think he's contributed code to the library > -- at least I didn't find him in Dima's list from GitHub. Looks like he has: ~/co/sage:develop$ git log --oneline --author=harald.schi...@gmail.com 36cfcde36d9 cleaned up SPKG.txt and added title and description a27f754d223 1.1.2.p2 - with patch for setup.py from #6456, comment 6 028fffa811b additional changes for 1.1.2 af81ac514c8 cvxopt 1.1.2 with some small modifications, saving older patches in patches-old 850fd55c35b Trac #8094: 8094: basic properties for matrices fc29cd63310 enable sage -upgrade to select a suiteable mirror from the sage mirror network, if url given, it doesn't ask and if url is 'ask', it lets the user decice which mirror to use 933a87c98fa enable sage -upgrade to select a suiteable mirror from the sage mirror network (updated patch) 2558adbd152 6456 changes for the doctested examples in the numerical_sage section for cvxopt 02d3bf34cb5 #9647 trivial example for a MILP in mip.pyx 31caa64efdb 9579 reviewer patch f6cc81447dc add fibonacci graph to graphs.* 36a99e95cb2 R pexpect interface - still needs work -- Marc -- 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/tgecki%247f8%241%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Matthias Koeppe wrote: > This is great question, thanks for the pointer to this GitLab.com URL. > I've updated > https://github.com/sagemath/sage/wiki/Github-vs-Gitlab-vs-trac#in-favor-of-gitlab > based on it. Additionally, here in France at least, many universities and research institutes already host their own (internal or semi-public) gitlab instance. -- Marc -- 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/tg971e%2412pj%241%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Samuel Lelièvre wrote: > a. The company operating GitHub can block access to GitHub, > block account creation, or terminate accounts for individuals, > companies or countries without prior notice on discriminatory > grounds, see links below. > > b. Relying on free software tools for essential infrastructure > is something I value a lot in the Sage project. Trac is that, > GitHub is not. > > c. Several people refuse to open a GitHub account and are > much more comfortable contributing to Sage using a Trac > account on our Trac server. > > d. Moving to GitHub because a lot of software development > has moved there does not seem a relevant argument to me. > > e. Today GitHub exists. Tomorrow it might shut down. > Gitorious, Google Code, Gna!, CodePlex and many others did. > > f. Today GitHub charges no fee to free software projects. > Tomorrow that might change. Remember how Travis CI > was once free for free software projects, then no longer. I largely agree with these points, and, personally, moving to github would not be my first choice. However, the benefits of moving away from trac seem large enough to me that I am more than happy to go with it. And I mean the benefits for myself as a not-so-frequent contributor with absolute zero involvement in maintaining any development infrastructure, even disregarding the opinion of people who actually work on that infrastructure. Moreover, most of your points are arguments against becoming dependent on github, not against using it. It has been mentioned in the thread that migrating from github to gitlab is easy. I think it would be good to ensure that this is true of all the features Sage development depends on; but if that's the case, it seems to me that only (c) and to a lesser extent (b) are serious concerns. -- Marc -- 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/tfv2ri%24mfl%241%40ciao.gmane.io.
[sage-devel] Re: A list of file with deprecation
David Ayotte wrote: > ~/sage$ git describe --contains $(git log --author=rel...@sagemath.org ^^ Could it be that whatever you are using to read sage-devel censors email addresses and that you copy-pasted the censored version of release at sagemath.org? > --grep="^Trac #25848" --pretty='%H') --exclude='*beta*' > --exclude='*rc*' --candidates=0 > fatal: cannot describe '4c9486b75fb02b14a21278bb69e44998c5045ccd' -- Marc Mezzarobba -- 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/tfqdtp%24nq%241%40ciao.gmane.io.
[sage-devel] Re: A list of file with deprecation
David Ayotte wrote: > I have a question: given a trac ticket number, is there a way of > recover the "Merge In" field of the ticket with the command line? I'd > like to automatically add this info to the list. In case they differ, do you want the contents of this field as it appears on trac, or the first sage version that includes the ticket? If the latter, something like git describe --contains $(git log --author=rele...@sagemath.org --grep="^Trac #33607" --pretty='%H') --exclude='*beta*' --exclude='*rc*' --candidates=0 should do the job. -- Marc -- 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/tfqaft%2487g%241%40ciao.gmane.io.
[sage-devel] Re: Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Dima Pasechnik wrote: > this script goes for a simpler route - it writes GitHub logins (or > original trac logins for the cases where there is no match) of users > who commented, etc. into > comments text. This does not need authorisation from users, but it's > arguably less nice looking. Not just less nice looking: it means for instance that you will not be able to search for all tickets/issues you reported both before and after the migration with a single, simple query. Or am I missing something? -- Marc -- 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/tfmhgf%2412cv%241%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Dima Pasechnik wrote: > I've conducted few experiments with a tool to import trac sites to > github: https://github.com/svigerske/trac-to-github, which in > particular allows to import trac tickets as github issues; a result of > running it on few tickets > may be inspected > here: > https://github.com/dimpase/trac_to_gh/issues?q=is%3Aissue+is%3Aclosed > (Here issues 1-10 correspond to trac tickets one to one :-)) Further > work on trac-to-github will be needed, in particular to properly link > branches in our git tree, but it's doable, and we have volunteers to > do it. How hard would it be to import issues in such a way that issues and comments created by people with git**b accounts are correctly linked to their accounts? This would require a way for these people to authorize the migration script to perform specific actions in their name, or to merge their user account with a temporary account created by the script, or something like that. I have no idea how flexible github or gitlab are in that respect. (It would presumably be easy with a self-hosted gitlab, though.) -- Marc -- 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/tfl50h%2481n%241%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Matthias Koeppe wrote: > OK, good point, and I agree. I'll work that into the wiki page. Thanks! -- Marc -- 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/tfij27%2451h%241%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Matthias Koeppe wrote: > No, Issues are not just for bugs, they can also be used for planning > enhancements. Sure; the changes I was suggesting are an oversimplification. But I don't think we should keep with the practice of forcing developers to open a dedicated issue for every proposed change. -- Marc Mezzarobba -- 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/tfiiib%247cn%242%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Matthias Koeppe wrote: > Yes, of course, and that's what I am documenting > at https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b Sorry, apparently I misunderstood your proposal. I would suggest the following changes then: "Instead of opening a Trac ticket" --> "To report a bug, instead of opening a Trac ticket" ""Bug"/"Enhancement" is mapped to "Labels"" --> "No "Bug"/"Enhancement" distinction (use pull requests to submit enhancements)" -- Marc -- 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/tfii1r%247cn%241%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Aram Dermenjian wrote: > In particular, github shows contributions made by a user to > various projects. This is true to some extent (only for commits as opposed to code review or other kinds of contributions, and maybe only for users who have set up their account in a certain way) even when the contributions were not developed on github but simply ended up in a repository mirrored on github. -- Marc Mezzarobba -- 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/tfihjd%24mf9%242%40ciao.gmane.io.
[sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac
Matthias Koeppe wrote: > I've added a draft of a proposed workflow on GitHub with the idea to > just follow the Trac workflow. In my eyes at least, it is a defect of our current workflow that tickets are used for tracking both bugs and proposed enhancements. On git**b, wouldn't it be more natural to use issues for, well, issues (that is, bug reports, as opposed to bug *fixes* or enhancements) and pull requests for proposed changes? -- Marc Mezzarobba -- 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/tfih6s%24mf9%241%40ciao.gmane.io.
[sage-devel] Re: Issue with external packages using Cython
Matthias Koeppe wrote: > See > https://trac.sagemath.org/wiki/ReleaseTours/sage-9.7#sagesage.ringssage.libs...arenowPEP420namespacepackages > and https://trac.sagemath.org/ticket/34221 Thanks a lot! -- Marc -- 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/tdh08d%2414vd%241%40ciao.gmane.io.
[sage-devel] Issue with external packages using Cython
Hi everyone, Some external packages that cimport cython modules from sage no longer build with sage 9.7.beta8. It looks like this is due to some recent change in Sage, as is reportedly works with sage 9.6. Two examples: ~/co/sage:develop$ ./sage -pip install sage-flatsurf Collecting sage-flatsurf Using cached sage_flatsurf-0.4.7-py3-none-any.whl (206 kB) Collecting surface-dynamics Using cached surface_dynamics-0.4.7.tar.gz (8.3 MB) Preparing metadata (setup.py) ... error error: subprocess-exited-with-error × python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [337 lines of output] /home/marc/co/sage/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/Cython/Compiler/Main.py:369: FutureWarning: Cython directive 'language_level' not set, using 2 for now (Py2). This will change in a later release! File: /tmp/pip-install-2fum1bmr/surface-dynamics_04b48bb6529e4830942d5ec0e4b492bb/surface_dynamics/flat_surfaces/origamis/origami_dense.pxd tree = Parsing.p_module(s, pxd, full_module_name) Error compiling Cython file: ... # Otherwise we end up with the strange error # sage: from .origami import Origami # Traceback (most recent call last): # ... # AttributeError: 'module' object has no attribute 'ModuleElementWithMutability' cimport sage.structure.element ^ surface_dynamics/flat_surfaces/origamis/origami_dense.pyx:39:8: 'sage/structure/element.pxd' not found [...] File "/home/marc/co/sage/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1250, in cythonize_one raise CompileError(None, pyx_file) Cython.Compiler.Errors.CompileError: surface_dynamics/flat_surfaces/origamis/origami_dense.pyx Adding extension surface_dynamics.flat_surfaces.origamis.origami_dense: sources = ['origami_dense.pyx', 'normal_form.c', 'lyapunov_exponents.c'] headers = ['origami_dense.pxd', 'lyapunov_exponents.h', 'normal_form.h'] Adding extension surface_dynamics.interval_exchanges.lyapunov_exponents: sources = ['lyapunov_exponents.pyx', 'generalized_permutation.c', 'lin_alg.c', 'quad_cover.c', 'random.c', 'permutation.c'] headers = ['lyapunov_exponents.h'] Adding extension surface_dynamics.interval_exchanges.integer_iet: sources = ['integer_iet.pyx', 'int_iet.c', 'int_vector.c'] headers = ['integer_iet.pxd', 'int_iet.h'] Adding extension surface_dynamics.interval_exchanges.iet_family: sources = ['iet_family.pyx'] headers = [] Compiling surface_dynamics/flat_surfaces/origamis/origami_dense.pyx because it changed. Compiling surface_dynamics/interval_exchanges/lyapunov_exponents.pyx because it changed. Compiling surface_dynamics/interval_exchanges/integer_iet.pyx because it changed. Compiling surface_dynamics/interval_exchanges/iet_family.pyx because it depends on /home/marc/co/sage/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/ppl/ppl_decl.pxd. [1/4] Cythonizing surface_dynamics/flat_surfaces/origamis/origami_dense.pyx [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed × Encountered error while generating package metadata. ╰─> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details. (exit 1) or: ~/co/sage:develop$ ./sage -pip install git+https://github.com/mkauers/ore_algebra.git Collecting git+https://github.com/mkauers/ore_algebra.git Cloning https://github.com/mkauers/ore_algebra.git to /tmp/pip-req-build-r3prw8dd Running command git clone --filter=blob:none --quiet https://github.com/mkauers/ore_algebra.git /tmp/pip-req-build-r3prw8dd Resolved https://github.com/mkauers/ore_algebra.git to commit 47e05a4556c854847f0ed9239fc3e288fde28ab3 Preparing metadata (setup.py) ... error error: subprocess-exited-with-error × python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [1582 lines of output] Error compiling Cython file: ... # Distributed under the terms of the GNU General Public License (GPL) either # version 2, or (at your option) any later version # # http://www.gnu.org/licenses/ from sage.libs.arb.types cimport * ^ src/ore_algebra/analytic/binary_splitting_arb.pyx:16:0: 'sage/libs/arb/types.pxd' not found [...] Cython.Compiler.Errors.CompileError: src/ore_algebra/analytic/binary_splitting_arb.pyx Compiling src/ore_alge
[sage-devel] Re: Sage Dev Prizes
William Stein wrote: > The 3 people who expressed interest in being on the Sage dev prize > committee are me, John Cremona, and Karl-Dieter Crisman. Didn't Samuel Lelièvre also volunteer? -- Marc -- 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/t50svt%24b14%241%40ciao.gmane.io.
[sage-devel] Re: Re: commits
Dima Pasechnik wrote: >> The graph clearly shows that there was a critical point between 2012 >> and 2014. I am curious what were major changes of circumstances >> around then. >> > OpenDreamKit grant, obviously. And the switch to git, I assume. For me at least, the "new" development workflow has made it incomparatively easier to contribute. -- Marc -- 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/sqcfcf%24f2g%241%40ciao.gmane.io.
[sage-devel] sage-devel@sourceforge
sage-de...@lists.sourceforge.net is still receiving new messages--99% spam, but not 100%, see: https://sourceforge.net/p/sage/mailman/sage-devel/ Does anyone have the necessary permissions to shut it down? -- Marc -- 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/rpoe8o%24hp3%241%40ciao.gmane.io.
[sage-devel] Re: Docker images
Dima Pasechnik wrote: > hopefully everything needed to fix docker builds will be merged in the > coming beta. Ok, thank you! -- Marc -- 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/roqq9b%24j5d%241%40ciao.gmane.io.
[sage-devel] Docker images
The most recent Docker image (excluding develop/latest) at https://hub.docker.com/r/sagemath/sagemath/tags corresponds to Sage 9.2.beta3. Is that normal? Thanks, -- Marc -- 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/rop8u9%244ai%241%40ciao.gmane.io.
[sage-devel] Re: "Real Field" -> "Real Floating-point Field"
Nathan Dunfield wrote: > -1: I don't really care what RealField.__repr__ returns, but cast a > token no vote to object to the logical next move of breaking backwards > compatibility by changing the meaning of RealField and/or RR. I see > the need for a "genuine real field", but it seems a lot simpler just > to call it something other than "RealField" and so not break a lot of > existing users' Sage code. I agree. More precisely, I am in favor of changing the string representation so that it contains the word "floating-point". I don't care about the exact wording. However, I think that the drawbacks of changing the meaning of RealField or RR greatly outweigh the benefits (at least now, probably also in the long term, but I might change my mind if a really useful AbstractRealField is ever implemented). To the backward compatibility reasons others have mentioned, I would add that for many people, "real numbers" in a "computational" context *does* mean floating-point numbers! -- Marc -- 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/rmpq0o%24ec8%241%40ciao.gmane.io.
[sage-devel] Re: Mutliprocessing for Matrix Computations?
Michael Jung wrote: > Ah, interesting. Do you have some literature/references for me? Among the standard references, Chapter 5 of *Modern Computer Algebra* by von zur Gathen & Gerhard discusses the basic evaluation-interpolation algorithm for computing the determinant of polynomial matrices in some detail. For more sophisticated methods and recent research on fast exact linear algebra (including both complexity questions and practical speed issues), look at the papers of the people involved in Linbox. -- Marc -- 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/rb5p9c%242hd4%241%40ciao.gmane.io.
[sage-devel] Re: Rounding in Sage
Hi Simon, Simon King wrote: > According to IEEE 754, the default rounding mode for floating-point > operations is "round half to even". However, in examples it seems that > the rounding roule in RR is: "round half away from zero if the total > number of decimal digits in the result is odd and towards zero if the > total number of decimal digits of the result is even I don't think I'm able to provide a complete answer, but here a a few elements. In principle, I think both RR and RDF should comply with IEEE-754 rounding rules (in the case of RDF, provided your platform does). In particular, simply converting a rational number to a certain RealField should (as far as I understand) round it to that field's precision according to that field's rounding mode. However, the examples you posted to sage-support, e.g., sage: round(3.55, ndigits=1) 3.5 sage: round(3.555, ndigits=2) 3.56 test much more than that. First, the round() toplevel function is a huge mess, see #25827 for some observations about it. Second, when you write 3.55, the preparser does not turn that into code that creates a RealNumber. An intermediate type called RealLiteral is used, with its own “features” related to rounding, see in particular #15542. Third, while any binary floating-point number can in principle be represented exactly in decimal, Sage sometimes tries to be clever when displaying floating-point numbers, which can involve rounding them again, see in particular the docstring of RealNumber.str(). Hope this helps... -- Marc -- 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/r6i6ip%242sdn%241%40ciao.gmane.io.
[sage-devel] Re: yanking sage doctests in vim
Simon King wrote: > But when I then go to Sage command line and hit -insert (which > usually inserts what was previously copied), nothing happens (resp. > some text was inserted that I have copied previously). This is with > vim version 8.2.343 > > What am I doing wrong? I don't know. Does y in vim otherwise copy text to the X clipboard? What happens if you try to paste it in vim itself? -- Marc -- 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/r4d6bq%241aac%241%40ciao.gmane.io.
[sage-devel] Re: yanking sage doctests in vim
Sébastien Labbé wrote: > But I am not getting errors, maybe my vim is too old (7.4.1689). I > need to update my machine but I am always postponing this to tomorro Indeed, it looks like I'm using features that appeared with vim 8. -- Marc -- 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/r4aj65%24269c%242%40ciao.gmane.io.
[sage-devel] Re: yanking sage doctests in vim
Simon King wrote: > sorry, I still don't get what *exactly* one needs to do in order to > achieve *what*. My post was intended mainly for vim users who would be able to figure out on their own what the code does and find it useful for their workflow. I didn't realize anyone else might be interested. Sorry about that. > If I understand correctly, repl is abbreviation for > read-eval-print-loop. I guess that' what I call "command line version > of Sage". Yes. > That makes me wonder two things: > - By "copy-pasting doctests to the sage repl", do you mean that you > mark the doctest including the expected output, and when you paste it > to Sage then the expected output is automatically stripped, which is > of course useful because it is Sage's job to compute that output? Yes, except it is stripped at copying time. > - How is vim involved in my interaction with Sage? Do you mean the > following: Open some file in vim that contains doctests, mark a > doctest in vim, then go to the Sage command linel and paste what > you've copied? Yes, or combine that with some other way of sending the content of your clipboard (or X selection, or other vim registers) to a sage command line. -- Marc -- 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/r4aj3p%24269c%241%40ciao.gmane.io.
[sage-devel] Re: yanking sage doctests in vim
Marc Mezzarobba wrote: > vnoremap Y :call YankSageTest(visualmode(), 1)' missing at the end -- Marc -- 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/r45n4l%24ouk%241%40ciao.gmane.io.
[sage-devel] Re: yanking sage doctests in vim
Sébastien Labbé wrote: > Should I understand that it filters out the output? Can you tell how > you use it? It only works linewise, and is mapped to Y, which is probably something like \Y depending on your setup. You can use it either by selecting some text in visual mode and typing \Y, or typing \Y followed by a motion (e.g. \Yap). It will keep the input lines only and strip the sage: and : markers. -- Marc -- 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/r45m4p%2427ml%241%40ciao.gmane.io.
[sage-devel] Confused about ARB_LIBRARY
Is it expected that ARB_LIBRARY is set to 'arb' (as opposed to 'flint-arb') on a Debian box where Sage links against the system arb? The linker complains about not finding -larb when I try to build an external cython module that uses sage.rings.complex_arb. And indeed, it should have looked for -lflint-arb: ~/co/sage:develop$ ldd /home/marc/co/sage/local/lib/python3.7/site- packages/sage/rings/complex_arb.cpython-37m-x86_64-linux-gnu.so | grep arb libflint-arb.so.2 => /lib/x86_64-linux-gnu/libflint-arb.so.2 (0x7fbf0c11b000) My setup.py calls cythonize(..., aliases=sage.env.cython_aliases(). I thought this should be enough to make it resolve the references to ARB_LIBRARY in acb.pxd to the correct library. However, cython_aliases() doesn't return what I'd expect: ~/co/sage:develop$ sage --nodotsage ┌┐ │ SageMath version 9.1.beta7, Release Date: 2020-03-08 │ │ Using Python 3.7.3. Type "help()" for help.│ └┘ ┏┓ ┃ Warning: this is a prerelease version, and it may be unstable. ┃ ┗┛ sage: sage.env.cython_aliases()['ARB_LIBRARY'] 'arb' This is with yesterday's beta. I don't remember seeing this issue before, but I may not have rebuilt this module with every release. Am I doing something wrong, or is this a bug? Thanks a lot, -- Marc -- 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/r45i68%24vp0%241%40ciao.gmane.io.
[sage-devel] yanking sage doctests in vim
Just in case it may be useful to somebody else, here is a vim config snippet for copy-pasting examples and doctests to the sage repl. (Improvements welcome!) function! YankSageTest(type, ...) if a:0 let lines = getline("'<", "'>") else let lines = getline("'[", "']") endif let pattern = '^\s*\(sage\|\.\.\.\.\): ' call filter(lines, {i, l -> l =~ pattern}) call map(lines, {i, l -> substitute(l, pattern, "", "")}) call setreg(v:register, join(lines, "\n"), "l") endfunction nnoremap Y :set opfunc=YankSageTestg@ vnoremap Y :call YankSageTest(visualmode(), 1)https://groups.google.com/d/msgid/sage-devel/r43f7d%24p5d%241%40ciao.gmane.io.
[sage-devel] Re: Re: Should Sage fiddle with .sage file permissions?
Michael Orlitzky wrote: > This is the right way to do it. The user/system already has UMASK set > to something generally acceptable. When you create a sensitive file, > you mask more permission bits, create the file, and then revert the > umask. After that, you leave everything alone. Ok, thank you all for your comments. I implemented a minimal fix at #29093. People who'd like to see a warning issued in some circumstances or whatever are welcome to take over the ticket and make the improvements they find useful :-) -- Marc -- 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/r0palc%242g54%241%40ciao.gmane.io.
[sage-devel] Should Sage fiddle with .sage file permissions?
Hi, I just noticed that Sage unconditionally changes the permissions of the DOT_SAGE directory to rwx--- even after the user manually modified them (sage/misc/misc.py, l. 92ff). It seems to me however that there are perfectly valid reasons to share one's .sage with other users. Worse, Sage crashes if the attempt to set the permissions fails (try chattr +i ~/.sage). Despite some comments in the code, I don't understand how people got to the idea of fiddling with these permissions in the first place, so I'm not sure how to fix the issue. Any opinions? Thanks, -- Marc -- 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/r0msdo%2413j1%241%40ciao.gmane.io.
[sage-devel] Re: Power series do not distinguish between different precisions!
Nils Bruin wrote: > I don't think that for any non-trivial applications generic code is > going to perform properly for both exact and non-exact base rings, but > actually the equality choice that has been made, allows the heuristic > approach: start with very high precision or double the precision a > couple of times and see if results stabilize. This can be extremely > useful in getting some experimental verification of conjectures. I agree that it can be convenient, but I still don't see how you make that work in a system where some other objects have a more rigid notion of equality. The point being that you can't really choose a convention independently for, say, power series and symbolic expressions; things like generic polynomial and matrices need equality to behave roughly the same for both. (The real answer is probably that you need both to distinguish "is certainly nonzero" for "may be nonzero" everywhere, *and* to carefully choose between several "equality" predicates, e.g., "is equal", "is approximately equal", "is formally/syntactically equal". But that's not really an option for Sage.) -- Marc -- 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/r0c70n%241gfq%241%40ciao.gmane.io.
[sage-devel] Re: Coercions of polynomials
Nils Bruin wrote: > I think the only choice (if any) is to match the occurrence of a name > in the smallest ring. > > If your generic code is relying on coercion in a setting where name > matching like this is relevant, I suspect it's almost certainly the > wrong choice. I think we agree. To clarify, what I was trying to say is that (1) Forbidding polynomial ring towers with repeated variables breaks essentially all code that creates polynomial rings for its private use over base rings provided by the caller, even code that doesn't use coercion, say def foo(a): Pol = PolynomialRing(a.parent(), 'x') return Pol([a, 1]).roots() (Everyone in this thread probably agrees on that part.) (2) Disallowing conversions from R to R[x] when R already contains a variable called x doesn't sound great to me either. Indeed, converting constants into polynomials is a pretty common operation, it is quite idiomatic to use parent-call syntax for that, and it may not be obvious on first sight that it could fail in some cases. Whereas I can only think of rather contrived examples where one would write Pol(p) in a situation where ambiguity may occur and expect it to map the variable of the polynomial p to that of the ring Pol. (Not only the pitfall is more evident, but also there are often other natural tools to do the job, e.g. change_ring() methods.) -- Marc -- 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/r0c64n%243c3s%241%40ciao.gmane.io.
[sage-devel] Re: Coercions of polynomials
[re-posting a reply from a week ago that apparently did not go through because of the gmane move] David Roe wrote: >> So one thing I thought of that could be a problem is this: >> >> ZZ['x'] --> ZZ['x,y']['x'] >> >> or more generally anytime there are repeated variable names. >> Actually, in this case, I feel the default should be to go into the >> base ring rather than the final ring, but another option would be to >> just error out and say it is ambiguous. > > I think an error is best. Users can always use lists if they really > want to do something like this. Since we have no real mechanism for creating fresh indeterminates, raising and error here would really complicate code written for univariate polynomial rings over generic base rings. -- Marc -- 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/r09hle%24poi%241%40ciao.gmane.io.
[sage-devel] Re: Power series do not distinguish between different precisions!
[re-posting a reply from a week ago that apparently did not go through because gmane was moving] Nils Bruin wrote: > This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns > true, as one would expect mathematically. Do you mean it has the advantage that cos(sin(tan(t^2)) - tan(sin(t^2))) == 1 returns True, as one would expect mathematically? ;-) Joking aside, if I hadn't be hit by that issue before, I would also expect to be able to trust equality more than that. And I would interpret the presence of an explicit O() term as a strong indication that inexact series won't be considered equal to anything. Perhaps more importantly, I find the fact that series and p-adics (but not intervals and balls) are doing that problematic for writing generic code. Suppose that a is a symbolic expression, or an element of any other parent where inequality is not decidable. Would you expect a.is_zero() to return True whenever Sage is unable to prove that a is nonzero? If not, what can code written for generic coefficient rings do to work with both expressions and series? Regarding power series in particular, the structure where cos(sin(tan(t^2)) - tan(sin(t^2))) == 1 exists and makes perfect sense, but it's the ring of polynomials mod t^20, not the ring of power series with precision 20. -- Marc -- 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/r09gso%2430f0%241%40ciao.gmane.io.
[sage-devel] Re: Significant slowdown of basic arithmetic
Marc Mezzarobba wrote: >> sage: def f(): >> : for i in [x]range(1): >> : a+a > > where a = Integer(1). > > If a is made local to the function, the very expensive lookups > disappear, and we still see calls to PyLong_FromLong taking much > longer than PyInt_FromLong, as Vincent suspected. ...But these seem to come from the loop indices. And indeed: sage: def f(): : a = Integer(1) : for i in range(1): : a+a sage: %time f() # py3 CPU times: user 5.58 s, sys: 0 ns, total: 5.58 s Wall time: 5.58 s sage: import itertools sage: def f(): : a = Integer(1) : for i in itertools.repeat(1, 1): : a+a sage: %time f() # py3 CPU times: user 3.7 s, sys: 3.92 ms, total: 3.71 s Wall time: 3.71 s sage: %time f() # py2 CPU times: user 4.83 s, sys: 3.92 ms, total: 4.83 s Wall time: 4.83 s But then I don't understand why the empty loop ran faster under py3... But I also no longer manage to reproduce that observation. So maybe what one observes with that particular example is just that range() has got slower with the int/long merge? I'd be surprised, however, if this explained a 10% slowdown in so many things. -- Marc -- 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/qregn6%24753%241%40blaine.gmane.org.
[sage-devel] Re: Significant slowdown of basic arithmetic
Marc Mezzarobba wrote: > Some profiling data (via linux-perf) for > > sage: def f(): > : for i in [x]range(1): > : a+a where a = Integer(1). If a is made local to the function, the very expensive lookups disappear, and we still see calls to PyLong_FromLong taking much longer than PyInt_FromLong, as Vincent suspected. However, I don't understand why PyLong_FromLong needs to be called at all here. - 79,71% 0,00% python2 libpython2.7.so.1.0 [.] builtin_eval builtin_eval PyEval_EvalCode PyEval_EvalCodeEx PyEval_EvalFrameEx call_function (inlined) fast_function (inlined) - PyEval_EvalFrameEx + 19,47% PyNumber_Add + 4,23% __pyx_f_4sage_5rings_7integer_fast_tp_dealloc - 2,19% PyInt_FromLong PyInt_FromLong 1,65% rangeiter_next 1,12% PyInt_FromLong@plt 0,67% 0x7fde644a906 - 77,70% 0,00% python3 libpython3.7m.so.1.0 [.] builtin_eval builtin_eval builtin_eval_impl (inlined) PyEval_EvalCode PyEval_EvalCodeEx _PyEval_EvalCodeWithName _PyEval_EvalFrameDefault call_function (inlined) function_code_fastcall - _PyEval_EvalFrameDefault + 15,77% PyNumber_Add - 13,30% PyLong_FromLong + 10,01% _PyLong_New 0,63% _PyLong_New@plt + 8,37% _PyObject_Free + 2,70% __pyx_f_4sage_5rings_7integer_fast_tp_dealloc 1,20% rangeiter_next 0,83% PyLong_FromLong@plt 0,83% PyNumber_Add@plt -- Marc -- 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/qrde2u%242uk%241%40blaine.gmane.org.
[sage-devel] Re: Significant slowdown of basic arithmetic
Some profiling data (via linux-perf) for sage: def f(): : for i in [x]range(1): : a+a Py2: Samples: 26K of event 'cycles', Event count (approx.): 17630706503 Children Self Command Shared ObjectSymbol + 77,85%47,79% python2 libpython2.7.so.1.0 [.] PyEval_EvalFrameEx + 75,42% 0,00% python2 libpython2.7.so.1.0 [.] PyEval_EvalCodeEx + 75,42% 0,00% python2 libpython2.7.so.1.0 [.] call_function (inlined) + 75,42% 0,00% python2 libpython2.7.so.1.0 [.] fast_function (inlined) + 75,39% 0,00% python2 libpython2.7.so.1.0 [.] PyObject_Call + 75,38% 0,00% python2 libpython2.7.so.1.0 [.] PyEval_EvalCode + 75,38% 0,00% python2 libpython2.7.so.1.0 [.] Py_Main + 75,38% 0,00% python2 libpython2.7.so.1.0 [.] PyRun_SimpleFileExFlags + 75,38% 0,00% python2 libpython2.7.so.1.0 [.] PyRun_FileExFlags + 75,38% 0,00% python2 libpython2.7.so.1.0 [.] run_mod (inlined) + 75,38% 0,00% python2 libpython2.7.so.1.0 [.] function_call + 75,37% 0,00% python2 python2.7[.] _start + 75,37% 0,00% python2 libc-2.29.so [.] 0x7fde64129bba + 75,34% 0,00% python2 libpython2.7.so.1.0 [.] exec_statement (inlined) + 75,34% 0,00% python2 libpython2.7.so.1.0 [.] ext_do_call (inlined) - 75,33% 0,00% python2 libpython2.7.so.1.0 [.] builtin_eval builtin_eval PyEval_EvalCode PyEval_EvalCodeEx PyEval_EvalFrameEx call_function (inlined) fast_function (inlined) - PyEval_EvalFrameEx + 15,44% PyNumber_Add 6,93% lookdict <--- + 2,28% __pyx_f_4sage_5rings_7integer_fast_tp_dealloc - 1,82% PyInt_FromLong <--- PyInt_FromLong 0,91% rangeiter_next 0,82% PyInt_FromLong@plt 0,66% 0x7fde644a9060 0,61% PyThread_acquire_lock + 17,25% 6,03% python2 libpython2.7.so.1.0 [.] binary_op1 + 16,84% 1,76% python2 libpython2.7.so.1.0 [.] PyNumber_Add + 15,05% 5,02% python2 integer.so [.] __pyx_pw_4sage_5rings_7integer_7Integer_63__add__ + 13,43%13,43% python2 libpython2.7.so.1.0 [.] lookdict + 12,52% 0,00% python2 integer.so [.] __pyx_pf_4sage_5rings_7integer_7Integer_62__add__ (inlined) +9,98% 9,56% python2 libgmp.so.23.0.3 [.] __gmpz_add +6,01% 0,00% python2 anon [.] 0x7fde62ec9d3f +3,70% 3,70% python2 integer.so [.] __pyx_f_4sage_5rings_7integer_fast_tp_dealloc +3,29% 0,00% python2 integer.so [.] __pyx_f_4sage_3ext_7stdsage_PY_NEW (inlined) +3,10% 3,10% python2 integer.so [.] __pyx_f_4sage_5rings_7integer_fast_tp_new +3,09% 0,00% python2 [unknown][k] 0x +2,96% 0,00% python2 libgmp.so.23.0.3 [.] __gmpn_add (inlined) Py3: Samples: 39K of event 'cycles', Event count (approx.): 26191091752 Children Self Command Shared Object Symbol + 79,05%24,87% python3 libpython3.7m.so.1.0 [.] _PyEval_EvalFrameDefault + 78,13% 0,00% python3 [unknown] [.] 0x + 77,94% 0,00% python3 libpython3.7m.so.1.0 [.] _PyEval_EvalCodeWithName + 77,94% 0,00% python3 libpython3.7m.so.1.0 [.] call_function (inlined) + 77,94% 0,00% python3 libpython3.7m.so.1.0 [.] function_code_fastcall + 77,94% 0,00% python3 libpython3.7m.so.1.0 [.] _PyFunction_FastCallKeywords + 77,89% 0,00% python3 libpython3.7m.so.1.0 [.] PyEval_EvalCodeEx + 77,89% 0,00% python3 libpython3.7m.so.1.0 [.] PyEval_EvalCode + 77,89% 0,00% python3 libpython3.7m.so.1.0 [.] _PyMethodDef_RawFastCallKeywords + 77,88% 0,00% python3 libpython3.7m.so.1.0 [.] _PyFunction_FastCallDict + 77,86% 0,00% python3 libpython3.7m.so.1.0 [.] _PyObject_Call_Prepend + 77,85% 0,00% python3 libpython3.7m.so.1.0 [.] _PyCFunction_FastCallKeywords + 77,85% 0,00% python3 libpython3.7m.so.1.0 [.] PyObject_Call + 77,84% 0,00% python3 libpython3.7m.so.1.0 [.] do_call_core (inlined) + 77,84% 0,00% python3 libpython3.7m.so.1.0 [.] builtin_exec + 77,84% 0,00% python3 libpython3.7m.so.1.0 [.] builtin_exec_impl (inlined) - 77,83% 0,00% python3 libpython3.7m.so.1.0 [.] builtin_eval builtin_eval builtin_eval_impl (inlined) PyEval_EvalCode PyEval_EvalCodeEx _PyEval_EvalCodeWithName _PyEval_EvalFrameDefault call_function (inlined) function_code_fastcall -
[sage-devel] Re: Significant slowdown of basic arithmetic
Vincent Delecroix wrote: > Then I guess the reason of the slowdown comes from the change in > the integer types in Python 3 and the way we handle the conversion > from Python integers to Sage integers This may be part of it, but I don't think it explains everything: sage: a = 1 sage: %timeit a+a The slowest run took 103.92 times longer than the fastest. This could mean that an intermediate result is being cached. 1000 loops, best of 3: 57.4 ns per loop vs sage: %timeit a+a The slowest run took 93.42 times longer than the fastest. This could mean that an intermediate result is being cached. 1000 loops, best of 5: 65.1 ns per loop -- Marc -- 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/qrdbq5%24383n%241%40blaine.gmane.org.
[sage-devel] Re: Significant slowdown of basic arithmetic
Vincent Delecroix wrote: > @Marc: could you perform some C profiling (it might work directly > inside Sage via %crun [2]). Yes, I'll try to investigate a bit more, but I first wanted to ask if it was a known issue. -- Marc -- 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/qrc0cb%2459ka%241%40blaine.gmane.org.
[sage-devel] Significant slowdown of basic arithmetic
Something like object creation, memory allocation, basic arithmetic, or cython calls seems to have become a lot slower recently. Overall, my Python code using sage runs about 10% slower with 9.0.beta6 than with 8.9. The slowdown seems to be spread evenly across many different functions. But here is a simple example that shows a significant difference: # 8.9 sage: def f(): : a = 0 : for i in xrange(10^7): : a += 1 sage: %time f() CPU times: user 1.27 s, sys: 3 ms, total: 1.28 s Wall time: 1.27 s # 9.0.beta6 sage: def f(): : a = 0 : for i in range(10^7): : a += 1 sage: %time f() CPU times: user 1.71 s, sys: 0 ns, total: 1.71 s Wall time: 1.7 s Note that a similar function running an empty loop is quite a bit *faster* with 9.0.beta6 (as one may have expected with the Python upgrade): ~260 ms vs ~300 ms. Also, sage: %time a = 3**(2**30+1) and other computations using GMP with no back-and-forth with Python run at the same speed with both versions, so GMP/MPIR versions or build options are probably not to blame. Any clue what is going on? -- Marc -- 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/qrbugi%241h5h%241%40blaine.gmane.org.
[sage-devel] Static libraries
Hi, Maybe a stupid question, but: does Sage really need to build all these static libraries? Why? 456M./local/lib/libgiac.a 144M./local/lib/libec.a 120M./local/lib/libppl_c.a 107M./local/lib/libpari.a 69M ./local/lib/libppl.a 48M ./local/lib/libsymmetrica.a 31M ./local/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.a 24M ./local/lib/libgsl.a 16M ./local/lib/python2.7/config/libpython2.7.a 16M ./local/lib/libsqlite3.a 16M ./local/lib/libfplll.a 7,7M./local/lib/ecl-16.1.2/libcmp.a 7,5M./local/lib/libbraiding.a 5,9M./local/lib/libSingular.a 5,4M./local/lib/libyasm.a 4,5M./local/lib/ecl-16.1.2/libasdf.a 3,7M./local/lib/libfactory.a 3,1M./local/lib/libecm.a 2,3M./local/libexec/singular/MOD/gfanlib.a 2,2M./local/lib/libpolys.a 2,2M./local/lib/libgslcblas.a 1,6M./local/lib/libgfan.a 1,6M./local/lib/libgc.a 1,6M./local/lib/libcddgmp.a 1,1M./local/lib/libiml.a 1,1M./local/lib/libgd.a 900K./local/lib/libplanarity.a 880K./local/lib/ecl-16.1.2/libdefsystem.a 796K./local/lib/libcdd.a 564K./local/lib/ecl-16.1.2/libdeflate.a 536K./local/lib/libgivaro.a 472K./local/share/gap/pkg/SmallGrp-1.3/small8/sml1536.a 448K./local/lib/ecl-16.1.2/libsockets.a 372K./local/share/gap/pkg/SmallGrp-1.3/small6/sml1152.a 364K./local/share/gap/pkg/SmallGrp-1.3/small6/sml1920.a 344K./local/lib/python2.7/site-packages/numpy/core/lib/libnpymath.a 320K./local/lib/libomalloc.a 292K./local/lib/liblrcalc.a 232K./local/lib/ecl-16.1.2/libecl-help.a 204K./local/libexec/singular/MOD/gitfan.a 200K./local/share/gap/pkg/SmallGrp-1.3/small7/sml512.a 200K./local/lib/ecl-16.1.2/libprofile.a 184K./local/lib/ecl-16.1.2/librt.a 180K./local/lib/libcord.a 176K./local/lib/libratpoints.a 172K./local/lib/libhomfly.a 172K./local/lib/ecl-16.1.2/libecl-cdb.a 168K./local/libexec/singular/MOD/cohomo.a 140K./local/lib/ecl-16.1.2/libecl-curl.a 132K./local/lib/ecl-16.1.2/libserve-event.a 132K./local/lib/ecl-16.1.2/libql-minitar.a 124K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1728.a 124K./local/libexec/singular/MOD/Order.a 120K./local/share/gap/pkg/SmallGrp-1.3/small2/sml896.a 116K./local/share/gap/pkg/SmallGrp-1.3/small2/sml640.a 116K./local/libexec/singular/MOD/syzextra.a 112K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1600.a 112K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1344.a 108K./local/share/gap/pkg/SmallGrp-1.3/small2/sml960.a 104K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1440.a 100K./local/share/gap/pkg/SmallGrp-1.3/small5/sml1944.a 100K./local/share/gap/pkg/SmallGrp-1.3/small2/sml384.a 96K ./local/share/gap/pkg/SmallGrp-1.3/small5/sml1296.a 96K ./local/share/gap/pkg/SmallGrp-1.3/small2/sml576.a 96K ./local/share/gap/pkg/SmallGrp-1.3/small2/sml256.a 96K ./local/lib/ecl-16.1.2/libecl-quicklisp.a 92K ./local/share/gap/pkg/SmallGrp-1.3/small2/sml864.a 72K ./local/share/gap/pkg/SmallGrp-1.3/small3/sml768.a 72K ./local/lib/ecl-16.1.2/libsb-bsd-sockets.a 64K ./local/libexec/singular/MOD/pyobject.a 44K ./local/libexec/singular/MOD/interval.a 32K ./local/lib/libatomic_ops_gpl.a 28K ./local/lib/libsingular_resources.a 24K ./local/lib/librw.a 24K ./local/lib/libatomic_ops.a 16K ./local/share/gap/pkg/SmallGrp-1.3/id3/id768.a 12K ./local/share/gap/pkg/SmallGrp-1.3/id5/id1344.a 12K ./local/libexec/singular/MOD/python_module.a 12K ./local/libexec/singular/MOD/bigintm.a 8,0K./local/share/gap/pkg/SmallGrp-1.3/id2/id832.a 8,0K./local/share/gap/pkg/SmallGrp-1.3/id2/id800.a 8,0K./local/share/gap/pkg/SmallGrp-1.3/id2/id576.a 8,0K./local/libexec/singular/MOD/customstd.a 4,0K./local/share/gap/pkg/SmallGrp-1.3/id10/id46620.a 4,0K./local/share/cliquer/testcase-small.a 4,0K./local/libexec/singular/MOD/singmathic.a 4,0K./local/libexec/singular/MOD/polymake.a -- Marc -- 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/qnniir%2426je%241%40blaine.gmane.org.
[sage-devel] Re: Automatic Differentiation - Taylor Arithmetics
Nisoli Isaia wrote: > I've seen that you wrote a sage interface for sollya, which > seems to take already take care of Taylor models. Indeed, though the Taylor models in Sollya may be a bit limited, and (if I understood right, but I'm really no expert here) have some performance issues. > Is Sollya already a part of Sage? > Are there any plans of Sollya entering sage? No. This doesn't prevent you from writing Python/Cython code that uses both Sage and Sollya, of course, but I think such code would take quite a bit of effort to include in Sage itself. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qboil2%2458lt%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Automatic Differentiation - Taylor Arithmetics
Nisoli Isaia wrote: > P.=CBF[] > x._sin_series(4) Indeed, I remembered wrong. Only a few of these arb functions are accessible from sage at this point. It is trivial to add more, though. The relevant files are src/sage/libs/arb/acb_poly.pxd src/sage/rings/polynomial/polynomial_complex_arb.pyx Also, contrary to what I said, we only have an implementation based on arb for the case of complex coefficients. Again, it wouldn't be hard (but maybe a bit tedious) to implement real polynomials on the same model. Sorry for the incorrect information! -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Automatic Differentiation - Taylor Arithmetics
Nisoli Isaia wrote: > I was planning in doing a Cython implementation of Forward automatic > differentiation and > Taylor arithmetics as in > https://press.princeton.edu/titles/9488.html > to use to implement a library for Sage with rigorous quadrature and > integration of ODE. This is very interesting! > I'm trying to understand which parent class could be the best for > these objects for them > to be compatible with Sage coercion model. I think the most natural thing to do would be to implement new parents similar to the rings of power series, but which would additionally track bounds on the truncation errors. Some refactoring in the implementations of polynomials and power series may be necessary to make it possible to share code when that makes sense. Note that in the case of a single variable, Sage already has very efficient code for arithmetic on real and complex interval Taylor series based on Arb. The available operations include composition of arbitrary series as well as a number of specialized routines for composing with elementary and special functions ("intrinsics" in Taylor model parlance). See the methods *_trunc and _*_series of polynomials over RBF and CBF. Arb provides a lot more functions of this kind that are not yet exposed by Sage. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: running sage in texmacs
Gabriel Frieden wrote: > I'm trying to run sage from TeXmacs, and I followed the instructions > here: https://wiki.sagemath.org/TeXmacs. When I click on Insert --> > Session --> SAGE, I get the message "Busy..." where it should give the > version information, above the input line with "Sage]." I can type in > the input line, but I can't execute anything. Any suggestions for how > to fix this? Is tm_sage in your $PATH? Does TeXmacs say anything on its standard error output? -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Deleting old upstream branches
Erik Bray wrote: > Personally I'm hesitant to touch that just because I don't want to go > deleting *anyone*'s branches that aren't my own. FWIW, I've been deleting my old branches as well as some old public branches I had worked on for years now, and I don't think anyone ever complained. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Rational functions
Hello everyone, Please allow me to advertise a couple of tickets currently waiting to be reviewed that deal with fraction field elements, and in particular rational fractions in several variables: https://trac.sagemath.org/ticket/25290 https://trac.sagemath.org/ticket/23909 https://trac.sagemath.org/ticket/16268 https://trac.sagemath.org/ticket/25318 (The patchbot appears to be broken right now, but with all four branches at once and no optional package installed, make ptestlong passes.) At least for some applications I'm interested in, these tickets bring Sage fraction field elements from "so slow they are unusable" to "not really great yet but reasonable". For example, this is with sage 8.3.beta5: sage: P. = QQ[] : Q. = Frac(P)[] : mat = matrix(3, 3, lambda i, j: (x+i*y+1)^j/(j*x*y+i)^(i+j)) : %time mat.det() CPU times: user 9.23 s, sys: 0 ns, total: 9.23 s Wall time: 9.23 s and this is what happens with all four branches merged in: sage: P. = QQ[] : Q. = Frac(P)[] : mat = matrix(3, 3, lambda i, j: (x+i*y+1)^j/(j*x*y+i)^(i+j)) : %time mat.det() CPU times: user 38.6 ms, sys: 238 µs, total: 38.9 ms Wall time: 37.2 ms (This example turned out to be a bit extreme, although I didn't choose it on purpose. But I'm observing speedups of ×5 to ×10 on real applications involving operations with rational fractions.) -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: divisions
Travis Scrimshaw wrote: >> I agree that having x^-1 and 1/x being different is confusing. I will >> update the branch at #25524 to make them identically return a >> rational fraction. > > I think this is even worse than the confusion. I agree with that. >> Though, close to what Nils talked about, there is no straight >> method for "internal division or raise error". > > I thought inverse_of_unit() did this? Only in the case of 1/b, not for general a/b... -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: divisions
Travis Scrimshaw wrote: > A casual user will almost certainly do > > 1 / x^k > > and then try to do a method on Laurent polynomials (say, iterate over > such element). The rational functions code does not have many of the > methods and features that Laurent polynomials have. Yes, but is that really a problem? In many cases, the sooner you realize you missed a subtle point, the better... Incidentally, couldn't we alleviate all these issues with parents by printing the (abbreviated name of) the parent by default when printing an Element as the result of a command in the REPL? I'm thinking of something like sage: 1 + 1 2 : ZZ sage: 2/1 2 : QQ sage: sage: Pol. = QQ[] sage: x + 1 x + 1 : QQ[x] and so on. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: ceil or ceiling?
John Cremona wrote: > I hope it is not being suggested that we have to add tangent() as an > alias to tan(), logoarithm() as an alias to log(), etc etc etc I made the comparison with acos() because ceil() clearly is the usual notation for me (I didn't know of any language or library calling it ceiling() before the mention of Mathematica in this thread), yet I agree that it is not 100% standard--like with acos() vs arccos(). Personally, I'd vote for keeping ceil(), and not adding any alias. But Sage does have both acos() and arccos()... -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: ceil or ceiling?
Kwankyu Lee wrote: > I guess, one principle in Sage is to use the full name unless an > abbreviated form is already firmly rooted in our culture I consider ceil() about as standard as, say, acos()... -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Matrix groups are not uniquely represented, why?
Travis Scrimshaw wrote: > In terms of surprise, the fast == is clearly worse, It is not that clear to me! (What I think I'd expect if I didn't know Sage would be for == to compare the representation of the objects, not their mathematical semantics, even when that semantics is unambiguous.) -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Problem of reduction of rational functions
Vincent Delecroix wrote: > That does not prevent us to normalize for let say: __repr__() , > numerator(), denominator(). Is there any reasonable rule to choose > when to and when not to normalize? For QQ itself, GMP does normalize > all the time. Just to be certain that we are talking about the same thing: Currently, elements of fraction fields are always reduced (except over inexact rings) in the sense of dividing out by the gcd of the numerator and the denominator. But no further normalization is done, and in particular, when the numerator and denominator are polynomials, their contents or leading coefficients are not normalized. There is a ticket needing review that proposes to normalize the leading coefficient of the denominator to one: https://trac.sagemath.org/ticket/16268 Actually, I first tried implementing a version that would systematically clear denominators inside the numerator and denominator of the fraction, but I didn't manage to make it reasonably fast, even with a dedicated class for polynomials over fraction fields (with a single denominator, similar to the representation of polynomials over ℚ). While I'm not saying it can't be done, in the short term, the version at #16268 is a lot simpler and already fixes a number of issues! Regarding your question: Having a variant of numerator()/denominator() that works recursively would definitely be useful, and yes, it may be nice to use it in __repr__(). At the same time, I think we do want to keep programmatic access to the “true” numerator and denominator as defined in the data structure. In case you want to experiment with the idea, here is a (perhaps a bit naive, improvements welcome!) implementation of something similar that I needed for something I'm working on. It is intended to be used with #16268 and #23909. def _my_lcm(elts): # non monic l = ZZ.one() for p in elts: l *= (p//p.gcd(l)) return l def _clear_denominators_1(elt, dom): num, den = elt.numerator(), elt.denominator() base = dom.base_ring() if isinstance(base, FractionField_generic): numnum, numden = clear_denominators(num, base) dennum, denden = clear_denominators(den, base) newdom = dom.change_ring(base.ring()) numnum = newdom(numnum) dennum = newdom(dennum) gnum = numnum.gcd(dennum) numnum, dennum = numnum//gnum, dennum//gnum gden = numden.gcd(denden) numden, denden = numden//gden, denden//gden return (numnum, numden, dennum, denden) else: return (num, dom.one(), den, dom.one()) def clear_denominators(elts, dom=None): r""" Recursively clear denominators in a list (or other iterable) of elements. Typically intended for elements of fields like QQ(x)(y). """ if not elts: return elts, dom.one() if dom is None: dom = elts[0].parent() if isinstance(dom, FractionField_generic): ring = dom.ring() split = [_clear_denominators_1(elt, ring) for elt in elts] lcmnum = _my_lcm((dennum for _, _, dennum, _ in split)) lcmden = _my_lcm((numden for _, numden, _, _ in split)) num = [(denden*(lcmden//numden))*(numnum*(lcmnum//dennum)) for (numnum, numden, dennum, denden) in split] den = lcmden*lcmnum g = gcd(num + [den]) # XXX: can we be more specific here? num = [p//g for p in num] den = den//g else: num, den = elts, dom.one() # assert all(b/den == a for a, b in zip(elts, num)) # assert gcd(num + [den]).is_one() return num, den -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Problem of reduction of rational functions
John Cremona wrote: > This is simpler than writing numerator and denominator as a rational > times a primitive integral polynomial, though that is probably what > users would prefer. And (at least in my limited experience), for rational fractions over general fraction fields (things like ℚ(x)(y), say), normalizing by extracting the contents can be very slow. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Problem of reduction of rational functions
Matthias Koeppe wrote: > This is discussed in https://trac.sagemath.org/ticket/16993 ...and https://trac.sagemath.org/ticket/16268 (needs review!). -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Internet access during tests
Thierry wrote: > sudo iptables -A OUTPUT -j ACCEPT -o lo > sudo iptables -A OUTPUT -j ACCEPT -o 127.0.0.1 > sudo iptables -A OUTPUT -j DROP > > But i guess this is not what you want. I don't know the details, but it looks like nowadays there are ways to do something a little more fine-grained: http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Graphical tool for matrix input
Simon King wrote: > The reason he gave: In Mathematica, matrices can be defined with a > graphical tool. Hence, one can input some entries, use arrow keys to > switch from entry to entry, and can insert (and delete?) rows or > columns on the fly. > > I think it would be nice for SageMath to have such function, too. Both > in the notebook and on command line, actually. Not really an answer, but TeXmacs[1] already provides Sage sessions, and its session plugin API makes it relatively easy to implement 2D input à la Maple/Mathematica. [1] http://texmacs.org/ -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: How much do we support the casual user
Dima Pasechnik wrote: > is_prime() should be restricted to rings in which one can have > non-trivial prime elements Well, that's what I'm doubting. If the goal is that the global is_prime() function doesn't do anything surprising for people who would have integers in mind, then it may be better to restrict it to plain integers. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: How much do we support the casual user
Simon King wrote: > That makes sense to me. > Thus I now think, z.is_prime() should roughly work like this: > def is_prime(self): > ... What about keeping the is_prime() *method* unchanged (except perhaps for adding an optional warning in the default implementation for field elements), and restricting the is_prime() *function* to integers-- perhaps allowing it to automatically convert its argument, after a deprecation period at least? -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: How much do we support the casual user
William Stein wrote: > If we are going to change something in this case, probably Simon's > suggestion to have a warning (that can be turned off) be printed by > the top-level globalsI() is_prime when confronted with a field element > seems best... It definitely won't break anybody's code, and avoids > Ralf's confusion. FWIW, Maple has a specific message type ("hint") for things that aren't really warnings but may help the interactive user do what they want. These messages are on by default but can be disabled globally. There may be a use for something similar in Sage (based on the standard python logging module, for instance). -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: How much do we support the casual user
John Cremona wrote: > However pedantic you are it is very hard indeed to justify this for a > package which is intended for a wide class of users: > > sage: a = 300/100 > sage: a > 3 > sage: a in ZZ > True > sage: a.is_prime() > False Yes, but having a.is_prime() return True may break generic code written for arbitrary commutative rings that needs to specialize gracefully to fields. This looks less likely with Vincent's examples, though factor() may be a borderline case. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Faster way to load python code
Hi Simon, Simon King wrote: > Is there a faster way to read and evaluate a large python code > block than sage.repl.load.load? I think %runfile is somewhat faster, though not exactly fast. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage's handling of complex I
Ralf Stephan wrote: > Now, in an existing doctest `sin(QQbar(I))` gives an error > because number field I and QQbar I are in the same arithmetic > operation. If one expects something non-crashing resulting from > `sin(QQbar(I))`, what should we do? IMO, fix embedded number fields so that they coerce into QQbar. There have been tickets towards that goal for a long time, but it still requires some work. > Try to return `I*sinh(1)` where `I` is what? `QQbar` or number field? As long as it is embedded in a symbolic expression, I don't think it matters much. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G2 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G2. Write > > if the lattice is reflexive ... > > but don't write > > if ``self`` is reflexive ... X -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G5 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G5. Write > > OUTPUT: > > - lattice > > > but do not write > > OUTPUT: > > lattice X -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G3 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G3. Write (1) > > Return True if the lattice is reflexive. > > but do not write (2) > > Return True if the lattice is reflexive and False otherwise. > > nor (3) > > Return whether the lattice is reflexive. > > nor (4) > > Test if the lattice is reflexive. X -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G4 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G4. OUTPUT block is optional +1 -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G1 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G1. Write > > Return True if something is true. > > but do not write > > Return ``True`` if something is true. > > The same applies to `False` and `None` X -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage policy question: require docstrings and doctests?
Jeroen Demeyer wrote: > For functions which are meant to be called directly by end users, > doctests are essential because they should show examples of how the > function should actually be used. However, for internal functions or > things like __init__, it is often not easy to write meaningful > docstrings. I suspect the policy of doctesting every function also discourages people from breaking their code into simpler functions. And it is not clear that it improves the documentation (or testing) even of the helper functions themselves, because pretty often it would make more sense to describe and test, say, a number of private methods of a class at once, in the class docstring. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage policy question: require docstrings and doctests?
Jeroen Demeyer wrote: >>- random seeds are always the same > > That can easily be fixed by explicitly changing the random seed in the > doctest (probably some helper context should be provided for this) Or, in the case of complicated tests done by a dedicated function, by using sage.misc.random_testing. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Should RLF/CLF be exact ?
Hi, Thierry wrote: > I opened https://trac.sagemath.org/ticket/22960 but i am not sure > whether RLF should stop claiming it is exact or whether we should > forbid things like RLF(0.1), what do you think (the first is easier to > implement) ? The latter option sounds better to me. A third way might be to "exactify" elements of inexact real fields (using x.exact_rational() for instance) when converting to RLF. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Inconsistencies in comparing
Ralf Stephan wrote: > Do I understand it right that then I can coerce a real to a complex > ball and always back to a real without raising an exception? Coerce, no; convert, yes, I think (assuming that by "a real" you mean "an element of a RealField"), but that's an implementation detail, not something you should rely on. > It does not work with interval fields: > sage: RR(CIF(1)) > 1.00 > sage: RR(CIF(1/7)) > ... > TypeError: unable to convert '0.1428571428571429?' to a real number But here, you aren't converting back something that was obtained by converting a floating-point number. Is isn't going to work in this case, even with ball fields. And unlike ball fields, interval fields do round floating-point numbers to the interval field precision, so that converting back is not possible in general. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Inconsistencies in comparing
Hi, Ralf Stephan wrote: > This though seems buggy: > sage: BF = RealBallField(precision=2) > sage: BF(1.002)>BF(1.001) > True > sage: BF(1.002)-BF(1.001) > [+/- 1.20e-7] I don't think there is a bug here. The difference prints as an interval containing zero, but this is a correct over-approximation, so no problem here. And note that we have: sage: d = BF(1.002)-BF(1.001) sage: d.mid(), d.rad() (8.9e-8, 2.9802322e-8) sage: d > 0 True Under the hood, what happens is that a ball field of precision p can contain elements represented with more than p bits of mantissa. (Subsequent *operations* on those elements will be done with a precision of p, though.) This is convenient in combination with automatic coercion. In particular, it is possible to coerce both operands of an operation between elements of different ball fields to the less precise one without information loss. > But then I would expect CC to raise exceptions for this: > sage: CC(I+1)>CC(I) > True > sage: CC(I-1)>CC(2*I) > False [...] > This should IMO raise exceptions: > sage: RealInterval(1,upper=2) False > sage: > ComplexIntervalFieldElement(1,1)>ComplexIntervalFieldElement(0,2) True I agree. Unfortunately, due to the confusion between cmp and richcmp in many parts of sage, and to existing code that depends on this confusion, making it happen still requires a bit of work. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: RR, coercion of numpy.float32() and clang - coercion experts needed
Dima Pasechnik wrote: > but it looks as if it might be a coercion problem. > Any ideas where to look? Not really, but it does look like the common parent discovered by the coercion system is incorrect: sage: import numpy as np sage: a = np.float('1.5') sage: b = np.float32('1.5') sage: get_coercion_model().common_parent(b, polygen(RR)) Univariate Polynomial Ring in x over Real Field with 53 bits of precision sage: RR.coerce(a) 1.50 sage: RR.coerce(b) ... TypeError: no canonical coercion from to Real Field with 53 bits of precision sage: get_coercion_model().common_parent(b, RR) -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: algdep (PARI) with clang on FreeBSD
Thierry wrote: > I found the reference i was looking for : > http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_double.html#sage.rings.real_double.RealDoubleElement.ulp That the default rounding mode is round-to-nearest means that correctly rounded results should be rounded to the nearest floating-point number (as opposed to upwards, towards zero...), not necessarily that all operations return correctly rounded results. But you are right that in the particular case of sqrt(3), one would expect the result to be correctly rounded, since the IEEE-754 standard requires correct rounding for square roots, and processors usually follow it... -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: algdep (PARI) with clang on FreeBSD
Thierry wrote: > I do not remember where i read that (correct me if i am wrong, or > provide a reference if you know where it is), but RDF is supposed to > round towards the nearest floating-point number. RR is, but I think RDF may or may not provide correct rounding depending what the underlying libm does. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Names of special methods like _pari_
Jeroen Demeyer wrote: > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > (__array__). However, creating such names possibly goes against the > Python documentation [2]. Why "possibly"? The way I understand [2] is that __names__ are reserved for use by the Python interpreter and standard library, period. In this particular case, it is unlikely that Python ever specifies a __pari__() magic method. But if you want to do the same with all conversion methods, there could well be a conflict with some future standard python module. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: symbolics: is_real versus conversion to RR
Emmanuel Charpentier wrote: > Should this be discussed again, with a call for *VOTE* ? I don't think this is something that can be decided independently of other conventions (such as the semantics of equality and comparisons and the handling of inexactness). At the very least, I think someone would have to dig through the archive of sage-devel and summarize the arguments brought up in previous discussions before it would make sense to vote. But I agree that there is a strong need for clarifying and documenting this kind of general conventions. I find it really frustrating, both as a user and an occasional contributor, to see the developer guide discuss at length things like the use of git, trac and cython (that are not specific to sage) and say so little about sage conventions on things that need to be handled consistently over the whole codebase (to name but a few: "unknown" results and comparisons again, current vs deprecated best practices, coercions involving "special" parents like SR, InfinityRing or interfaces, branches of analytic functions, semantics of real and complex parents, of variable names [wrt comparison and coercion], of methods like is_field() or is_exact(), when to use conversion and when to use coercion in library code...). -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercions from (quadratic) NumberFields to AA
Travis Scrimshaw wrote: > If no coercion is currently known, then coerce_map_from() calls > _coerce_map_from_(). If _coerce_map_from_() returns a map, then that > map becomes the coercion map. If it simply returns True, then the > coercion map is constructed by using _element_constructor_() as the > definition of the map. In either case, a coercion map is constructed > and stored. Sure, but I still don't see how that's relevant. Perhaps I didn't understand what you said wasn't true in your previous message. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercions from (quadratic) NumberFields to AA
Travis Scrimshaw wrote: > That is not true. Note that Foo.has_coerce_map_from() is not > Foo._coerce_map_from_(). The method has_coerce_map_from() calls > _coerce_map_from_, which should either return a coercion map or True, > and in the latter case, then it uses Foo(bar) to define the coercion > (which really uses _element_constructor_). What has_coerce_map_from() > does is it checks to see if _coerce_map_from_() returns something that > is not False (or perhaps None, I forget off-hand). Sorry, I don't understand what you mean. As far as I can see, has_coerce_map_from() calls _internal_coerce_map_from(), which first looks in _coerce_from_hash and only then, if nothing is found, calls discover_coerce_map_from() which eventually calls _coerce_map_from_(). But _coerce_from_hash is also affected by _populate_coercion_lists_(), via register_coercion(). -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercions from (quadratic) NumberFields to AA
Daniel Krenn wrote: > In the doc of sage.rings.qqbar.AlgebraicRealField._coerce_map_from_ > there is the following test: > > sage: K. = QuadraticField(7, embedding=AA(7).sqrt()) > sage: AA.has_coerce_map_from(K) > True > > Why does this return (correctly) True, although the code of this > method is simply > > def _coerce_map_from_(self, from_par): > return (from_par is ZZ or from_par is QQ > or from_par is AA) > > ? Probably because NumberField_generic.__init__() does: self._populate_coercion_lists_(embedding=embedding) -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Kwankyu Lee wrote: > I expect that the comparison operators try to return mathematically > sensible result as far as it is practical (one systematic way is to > use coercion), and do something else (but still True or False) that is > clearly documented as soon as any difficulty you mentioned can arise. What about <, <=, etc.? Do you agree that they should fail when rather than return a result with no mathematical meaning, even if the result is clearly documented? >> (3) "x != y" and "x == y" never raise an exception. >> >> Why? We are not talking about raising exceptions all the time, only >> in cases where it is likely that there is a bug... > > Because you mentioned TypeError as an option. Yes, sorry if I wasn't clear: what I'm aksing is what benefit you see of returning False instead of raising an error (in the case of !=). Thanks again, -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Kwankyu Lee wrote: > Do we have such cases in Python proper? I mean a case that disobeys > (1). I can't think of any example for base types(*). But this is explicitly allowed by PEP207: |3 The == and != operators are not assumed to be each other's | complement (e.g. IEEE 754 floating point numbers do not satisfy | this). It is up to the type to implement this if desired. and I guess there are a number of other libraries that use this option. (*) What I said about NaNs earlier in the thread was incorrect: I think the rule is actually that NaN < a, NaN > a, NaN == a are all false for all a (even when a is [the same] NaN), but NaN != a is true for all a. And that's, of course, assuming a particular mapping of the language's comparison operators to IEEE754 comparison predicates, which is the job of the language specification. And hence I don't understand what the remark about IEEE754 in the above quotation refers to. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Simon King wrote: > I didn't closely follow the discussion here. Have there been > suggestions how Sage should in future distinguish the two meanings of > comparison (maths vs programming)? Not in this thread. However, if I understood right, several people who worked on getting rid of cmp() came to the conclusion that having a total order on all objects like cmp() used to (sort of!) promise wasn't that useful. Yet, it would be nice to standardize a few additional comparison functions with well-specified semantics. (That's not what I'm trying to do at the moment, however.) > It would obviously be rather awkward to have to do "A.is_equal(B)" for > a mathematical equality test. It would nevertheless be the best option, IMO, if we were starting from scratch. But that's not the case. -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Thank you for you comments. Kwankyu Lee wrote: > (1) "x != y" should behave always and exactly as "not (x == y)" This is difficult to achieve. For example, in interval arithmetic, one usually expects a == b to return True iff a and b are equal point intervals, and a != b to return True iff a and b are disjoint intervals. Also, for lots of objects coming up in computer algebra (e.g., symbolic expressions in one variable), the equality test is either undecidable or at least not known to be decidable. In all these cases, there are at least three possible outcomes for the comparison a == b: - a and b can be determined to be equal, - a and b can be determined to be different, - a and b are neither known to be equal nor known to be different (and perhaps, sometimes, variants like "a and b are known to be neither equal nor different": e.g., the IEEE standard for floating- point arithmetic says that NaN == NaN and NaN != NaN should both return False, and it is not clear that this can be considered a case where the "actual" result is unknown, as with interval arithmetic). Then, the questions "are a and b known to be equal" and "are a and b known to be different" are not the same. For example, if you are trying to make sure that a matrix is nonsingular, you will usually want to test that its determinant is known to be nonzero. If, however, you are trying to decide whether a term can be dropped from the representation of a polynomial, you'll usually want to test if it is known to be zero. A partial solution to these problems is to allow comparisons to return "Unknown" instead of just "True" or "False". This is in fact possible; however (as discussed at length on sage-devel in the past), Python will need to convert the "Unknown" result to a boolean as soon as it is used as part of a conditional expression, so that we essentially are back to the previous problem. (I guess one could implement a more explicit, if essentially equivalent, way of handling that, e.g. have comparisons themselves return Unknown, conversions from Unknown objects to boolean raise an exception, and introduce "modality" operators for the various possible conversions from {True,False,Unknown} to {True,False}. But that's not how things are done in Sage for now.) > (2) When parents of x and y are different after coercion, "x != y" ("x > == y") returns True (False) for both (i) and (ii) Why only "after coercion"? I would understand that x != y return False as soon as x and y have different parents--that would actually be the best convention from my POV, but many people disagree, and that would be a major break of compatibility. But I don't like the idea that a comparison that makes sense mathematically returns True or False depending whether the coercion system finds a common parent or not. Besides, it is not hard to find cases where the user could *expect* the system to make sense of the comparison, even though x and y actually have good reasons not to have a common parent. In other words: the choice has been made, long ago, to have ==/!= in Sage stand for "semantic" comparison of mathematical objects rather than "syntactic" comparison of data structures. I don't think it was the right choice, but as long as we stick to it, it seems to me that comparisons that don't have a well-defined mathematical result should fail whenever practical, and return False (under the above asymmetric interpretation) if they really need to return a boolean result. > (3) "x != y" and "x == y" never raise an exception. Why? We are not talking about raising exceptions all the time, only in cases where it is likely that there is a bug... -- Marc -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.