Re: [sage-devel] Re: gamma function enhancement proposal
On Fri, Jan 22, 2016 at 12:58 AM, Buck Evan wrote: > Fredrik: > Thank you for your thoughtful reply! > > On Thu, Jan 21, 2016 at 2:48 PM Fredrik Johansson > wrote: >> >> Arb (which is now in Sage) permits computing incomplete gamma >> functions with rigorous error bounds over arbitrary-precision >> real/complex (interval) fields. > > > I don't find the incomplete function. Am I looking in the wrong section? > http://fredrikj.net/arb/acb.html?highlight=gamma#gamma-function Yes; see http://fredrikj.net/arb/acb_hypgeom.html?highlight=gamma#incomplete-gamma-functions >> >> Supporting the different regularized >> versions is just a matter of dividing by a complete gamma function. > > > My understanding is that computing the regularized function directly gives > less error than division of two huge numbers, but I don't truly understand > the theory of numeric error. This is not a problem with an arbitrary precision backend (you can increase the precision to compensate). Anyway, it's not hard to implement the asymptotic cases separately. >> >> Looking at the attachment, I don't know if the logarithmic versions of >> incomplete gamma functions are really useful. > > > Why would gamma_log(a, x) be less useful than gamma_log(a)? > Certainly the incomplete functions increase to astronomical quantities > similarly to the complete function. Anyway, that doesn't seem to be an > argument to make it unavailable. Sure, but this is not really concern if using Sage's RR. You could make the case for having a log=True option for any function that grows exponentially, but in that case, why not just work with a type that supports large numbers? There are of course exceptions: the usual gamma function and the scaled complementary error function come to mind. I'm not saying it couldn't be useful, but do you have a concrete application in mind for gamma_log(a, x) that would make it worth the added complexity? As soon as you introduce options, you have a lot more special cases to worry about handling correctly in the implementation. I don't even know how you would define the logarithm of the incomplete gamma function for complex numbers to make it useful. The usual log gamma function is not defined as log(gamma(z)). > However I do hear the point that I shouldn't worry about this edge case at > all. > >> >> The regularized >> incomplete gamma functions P and Q are quite standard and used in >> statistics, I think. > > > That's a useful note. That's what I'm seeing in my research as well. > >> >> Personally, I think the usual gamma() function is too important in its >> own right to complicate by adding extra options. I would rather leave >> gamma() a single-argument function and have separate functions for >> logarithmic and incomplete gamma functions of various kinds. > > > Options and number of arguments are separate issues, in my mind. > The one extreme would be gamma(a) while the other would be gamma(a, x1=0, > x2=oo, log=False, regularized=False). > > > I believe you and Nils agree that the 'log' and 'regularized' options are > sketchy. I think I agree too. However the three-argument gamma (the > generalized gamma) is a useful normal form for the upper and lower > incomplete functions. > >> >> In mpmath, there is a single function gammainc() that covers all cases of >> incomplete gamma functions. But it's not necessary to do it in that >> particular way. > > > mpmath.gammainc() with one argument calculates the complete gamma, which > makes it feel miss-named and redundant to me. This is, again, motivated by having a clean interface for the ordinary gamma function. But that's subjective. >> If you want symbolic manipulation to be aware of different variants, >> >> you probably need to do something in Pynac/SymPy/Maxima rather than >> Sage itself. > > > All three, or just one? > If one, is it my decision, or predetermined by details of sage? I don't know. Fredrik -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] Do we really need Element, RingElement, AdditiveGroupElement, ...?
A related question now that I'm thinking about refactoring: can we drop the in-place methods like __iadd__? May we assume that no Element will need in-place methods with coercion? The problem is when classes want to implement a special __add__ without coercion (that is legitimate). If those classes do not also implement __iadd__, stuff breaks because of the __iadd__ implemented in the coercion model. Note that classes can still implement in-place methods without coercion if they want. Jeroen. -- You received this message because you are subscribed to the Google Groups "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] building Software Carpentry "lesson" for Sagemath
Software Carpentry, see http://software-carpentry.org, is a charity that does "Teaching basic lab skills for research computing". But goes beyond that; their workshops can include more nontrivial components, e.g. recently GAP people conducted such an introductory GAP workshop: https://kkwakwa.github.io/2015-11-16-manchester-codima/ Such workshop materials are prepared to a standard and are reusable. As a followup, I did a 3-hour introduction to Sage there. Now the idea is to create and run specifically Sage(math) Software Carpentry workshops. Alex Konovalov (who did the bulk of work for the GAP S.C. workshop, in cc:) created a skeleton git repo for such a lesson: https://github.com/alex-konovalov/sage-lesson and is assembling a team to work on this. Not sure about the timeline at the moment, but most probably we'd like to organise such a Software Carpentry workshop for Sage(math) in the autumn. In case you're interested, please get in touch. Dima -- You received this message because you are subscribed to the Google Groups "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] solve() with anonymous symbols loses symbol identity
Hello, I encountered some unexpected behavior when using solve() with anonymous symbols generated using SR.symbol(). The returned by solve are not the same as the ones passed in (even though they look the same). Here is a minimal example: x sage: x = SR.symbol(); x symbol151 sage: sol = solve(x==1, x, solution_dict=True)[0] sage: x2 = sol.keys()[0]; x2 symbol151 sage: bool(x2 == x) False sage: bool(SR.symbol(str(x)) == x2) True sage: bool(SR.symbol(str(x)) == x) False The issue also appears when solution_dict=True is not used (for example, when trying to substitute the solutions into other expressions). I am guessing this is related to http://trac.sagemath.org/ticket/13655. My environment: $ sage --version; lsb_release -a; uname -a SageMath Version 6.10, Release Date: 2015-12-18 LSB Version: 1.4 Distributor ID: Arch Description: Arch Linux Release: rolling Codename: n/a Linux ashryn 4.3.3.201601171913-1-grsec #1 SMP PREEMPT Sun Jan 17 21:26:59 EST 2016 x86_64 GNU/Linux Best, Andres -- You received this message because you are subscribed to the Google Groups "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] The sage.rings.finite_rings.constructor module
Hello everybody, The title of the following module is 'Finite Fields'. Its contains code related to finite fields. sage/rings/finite_rings/constructor.py Is it just me, or is there a noticeable discrepancy between the filename and the content/title? Thanks, Nathann -- You received this message because you are subscribed to the Google Groups "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-support] building Software Carpentry "lesson" for Sagemath
Hi Dima, I’m not sure how much time I can contribute, but I’m in principle interested and would appreciate being kept in the loop. Cheers, Martin Dima Pasechnik writes: > Software Carpentry, see http://software-carpentry.org, is a charity that > does "Teaching basic lab skills for research computing". But goes beyond > that; their workshops can include more nontrivial components, e.g. recently > GAP people conducted such an introductory GAP workshop: > https://kkwakwa.github.io/2015-11-16-manchester-codima/ > Such workshop materials are prepared to a standard and are reusable. > > As a followup, I did a 3-hour introduction to Sage there. > > Now the idea is to create and run specifically Sage(math) Software > Carpentry workshops. > Alex Konovalov (who did the bulk of work for the GAP S.C. workshop, in cc:) > created a skeleton git repo for such a > lesson: https://github.com/alex-konovalov/sage-lesson > and is assembling a team to work on this. Not sure about the timeline at > the moment, but most probably we'd like to organise such a Software > Carpentry workshop for Sage(math) in the autumn. > > In case you're interested, please get in touch. > Dima -- _pgp: https://keybase.io/martinralbrecht _www: https://martinralbrecht.wordpress.com _jab: martinralbre...@jabber.ccc.de _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF -- You received this message because you are subscribed to the Google Groups "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. signature.asc Description: PGP signature
[sage-devel] Re: building Software Carpentry "lesson" for Sagemath
Thank you, Dima, > On 22 Jan 2016, at 09:49, Dima Pasechnik wrote: > > Software Carpentry, see http://software-carpentry.org, is a charity that does > "Teaching basic lab skills for research computing". But goes beyond that; > their workshops can include more nontrivial components, e.g. recently GAP > people conducted such an introductory GAP workshop: > https://kkwakwa.github.io/2015-11-16-manchester-codima/ > Such workshop materials are prepared to a standard and are reusable. This page contains links to all Software Carpentry lessons taught there - the particular one which I've developed is on GAP: http://alex-konovalov.github.io/gap-lesson/index.html and I am thinking of something along the same teaching philosophy for SageMath. > As a followup, I did a 3-hour introduction to Sage there. > > Now the idea is to create and run specifically Sage(math) Software Carpentry > workshops. > Alex Konovalov (who did the bulk of work for the GAP S.C. workshop, in cc:) > created a skeleton git repo for such a > lesson: https://github.com/alex-konovalov/sage-lesson > and is assembling a team to work on this. Not sure about the timeline at the > moment, but most probably we'd like to organise such a Software Carpentry > workshop for Sage(math) in the autumn. > > In case you're interested, please get in touch. The best way to get in touch is to leave a comment at: https://github.com/alex-konovalov/sage-lesson/issues/1 and watch that repository so you will get updates. Best wishes Alexander -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] The sage.rings.finite_rings.constructor module
On 2016-01-22 11:13, Nathann Cohen wrote: Hello everybody, The title of the following module is 'Finite Fields'. Its contains code related to finite fields. sage/rings/finite_rings/constructor.py Is it just me, or is there a noticeable discrepancy between the filename and the content/title? I can do better: src/sage/rings/real_lazy.pyx contains code for real and *complex* lazy numbers. -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] The sage.rings.finite_rings.constructor module
> I can do better: > > src/sage/rings/real_lazy.pyx > > contains code for real and *complex* lazy numbers. Nice. I hope nobody will beat that. Do you see have any objection to setting things right? Nathann -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] The sage.rings.finite_rings.constructor module
On 2016-01-22 11:41, Nathann Cohen wrote: Do you see have any objection to setting things right? Of course not, but we need to deprecate the old modules. -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] The sage.rings.finite_rings.constructor module
> Of course not, but we need to deprecate the old modules. Yes yes of course. Nathann -- You received this message because you are subscribed to the Google Groups "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: The sage.rings.finite_rings.constructor module
The 'constructor' file is being renamed to 'finite_field_constructor' in the following ticket: http://trac.sagemath.org/ticket/19941 Nathann On 22 January 2016 at 12:13, Nathann Cohen wrote: > Hello everybody, > > The title of the following module is 'Finite Fields'. Its contains > code related to finite fields. > > sage/rings/finite_rings/constructor.py > > Is it just me, or is there a noticeable discrepancy between the > filename and the content/title? > > Thanks, > > Nathann -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] Re: Torrent file downloads from http://www.sagemath.org/mirror/torrents.html fails with HTTP error 404
Thanks Karl-Philip Richter for reporting these broken links. Harald, could we set up a redirection from http://www.sagemath.org/mirror/* to http://files.sagemath.org/* Note that we already have a redirection from http://www.sagemath.org/src-old/ to http://old.files.sagemath.org/src-old/ Let me know if I can help with this. -- You received this message because you are subscribed to the Google Groups "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: Missing file in src/build/cythonized/sage/structure/list_clone.c
On Tuesday, January 12, 2016 at 10:15:00 AM UTC-7, Volker Braun wrote: > > On Tuesday, January 12, 2016 at 3:30:22 PM UTC+1, Jan Groenewald wrote: >> >> Funny thing is, basic operations ad plotting work fine, whereas I thought >> if relocate-once.py failed sage would not be able to find any of it's >> libraries and just crash. >> > > Thats because relocate-once.py partially worked until it encountered the > file that you deleted; Depending on how far it got your install can be > mostly OK. > > Same thing happened to me after new install on Ubuntu 14.04. I'm a brand new user and this is not inspiring or confidence building. Tempted to uninstall and try the next on the list. Got the error during install and I get it every startup and sage crashed the first time I tried to start it. :( -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To 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.
Re: [sage-devel] Re: Missing file in src/build/cythonized/sage/structure/list_clone.c
Hi Yes, I am getting some queries directly to me as well (as PPA maintainer). The SAGE_ROOT/relocate-once.py is becoming less compatible with dpkg-buildpackage, which wants to manage the files, and not have them changed after installation. We're thinking of a new simpler package, which contains the tarball, and has a script to untar it. We're still discussing the various options around this. Our criteria are: 1) prompts for updates in the distro package management system (gets our alumni body to actually update) 2) ease of install. In fact we pre-install it for most of our users via a Ubuntu derivative 3) save bandwidth and disk space (we'll have to drop the smaller version now and include the whole tarball with the SAGE_ROOT/src folder) 4) have a local to each laptop version (not a cloud server or campus server) for situations with both bandwidth and electricity interruptions So far this error does not inspire confidence, but this PPA 6.10 is deployed on our campus where people are using sage in teaching and I have not had to revert to 6.9. Regards, Jan On 22 January 2016 at 16:51, Richard Kandarian wrote: > > > On Tuesday, January 12, 2016 at 10:15:00 AM UTC-7, Volker Braun wrote: >> >> On Tuesday, January 12, 2016 at 3:30:22 PM UTC+1, Jan Groenewald wrote: >>> >>> Funny thing is, basic operations ad plotting work fine, whereas I >>> thought if relocate-once.py failed sage would not be able to find any of >>> it's libraries and just crash. >>> >> >> Thats because relocate-once.py partially worked until it encountered the >> file that you deleted; Depending on how far it got your install can be >> mostly OK. >> >> Same thing happened to me after new install on Ubuntu 14.04. I'm a brand > new user and this is not inspiring or confidence building. Tempted to > uninstall and try the next on the list. Got the error during install and I > get it every startup and sage crashed the first time I tried to start it. > > :( > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To 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. > -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ -- You received this message because you are subscribed to the Google Groups "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] 0^0 in unramified extensions of Zp
Hello, I have noticed an unexpected behavior when trying to evaluate 0^0 in unramified extensions of Zp. Here is an example: sage: A. = Zq(4) sage: A(0)^0 O(2^0) Compare with: sage: B = Zp(2) sage: B(0)^0 1 + O(2^20) I am using Sage 6.10 on MacOS X version 10.11. -- You received this message because you are subscribed to the Google Groups "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: solve() with anonymous symbols loses symbol identity
On Friday, January 22, 2016 at 4:49:23 AM UTC-5, Andres Erbsen wrote: > > Hello, > > I encountered some unexpected behavior when using solve() with anonymous > symbols generated using SR.symbol(). The returned by solve are not the same > as the ones passed in (even though they look the same). Here is a minimal > example: > > x sage: x = SR.symbol(); x > symbol151 > sage: sol = solve(x==1, x, solution_dict=True)[0] > sage: x2 = sol.keys()[0]; x2 > symbol151 > sage: bool(x2 == x) > False > sage: bool(SR.symbol(str(x)) == x2) > True > sage: bool(SR.symbol(str(x)) == x) > False > > The issue also appears when solution_dict=True is not used (for example, > when trying to substitute the solutions into other expressions). > > I am guessing this is related to http://trac.sagemath.org/ticket/13655. > > I am guessing you are right. solve calls Maxima, always. > My environment: > > $ sage --version; lsb_release -a; uname -a > SageMath Version 6.10, Release Date: 2015-12-18 > LSB Version: 1.4 > Distributor ID: Arch > Description: Arch Linux > Release: rolling > Codename: n/a > Linux ashryn 4.3.3.201601171913-1-grsec #1 SMP PREEMPT Sun Jan 17 21:26:59 > EST 2016 x86_64 GNU/Linux > > Best, > Andres > -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] vote for making nauty a standard package (Re: About license of nauty and poset generator)
On Fri, Jan 22, 2016 at 2:29 AM, Dima Pasechnik wrote: > > > On Thursday, 21 January 2016 07:16:45 UTC, Jeroen Demeyer wrote: >> >> On 2016-01-21 00:29, Dima Pasechnik wrote: >> > Surely, if the official nauty got another licence it would have solved >> > the problem easier. >> >> Maybe you could ask McKay if he is willing to license *every* version of >> nauty (past and future) with a GPL-compatible license? If we are only >> allowed to ship one specific version of nauty in Sage, we should not >> make it standard since it won't be maintainable. > > > I have asked, and here is his proposed licence for 2.6: > (I have asked him to deal with part D better, too) > > > This is the copyright notice for the software package Nauty and > Traces, versions 2.6 and later. > > Four categories of software are included in the package: > A. All files not listed as B-D below, copyright Brendan McKay (1984-) > B. Files traces.h and traces.h, copyright Adolfo Piperno (2008-) > C. File watercluster2.c, copyright Gunnar Brinkmann (2009-) > D. Files planarity.h and planarity.c, copyright Magma project >(University of Sydney) > Can planarity.h and planarity.c be removed from the Sagemath version of nauty? > Regarding files in classes A, B and C: >Permission is hereby given for the use, distribution and >modification of this software subject to the following. >* You must include this copyright notice with all distributed > copies of this software, including modified copies. >* You must clearly mark modified versions of this software > as differing from the original. > > Regarding files in class D: >Permission should be sought from the Magma project. > > Regarding all the files in the package: >This software is only provided "as is". No guarantee is made >as to the suitability of this software for any purpose. No >responsibility will be taken by the authors or their employers >for any misfortune which befalls you because of its use. Your >use of this software implies your agreement with this notice. > > Brendan McKay: Australian National University; brendan.mc...@anu.edu.au > Adolfo Piperno: University of Rome "Sapienza"; pipe...@di.uniroma1.it > Gunnar Brinkmann: University of Ghent; gunnar.brinkm...@ugent.be > > ---END-OF-FORMAL-COPYRIGHT-NOTICE--- > > Earlier (pre-2.6) versions of this package carried a different > notice: "Permission is hereby given for use and/or distribution > with the exception of sale for profit or application with nontrivial > military significance." These days most people use nauty via a > larger package such as Magma, Sage, or GAP, and often they don't > even know they are using nauty. Due to the legal nonsense that > large package distributors need to worry about, it has proved too > much trouble to maintain an idiosyncratic licence. I didn't change > my opinion about military use, but it is no longer part of the > formal notice. Brendan McKay (Jan 20, 2016) > > >> >> >> Jeroen. > > -- > You received this message because you are subscribed to the Google Groups > "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. -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] 0^0 in unramified extensions of Zp
On Fri, Jan 22, 2016 at 10:15 AM, srozensz wrote: > sage: A. = Zq(4) > sage: A(0)^0 > O(2^0) Thanks. This is now http://trac.sagemath.org/ticket/19943 David -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To 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.
Re: [sage-devel] vote for making nauty a standard package (Re: About license of nauty and poset generator)
I would vote yes if the concerns presented by François are addresed. -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] Re: Rationale behind HasseDiagram class
On Friday, January 22, 2016 at 1:03:59 AM UTC-6, Nathann Cohen wrote: > > >Do you want DiGraph to have methods like rank or is_chain? > > Of course not. The idea was to have Poset carry a DiGraph > _hasse_diagram instead of a HasseDiagram object, and to [move/merge] > the methods from HasseDiagram with their Poset counterparts. > > > Also, by > > implementing them directly into the Poset's class, you must deal with > the > > elements labels at each computation, not just when you're moving to/from > the > > HasseDiagram backend. > > It is the same right now: you mut translate the elements in the Poset > function which calls the HasseDiagram function. Except when the > function does not care, like 'rank'. > > > this would require a > > lot more interaction converting between the two different > representations. > > At least with the HasseDiagram, which is a DiGraph, it reduces the > amount of > > overhead with this. > > I do not see how: this would happen as often, but it would happen in > the same location. Right now we write Poset functions whose only > purpose is to relabel elements before calling HasseDiagram methods. > This could be done at the same place. > > > Moreover, the methods in Poset should just be a wrapper > > around such functions in HasseDiagram (unless there is no apparent > penalty > > for directly implementing them in Poset). > > Why do you say that it is how the *should* be? > >Suppose you have function A that calls function B a lot over a loop, and both of them can take advantage of the canonical labeling of the DiGraph. If you do not have a HasseDiagram class, then A would have to convert the canonical labeling, then convert back every time it called B, which would have to unconvert, do it's operation. With the HasseDiagram, the Poset class can just act as a translation layer, so you only have to convert each way at most once. You could have a method of Poset which is convert_to_canonical and convert_from_canonical (although I think it does it right now the faster way of copying one list comprehension around), but it is a much better design to have the HasseDiagram subclass of DiGraph. It is such a small amount more code you need to write, and there is very little complexity added. You should not be having anything in the HasseDiagram class really call stuff from the Poset, so everything has good locality too. Best, Travis -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] vote for making nauty a standard package (Re: About license of nauty and poset generator)
On Friday, 22 January 2016 17:23:06 UTC, David Joyner wrote: > > On Fri, Jan 22, 2016 at 2:29 AM, Dima Pasechnik > wrote: > > > > > > On Thursday, 21 January 2016 07:16:45 UTC, Jeroen Demeyer wrote: > >> > >> On 2016-01-21 00:29, Dima Pasechnik wrote: > >> > Surely, if the official nauty got another licence it would have > solved > >> > the problem easier. > >> > >> Maybe you could ask McKay if he is willing to license *every* version > of > >> nauty (past and future) with a GPL-compatible license? If we are only > >> allowed to ship one specific version of nauty in Sage, we should not > >> make it standard since it won't be maintainable. > > > > > > I have asked, and here is his proposed licence for 2.6: > > (I have asked him to deal with part D better, too) > > > > > > This is the copyright notice for the software package Nauty and > > Traces, versions 2.6 and later. > > > > Four categories of software are included in the package: > > A. All files not listed as B-D below, copyright Brendan McKay (1984-) > > B. Files traces.h and traces.h, copyright Adolfo Piperno (2008-) > > C. File watercluster2.c, copyright Gunnar Brinkmann (2009-) > > D. Files planarity.h and planarity.c, copyright Magma project > >(University of Sydney) > > > > Can planarity.h and planarity.c be removed from the Sagemath version of > nauty? > > At my prompting, Brendan asked Magma group for permission to release. But if for some reason this won't work we can indeed just remove them. > > Regarding files in classes A, B and C: > >Permission is hereby given for the use, distribution and > >modification of this software subject to the following. > >* You must include this copyright notice with all distributed > > copies of this software, including modified copies. > >* You must clearly mark modified versions of this software > > as differing from the original. > > > > Regarding files in class D: > >Permission should be sought from the Magma project. > > > > Regarding all the files in the package: > >This software is only provided "as is". No guarantee is made > >as to the suitability of this software for any purpose. No > >responsibility will be taken by the authors or their employers > >for any misfortune which befalls you because of its use. Your > >use of this software implies your agreement with this notice. > > > > Brendan McKay: Australian National University; brenda...@anu.edu.au > > > Adolfo Piperno: University of Rome "Sapienza"; pip...@di.uniroma1.it > > > Gunnar Brinkmann: University of Ghent; > > > > ---END-OF-FORMAL-COPYRIGHT-NOTICE--- > > > > Earlier (pre-2.6) versions of this package carried a different > > notice: "Permission is hereby given for use and/or distribution > > with the exception of sale for profit or application with nontrivial > > military significance." These days most people use nauty via a > > larger package such as Magma, Sage, or GAP, and often they don't > > even know they are using nauty. Due to the legal nonsense that > > large package distributors need to worry about, it has proved too > > much trouble to maintain an idiosyncratic licence. I didn't change > > my opinion about military use, but it is no longer part of the > > formal notice. Brendan McKay (Jan 20, 2016) > > > > > >> > >> > >> Jeroen. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to sage-devel+...@googlegroups.com . > > To post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] The sage.rings.finite_rings.constructor module
On Friday, 22 January 2016 10:23:18 UTC, Jeroen Demeyer wrote: > > On 2016-01-22 11:13, Nathann Cohen wrote: > > Hello everybody, > > > > The title of the following module is 'Finite Fields'. Its contains > > code related to finite fields. > > > > sage/rings/finite_rings/constructor.py > > > > Is it just me, or is there a noticeable discrepancy between the > > filename and the content/title? > > I can do better: > > src/sage/rings/real_lazy.pyx > > contains code for real and *complex* lazy numbers. > probably real_lazy is the author's signature in this case... :-) -- You received this message because you are subscribed to the Google Groups "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: gamma function enhancement proposal
Fredrik Johansson wrote: > Arb (which is now in Sage) permits computing incomplete gamma > functions with rigorous error bounds over arbitrary-precision > real/complex (interval) fields. Incidentally, the sage bindings (over complex balls) need review: http://trac.sagemath.org/ticket/19082 -- 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.
Re: [sage-devel] Re: The sage.rings.finite_rings.constructor module
I raised some objections on the ticket. David On Fri, Jan 22, 2016 at 7:38 AM, Nathann Cohen wrote: > The 'constructor' file is being renamed to 'finite_field_constructor' > in the following ticket: > > http://trac.sagemath.org/ticket/19941 > > Nathann > > On 22 January 2016 at 12:13, Nathann Cohen > wrote: > > Hello everybody, > > > > The title of the following module is 'Finite Fields'. Its contains > > code related to finite fields. > > > > sage/rings/finite_rings/constructor.py > > > > Is it just me, or is there a noticeable discrepancy between the > > filename and the content/title? > > > > Thanks, > > > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "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. > -- You received this message because you are subscribed to the Google Groups "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.
Re: [sage-devel] Re: Rationale behind HasseDiagram class
>Suppose you have function A that calls function B a lot over a loop, and > both of them can take advantage of the canonical labeling of the DiGraph. If > you do not have a HasseDiagram class, then A would have to convert the > canonical labeling, then convert back every time it called B, which would > have to unconvert, do it's operation. class Poset: def A(): for i in ZZ: self._B() def _B(): # works on the digraph self._hasse_diagram, taking advantage of its labelling I do not see where the problem is. It requires a helper function _B a in the current design (where _B would be a HasseDiagram method), and for the other functions that do not need to "call a function that takes advantage of the labelling" (whatever that means) we would need only one function (which is 99% of the time). I still do not see what makes HasseDiagram mandatory. To clear any misunderstanding, look at the following ticket: http://trac.sagemath.org/ticket/19659 It implements a Poset function that "takes advantage of the diagram's labelling" and we don't need any HasseDiagram method, so I do not know what you are talking about. Nathann -- You received this message because you are subscribed to the Google Groups "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.
