Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 2014-11-12 21:33, Ursula Whitcher wrote: On 11/11/2014 4:46 AM, Jeroen Demeyer wrote: * The sentence A recent tweak of another part of Sage’s matrix code had changed the definition of “small n” to n = 63. is wrong: what had changed is the bound on p to compute the determinant over GF(p) using LinBox (for larger p, we compute determinants over GF(p) by lifting to ZZ): it used to be the case that the bound in LinBox depended on n, this was changed to a fixed bound for p which was less than the old value for n = 63. What's the fixed bound? 2^23, so the largest prime number is 8388593. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Posets: interval/closed_interval
On Wed, 12 Nov 2014, Travis Scrimshaw wrote: That's exactly what I'm saying. With this change, that may not occur if someone had overwritten interval() with some slightly different behavior in a subclass and was calling closed_interval(), they would experience an unexpected change (or, perhaps more likely, a major slow-down). It would be calling the interval() of FinitePoset rather than the subclass. rsk.py contains robinson_schensted_knuth = RSK, posets.py contains Posets_all = Posets and poset_examples.py contains posets = Posets. Does same thing happen with those also? * * * As I wrote to ticket, it seems a little confusing for me to have documentation with two functions, both with examples and so, that actually does same thing. Maybe docstring of other could be only Alias for linkxxx()/link.? -- Jori Mäntysalo -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 2014-11-12 23:09, William Stein wrote: There's also maybe 5000+ (??) lines of examples in other documentation You also forgot Cython files. I get a total of 239600 doctests (not counting the non-English documentation since those are translated files): $ find src/sage src/doc/en -type f |xargs cat | grep -c '^ *sage: ' 239600 Of course, some are optional/not tested/known bug tests or examples in .txt files (there are several old todo.txt and notes.txt files lying around) -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
IS that individual lines of doctests or doctest units themselves? -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 2014-11-13 10:29, mmarco wrote: IS that individual lines of doctests or doctest units themselves? I don't know what a doctest unit is, but the answer is: lines matching /^ *sage: / Note that this count *excludes* the Sage notebook, since that's a separate project (at least on paper). -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
where Sage tried to find det(A) “modulo a few additional primes”. When a prime p is large, Sage computes determinants (mod p) by lifting to Z. Sage defines “large p” by reference to the size n of the matrix in question. A re- cent tweak to another part of Sage’s matrix code had changed the definition of “large p” to depend only on a constant for n ≤ 63. Something does not depend on a constant, something is a constant. And the for n = 63 can be removed, it is a constant not depending on n. To clarify: the bound for large p *used* to depend on n but recent changes before #14032 changed it to a constant bound not depending on n at all. The reason that determinant() only broke for n = 63 is that the old non-constant bound was larger than the new constant bound for n = 63 only. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 2014-11-12 21:35, Ursula Whitcher wrote: Future releases of Sage will use FLINT, the Fast Library for Number The- ory, to compute the determinants of integer matrices. Today's future version will very likely be the current version when this article is published. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
2014-11-12 21:18:56 UTC+1, Ursula Whitcher wrote: All I can see from trac is that everything happened 22 months ago. How do I find how long it took to go from positive review to stable release? Once logged into sage's trac, follow the top-right link to Preferences then go to the Date and time tab. There you can set date relative/absolute format to absolute, and you will get absolute dates rather than how long ago. The Date and time tab has two more settings, - time zone, which has UTC among the options, - date format, which has ISO 8601 as an option. SL -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 12 November 2014 20:35, Ursula Whitcher whitc...@uwec.edu wrote: Article at http://people.uwec.edu/whitchua/notes/sagebugprocess.pdf has been updated based on feedback. UAW A bit more feedback - from a non-mathematician. 1) It would be better if rather than over-writing an old version of your document, you wrote a revised version and called is sagebugprocess-vesion-2 or similar. 2) Change Working mathematicians have an alternative to comparing the output of di erent(sic) black boxes: to Working mathematicians have a much better alternative than to compare the output of different black boxes, which may well share some of the same code 2) The phase A very con dent(sic) user might move straight to the next step: creating a ticket is wrong. You need to be a particularly confident use to report a bug in a trac ticket. I have reported bugs in software I know very little about, but enough to know there is a bug. Actually fixing the bug requires *ability*, rather than confidence. A totally incompetent user could try to fix the bug, but make a complete mess of it. But you stated something quite different. 3) You have totally missed the point I made, which Karl-Dieter Crisman wrote was a very good point. This is that comparing the output of two black boxes may well be comparing the output of two *identical* bits of code. I just checked the libraries for Mathematica version 7.0.1 on Solaris x86, and a view of the names of them libML64i3.so libML32i3.so liblapack.a libcblas.a libsndfile.so.1 libf77blas.a libatlas.a libgmp.so.3 libQtXml.so.4 libQtGui.so.4 libQtSql.so.4 libQtNetwork.so.4 Qt-Plugins libGLU.so libGLU.so.1 Mesa libQtSvg.so.4 libaspell.so.1 libQt3Support.so.4 libMesaGL.so libMesaGLU.so libQtCore.so.4 would suggest to me that Mathematica is using at least the following two maths libraries * ATLAS * GMP It would be worth checking a more recent release, to see if things have changed, but it is largely irrelevant. The fact remains WRI did use both those maths libraries is good enough. There's no reason Maple could not use them too. GMP is licensed under the GNU Lesser General Public License (LGPL), so Wolfram Research and Maplesoft are well within their rights to do that. In fact, they are well within their rights to hide that fact, as they could just compile GMP into a library libfoo.so, and you would be none the wiser. The mere fact they are black boxes means you don't have a clue. If there was a bug in ATLAS, comparing the output of Mathematica and Maple could lead you to a false sense of security, believing you are using two bits of software to perform a computation, but instead using the same bit of code twice. Both you, and the trio of mathematicians seem to have missed this point. This non-mathematician (i.e. me) thinks it is an important point !! 4) It might be worth briefly stating that if (hypothetically) such a bug was found in Sage, rather than just report the bug, the trio could have inspected Sage, determined the code used to find the determinate used algorithms A, B and C, using software packages X, Y and Z, then looked to find the bug in A, B, C or some code which links them together. That would hint Sage gets it right, but be more constructive than just saying it gets it right. You could put that in a few sentances - there is no need to detail the exact process they would have to use. Dave -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 13 November 2014 11:19, Dr. David Kirkby (Kirkby Microwave Ltd) drkir...@kirkbymicrowave.co.uk wrote: You need to be a particularly confident use to report a bug in a trac ticket. I have reported bugs in software I know very little about, but enough to know there is a bug. Of course I mean you do NOT have to be a particularly confident use to report a bug in a trac. Dave -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 12 November 2014 20:18, Ursula Whitcher whitc...@uwec.edu wrote: On 11/11/2014 3:41 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: If I am honest, I am not that convinced it is a good follow up comment, OK, I won't put your name on it ;) You can if I ultimately feel the submitted version is good ! Thanks for the comments! 1) Add a time line. How long it took from the reporting of the bug, to the bug fixed, peer reviewed, then to release of a new alpha/beta/release candidate and finally to the release of a stable version with the bug fixed. I suspect it was faster than the year or so the bug has remained in Mathematica. All I can see from trac is that everything happened 22 months ago. How do I find how long it took to go from positive review to stable release? I need to go to a hospital soon, so are not going to give full details, but a search of sage-release would show the dates when the release manager made a particular release. I think times (in days) are far more useful than actual dates, but you can work out the days from the dates. Dave -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On Thursday, November 13, 2014 11:19:37 AM UTC, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: The mere fact they are black boxes means you don't have a clue Which patches did Wolfram apply to ATLASGMP, and which versions did they use? I know we apply patches, so its extremely unlikely that we have identical libraries here even if upstream is the same. Also, without being able to trace the program flow we don't even know whether Mathematica was using ATLAS in that particular computation or not. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 2014-11-13 12:19, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: di erent(sic) con dent(sic) I think these are font issues with your PDF reader. You are missing the glyphs for the ligatures ff and fi. I don't have this problem (qpdfview on Gentoo Linux) -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
LOn 13 Nov 2014 11:19, Dr. David Kirkby (Kirkby Microwave Ltd) drkir...@kirkbymicrowave.co.uk wrote: 4) It might be worth briefly stating that if (hypothetically) such a bug was found in Sage, rather than just report the bug, the trio could have inspected Sage, determined the code used to find the determinate used algorithms A, B and C, using software packages X, Y and Z, then looked to find the bug in A, B, C or some code which links them together. I meant bug in X, Y or Z, rather than A, B or C. But thinking about it more, there could be an error in algorithm A, B or C. Or perhaps use of such an algorithm was inappropriate. Clearly with open source software, a lot more possibilities exist if a bug is found. Dave -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 13 Nov 2014 11:27, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2014-11-13 12:19, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: di erent(sic) con dent(sic) I think these are font issues with your PDF reader. You are missing the glyphs for the ligatures ff and fi. I don't have this problem (qpdfview on Gentoo Linux) Thanks. I was using Acrobat Reader on Solaris. Anyway, I think there are are some fundamental flaws in the paper. Dave -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Problems with building Sage because of package ecm-6.4.4.
So I tried to reinstall Sage 6.3. on my Lenovo Edge E540 with Ubuntu 12.04 in different ways, but make always fails because of the following error message: Error building Sage. The following package(s) may have failed to build: package: ecm-6.4.4 Here is the part of the log file that I think is causing the mistake Now building GMP-ECM... make[3]: Entering directory `/home/mussna/sage/sage-6.3/local/var/tmp/sage/build/ecm-6.4.4/src' make all-recursive make[4]: Entering directory `/home/mussna/sage/sage-6.3/local/var/tmp/sage/build/ecm-6.4.4/src' Making all in x86_64 make[5]: Entering directory `/home/mussna/sage/sage-6.3/local/var/tmp/sage/build/ecm-6.4.4/src/x86_64' m4 -I../ -DOPERATION_mulredc1 `test -f mulredc1.asm || echo './'`mulredc1.asm mulredc1.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc1.lo mulredc1.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc1.s -o mulredc1.o m4 -I../ -DOPERATION_mulredc2 `test -f mulredc2.asm || echo './'`mulredc2.asm mulredc2.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc2.lo mulredc2.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc2.s -o mulredc2.o m4 -I../ -DOPERATION_mulredc3 `test -f mulredc3.asm || echo './'`mulredc3.asm mulredc3.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc3.lo mulredc3.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc3.s -o mulredc3.o m4 -I../ -DOPERATION_mulredc4 `test -f mulredc4.asm || echo './'`mulredc4.asm mulredc4.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc4.lo mulredc4.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc4.s -o mulredc4.o m4 -I../ -DOPERATION_mulredc5 `test -f mulredc5.asm || echo './'`mulredc5.asm mulredc5.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc5.lo mulredc5.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc5.s -o mulredc5.o m4 -I../ -DOPERATION_mulredc6 `test -f mulredc6.asm || echo './'`mulredc6.asm mulredc6.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc6.lo mulredc6.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc6.s -o mulredc6.o m4 -I../ -DOPERATION_mulredc7 `test -f mulredc7.asm || echo './'`mulredc7.asm mulredc7.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc7.lo mulredc7.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc7.s -o mulredc7.o m4 -I../ -DOPERATION_mulredc8 `test -f mulredc8.asm || echo './'`mulredc8.asm mulredc8.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc8.lo mulredc8.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc8.s -o mulredc8.o m4 -I../ -DOPERATION_mulredc9 `test -f mulredc9.asm || echo './'`mulredc9.asm mulredc9.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc9.lo mulredc9.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc9.s -o mulredc9.o m4 -I../ -DOPERATION_mulredc10 `test -f mulredc10.asm || echo './'`mulredc10.asm mulredc10.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc10.lo mulredc10.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc10.s -o mulredc10.o m4 -I../ -DOPERATION_mulredc11 `test -f mulredc11.asm || echo './'`mulredc11.asm mulredc11.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc11.lo mulredc11.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc11.s -o mulredc11.o m4 -I../ -DOPERATION_mulredc12 `test -f mulredc12.asm || echo './'`mulredc12.asm mulredc12.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc12.lo mulredc12.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc12.s -o mulredc12.o m4 -I../ -DOPERATION_mulredc13 `test -f mulredc13.asm || echo './'`mulredc13.asm mulredc13.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc13.lo mulredc13.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc13.s -o mulredc13.o m4 -I../ -DOPERATION_mulredc14 `test -f mulredc14.asm || echo './'`mulredc14.asm mulredc14.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc14.lo mulredc14.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc14.s -o mulredc14.o m4 -I../ -DOPERATION_mulredc15 `test -f mulredc15.asm || echo './'`mulredc15.asm mulredc15.s /bin/bash ../libtool --mode=compile gcc -march=native -g -O3 -fPIC -c -o mulredc15.lo mulredc15.s libtool: compile: gcc -march=native -g -O3 -fPIC -c mulredc15.s -o mulredc15.o m4 -I../ -DOPERATION_mulredc16 `test -f mulredc16.asm || echo './'`mulredc16.asm mulredc16.s /bin/bash
Re: [sage-devel] Problems with building Sage because of package ecm-6.4.4.
On 2014-11-13 15:58, Florian Mussner wrote: So what can I do to make it work? Upgrade your compiler toolchain or build Sage with SAGE_INSTALL_GCC=yes. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Problems with building Sage because of package ecm-6.4.4.
Thank you, I will try that Am Donnerstag, 13. November 2014 16:04:48 UTC+1 schrieb Jeroen Demeyer: On 2014-11-13 15:58, Florian Mussner wrote: So what can I do to make it work? Upgrade your compiler toolchain or build Sage with SAGE_INSTALL_GCC=yes. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
Yes. Note also here: http://mathworld.wolfram.com/AbsoluteValue.html which says that complex derivative of d|z|/dz does not exist, as Cauchy-Riemann equations do not hold for Abs(z). And: As a result of the fact that computer algebra programs such as Mathematica generically deal with complex variables (i.e., the definition of derivative always means complex derivative), d|z|/dz correctly returns unevaluated by such software. So perhaps SymPy and Sage should return Derivative(Abs(x), x). Only when user specifies that x is real, only then we can differentiate. Ondrej On Thu, Nov 13, 2014 at 12:17 AM, Clemens Heuberger clemens.heuber...@aau.at wrote: possibly related to http://trac.sagemath.org/ticket/12588 ? Regards, CH Am 2014-11-13 um 06:19 schrieb Ondřej Čertík: Hi, With Sage 6.3, I am getting: sage: abs(x).diff(x) x/abs(x) sage: abs(I*x).diff(x) -x/abs(I*x) But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x) must be the same. But in the first case we get x/abs(x), and in the second we got -x/abs(x). In SymPy, the answer is: In [1]: abs(x).diff(x) Out[1]: d d re(x)⋅──(re(x)) + im(x)⋅──(im(x)) dxdx ─ │x│ In [2]: x = Symbol(x, real=True) In [3]: abs(x).diff(x) Out[3]: sign(x) In [4]: abs(I*x).diff(x) Out[4]: sign(x) In [26]: var(x) Out[26]: x Which seems all correct --- in the complex case [1] we get a little messy expression, but a correct one. For a real case, we get the correct answer. In Wolfram Alpha, the answer of abs(I*x).diff(x) is x/abs(x): http://www.wolframalpha.com/input/?i=Diff%5BAbs%5Bi*x%5D%2C+x%5D Which is only correct for real x, but at least it is correct for this special case. The Sage result seems wrong for any x. Ondrej -- Univ.-Prof. Dr. Clemens HeubergerAlpen-Adria-Universität Klagenfurt Institut für Mathematik, Universitätsstraße 65-67, 9020 Klagenfurt, Austria Tel: +43 463 2700 3121Fax: +43 463 2700 99 3121 clemens.heuber...@aau.athttp://wwwu.aau.at/cheuberg -- You received this message because you are subscribed to the Google Groups 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Posets: interval/closed_interval
In those cases, those are functions (or classes), not methods, and so they are safe. There are cases where methods get aliased, and there the user my experience something unexpected when first trying to subclass, but they won't experience a sudden change when upgrading Sage. However I'm not opposed to mentioning in the docstring that it is an alias. Yet the docstring is short, so I won't remove it. IMO we should never have the docstring just be Alias for :meth:`foo`, at the very least the short description should tell what the (redirected) function does. Best, Travis On Thursday, November 13, 2014 1:18:11 AM UTC-8, Jori Mantysalo wrote: On Wed, 12 Nov 2014, Travis Scrimshaw wrote: That's exactly what I'm saying. With this change, that may not occur if someone had overwritten interval() with some slightly different behavior in a subclass and was calling closed_interval(), they would experience an unexpected change (or, perhaps more likely, a major slow-down). It would be calling the interval() of FinitePoset rather than the subclass. rsk.py contains robinson_schensted_knuth = RSK, posets.py contains Posets_all = Posets and poset_examples.py contains posets = Posets. Does same thing happen with those also? * * * As I wrote to ticket, it seems a little confusing for me to have documentation with two functions, both with examples and so, that actually does same thing. Maybe docstring of other could be only Alias for linkxxx()/link.? -- Jori Mäntysalo -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
What i mean is that, for example: sage: R.x,y = PolynomialRing(QQ) sage: I = R.ideal([x^2 - y ^2, x + y +1]) sage: I.groebner_basis() [x + 1/2, y + 1/2] Is just one doctest unit (since it is really one test going on, we only check that the groebner basis coincides with the expected one). But it involves three lines that match 'sage:' -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On Thu, Nov 13, 2014 at 8:00 AM, mmarco mma...@unizar.es wrote: What i mean is that, for example: sage: R.x,y = PolynomialRing(QQ) sage: I = R.ideal([x^2 - y ^2, x + y +1]) sage: I.groebner_basis() [x + 1/2, y + 1/2] Is just one doctest unit (since it is really one test going on, we only check that the groebner basis coincides with the expected one). But it involves three lines that match 'sage:' The answer to your original question IS that individual lines of doctests or doctest units themselves? is clear since Jereon posted the (very nice) code he used to compute the total: $ find src/sage src/doc/en -type f |xargs cat | grep -c '^ *sage: ' 239600 It would be nice if somebody wrote a more sophisticated scanner to compute the number of doctest units, as you suggest above. William -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Posets: interval/closed_interval
Is there some Python idiom to alias class methods that respects
subclassing? Usually the docstring of aliases in Sage containes less
examples, and when the original method is updated (e.g. warn about an
edge case), there is a risk of not updating the alias' docstring.
What I would like to see is, assuming we have something like
class C(object):
def foo():
The full docstring of foo
alias(foo, bar)
is that automagically bar.__doc__ is now
bar is an alias of :meth:`C.foo`.
The full docstring of foo
Or do we have to mess with C.__{get,set}attr__?
Regards,
TB
On 11/13/2014 04:54 PM, Travis Scrimshaw wrote:
In those cases, those are functions (or classes), not methods, and
so they are safe. There are cases where methods get aliased, and there
the user my experience something unexpected when first trying to
subclass, but they won't experience a sudden change when upgrading Sage.
However I'm not opposed to mentioning in the docstring that it is an
alias. Yet the docstring is short, so I won't remove it. IMO we should
never have the docstring just be Alias for :meth:`foo`, at the very
least the short description should tell what the (redirected) function does.
Best,
Travis
On Thursday, November 13, 2014 1:18:11 AM UTC-8, Jori Mantysalo wrote:
On Wed, 12 Nov 2014, Travis Scrimshaw wrote:
That's exactly what I'm saying. With this change, that may not
occur if
someone had overwritten interval() with some slightly different
behavior in
a subclass and was calling closed_interval(), they would
experience an
unexpected change (or, perhaps more likely, a major slow-down).
It would be
calling the interval() of FinitePoset rather than the subclass.
rsk.py contains robinson_schensted_knuth = RSK, posets.py contains
Posets_all = Posets and poset_examples.py contains posets = Posets.
Does same thing happen with those also?
* * *
As I wrote to ticket, it seems a little confusing for me to have
documentation with two functions, both with examples and so, that
actually
does same thing. Maybe docstring of other could be only Alias for
linkxxx()/link.?
--
Jori Mäntysalo
--
You received this message because you are subscribed to the Google
Groups sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-devel+unsubscr...@googlegroups.com
mailto:sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com
mailto:sage-devel@googlegroups.com.
Visit this group at http://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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Posets: interval/closed_interval
I would like to see is, assuming we have something like class C(object): def foo(): The full docstring of foo alias(foo, bar) +1 to that ! 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
All I can see from trac is that everything happened 22 months ago. How do I find how long it took to go from positive review to stable release? ... a search of sage-release would show the dates when the release manager made a particular release. I think times (in days) are far more useful than actual dates, but you can work out the days from the dates. Unfortunately, we no longer use the Merged in part of Trac, which was a VERY efficient way to find this out. Searching through git history and then trying to forward to the next release is something for git wizards, no doubt some command using tag... amazingly, I found something relevant. $ git tag --contains 4f8b380 6.4.rc1 6.4.rc2 Hope this helps. It should not be necessary for people to spend time figuring this out, though; you should be able to work it out without using Trac or searching through sage-release - indeed, without knowing about commits at all, because many people who want to know what version of Sage has such-and-such fixed won't be developers, just users. - kcrisman -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 2014-11-13 17:07, William Stein wrote: It would be nice if somebody wrote a more sophisticated scanner to compute the number of doctest units, as you suggest above. I'm sure this could be added easily to the doctest framework. I don't really see the point though... a single doctest unit can contain many independent tests. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Future NTL versions and exception handling
Sage's wrapping of NTL should be just fine as long as it's declared in the Cython declarations, but there's a question of all the libraries that use NTL indirectly which may have more difficulty adapting to exceptions being thrown though their call stacks. On Tue, Nov 11, 2014 at 3:48 PM, Francesco Biscani bluesca...@gmail.com wrote: OOM exception handling is gonna be hard to implement, as GMP does not provide any mechanism to recover from memory errors. You can replace the GMP memory management functions but the usual problem with that approach is that you might be potentially interacting with other packages which might also want to override the default functions. Another problem is that IIRC throwing C++ exceptions from C is undefined (or maybe implementation-defined?) behaviour. In any case, exceptions are the way to go when you program in C++. A well-coded C++ program should state precisely what level of exception safety the routines provide (no-throw, strong, basic), and how and what a routine can throw. Ideally you would want strong exception safety always - this is quite doable but sometimes for the sake of performance basic exception safety is a good compromise. Of course anything involving move semantics should be marked noexcept. Another typical suggestion is always to use RAII patterns when coding routines that can throw - that way you are guaranteed that any resource is properly cleaned up before exiting the function through an exception. C++11 also has good support for handling exceptions in threads, including transporting exceptions between threads. In particular, using an std::future for managing the return value of (or the exception thrown within) a thread is pretty handy. Cheers, Francesco. On 12 November 2014 00:05, Jean-Pierre Flori jpfl...@gmail.com wrote: On Tuesday, November 11, 2014 11:55:49 PM UTC+1, Volker Braun wrote: What kind of error states are we talking about? divide by zero and out of memory? Exactly, that is exactly the kind of stuff Victor mentioned. IMHO a C++ library should just throw C++ exceptions, thats what they are here for. If only for better readability - less bugs. If you declare methods with except + to Cython then they will automatically be converted into Python exceptions, so its also very convenient for us. Pynac uses that all the time. Pretty much the only potential downside are rumors that exceptions might possibly hinder the optimizer. Though I've never seen that in a reasonable benchmark. While that is certainly a possibility, it would just be an optimizer bug. All reasonable C++ compilers uses a zero-cost model so its at least as fast as handling / returning some error flag. What _is_ expensive is when an exception occurs, but in C++ you are not supposed to use exceptions for program flow like in Python. On Tuesday, November 11, 2014 10:15:44 PM UTC, Jean-Pierre Flori wrote: Dear all, As you must have noticed, Victor Shoup just released a new thread safe version of NTL. He also took the opportunity to ask me (and surely a bunch of other people) what would be expected from exception handling in NTL Currently NTL just prints something and then aborts. Note that we patch that in Sage to call one of our own functions and avoid aborting. I'm no C++ expert and don't usually play with exceptions, so I don't have anything that sart to say. But your comments/ideas/suggestions are more than welcomed. I can gather them and forward them back to Victor. Best, JP -- You received this message because you are subscribed to the Google Groups 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 http://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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] review tutorial en español
Spanish speakers: After some neglect, #7192, #10165, and #10180 are ready for review, hopefully just minor edits needed? (And for those great at tracking down subtle Sphinx errors, #10180 has one of those...) -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On Thu, Nov 13, 2014 at 8:53 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2014-11-13 17:07, William Stein wrote: It would be nice if somebody wrote a more sophisticated scanner to compute the number of doctest units, as you suggest above. I'm sure this could be added easily to the doctest framework. I don't really see the point though... a single doctest unit can contain many independent tests. We could define a doctest unit to be a sequence of inputs followed by some verified output, terminated by a new input. So: sage: 2+2 4 sage: a = 5 sage: 3+a 8 Is *two* doctest units.If we're testing anything at all about running code except it didn't crash (e..g, the a=5 line), then this seems meaningful. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
It has always seemed very inconvenient to me that computer algebra programs such as Mathematica choose to define derivative as complex-derivative. I believe a reasonable alternative is what is known as a Wirtinger derivative. Wirtinger derivatives exist for all continuous complex-valued functions including non-holonomic functions and permit the construction of a differential calculus for functions of complex variables that is analogous to the ordinary differential calculus for functions of real variables http://en.wikipedia.org/wiki/Wirtinger_derivatives Wirtinger derivatives come in conjugate pairs but we have f(x).diff(conjugate(x)) = conjugate(conjugate(f(x).diff(x)) so we really only need one derivative given an appropriate conjugate function. The Cauchy-Riemann equations reduce to f(x).diff(conjugate(x)) = 0 I also like that abs is related to the sgn function abs(x).diff(x) = x/abs(x) This is consistent with abs(x)=sqrt(x*conjugate(x)) The Wirtinger derivative of abs(x) is 1/2 x/abs(x). Its total Wirtinger derivative is x/abs(x). I have implemented conjugate and Wirtinger derivatives in FriCAS http://axiom-wiki.newsynthesis.org/SandBoxWirtinger Unfortunately I have not yet been able to convince the FriCAS developers of the appropriateness of this approach. I would be happy to find someone with whom to discuss this further, pro and con. The discussion on the FriCAS email list consisted mostly of the related proper treatment of conjugate without making explicit assumptions about variables. Regards, Bill Page. On 13 November 2014 10:29, Ondřej Čertík ondrej.cer...@gmail.com wrote: Yes. Note also here: http://mathworld.wolfram.com/AbsoluteValue.html which says that complex derivative of d|z|/dz does not exist, as Cauchy-Riemann equations do not hold for Abs(z). And: As a result of the fact that computer algebra programs such as Mathematica generically deal with complex variables (i.e., the definition of derivative always means complex derivative), d|z|/dz correctly returns unevaluated by such software. So perhaps SymPy and Sage should return Derivative(Abs(x), x). Only when user specifies that x is real, only then we can differentiate. Ondrej On Thu, Nov 13, 2014 at 12:17 AM, Clemens Heuberger clemens.heuber...@aau.at wrote: possibly related to http://trac.sagemath.org/ticket/12588 ? Regards, CH Am 2014-11-13 um 06:19 schrieb Ondřej Čertík: Hi, With Sage 6.3, I am getting: sage: abs(x).diff(x) x/abs(x) sage: abs(I*x).diff(x) -x/abs(I*x) But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x) must be the same. But in the first case we get x/abs(x), and in the second we got -x/abs(x). In SymPy, the answer is: In [1]: abs(x).diff(x) Out[1]: d d re(x)⋅──(re(x)) + im(x)⋅──(im(x)) dxdx ─ │x│ In [2]: x = Symbol(x, real=True) In [3]: abs(x).diff(x) Out[3]: sign(x) In [4]: abs(I*x).diff(x) Out[4]: sign(x) In [26]: var(x) Out[26]: x Which seems all correct --- in the complex case [1] we get a little messy expression, but a correct one. For a real case, we get the correct answer. In Wolfram Alpha, the answer of abs(I*x).diff(x) is x/abs(x): http://www.wolframalpha.com/input/?i=Diff%5BAbs%5Bi*x%5D%2C+x%5D Which is only correct for real x, but at least it is correct for this special case. The Sage result seems wrong for any x. Ondrej -- Univ.-Prof. Dr. Clemens HeubergerAlpen-Adria-Universität Klagenfurt Institut für Mathematik, Universitätsstraße 65-67, 9020 Klagenfurt, Austria Tel: +43 463 2700 3121Fax: +43 463 2700 99 3121 clemens.heuber...@aau.athttp://wwwu.aau.at/cheuberg -- You received this message because you are subscribed to the Google Groups 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 http://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 http://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 http://groups.google.com/group/sage-devel.
Re: [sage-devel] Bug in abs(I*x).diff(x)
On 13 November 2014 12:16, Bill Page bill.p...@newsynthesis.org wrote: The Wirtinger derivative of abs(x) is 1/2 x/abs(x). Its total Wirtinger derivative is x/abs(x). Sorry, I should have written that the Wirtinger derivative of abs(x) is 1/2 conjugate(x)/abs(x) Bill. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Code of Conduct
Can we create an environment... where character matters, hard work is respected, humility is valued, and support for one another is unconditional? I admittedly stole that quote, but only because I wholeheartedly agree it is good to always aspire to better ourselves. Some of the Sage developers who are better with words than me went ahead and stole a lot more, mostly from Fedora (http://fedoraproject.org/code-of-conduct) and Django ( https://www.djangoproject.com/conduct), to formulate a Code of Conduct for the Sage project. I'm happy to present it here, and welcome everyone to vote on it. Code of Conduct --- The Sage community is comprised of an international mixture of mathematicians, computer scientists, engineers, researchers, teachers, amateurs, and others with varied backgrounds. This diversity is one of our strengths, but it can also lead to communication problems and unhappiness. People who love working on Sage can more effectively collaborate with others if they follow this code. If you believe someone is violating the code of conduct, we ask that you report it by emailing sage-ab...@googlegroups.com. The group administrators will consider the issue and explore resolutions. It is also possible to move heated discussions to the mailing list sage-fl...@googlegroups.com. 1) Be friendly and patient. 2) Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. 3) Be considerate. Your work will be used by other people and you in turn will depend on the work of others. Any decision you take will affect users and developers so you should take those consequences into account when making decisions. Conversely, Sage is constantly evolving, and earlier decisions that were made in good faith may sometimes need to be reconsidered. Nonetheless, we should still appreciate the hard work done in the past. 4) Be respectful and polite. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to morph into personal attacks. It is important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Sage community should be respectful when dealing with other developers and users. When we disagree, we should try to understand why. Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Being unable to understand why someone holds a viewpoint does not mean that they are wrong. Do not forget that it is human to err. Blame alone gets us nowhere, it is better to help resolve issues so we can all learn from our mistakes. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Code of Conduct
On Thu, Nov 13, 2014 at 10:48 AM, Volker Braun vbraun.n...@gmail.com wrote: Can we create an environment... where character matters, hard work is respected, humility is valued, and support for one another is unconditional? I admittedly stole that quote, but only because I wholeheartedly agree it is good to always aspire to better ourselves. Some of the Sage developers who are better with words than me went ahead and stole a lot more, mostly from Fedora (http://fedoraproject.org/code-of-conduct) and Django (https://www.djangoproject.com/conduct), to formulate a Code of Conduct for the Sage project. I'm happy to present it here, and welcome everyone to vote on it. For concreteness: [ ] Yes, this is a great idea. About time! [ ] This looks good, but it would be better if... (insert suggestions). [ ] No, I greatly value the freedom to spout offensive profanity, and will fork Sage in frustration if there is such a code. (We really do want to know if there are any developers who would quit working on Sage if we have this Code of Conduct; by definition such a person should have no hesitation publicly saying so in response to this email. I'm imagining what someone like Linus Torvalds might say if this were proposed on the Linux kernel mailing list. I just want people to think -- having a code of conduct isn't _obviously_ the right thing to do.) Code of Conduct --- The Sage community is comprised of an international mixture of mathematicians, computer scientists, engineers, researchers, teachers, amateurs, and others with varied backgrounds. This diversity is one of our strengths, but it can also lead to communication problems and unhappiness. People who love working on Sage can more effectively collaborate with others if they follow this code. If you believe someone is violating the code of conduct, we ask that you report it by emailing sage-ab...@googlegroups.com. The group administrators will consider the issue and explore resolutions. It is also possible to move heated discussions to the mailing list sage-fl...@googlegroups.com. 1) Be friendly and patient. 2) Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. 3) Be considerate. Your work will be used by other people and you in turn will depend on the work of others. Any decision you take will affect users and developers so you should take those consequences into account when making decisions. Conversely, Sage is constantly evolving, and earlier decisions that were made in good faith may sometimes need to be reconsidered. Nonetheless, we should still appreciate the hard work done in the past. 4) Be respectful and polite. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to morph into personal attacks. It is important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Sage community should be respectful when dealing with other developers and users. When we disagree, we should try to understand why. Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Being unable to understand why someone holds a viewpoint does not mean that they are wrong. Do not forget that it is human to err. Blame alone gets us nowhere, it is better to help resolve issues so we can all learn from our mistakes. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Code of Conduct
Hi Great to have in place to refer to as an educational guideline (not to be abused as strict rules). It could also mention core values of Libre Software, with additional emphasis on scientific transparency. Regards, Jan On 13 November 2014 21:00, William Stein wst...@gmail.com wrote: On Thu, Nov 13, 2014 at 10:48 AM, Volker Braun vbraun.n...@gmail.com wrote: Can we create an environment... where character matters, hard work is respected, humility is valued, and support for one another is unconditional? I admittedly stole that quote, but only because I wholeheartedly agree it is good to always aspire to better ourselves. Some of the Sage developers who are better with words than me went ahead and stole a lot more, mostly from Fedora (http://fedoraproject.org/code-of-conduct) and Django (https://www.djangoproject.com/conduct), to formulate a Code of Conduct for the Sage project. I'm happy to present it here, and welcome everyone to vote on it. For concreteness: [ ] Yes, this is a great idea. About time! [ ] This looks good, but it would be better if... (insert suggestions). [ ] No, I greatly value the freedom to spout offensive profanity, and will fork Sage in frustration if there is such a code. (We really do want to know if there are any developers who would quit working on Sage if we have this Code of Conduct; by definition such a person should have no hesitation publicly saying so in response to this email. I'm imagining what someone like Linus Torvalds might say if this were proposed on the Linux kernel mailing list. I just want people to think -- having a code of conduct isn't _obviously_ the right thing to do.) Code of Conduct --- The Sage community is comprised of an international mixture of mathematicians, computer scientists, engineers, researchers, teachers, amateurs, and others with varied backgrounds. This diversity is one of our strengths, but it can also lead to communication problems and unhappiness. People who love working on Sage can more effectively collaborate with others if they follow this code. If you believe someone is violating the code of conduct, we ask that you report it by emailing sage-ab...@googlegroups.com. The group administrators will consider the issue and explore resolutions. It is also possible to move heated discussions to the mailing list sage-fl...@googlegroups.com. 1) Be friendly and patient. 2) Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. 3) Be considerate. Your work will be used by other people and you in turn will depend on the work of others. Any decision you take will affect users and developers so you should take those consequences into account when making decisions. Conversely, Sage is constantly evolving, and earlier decisions that were made in good faith may sometimes need to be reconsidered. Nonetheless, we should still appreciate the hard work done in the past. 4) Be respectful and polite. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to morph into personal attacks. It is important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Sage community should be respectful when dealing with other developers and users. When we disagree, we should try to understand why. Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Being unable to understand why someone holds a viewpoint does not mean that they are wrong. Do not forget that it is human to err. Blame alone gets us nowhere, it is better to help resolve issues so we can all learn from our mistakes. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- .~. /V\ Jan Groenewald /( )\
Re: [sage-devel] Code of Conduct
good to always aspire to better ourselves. Some of the Sage developers who are better with words than me went ahead and stole a lot more, mostly from Fedora (http://fedoraproject.org/code-of-conduct) and Django (https://www.djangoproject.com/conduct), to formulate a Code of Conduct for the Sage project. I'm happy to present it here, and welcome everyone to vote on it. This also seems to channel an inner Larry Wall :) For concreteness: [X] This looks good, but it would be better if... (insert suggestions). I'd suggest that the language of reporting a violation could be softened, since naturally there will even be disagreements about what constitutes a 'violation'... as we know, this has been debated over the years on various threads that may or may not have turned personal, including by very valuable members of the community. I'd hate to have some kicking out policy for that, referring to sage-flame seems like a very good idea. Indeed, eventually (already? I don't think so, but who knows) we will have people coming from very different cultural contexts as to what constitutes respect or considerateness - e.g. directness versus face-saving versus something yet again? What I do think this brings is a tool to remind all of us (!) that everything here reflects on Sage, whether or not you care about your own personal reputation. So more or less in support, and certainly in support very much of the values themselves. - kcrisman PS that includes trying to keep things PG and SFW! I fully expect our first elementary-schooler to contribute something within a year... am I kidding? I don't know! I wouldn't be surprised. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Bug in abs(I*x).diff(x)
We had a similar problem with the complex derivative of logarithms in combination with the complex conjugate, where I also the use of Wirtinger Operators would solve the problem: https://groups.google.com/forum/?hl=en#!topic/sage-support/bEMPMEYeZKU Having them in Sage would be a great achievement! Although this has some sense in complex analysis one should be careful with 'deriving' the absolute value, since it results in the weak derivative ( http://en.wikipedia.org/wiki/Weak_derivative) , which is in a broader sense the derivative in the distribution sense. Thus we have infinite possible derivatives With this expression it is indirectly forbidden to asign a specific value to the unspecified value at zero: sage: f = abs(x).diff(x) sage: f(x=0) --- ValueErrorTraceback (most recent call last) ipython-input-14-615bbebcb37c in module() 1 f(x=Integer(0)) /home/maldun/sage/sage-6.3/local/lib/python2.7/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression.__call__ (build/cythonized/sage/symbolic/expression.cpp:21933)() /home/maldun/sage/sage-6.3/local/lib/python2.7/site-packages/sage/symbolic/ring.so in sage.symbolic.ring.SymbolicRing._call_element_ (build/cythonized/sage/symbolic/ring.cpp:8493)() /home/maldun/sage/sage-6.3/local/lib/python2.7/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression.substitute (build/cythonized/sage/symbolic/expression.cpp:21183)() ValueError: power::eval(): division by zero This is in some sense good, since we don't have to care about the derivative at zero, but in an other sense it is not so good, since the subdifferential ∂abs(0) = [0,1] is a bounded and with this definition one could come to the false conclusion that abs(x) has a pole, althoug by taking limits one can easily see that it should be bounded at zero. For symbolic purposes, of course one could live on 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Bug in abs(I*x).diff(x)
This is in some sense good, since we don't have to care about the derivative at zero, but in an other sense it is not so good, since the subdifferential ∂abs(0) = [0,1] is a bounded and with this definition one could come to the false conclusion that abs(x) has a pole, althoug by taking limits one can easily see that it should be bounded at zero. Sorry I meant ∂abs(0) = [-1,1] ... And another thing to add: I think the only clean solution could be a warning like: Warning: This is not a derivative in the classical sense! But I don't know if this is really worth the effort ... -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
Hi Bill, On Thu, Nov 13, 2014 at 10:16 AM, Bill Page bill.p...@newsynthesis.org wrote: It has always seemed very inconvenient to me that computer algebra programs such as Mathematica choose to define derivative as complex-derivative. I believe a reasonable alternative is what is known as a Wirtinger derivative. Wirtinger derivatives exist for all continuous complex-valued functions including non-holonomic functions and permit the construction of a differential calculus for functions of complex variables that is analogous to the ordinary differential calculus for functions of real variables http://en.wikipedia.org/wiki/Wirtinger_derivatives Wirtinger derivatives come in conjugate pairs but we have f(x).diff(conjugate(x)) = conjugate(conjugate(f(x).diff(x)) so we really only need one derivative given an appropriate conjugate function. The Cauchy-Riemann equations reduce to f(x).diff(conjugate(x)) = 0 I also like that abs is related to the sgn function abs(x).diff(x) = x/abs(x) This is consistent with abs(x)=sqrt(x*conjugate(x)) The Wirtinger derivative of abs(x) is 1/2 x/abs(x). Its total Wirtinger derivative is x/abs(x). I have implemented conjugate and Wirtinger derivatives in FriCAS http://axiom-wiki.newsynthesis.org/SandBoxWirtinger Unfortunately I have not yet been able to convince the FriCAS developers of the appropriateness of this approach. I would be happy to find someone with whom to discuss this further, pro and con. The discussion on the FriCAS email list consisted mostly of the related proper treatment of conjugate without making explicit assumptions about variables. Thanks for your email! I haven't talked to you in a long time. Literally just today I learned about Wirtinger derivatives. The wikipedia page is *really* confusing to me. It took me a while to realize, that Wirtinger derivatives is simply the derivative with respect to z or conjugate(z). I.e. z = x + i*y conjugate(z) = x - i*y From this it follows: x = 1/2*(z + conjugate(z)) y = i/2*(-z+conjugate(z)) Then I take any function and write it in terms of z and conjugate(z), some examples: |z| = sqrt(z*conjugate(z)) Re z = x = 1/2 * (z + conjugate(z)) z^2 = (x+i*y)^2 And then I simply differentiate with respect to z or conjugate(z). This is called the Wirtinger derivative. So: d|z|/dz = d sqrt(z*conjugate(z)) / dz = 1/2*conjugate(z) / |z| As you said, the function is analytic if it doesn't functionally depend on conjugate(z), as can be shown easily. So |z| or Re z are not analytic, while z^2 is. If the function is analytic, then df/d conjugate(z) = 0, and df/dz is the complex derivative. Right? So for analytic functions, Wirtinger derivative gives the same answer as Mathematica. For non-analytic functions, Mathematica leaves it unevaluated, but Wirtinger derivative gives you something. How do you calculate the total Wirtinger derivative? How is that defined? Because I would like to get d|x| / d x = x / |x| for real x. And I don't see currently how is this formula connected to Wirtinger derivatives. Finally, the derivative operator in a CAS could return Wirtinger derivatives, I think it's a great idea, if somehow we can recover the usual formula for abs(x) with real x. What are the cons of this approach? Ondrej -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 11/13/2014 3:05 AM, Jeroen Demeyer wrote: On 2014-11-12 21:33, Ursula Whitcher wrote: On 11/11/2014 4:46 AM, Jeroen Demeyer wrote: * The sentence A recent tweak of another part of Sage’s matrix code had changed the definition of “small n” to n = 63. is wrong: what had changed is the bound on p to compute the determinant over GF(p) using LinBox (for larger p, we compute determinants over GF(p) by lifting to ZZ): it used to be the case that the bound in LinBox depended on n, this was changed to a fixed bound for p which was less than the old value for n = 63. What's the fixed bound? 2^23, so the largest prime number is 8388593. This is fixed as in the old, bad constant, rather than an improved bound which fixed the problem, right? UAW -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Problems with building Sage because of package ecm-6.4.4.
It worked, thank you very much! Am Donnerstag, 13. November 2014 16:04:48 UTC+1 schrieb Jeroen Demeyer: On 2014-11-13 15:58, Florian Mussner wrote: So what can I do to make it work? Upgrade your compiler toolchain or build Sage with SAGE_INSTALL_GCC=yes. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Code of Conduct
On 2014-11-13, Volker Braun vbraun.n...@gmail.com wrote: Can we create an environment... where character matters, hard work is respected, humility is valued, and support for one another is unconditional? Yes, I think you can, although I think formulating a code of conduct is mostly a distraction. People take their cues from others who are perceived to be socially superior, so the key is to get anybody who has a lot of visibility / brownie points / respect / whatever to get on the bandwagon. Whatever those people practice, is going to become the conventional way, so we had better hope they have good habits. About good habits, I think it's really pretty simple: * talk about ideas instead of people * don't feed the trolls * get to the point But if someone like, oh, I don't know, Linus Torvalds for instance, consistently treats others like shit, everybody else joins the fun, and everything goes downhill from there. As I get older, I've become fascinated by the way that people pick up culture (i.e., shared assumptions about how things work) from each other, in all kinds of situations. I'm pretty sure that informal cues vastly outweigh the formal ones, for better or worse. For what it's worth, Robert Dodier -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
The answer to your original question IS that individual lines of doctests or doctest units themselves? is clear since Jereon posted the (very nice) code he used to compute the total: $ find src/sage src/doc/en -type f |xargs cat | grep -c '^ *sage: ' 239600 Using ag I find: sage: ag '^\s*sage:'| wc -l 300410 If we just want to look for testing blocks then a crude lower bound is: sage: ag '^\s*(TEST|EXAMPLE)S::' | wc -l 62882 Andrew -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Code of Conduct
Hi! On 2014-11-13, William Stein wst...@gmail.com wrote: For concreteness: [ ] Yes, this is a great idea. About time! [ ] This looks good, but it would be better if... (insert suggestions). [ ] No, I greatly value the freedom to spout offensive profanity, and will fork Sage in frustration if there is such a code. (We really do want to know if there are any developers who would quit working on Sage if we have this Code of Conduct; by definition such a person should have no hesitation publicly saying so in response to this email. I'm imagining what someone like Linus Torvalds might say if this were proposed on the Linux kernel mailing list. I just want people to think -- having a code of conduct isn't _obviously_ the right thing to do.) I certainly see the possibility that a contributor quits if s/he is mistreated by other contributors. I actually have first-hand experience: A couple of years ago, I was involved in the German translation of some parts of the Sage documentation. Another contributor personally insulted me here on the list, and even by comments that he tried to put into the Sage code. As a result, the German translation became a very low priority for me, and I am not even sure if it is completed now. However: If there was even the vague possibility of instrumenting a code of conduct to kick valuable contributors out, then by Murphy's law it would eventually happen. But I think it must not happen, which is why I am strongly against a code of conduct that has the status of enforceable law within our community. I don't think that publishing a code of conduct is the right thing to do. What really matters (also in the case of bullying at school) is: If people see that contributor A mistreats contributor B, then they should first of all be solidaric with B and openly express that they do not agree with how A acts--- *without* starting to mistreat A in turn. This, I think, is by far more important and helpful for B and for the community as a whole than to kick A out. Instead of publishing a code of conduct, I think it would be more helpful to explain by (constructed) examples how and why people get offended by certain ways of expressing concerns, and suggest better ways of expressing the concern. Best regards, Simon -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Code of Conduct
Hi Robert, On 2014-11-13, Robert Dodier robert.dod...@gmail.com wrote: Can we create an environment... where character matters, hard work is respected, humility is valued, and support for one another is unconditional? Yes, I think you can, although I think formulating a code of conduct is mostly a distraction. +1 People take their cues from others who are perceived to be socially superior, so the key is to get anybody who has a lot of visibility / brownie points / respect / whatever to get on the bandwagon. Whatever those people practice, is going to become the conventional way, so we had better hope they have good habits. About good habits, I think it's really pretty simple: * talk about ideas instead of people * don't feed the trolls * get to the point Very good comment, I think! Cheers, Simon -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: tab completion for list of associated objects
On Wednesday, 12 November 2014 21:27:50 UTC+11, Volker Braun wrote: The Sage code style is that methods are preferred over properties if in doubt. And even in plain Python I would really recommend to only use properties for static accessors. If you need to make a computation, use a method. This makes it clear to the user that there is a computation involved, even if it is just enumerating the possible representations for future use. It might be a minor inconvenience to have to write sage: A=MyFavouriteAlgebra() sage. A.representations() sage: _.tab but its much more annoying to have A.representations.tab hang for a long time and then potentially raise an out of memory error etc. Also your UI might automatically collect tab completions before you even press tab. The UI is essentially just a dictionary and it is constructed when A is first created. The objects that get included in it depend in a trivial way on the type and deformation parameters of the algebra A (i.e. arguments to __init__), so the run-time cost is negligible. My rationale for having this is the same as for the groups().tab expanders. If people don't like I'll remove it. Andrew -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi Bill, On Thu, Nov 13, 2014 at 10:16 AM, Bill Page bill.p...@newsynthesis.org wrote: It has always seemed very inconvenient to me that computer algebra programs such as Mathematica choose to define derivative as complex-derivative. I believe a reasonable alternative is what is known as a Wirtinger derivative. Wirtinger derivatives exist for all continuous complex-valued functions including non-holonomic functions and permit the construction of a differential calculus for functions of complex variables that is analogous to the ordinary differential calculus for functions of real variables http://en.wikipedia.org/wiki/Wirtinger_derivatives Wirtinger derivatives come in conjugate pairs but we have f(x).diff(conjugate(x)) = conjugate(conjugate(f(x).diff(x)) so we really only need one derivative given an appropriate conjugate function. The Cauchy-Riemann equations reduce to f(x).diff(conjugate(x)) = 0 I also like that abs is related to the sgn function abs(x).diff(x) = x/abs(x) This is consistent with abs(x)=sqrt(x*conjugate(x)) The Wirtinger derivative of abs(x) is 1/2 x/abs(x). Its total Wirtinger derivative is x/abs(x). I have implemented conjugate and Wirtinger derivatives in FriCAS http://axiom-wiki.newsynthesis.org/SandBoxWirtinger Unfortunately I have not yet been able to convince the FriCAS developers of the appropriateness of this approach. I would be happy to find someone with whom to discuss this further, pro and con. The discussion on the FriCAS email list consisted mostly of the related proper treatment of conjugate without making explicit assumptions about variables. Thanks for your email! I haven't talked to you in a long time. Literally just today I learned about Wirtinger derivatives. The wikipedia page is *really* confusing to me. It took me a while to realize, that Wirtinger derivatives is simply the derivative with respect to z or conjugate(z). I.e. z = x + i*y conjugate(z) = x - i*y From this it follows: x = 1/2*(z + conjugate(z)) y = i/2*(-z+conjugate(z)) Then I take any function and write it in terms of z and conjugate(z), some examples: |z| = sqrt(z*conjugate(z)) Re z = x = 1/2 * (z + conjugate(z)) z^2 = (x+i*y)^2 And then I simply differentiate with respect to z or conjugate(z). This is called the Wirtinger derivative. So: d|z|/dz = d sqrt(z*conjugate(z)) / dz = 1/2*conjugate(z) / |z| As you said, the function is analytic if it doesn't functionally depend on conjugate(z), as can be shown easily. So |z| or Re z are not analytic, while z^2 is. If the function is analytic, then df/d conjugate(z) = 0, and df/dz is the complex derivative. Right? To elaborate on this point, if the function has a complex derivative (i.e. it is analytic), then the complex derivative f'(z) = \partial f / \partial x. So to calculate a complex derivative with respect to z=x+i*y, we just need to differentiate with respect to x. It can be shown, that the Wirtinger derivatives df/dz is equal to \partial f / \partial x for analytic functions, i.e. when df/d conjugate(z) = 0. So in a CAS, we can simply define the derivative f'(z) as \partial f / \partial x for any function, even if it doesn't have a complex derivative. For any function we can show that: \partial f / \partial x = d f / d z + d f / d conjugate(z) Bill, is this what you call the total Wirtinger derivative? For example, for |z| we get: |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z| Using our definition, this holds for any complex z. Then, if z is real, we get: |z|' = z / |z| Which is exactly the usual real derivative. Bill, is this what you had in mind? That a CAS could return the derivative of abs(z) as Re(z) / abs(z) ? Ondrej So for analytic functions, Wirtinger derivative gives the same answer as Mathematica. For non-analytic functions, Mathematica leaves it unevaluated, but Wirtinger derivative gives you something. How do you calculate the total Wirtinger derivative? How is that defined? Because I would like to get d|x| / d x = x / |x| for real x. And I don't see currently how is this formula connected to Wirtinger derivatives. Finally, the derivative operator in a CAS could return Wirtinger derivatives, I think it's a great idea, if somehow we can recover the usual formula for abs(x) with real x. What are the cons of this approach? Ondrej -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
On 13 November 2014 19:24, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: As you said, the function is analytic if it doesn't functionally depend on conjugate(z), as can be shown easily. So |z| or Re z are not analytic, while z^2 is. If the function is analytic, then df/d conjugate(z) = 0, and df/dz is the complex derivative. Right? Yes. In my email I notice that I wrote holonomic but what I meant was holomorphic. Complex-analytic functions are holomorphic and vice-versa. ... So in a CAS, we can simply define the derivative f'(z) as \partial f / \partial x for any function, even if it doesn't have a complex derivative. Yes. For any function we can show that: \partial f / \partial x = d f / d z + d f / d conjugate(z) Bill, is this what you call the total Wirtinger derivative? Yes For example, for |z| we get: |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z| Using our definition, this holds for any complex z. Then, if z is real, we get: |z|' = z / |z| Which is exactly the usual real derivative. Bill, is this what you had in mind? That a CAS could return the derivative of abs(z) as Re(z) / abs(z) ? Ondrej So for analytic functions, Wirtinger derivative gives the same answer as Mathematica. For non-analytic functions, Mathematica leaves it unevaluated, but Wirtinger derivative gives you something. How do you calculate the total Wirtinger derivative? How is that defined? Because I would like to get d|x| / d x = x / |x| for real x. And I don't see currently how is this formula connected to Wirtinger derivatives. Finally, the derivative operator in a CAS could return Wirtinger derivatives, I think it's a great idea, if somehow we can recover the usual formula for abs(x) with real x. What are the cons of this approach? Ondrej -- You received this message because you are subscribed to the Google Groups 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Fwd: [sage-devel] Bug in abs(I*x).diff(x)
Sorry, I hit send before I was quite ready. To continue ... On 13 November 2014 19:24, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: ... For example, for |z| we get: |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z| Using our definition, this holds for any complex z. Then, if z is real, we get: |z|' = z / |z| Which is exactly the usual real derivative. Bill, is this what you had in mind? That a CAS could return the derivative of abs(z) as Re(z) / abs(z) ? Yes, exactly. I think a question might arise whether we should treat conjugate or Re as elementary. ... What are the cons of this approach? First, care needs to be taken to properly extend the chain rule to include the conjugate Wirtinger derivative where necessary. Second, in principle problems can arise when defining a test for constant functions. For example this is necessary as part of rewriting expressions in terms of the smallest number of elementary functions (normalize) as a kind of zero test for expressions in FriCAS/Axiom. Usually we assume that df(x)/dx = 0 is necessary and sufficient for f to be a constant function. But requiring that the total derivative d f / d z + d f / d conjugate(z) = 0 is not what we mean by constant. In fact it seems to be an open question whether Richardson's theorem can be extended to include conjugate as an elementary function in such a way that the zero test is still computable. This is the last point of discussion on the FriCAS email list. Bill. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Code of Conduct
I believe we need to have such a code-of-conduct posted stating the manner in which we should act. Like Jan and Simon, this should not be some strict set of rules that gets referenced every time someone feels another developer is out of line. By publishing such a code, we give explicit guideline which we want our contributors to try to adhere to. It should not be a zero tolerance policy, but it needs to be enforceable when necessary for clear repetitive violations. To give a counterpoint to Simon's analogy, we agree that bullying is bad, but by the rules, we can tell bullies explicitly what their doing is wrong, why we can't push the bullies down, and explain what will happen if the behavior escalates. Bullying can get so bad that the teachers need to step in and enact the correct punishment. Best, Travis On Thursday, November 13, 2014 11:00:58 AM UTC-8, William wrote: On Thu, Nov 13, 2014 at 10:48 AM, Volker Braun vbrau...@gmail.com javascript: wrote: Can we create an environment... where character matters, hard work is respected, humility is valued, and support for one another is unconditional? I admittedly stole that quote, but only because I wholeheartedly agree it is good to always aspire to better ourselves. Some of the Sage developers who are better with words than me went ahead and stole a lot more, mostly from Fedora (http://fedoraproject.org/code-of-conduct) and Django (https://www.djangoproject.com/conduct), to formulate a Code of Conduct for the Sage project. I'm happy to present it here, and welcome everyone to vote on it. For concreteness: [ ] Yes, this is a great idea. About time! [ ] This looks good, but it would be better if... (insert suggestions). [ ] No, I greatly value the freedom to spout offensive profanity, and will fork Sage in frustration if there is such a code. (We really do want to know if there are any developers who would quit working on Sage if we have this Code of Conduct; by definition such a person should have no hesitation publicly saying so in response to this email. I'm imagining what someone like Linus Torvalds might say if this were proposed on the Linux kernel mailing list. I just want people to think -- having a code of conduct isn't _obviously_ the right thing to do.) Code of Conduct --- The Sage community is comprised of an international mixture of mathematicians, computer scientists, engineers, researchers, teachers, amateurs, and others with varied backgrounds. This diversity is one of our strengths, but it can also lead to communication problems and unhappiness. People who love working on Sage can more effectively collaborate with others if they follow this code. If you believe someone is violating the code of conduct, we ask that you report it by emailing sage-...@googlegroups.com javascript:. The group administrators will consider the issue and explore resolutions. It is also possible to move heated discussions to the mailing list sage-...@googlegroups.com javascript:. 1) Be friendly and patient. 2) Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. 3) Be considerate. Your work will be used by other people and you in turn will depend on the work of others. Any decision you take will affect users and developers so you should take those consequences into account when making decisions. Conversely, Sage is constantly evolving, and earlier decisions that were made in good faith may sometimes need to be reconsidered. Nonetheless, we should still appreciate the hard work done in the past. 4) Be respectful and polite. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to morph into personal attacks. It is important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Sage community should be respectful when dealing with other developers and users. When we disagree, we should try to understand why. Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Being unable to understand why someone holds a viewpoint does not mean that they are wrong. Do not forget that it is human to err. Blame alone gets us nowhere, it is better to help resolve issues so we can all learn from our mistakes. -- You received this message because you are subscribed 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 javascript:. To post
Re: [sage-devel] Re: Posets: interval/closed_interval
Hi, I have used method aliasing (such as frobenius = frobenius_endomorphism) a lot. What should I be doing instead, and what is the problem? (I have to admit this thread was TL;DR to me.) Best regards, Darij -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Posets: interval/closed_interval
Yo !
I have used method aliasing (such as frobenius = frobenius_endomorphism)
a lot. What should I be doing instead, and what is the problem? (I have to
admit this thread was TL;DR to me.)
1) Build a class with a method named A, aliased by B
2) Extend this class and redefine A
B still points toward the old A.
For this, it would be nice to have a function doing B = alias('A') which
does the job 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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Posets: interval/closed_interval
Hi Nathan, On Thu, Nov 13, 2014 at 11:07 PM, Nathann Cohen nathann.co...@gmail.com wrote: 1) Build a class with a method named A, aliased by B 2) Extend this class and redefine A B still points toward the old A. OK, I see. Well, good enough that the classes I am talking about are not usually extended. Best regards, Darij -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Code of Conduct
I agree with Travis that it is good to have guidelines that one can point people to if discussions escalate. I agree that it is best to try to work things out mutually, but this does not always seem possible. So ... [X ] Yes, this is a great idea. About time! Best, Anne -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Bug in abs(I*x).diff(x)
The only clean solution for this behaviour would be a warning e.g: Warning: This Identity holds only almost everywhere! But I don't know if it's worth the effort ... -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Code of Conduct
Hi Travis, On 2014-11-14, Travis Scrimshaw tsc...@ucdavis.edu wrote: To give a counterpoint to Simon's analogy, we agree that bullying is bad, but by the rules, we can tell bullies explicitly what their doing is wrong, why we can't push the bullies down, and explain what will happen if the behavior escalates. Bullying can get so bad that the teachers need to step in and enact the correct punishment. In my experience, it is often the *teachers* who are bullying, in the sense that bullying pupils are just the teacher's tools to destroy pupils they don't like. But school aside. If person A verbally attacks person B, I still think it does not help to show a *disapproving* reaction towards person A, because then A may feel attacked, which may make his/her behaviour even worse, and which wouldn't help B at all. Instead, I suggest to show a *supporting* reaction towards person B, in order to make B stronger and prevent damage. As it has been said by (IIRC) Jan, it is important that authorities set a good example. It may not always help with any individual, but is the best way to keep a communicative environment healthy. And concerning those individuals for which a good example isn't good enough, I'd prefer to see a don't feed the troll policy. If person A realises that his/her stampede ended in a vacuum, then s/he will usually stop. And if there was harm done to B on the way towards the vacuum, then helping B has priority over banning A. Best regards, Simon -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Code of Conduct
On Friday, November 14, 2014 3:55:34 AM UTC+1, Travis Scrimshaw wrote: Bullying can get so bad that the teachers need to step in and enact the correct punishment. ...yet, in my experience, they usually don't, and often because the bullies are likable, or socially influential (e.g., son of the superintendent/major donor, comes from a good family), etc. Sometimes a teacher can unintentionally make a student feel like s/he is bullying her or him. Speech codes are sometimes used simply to shut down debate on topics that become culturally unfashionable, and are often applied unevenly. I personally prefer civilized discourse, but I've also noticed that Western society seems to have adopted an undercurrent of thin-skinned outrage. If someone wanted to add a patch that verifiably improved the performance of Sage on [insert your favorite subsystem here], what would you do if her or his comments were frequently abusive toward other contributors, or previous contributions? i.e., profanity-laced, derogatory, etc. Not the code itself, mind, just the comments in the trac ticket and/or discussion in sage-devel. Presumably, someone would take her/ him aside talk to him, but what if (as often happens) that person ignored the intervention continued to heap abuse on you? Would you reject the patch? If not, what's the point of the proposed code? Again, I like civilized discourse, but a code without consequences strikes me as worse than no code at all. -- You received this message because you are subscribed to the Google Groups 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
On Thu, Nov 13, 2014 at 6:56 PM, Bill Page bill.p...@newsynthesis.org wrote: Sorry, I hit send before I was quite ready. To continue ... On 13 November 2014 19:24, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: ... For example, for |z| we get: |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z| Using our definition, this holds for any complex z. Then, if z is real, we get: |z|' = z / |z| Which is exactly the usual real derivative. Bill, is this what you had in mind? That a CAS could return the derivative of abs(z) as Re(z) / abs(z) ? Yes, exactly. I think a question might arise whether we should treat conjugate or Re as elementary. Ok, thanks for the confirmation. There is an issue though --- since |z| is not analytic, the derivatives depend on the direction. So along x you get ... What are the cons of this approach? First, care needs to be taken to properly extend the chain rule to include the conjugate Wirtinger derivative where necessary. Second, in principle problems can arise when defining a test for constant functions. For example this is necessary as part of rewriting expressions in terms of the smallest number of elementary functions (normalize) as a kind of zero test for expressions in FriCAS/Axiom. Usually we assume that df(x)/dx = 0 is necessary and sufficient for f to be a constant function. But requiring that the total derivative d f / d z + d f / d conjugate(z) = 0 is not what we mean by constant. In fact it seems to be an open question whether Richardson's theorem can be extended to include conjugate as an elementary function in such a way that the zero test is still computable. This is the last point of discussion on the FriCAS email list. Bill. -- You received this message because you are subscribed to the Google Groups 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
On Fri, Nov 14, 2014 at 12:14 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Thu, Nov 13, 2014 at 6:56 PM, Bill Page bill.p...@newsynthesis.org wrote: Sorry, I hit send before I was quite ready. To continue ... On 13 November 2014 19:24, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: ... For example, for |z| we get: |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z| Using our definition, this holds for any complex z. Then, if z is real, we get: |z|' = z / |z| Which is exactly the usual real derivative. Bill, is this what you had in mind? That a CAS could return the derivative of abs(z) as Re(z) / abs(z) ? Yes, exactly. I think a question might arise whether we should treat conjugate or Re as elementary. Ok, thanks for the confirmation. There is an issue though --- since |z| is not analytic, the derivatives depend on the direction. So along x you get Sorry, a bug in gmail sent the message along x you get: |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z| but along y you get: |z|' = \partial |z| / \partial i*y = d |z| / d z - d |z| / d conjugate(z) = conjugate(z) / (2*|z|) - z / (2*|z|) = i*Im(z) / |z| So I get something completely different. So which direction should be preferred in the CAS convention and why? Ondrej ... What are the cons of this approach? First, care needs to be taken to properly extend the chain rule to include the conjugate Wirtinger derivative where necessary. Second, in principle problems can arise when defining a test for constant functions. For example this is necessary as part of rewriting expressions in terms of the smallest number of elementary functions (normalize) as a kind of zero test for expressions in FriCAS/Axiom. Usually we assume that df(x)/dx = 0 is necessary and sufficient for f to be a constant function. But requiring that the total derivative d f / d z + d f / d conjugate(z) = 0 is not what we mean by constant. In fact it seems to be an open question whether Richardson's theorem can be extended to include conjugate as an elementary function in such a way that the zero test is still computable. This is the last point of discussion on the FriCAS email list. Bill. -- You received this message because you are subscribed to the Google Groups 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 http://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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
