Re: [sage-devel] sage-6.4 fallout: stein-watkins-ecdb
On 2014-11-15 19:57, William Stein wrote: I installed the huge stein-watkins-ecdb optional spkg, sage -i stein-watkins-ecdb The correct command is sage -i database_stein_watkins We should really *remove* the optional package stein-watkins-ecdb. -- You received this message because you are subscribed to the Google Groups 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] [ARM] Sage 6.4
Hi, will a bdist of sage 6.4 for ARM be made available on the website, or should I compile one myself and pass it along as usual? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups 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: About recmpilations caused by Git
On Monday, November 17, 2014 3:06:42 AM UTC, Nathann Cohen wrote: You declared that unnecessary merges are bad Its not just me, ask any lager project that is using git. Half of them even force you to clean up your history before submitting anything. The log is not just there for the reviewer, it is fixed for all time in our history and if you ever want to figure out where a particular line comes from (git blame) then you'll have to be able to understand the history around the commit. -- You received this message because you are subscribed to the Google Groups 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: [ARM] Sage 6.4
Our gcc 4.9.2 doesn't compile on arm, and nobody reviewed http://trac.sagemath.org/ticket/17348 so far. On Monday, November 17, 2014 8:33:44 AM UTC, Snark wrote: Hi, will a bdist of sage 6.4 for ARM be made available on the website, or should I compile one myself and pass it along as usual? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups 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] sage-6.4 fallout: stein-watkins-ecdb
On Mon, Nov 17, 2014 at 9:29 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: We should really *remove* the optional package stein-watkins-ecdb. I can do this, but it would break for older Sage installs, right? The bad one is in the huge directory, whereas the good one is in upstream. Besides that, there are three different instances of it in upstream, do we need them? .../packages$ find -name *watkins* -size +100M ./huge/stein-watkins-ecdb.spkg ./upstream/database_stein_watkins/database_stein_watkins-20070827.tar.bz2 ./upstream/database_stein_watkins/database_stein_watkins-20030423.tar.bz2 ./upstream/database_stein_watkins/database_stein_watkins-20110713.tar.gz -- Harald -- You received this message because you are subscribed to the Google Groups 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] sage-6.4 fallout: stein-watkins-ecdb
We haven't formulated a policy yet. Obviously we'll have to delete old tarballs at one point, but is disk space really an issue already? On Monday, November 17, 2014 11:22:00 AM UTC, Harald Schilly wrote: On Mon, Nov 17, 2014 at 9:29 AM, Jeroen Demeyer jdem...@cage.ugent.be javascript: wrote: We should really *remove* the optional package stein-watkins-ecdb. I can do this, but it would break for older Sage installs, right? The bad one is in the huge directory, whereas the good one is in upstream. Besides that, there are three different instances of it in upstream, do we need them? .../packages$ find -name *watkins* -size +100M ./huge/stein-watkins-ecdb.spkg ./upstream/database_stein_watkins/database_stein_watkins-20070827.tar.bz2 ./upstream/database_stein_watkins/database_stein_watkins-20030423.tar.bz2 ./upstream/database_stein_watkins/database_stein_watkins-20110713.tar.gz -- Harald -- You received this message because you are subscribed to the Google Groups 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] Warning message and encoding
Matrix(RR, [[1,2],[3,4]]).eigenvalues() gives warning message Using generic algorithm for an inexact ring - -, which is of course correct. After that it prints #!/usr/bin/env python. But on one occasion I already get # -*- coding: utf-8 -*- aftew warning on version 6.4. Is this reproducible everywhere, or does it depend on OS / charset / something? -- 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: About recmpilations caused by Git
Yo ! Its not just me, ask any lager project that is using git. Half of them even force you to clean up your history before submitting anything. Volker, I am not telling you that having bad histories is good, I am telling you that letting newcomers not care about the amount of merge commits is not a problem for us. We already do that to some extent: when I see a newcomer here I make very very long reviews about all points of doc and doctests, and from time to time I do these changes myself telling them what he should pay attention to. That is normal. I remember having refused to review a patch because the history was awful, and this is something I did because the reviewer was experienced. So let us insist on having clear histories, because indeed, like the code, history is read much more often than it is written, but that is not such a big problem if the first 2~3 patches of a newcomer have one or two commit merges. Again, you only create a merge commit when the development of a ticket lasts over several beta releases, and in my experience this is rare for newcomers. Newcomers patches are never fundamental stuff, and this will not be a problem in the long run. So even if it is just to prevent them from recompiling Sage when they want to fix a typo in the doc, let's make it easy for them. If they stick around they will get to learn git anyway. 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: About recmpilations caused by Git
On Monday, November 17, 2014 11:46:22 AM UTC, Nathann Cohen wrote: Volker, I am not telling you that having bad histories is good So we agree, perfect ;-) Really the problem is that we rely on time stamps for deciding what to compile. That is a technical issue that we'll fix eventually. -- You received this message because you are subscribed to the Google Groups 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: About recmpilations caused by Git
Volker, I am not telling you that having bad histories is good So we agree, perfect ;-) Really the problem is that we rely on time stamps for deciding what to compile. That is a technical issue that we'll fix eventually. There is something wrong with the world. Sometimes I think that it is only me, but on some other occasions there is no doubt possible. The world is wrong. 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.
[sage-devel] Re: Warning message and encoding
I agree that it is not desirable, but that is the standard IPython behavior:
$ ipython
[...]
In [1]: import warnings
In [2]: warnings.warn('foo')
/usr/bin/ipython:1: UserWarning: foo
#!/usr/bin/python
On Monday, November 17, 2014 11:45:53 AM UTC, Jori Mantysalo wrote:
Matrix(RR, [[1,2],[3,4]]).eigenvalues() gives warning message Using
generic algorithm for an inexact ring - -, which is of course correct.
After that it prints #!/usr/bin/env python.
But on one occasion I already get # -*- coding: utf-8 -*- aftew warning
on version 6.4.
Is this reproducible everywhere, or does it depend on OS / charset /
something?
--
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] sage-6.4 fallout: stein-watkins-ecdb
On 17 November 2014 11:21, Harald Schilly harald.schi...@gmail.com wrote: On Mon, Nov 17, 2014 at 9:29 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: We should really *remove* the optional package stein-watkins-ecdb. I can do this, but it would break for older Sage installs, right? The bad one is in the huge directory, whereas the good one is in upstream. Besides that, there are three different instances of it in upstream, do we need them? .../packages$ find -name *watkins* -size +100M ./huge/stein-watkins-ecdb.spkg ./upstream/database_stein_watkins/database_stein_watkins-20070827.tar.bz2 ./upstream/database_stein_watkins/database_stein_watkins-20030423.tar.bz2 ./upstream/database_stein_watkins/database_stein_watkins-20110713.tar.gz Of the first two there is a logical difference: the Stein-Watkins db was first created in 2003, and some additions and corrections were made to it in 2007. So the 2003 version has some historical imprtance (conceivably). I don't know about the 2011 version, since (unlie the others) I did not make it. John -- Harald -- You received this message because you are subscribed to the Google Groups 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] NTL and Singular updates
Dear all, Anyone feeling like reviewing the updates to NTL 6.2.1 (http://trac.sagemath.org/ticket/16882) and Singular 3-1-7 (http://trac.sagemath.org/ticket/17184) ? It would be nice to have them in before working on the much more involved Singular 4-0-x and (surely not so hard) NTL 7.0.1 updates. By the way, there is also http://trac.sagemath.org/ticket/12703 which eases things on Cygwin. 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.
[sage-devel] How to clean up local git history?
Hi! On another thread, there was talk about avoiding unnecessary merge comits. I agree that a nice git history is, well, nice. But I need some pointers to achieve it. Situation: I have a local branch branch_local (not published) that I'd like to rebase on top of the latest develop, in order to have a nice history. However, git rebase develop fails due to several conflicts. But, to my slight surprise, git merge develop works without conflict. Additional complication: My local branch contains (or depends on) another branch branch_public that is published on trac but isn't in develop yet. Thus (if one accepts git's notion of history), it would be bad to rebase it. Questions: 1. Why does git merge develop work when git rebase develop doesn't? 2. Is git merge develop followed by git rebase develop the right thing to do in order to obtain a good revision history for branch_local before publishing it? Or would that be bad, since it would also involve rebasing branch_public, which already is published? In that case, what should I do instead? 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] Re: About recmpilations caused by Git
On Monday, 17 November 2014 22:53:53 UTC+11, Volker Braun wrote: On Monday, November 17, 2014 11:46:22 AM UTC, Nathann Cohen wrote: Volker, I am not telling you that having bad histories is good So we agree, perfect ;-) OK, so if I have a branch that is using an old version of sage what is the recommended way of moving it up to the latest development branch. What I have been doing is updating the develop branch and then git checkout my_branch git merge develop This pull a lot of (unclean) garbage into my history so I am guessing that, on principle, Nathan would refuse to review such patches when they are done. 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] Document patches in the patch file, not in SPKG.txt
I would like to propose another change to SPKG.txt, and that is to NOT document patches in there but in the patch file. As you might know, the patch can have arbitrary text before the first diff hunk, anything that is not an actual diff is ignored. The documentation change will be http://trac.sagemath.org/ticket/17357, we can then slowly transition to the new-style patch documentation. -- You received this message because you are subscribed to the Google Groups 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: About recmpilations caused by Git
On Monday, November 17, 2014 12:43:28 PM UTC, Andrew wrote: OK, so if I have a branch that is using an old version of sage what is the recommended way of moving it up to the latest development branch. The recommended way is to stay on the old version unless you actually need something from the latest development branch. -- You received this message because you are subscribed to the Google Groups 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: Document patches in the patch file, not in SPKG.txt
On Monday, November 17, 2014 1:45:09 PM UTC+1, Volker Braun wrote: I would like to propose another change to SPKG.txt, and that is to NOT document patches in there but in the patch file. As you might know, the patch can have arbitrary text before the first diff hunk, anything that is not an actual diff is ignored. I agree this is a good thing to do. (In particular it allows to easily just add or remove a patch without needing to modifyin SPKG.txt.) -- You received this message because you are subscribed to the Google Groups 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: How to clean up local git history?
1) Thats a bit vague, but it wouldn't surprise me that merge has fewer conflicts since it has more information available. Rebase just replays the commits so you have to re-resolve conflicts. Though there is git rerere to help with that. 2) The default should be not to merge either branch with the current develop unless you really need something from develop. Once branch_public has been merged into develop you can rebase your private branch. On Monday, November 17, 2014 12:34:59 PM UTC, Simon King wrote: Hi! On another thread, there was talk about avoiding unnecessary merge comits. I agree that a nice git history is, well, nice. But I need some pointers to achieve it. Situation: I have a local branch branch_local (not published) that I'd like to rebase on top of the latest develop, in order to have a nice history. However, git rebase develop fails due to several conflicts. But, to my slight surprise, git merge develop works without conflict. Additional complication: My local branch contains (or depends on) another branch branch_public that is published on trac but isn't in develop yet. Thus (if one accepts git's notion of history), it would be bad to rebase it. Questions: 1. Why does git merge develop work when git rebase develop doesn't? 2. Is git merge develop followed by git rebase develop the right thing to do in order to obtain a good revision history for branch_local before publishing it? Or would that be bad, since it would also involve rebasing branch_public, which already is published? In that case, what should I do instead? 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] Re: About recmpilations caused by Git
This pull a lot of (unclean) garbage into my history so I am guessing that, on principle, Nathan would refuse to review such patches when they are done. Nathann-bashing has become a game or what ?... I would see nothing wrong with that branch. By the way on trac the diff file would only show the content of your branch. The problem with your method is that you change all timestamps. I do it reverse: fetch the remote branch, and merge it into develop. No change in the timestamps. 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] Code of Conduct
[X ] Yes, this is a great idea. About time! To a newcomer, some of the posts may make the Sage community look aggressive and end up steering them in another direction. -- You received this message because you are subscribed to the Google Groups 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: sage-6.4 fallout: optional ore_algebra package now broken due to change in Sage (?) (Re: downloading Ore_algebra package to sagemath)
This is Trac Ticket #17205 http://trac.sagemath.org/ticket/17205. John Palmieri gave a quick fix in comment #2. Note that I'm not one of the developers of this package -- merely a happy user. :-) Best, Konstantin -- You received this message because you are subscribed to the Google Groups 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: About recmpilations caused by Git
This pull a lot of (unclean) garbage into my history so I am guessing that, on principle, Nathan would refuse to review such patches when they are done. Nathann-bashing has become a game or what ?... I read that as just repeating what you said as a statement, but I may have misread it? I would see nothing wrong with that branch. By the way on trac the diff file would only show the content of your branch. The problem with your method is that you change all timestamps. I do it reverse: fetch the remote branch, and merge it into develop. No change in the timestamps. See, the fact that one has to understand all these things - ALL OF WHICH ARE NON-MATHEMATICAL - is the entire problem. I agree with John that one shouldn't have to wait forever for a recompilation - during which it is presumably not safe to try other branches on the same Sage install? - when just checking a minor change. I also now always *review* by branching from develop and then pulling the branch to that 'safe' branch, but even then when I go back to develop sometimes it takes exceedingly long. See https://groups.google.com/d/msg/sage-devel/iGxa2F01rFc/ERRec52gHY0J Also part of the problem is the use of 'make' that is recommended; I've gone back to sage -b and sometimes that helps. -- You received this message because you are subscribed to the Google Groups 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: sage-6.4 fallout: brian optional package
sage: !sage -i brian Found package brian in /usr/local/sage/sage-6.4/upstream/brian-1.4.1.p0.spkg brian-1.4.1.p0 (Stripping trailing CRs from patch; use --binary to disable.) patching file brian/units.py Hunk #1 FAILED at 11173 (different line endings). 1 out of 1 hunk FAILED -- saving rejects to file brian/units.py.rej Error applying '../patches/units.py.patch'. The reason for the failure is that we updated patch and it is now less lenient with malformed patches. Is there a reason we need to have our own version? Perhaps not, but then we need to massively updated documentation on how to install various Python packages. Right now the advantage of spkgs is that people who *only* use Sage don't have to start to understand the rest of the Python ecosystem. $ pip -bash: pip: command not found However, in this case I'm sure we can just fix the patch. -- You received this message because you are subscribed to the Google Groups 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: merged in field of trac (was: Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems)
IMHO the most convenient place is to look in the git history, this also works if you don't currently have internet access for starters. The git-trac script implements this: $ git trac find 4f8b380 Commit has been merged in 6.4.rc1. Very useful, but perhaps not so much to people who are only users, not developers. Though this could be something to encourage me to use git trac finally. If you want me to update the merged in field on trac then post a PR to the git-trac script (which includes the release management scripts). I would very much like to but I doubt I have the technical capability to do so in a reasonable amount of time. :-( I have missed the discussion which led to not using the field merged in anymore. What were the reasons? Simply lack of manpower to write a script modifying the merged in fields once a new develop release is made? Or not wanting to feed redundant information into trac when it is visible on the git command line, anyway? I think mostly because each release manager has their own style and scripts, which is reasonable. Redundancy is definitely not always bad, so I hope that wasn't the reason. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To 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: Code of Conduct
1. Continuing to lose talented Sage developers specifically because they do not feel comfortable with the tone of the lists, and Can you give an example of this, even if vaguely? I don't read every conversation on the lists, but in my personal experience, the community has been very supportive, even when I'm an idiot. (Sometimes you have been supportive *especially* when I'm an idiot.) I do see a lot of I think the community is quite welcoming to true newcomers who clearly do not know the ropes. I think the problem comes in when people have tried and achieved a certain amount of comfort with the tools but then encounter either a philosophical problem between two different visions for some area of Sage or around some other non-mathematical thing. Then people can vote with their feet, and are very unlikely to bother spending time on a list - or, for that matter, replying to this thread (which is what I meant when I said a couple dozen or whatever). And as much as some mathematicians are political figures, probably most of them first and foremost just want to get some math done. It's also frustrating to hear that there are private development discussions, though I do understand why, and I have to admit that sometimes I am embarrassed at how much I talk to myself on tickets with my own debugging log that no one wants to hear, maybe that *should* be private. What if instead of a code of conduct there was a community expectations SHORT document that just say what we expect? (perhaps based on this thread as well as the original document Volker et al. (who were the et al?) suggested) Expecting doesn't mean it always happens, just like a budget ;-) But I agree 100% with William about supporting the person who feels attacked, when that may happen, rather than playing the blame game. -- You received this message because you are subscribed to the Google Groups 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: About recmpilations caused by Git
Hello ! I read that as just repeating what you said as a statement, but I may have misread it? Well, the branch I had in mind had something like 5-6 commits and all had the same message merged with develop or something. No way to know what was happening, and of course they were not only merge commits as code was implemented there. I don't see anything wrong with a branch that is merged with the latest release at some point, whichever the direction. See, the fact that one has to understand all these things - ALL OF WHICH ARE NON-MATHEMATICAL - is the entire problem. Yep. I will try to read the developper's manual this weekend to see if anything can be made clearer. There has to be a way. 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] Bug in abs(I*x).diff(x)
For reference (since Sage uses Ginac for most derivatives) see http://www.cebix.net/pipermail/ginac-devel/2014-April/002105.html -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To 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)
Vladimir V. Kisil kisilv's patch http://www.ginac.de/pipermail/ginac-devel/2013-November/002053 looks like a good start to me especially if one doesn't want to consider the issue of derivatives of non-analytic functions in general. On 17 November 2014 10:14, kcrisman kcris...@gmail.com wrote: For reference (since Sage uses Ginac for most derivatives) see http://www.cebix.net/pipermail/ginac-devel/2014-April/002105.html -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To 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)
Vladimir V. Kisil kisilv's patch http://www.ginac.de/pipermail/ginac-devel/2013-November/002053 looks like a good start to me especially if one doesn't want to consider the issue of derivatives of non-analytic functions in general. http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html (was missing extension) -- You received this message because you are subscribed to the Google Groups 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] vote: include pip with sage
vdelecroix wrote: The pip ticket (#16479) is now positively reviewed. Should I open a new one to make it standard? 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] vote: include pip with sage
The pip ticket (#16479) is now positively reviewed. Should I open a new one to make it standard? Yes! Alternately (or complementarily?) see #17155. -- You received this message because you are subscribed to the Google Groups 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: sage-6.4 fallout: brian optional package
Is there a reason we need to have our own version? Actually, I think there is, because see the original ticket #9675: I must say I detected some problems with Brian units related to the Sage classes 'RealNumber? http://trac.sagemath.org/wiki/RealNumber' and 'Integer', so I created a patch so that when Brian is imported these two classes are redefined as follows: RealNumber=float Integer=int This solves the problems. $ pip -bash: pip: command not found Though see #17155, which I just remembered about. However, in this case I'm sure we can just fix the patch. sage -pip wouldn't fix that issue, unfortunately. -- You received this message because you are subscribed to the Google Groups 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: sage-6.4 fallout: optional ore_algebra package now broken due to change in Sage (?) (Re: downloading Ore_algebra package to sagemath)
This is Trac Ticket #17205 http://trac.sagemath.org/ticket/17205. John Palmieri gave a quick fix in comment #2. Note that I'm not one of the developers of this package -- merely a happy user. :-) Note also that http://www.risc.jku.at/research/combinat/software/ore_algebra/ suggests that Right now you are using Version 0.2 last updated on November 16, 2014, developed for Sage 6.3. So maybe we just need to update our package? ore_algebra-0.1 . not installed -- You received this message because you are subscribed to the Google Groups 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: sage-6.4 fallout: brian optional package
On Nov 17, 2014 10:42 AM, kcrisman kcris...@gmail.com wrote: Is there a reason we need to have our own version? Actually, I think there is, because see the original ticket #9675: I must say I detected some problems with Brian units related to the Sage classes 'RealNumber?' and 'Integer', so I created a patch so that when Brian is imported these two classes are redefined as follows: RealNumber=float Integer=int This solves the problems. Wait? Are you really saying that if a user does Sage: import brian Sage: 2/3 They now get 0? If so I'm -1 to this. Best would be to fix brian so it works with sage ints and reals (and upstream the patches) or short of that to print a message suggesting the user type what you put above (with caveats) Hard developer question: is there any way to hack python or cython to make it so our types appear to derive from int and float to solve this problem once and for all? Has anybody seriously thought about this? $ pip -bash: pip: command not found Though see #17155, which I just remembered about. However, in this case I'm sure we can just fix the patch. sage -pip wouldn't fix that issue, unfortunately. -- You received this message because you are subscribed to the Google Groups 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: sage-6.4 fallout: optional ore_algebra package now broken due to change in Sage (?) (Re: downloading Ore_algebra package to sagemath)
Note also that http://www.risc.jku.at/research/combinat/software/ore_algebra/ suggests that Right now you are using Version 0.2 last updated on November 16, 2014, developed for Sage 6.3. So maybe we just need to update our package? ore_algebra-0.1 . not installed I just installed ore_algebra version 0.2 on a bleeding-edge Sage (Version 6.5.beta0, Release Date: 2014-11-16) and it works just fine: ore_algebra-0.1 . installed version: 0.2 Is there anything else I can help with? Best, Konstantin -- You received this message because you are subscribed to the Google Groups 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 Sat, Nov 15, 2014 at 9:18 AM, Bill Page bill.p...@newsynthesis.org wrote: On 14 November 2014 14:29, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Nov 14, 2014 11:30 AM, Bill Page bill.p...@newsynthesis.org wrote: What do you mean by the real derivative? The absolute value doesn't have a complex derivative, but it has a real derivative, over the real axis. It seems to me that the concept of real axis is rather foreign to the algebra. Assuming conjugate is implemented properly, i.e. algebraically, what you are actually saying is just that z = conjugate(z) That's fine. ... You are not differentiating with respect to x, you are differentiating with respect to (z+conjugate(z))/2 Is that how you propose to define the derivatives for non-analytic functions? I am a little confused what exactly is your proposal. I am sorry for the confusion. What I am proposing is that the Wirtinger derivative(s) be considered the fundamental case (valid for complex or even quaternion variables). As you noted previously this is fine and doesn't change anything for the case of analytic functions. If someone wants the derivative of a non-analytic function over a given domain that should be called something else. I still don't understand exactly your proposal. We've played with a few ideas above, in particular we have considered at least (below d/dz is the Wirtinger derivative, d/dx and d/d(iy) are partial derivatives with respect to x or iy in z=x+i*y) : 1) d/dz 2) d/dz + d/d conjugate(z) = d/dx 3) d/dz - d/d conjugate(z) = d/d(iy) 4) 2 * (d/dz + d/d conjugate(z)) 5) 2 * d/dz Which of these do you propose to use? For analytic functions, only 1) and 2) reduce to the usual complex derivative. 4) and 5) will be off by a factor of 2. For example, for a function z^2 we get: 1) 2*z 2) 2*z 3) 2*z 4) 4*z 5) 4*z Since z^2 is analytic, the correct derivative is 2*z, so 1), 2) and 3) give the right answer. For abs(z), we get: 1) conjugate(z) / (2*|z|) 2) Re(z) / |z| 3) -i*Im(z) / |z| 4) 2*Re(z) / |z| 5) conjugate(z) / |z| When z is real, then the (real) derivative of |z|' = z/|z|. We want our complex formula to be equal to z/|z| if z is real. Of the above, only 2) and 5) is equal to z/|z| when z is real. Note that I made a sign mistake in my previous email regarding 3). Comparing these two cases, options 1) and 3) are eliminated because the results for abs(z) do not reduce to the correct real derivative. Option 4) is eliminated, because it gives wrong results for analytic functions, as well as it doesn't reduce to the correct real derivative for abs(z). Option 5) is eliminated because it gives wrong results for analytic functions. As such, only option 2) is consistent. For all analytic functions, it gives the correct complex derivative, and for non-analytic functions, at least for abs(z) it reduces to the correct real derivative in the special case when z is real, i.e. z = conjugate(z). Note that you cannot apply z = conjugate(z) to the definition of 2) to obtain the (incorrect) result 2*d/dz, you need to treat z and conjugate(z) separately when differentiating and only at the end apply z = conjugate(z). It seems to work for other non-analytic functions, for example for Re(z) = (z+conjugate(z))/2, we get: 2) 1 for Im(z) = (-z+conjugate(z))*i/2 we get: 2) 0 So that all works as expected. To prove that this works for all non-analytic functions, we just use the fact that d/dz + d/d conjugate(z) = d/dx, as we talked about above. So we are just calculating the partial derivative with respect to x (we use the notation z = x+i*y). When z is real, i.e. z = conjugate(z), it follows that y = 0, and d/dx is just the usual (real) derivative. When y is non-zero, we still calculate d/dx but using z and conjugate(z). As shown above, for analytic functions this d/dx derivative is equal to the complex derivative. For non-analytic functions the complex derivative doesn't exist, so it's just our definition, but it reduces to the usual real derivative (which is always equal to d/dx). In one of my previous emails, I raised a question for non-analytic functions, why we can't define it in some other way, perhaps d/d(iy), i.e. the option 3) above. I think the answer is that we can, but it will not reduce to the real derivative d/dx if z is real, simply because d/d(iy) is not equal to d/dx, unless the function is analytic, i.e. 3) works for analytic functions, but fails for abs(z), as shown above (as well as in my previous email --- note again that I made a sign mistake there). I think one either leaves the derivatives of non analytic functions unevaluated, No, this is just giving up. We should be able to do much better than that. or defines them in such a way that one recovers the real derivative as a special case, as long as there are no inconsistencies. Yes exactly, the concept of real derivative is a special case. Hopefully the above clarifies, that from everything that we have
Re: [sage-devel] Bug in abs(I*x).diff(x)
I still don't understand exactly your proposal. We've played with a few ideas above, in particular we have considered at least (below d/dz is the Wirtinger derivative, d/dx and d/d(iy) are partial derivatives with respect to x or iy in z=x+i*y) : 1) d/dz 2) d/dz + d/d conjugate(z) = d/dx 3) d/dz - d/d conjugate(z) = d/d(iy) 4) 2 * (d/dz + d/d conjugate(z)) 5) 2 * d/dz Which of these do you propose to use? For analytic functions, only 1) and 2) reduce to the usual complex derivative. 4) and 5) will be off by a factor of 2. For example, for a function z^2 we get: Correction: For analytic functions, only 1), 2) and 3) reduce to the usual complex derivative. (As is shown below on particular examples.) -- You received this message because you are subscribed to the Google Groups 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: About recmpilations caused by Git
Nathann-bashing has become a game or what ?... Sorry, wasn't intended as Nathan-bashing: I was just referring to your previous comment. The problem with your method is that you change all timestamps. I do it reverse: fetch the remote branch, and merge it into develop. No change in the timestamps. OK, will try this in future. Of course, this doesn't work with branches that have not been pushed to trac. When push pushing to trac I guess that rebase -i should be used to prune the local commits to something reasonable. The recommended way is to stay on the old version unless you actually need something from the latest development branch. When the branch is finally ready for review it has to be merged with the latest development branch, so you can't avoid this indefinitely. As with Nathan, I'm reluctant to continuously switch between versions because of the compile time lag. 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 17 November 2014 15:17, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Sat, Nov 15, 2014 at 9:18 AM, Bill Page bill.p...@newsynthesis.org wrote: I am sorry for the confusion. What I am proposing is that the Wirtinger derivative(s) be considered the fundamental case (valid for complex or even quaternion variables). As you noted previously this is fine and doesn't change anything for the case of analytic functions. If someone wants the derivative of a non-analytic function over a given domain that should be called something else. I still don't understand exactly your proposal. We've played with a few ideas above, in particular we have considered at least (below d/dz is the Wirtinger derivative, d/dx and d/d(iy) are partial derivatives with respect to x or iy in z=x+i*y) : 1) d/dz 2) d/dz + d/d conjugate(z) = d/dx 3) d/dz - d/d conjugate(z) = d/d(iy) 4) 2 * (d/dz + d/d conjugate(z)) 5) 2 * d/dz Which of these do you propose to use? Both d/dz and d/d conjugate(z), i.e. the Wirtinger derivatives. ... When z is real, then the (real) derivative of |z|' = z/|z|. We want our complex formula to be equal to z/|z| if z is real. Presumably you intend to choose only one of these? But this cannot work in the general case. ... As such, only option 2) is consistent. For all analytic functions, it gives the correct complex derivative, and for non-analytic functions, at least for abs(z) it reduces to the correct real derivative in the special case when z is real, i.e. z = conjugate(z). Yes. ... Yes exactly, the concept of real derivative is a special case. Hopefully the above clarifies, that from everything that we have considered so far, only the option 2) can work. It turns out that that's also precisely what also ginac considered for abs(z)'. So the conclusion seems clear --- simply use 2) for any function, be it analytic or not. If there is only one derivative, how will you handle the chain rule? However, Bill, from your emails, you seem to be giving conflicting statements. It seems you agree that 2) is the way to go in some emails, but then in some other emails you write: It seems to me that we should forget about x and y. All we really need is |z|' = d |z| / d z = conjugate(z) / (2*|z|) Which is the case 1) above, and it is shown that it doesn't work. We need both Wirtinger derivatives. Option 2) is their sum. Right in the next paragraph you wrote: The constant 1/2 is irrelevant. What do you mean that the constant 1/2 is irrelevant? I think it is very relevant, as it makes the answer incorrect. I said that actually only one Wirtinger derivative was required because the other can be expressed in terms of conjugate but I did not mean to imply that it would meet your criteria of reducing to exactly to the real case. It just happens that both Wirtinger derivatives are the same in the case of abs. When you say I am proposing that the Wirtinger derivative(s) be considered the fundamental case, which of the five cases above are you proposing? Strictly speaking, Wirtinger derivative is the case 1), but that doesn't work. Are you proposing the case 2) instead? No, I meant that other derivatives (such as the real derivative) can be obtained from the Wirtinger derivatives but not vice versa. ... If someone wants the derivative of a non-analytic function over a given domain that should be called something else. Are you proposing to only consider analytic functions? No. I thought the whole conversation in this thread was about how to extend this to non-analytic functions... Yes. The main issue is non-analytic (non-holomorphic) functions. ... I thought the goal was rather to extend the definition of derivative to also apply for non-analytic functions, in the whole complex domain in such a way, so that it reduces to a complex derivative for analytic functions, and a real derivative if we restrict z to be real. It seems that 2) above is one such definition that would allow that. 2) alone is not sufficient. In general for non-analytic functions two derivatives are required. Bill, would you mind clarifying the above misunderstandings? I think we are on the same page, probably we both just understood something else with the terminology we used, but I want to make 100% sure. Thank you. I am happy to continue the discussion. 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] Bug in abs(I*x).diff(x)
Hi Bill,
Thanks for the clarification. So your point is that 2) is not
sufficient, that we really need two Wirtinger derivatives --- it's
just that one can be expressed using the other and a conjugate, so
perhaps CAS can only return one, but a chain rule needs modification
and probably some other derivatives handling as well. I need to think
about this harder.
Here is a relation that I found today in [1] (see also the references
there), I don't know if you are aware of it:
D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}
Where Df/Dz is the derivative in a complex plane along the direction
theta (the angle between the direction and the x-axis) and df/dz and
df/d conjugate(z) are the two Wirtinger derivatives. This formula
holds for any function. So all the derivatives no matter which
direction lie on a circle of radius df/d conjugate(z) and center
df/dz.
For analytic functions, we have df/d conjugate(z) = 0, and so the
above formula proves that all the derivatives are independent of
direction theta and equal to df/dz.
For non-analytic functions, the above formula gives all the possible
derivatives, and besides df/dz, the derivatives also depend on df/d
conjugate(z) and theta. But that's it. So as you said, the two
Wirtinger derivatives allow us to calculate the derivative along any
direction theta we want.
From my last email, the case 1) corresponds to df/d conjugate(z)=0,
i.e. analytic functions and the result is independent of theta. Case
2) is theta = 0, pi, 2*pi, ..., i.e. taking the derivative along the
x-axis. Case 3) is theta = pi/2, 3*pi/2, 5*pi/2, ..., i.e. taking the
derivative along the y-axis.
A real derivative of a real function g(x) is simply taken along the
x-axis. You can imagine that g(x) is also (arbitrarily) defined in the
whole complex plane and you are taking the Dg/gz derivative above with
theta = 0. The result is the same. So that's why the case 2), i.e.
theta=0, always reproduces the real derivative, because real
derivative is defined as theta=0.
For CAS, one could probably just say that theta=0 in our definition,
and then everything is consistent, and we only have one derivative,
2). The other option is to return both derivatives and make the
derivative Df/Dz of non-analytic function equal to the above formula,
i.e. depending on df/dz, df/d conjugate(z) and theta.
I need to think about the chain rule. I would simply introduce the
theta dependence into all formulas, as that gives all possible
derivatives and gives the exact functional dependence of all
possibilities. And then see whether we need to keep all formulas in
terms of theta, or perhaps if we can set theta = 0 for everything.
Ondrej
[1] Pyle, H. R., Barker, B. M. (1946). A Vector Interpretation of
the Derivative Circle. The American Mathematical Monthly, 53(2), 79.
doi:10.2307/2305454
--
You received this message because you are subscribed to the Google Groups
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.
