[sage-devel] Re: Error in I.variety(algorithm='msolve', proof=False)

[Marc Mezzarobba]

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)

[Marc Mezzarobba]

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

[Marc Mezzarobba]

'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

[Marc Mezzarobba]

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]

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]

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]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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 

[sage-devel] Re: Sage Dev Prizes

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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"

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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!

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

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]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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: ceil or ceiling?

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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?

[Marc Mezzarobba]

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 ?

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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_

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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

[Marc Mezzarobba]

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.

[sage-devel] Re: Re: Re: Cross-type comparisons

[Marc Mezzarobba]

Jeroen Demeyer wrote:
> I would prefer to treat these as any other non-Element. I see no
> reason for the special case.

It would catch cases like QQ(1) != ZZ or (going back to the case of 
general rich comparison) float(1) < RIF(pi) where Python2 would compare 
by type otherwise.

-- 
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: Cross-type comparisons

[Marc Mezzarobba]

Marc Mezzarobba wrote:
> Jeroen Demeyer wrote:
>> Don't forget the option
>>
>> (c) return NotImplemented
>>
>> I would say:
>>
>> Case (i): (b)
>> Case (ii): (c)
> 
> Yes, I kept that out because my current patches don't change that part
> of the logic, but I think I agree.

What about making a finer distinction, like

- (b), i.e. fail, when y is a SageObject or can be converted using
  py_scalar_to_element(),

- (c), i.e. return NotImplemented, otherwise?

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