Re: [sympy] Merging instead of rebasing
Am 16.07.2015 um 05:32 schrieb Aaron Meurer: Also, if you're a habitual rebaser and you have push access, you had better have your origin remote set to read-only. Very much agreed. Maybe not just for habitual rebasers, merging with conflicts can go wrong, too. I hope to set up my own projects so that committers will have two workdirs, one for day-to-day work preparing PRs and one for working on the main branch. The former can have its push access disabled; for the latter, I hope there's a way to disable rebasing and merge conflict resolution. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A77213.1070709%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 16.07.2015 um 18:21 schrieb Aaron Meurer: OK, guys, this thread has reached its end. Fully agreed. With 20/20 hindsight, I'd say it did many messages ago. I'm not going to take 100% responsibility for this, but enough that I want to offer my apologies. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A7E28D.3040802%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] Okay... bye then
Given the way Jason Moore has been acting towards me - some valid points buried so deep in personal attacks that even talking to him has become painful for me... ...and given that he's implying he's speaking for the project, which would be bad if he does not and worse if he actually did... ... well, I do not think I can work for the SymPy project anymore. It was nice while it lasted, and I'm grateful for the amount of technical and nontechnical things that I could learn, but the time has come for me to move on. Regards, have a good time everybody, good luck, and bye Jo P.S.: I'm not the scorched-earth type, so everything that was on my disk, ready or not, got submitted as a PR. Feel free to pick up anything that needs more work. @mention me on GitHub, and I'll come for answers, explanations, or whatever help would be appreciated. P.P.S.: I'm signing off from the mailing list. I can still be reached through my mail address and via GitHub. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A7E2FD.40300%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
The more you do this, the less we like you. Frankly, I do not care whether you like me. I care about code. Also, I do not believe anybody gave you a mandate to tell me that they don't like me anymore. You accuse me of not helping moving stuff forward. Ironically, you've been bogging this discussion down with personal allegations about my stance, my motives, and my understanding, detracting from factual issues. You complained I write too much, and I tried to stick with two-sentence arguments; now you're simply ignoring their factual content, and write a huge message that's 90% allegations about my motives, my aims, and my understanding, i.e. the exact opposite of what you've been demanding of me. You're a hypocrite, sir. Have a nice day. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A7D5F4.4070808%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 15.07.2015 um 20:23 schrieb Ondřej Čertík: I agree with this --- many times there is just a few lines change, that took 50 commits to get done, because the author was learning how to make it work. That too, yes. For these cases I recommend to send a new PR with a polished (=rebased) history. Then there is no problem. Ah, nice. Sounds like a good alternative approach. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A6AE2F.8010201%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 15.07.2015 um 20:54 schrieb AMiT Kumar: Well said, I think, this point won the argument! Actually it didn't, each sentence is easily refuted: Changing the history of your revisions is detrimental to the open philosophy that you should have when developing in open source. Open philosophy and open source are strictly orthogonal. There are automotive companies that do glass-pane production, i.e. you can look into the actual production process; yet their products are as proprietary as their legal departments can make them (e.g. apply design copyright so nobody can sell a replacement mirror). The converse is available as well: strictly open-source libraries of highest quality that are developed mostly behind closed doors, witness Google's Guava library (you *can* get your changes in, but it's a major undertaking and you don't see the team's internal priorities so you don't even know where a contribution would be welcome). We should not be afraid to make mistakes, and even have it in a permanent record that we made those mistakes. It's also not about showing mistakes to the public. It's about making the commit log more useful. Good open source software, certainly SymPy, is built in the bazaar, not the cathedral. It's not an opposite, it's a trade-off. Bazaar tends to favor quantity over quality, cathedral is the reverse. Case in point is Linux, according to Con Kolivas of kernel scheduler fame: http://ck-hack.blogspot.be/2010/10/other-schedulers-illumos.html and also according to the list of CVEs for Linux (bazaar) vs. OpenBSD (cathedral). I suggest that we let the proposal stand and that Jo can document all of the cases over the next several months where rebasing was necessary and where this guideline caused more problems that it solved. Once Jo builds his case with real data he can propose a new guideline and then we can discuss. Is that sufficient to move forward here? +1 We'd just be arguing about whether rebasing in what particular case would have helped or not. Aaron's stance is that the commit log should be a stream-of-consciousness thing. I see no value in that, and actually think it's damaging (I found the log to be less than helpful to find out what was changed and why), but essentially it's priorities and preferences, both subjective, and there's no point in arguing that. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A6B842.5030907%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 13.07.2015 um 23:58 schrieb Jason Moore: Finally, if you would like to share an alternative solution to making it simpler and easier for PRs to get merged then, by golly, please do so. You've now written two long emails that do not come even close to offering an alternative solution to the problems we are trying to solve. That's a cheap shot. Complaining I write too much, then complaining I'm not giving substance - plus, summarily ignoring the actual arguments. That's not trying to be helpful, that's trying to make me shut up. I didn't think it could happen, but now I'm really mad at you. Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A4E535.9040201%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 14.07.2015 um 16:39 schrieb Jason Moore: It wasn't ignored, I just don't see it. All I see are detailed agreements or counters to each point that has been mentioned to be negative about rebasing. Indeed, I misrepresented that a bit. I can't hope to discuss solution details if we don't even agree on the analysis. Even less if the solution isn't 100% complete yet. Here is my two sentence solution: Rebasing has enough substantial negative effects on contributions that we'd like to avoid encouraging it and using it in SymPy development. The few benefits that rebasing offers are not worth the cost of the loss contributions. Can you write a two sentence solution to solving the loss of contributions due to git kung fu issues? I'm happy to read it if so. 1) I think the negative effects can be nullified by giving people a tried-and-true, undoable git workflow (I think is what I meant with incomplete above). 2) Rebasing is the only way to clean up a PR that has undergone several rounds of review. My two-sentence position on the current official policy: A) Rebasing is indeed a more advanced use of git, so it should never be requested, and recommended only with a reference to the explanation of the workflow. B) The current official policy is too strict, the justifications are either bogus or can be avoided. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A52B99.7%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 14.07.2015 um 16:05 schrieb Jason Moore: I want to discuss a comprehensive solution that minimizes the git kung fu overhead for sympy contributors. If you have a suggestion for that, please make it. I did, but that got ignored. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A51C13.2070900%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 14.07.2015 um 18:10 schrieb Matthew Brett: ? I've certainly done PRs where I had a set of changes that I had to rewrite completely on the basis of comments, so that the full history would have been useless and distracting, and an interactive rebase was obviously the best way to clean that up. It seems like a good idea to allow for that possibility, which I think is the main case Jo is worrying about. You're right on spot with that. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A5393B.9080200%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 13.07.2015 um 20:10 schrieb Aaron Meurer: - Greatly increases the complexity of git for new users. Agreed. I would recommend it only for people who are willing to write it. - You can create commits that don't do what they say they do. Yes for non-interactive rebases. For an interactive rebase, you can and should review the commit comment. - You can lose data https://asmeurersympy.wordpress.com/2009/06/22/how-to-permanently-lose-data-with-git-and-then-retrieve-it-again/ . - git rebase puts your repository in a rebase mode, which, unless you have the right tools in your prompt, you may forget you are in (this is how I lost a lot of data using it). Yeah, I can feel that pain. git status is your friend for that. I made a habit of doing that before starting to work on anything, and before committing, pushing, or about any other git command (well, not every single command, but you get the drift). That has been working quite well for me. - Rebasing requires you to force push, which gives you bad habits (particularly, the bad habit of force pushing). True. Not a real issue for pushing PRs. I *think* if I had write access I'd use a separate directory for updates to the master repo. I'd probably want to configure git so that it refuses to force-push from that directory, so that any bad habit can't have a consequence. - Rebased branches are more difficult to review on GitHub. Normally, you see new commits at the bottom of the discussion, but when the branch is rebased, all commits are new commits. If the rebase squashes commits, you have no hope of seeing only the new changes. The bottom discussion always survives. I *think* I saw code lines discussions survive, too, in those cases where a chunk of lines survived the rebase. I'm not sure about when exactly that works and when it does not. Essentially, a rebase requires another round of review to check that all the things discussed are still in there. Maybe there's a way to diff the rebase result against the state of the last commit on GitHub (there certainly is on a local git but that's going to be too much burden on the reviewer). In general, the policy should be do not change anything under a rebase. - Merge conflicts are more difficult to deal with when rebasing. I thought so myself, until I changed my approach to rebasing within my working branch first, merge commits until each piece of code isn't modified by more than one commit, *then* rebase with master. So far, the net result was just the kind of conflicts that I'd have gotten with a merge. - Most fundamentally, rebasing *changes the revision log*. This completely negates the whole purpose of using a version control system, which is to *track* *the revision log*. If this were true, Linus wouldn't have allowed rebasing in git. I think the revision log is a means to an end. The end being the ability to reproduce previous revisions, and keep a record of decisions. Cutting out decisions that were dead ends, misunderstandings, and multiple iterations on less important stuff (PEP8 comes to mind) is a good thing; we do not need the interim versions, and there are no relevant decisions worthy of logging. Furthermore, git handles non-clean history just fine: - Use git log --graph when viewing history. Or use a tool that shows the history as a graph like gitk or gitx. I'm not nervous about the branches themselves. What I find hard to read is long-running branches at the merge point; I'm getting all the changes all at once; if I don't understand them, I have to go back on the side branch, mentally rewinding to the point in time when the side branch forked off. In the end, when I understand what the side branch did and why, I usually find I forgot what I was investigating, so I have to mentally rewind again. I find this hard enough for two branches. If more than two branches are involved, I expect that to become virtually impossible. Rebasing rearranges things into a linear history. I never have to rewind; if I find something uninteresting, I can mentally skip ahead. - git bisect does handle merge commits. It only doesn't know what to do when there is an ambiguity (that is, the bad change comes from the merge resolution itself), which is rare. The more you merge the more often it will happen. A lot depends on how many long-running branches are in existence I think. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A4145F.9000403%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 13.07.2015 um 16:39 schrieb Jason Moore: I apologize for insulting you. Okay. I have no intention of insulting you but I find that the majority of your responses to emails/pr/issues are in essence nitpicks or bikesheds. Yeah... it's all things that one of the project leads or another has insisted on in the past. Personally, I'm happy with whatever the bikeshed color is, but if the majority said yellow then I'm telling newbies to do yellow. Except it doesn't help if one project lead steps in and insist on light brown, because that's how he perceived that color (and sometimes a project leads insists on green, because he doesn't remember, or cares more about personal pet peeves, or both). Things are getting even worse if somebody tries to clean up PEP8 stuff, at which point somebody else steps in and declared that it's bad for the git log. So I take home that the git log is important (which I can agree with), and now I see a policy for merging which is bad for the git log... really, this all is driving me mad. Oh, and all of this bikeshedding and sidetracking discussion while I'm waiting for the really interesting stuff to even get discussed, let alone merged. So there's that source of frustration for me - my nitpicking and bikeshedding is just a mirror of what I get from the project, and trying to make it (mostly) unnecessary to do PEP8 cleanup but now *you* are dissatisfied. Plus, there are things about SymPy that are harder to fix and more difficult to reach a consensus about than PEP8 or even git workflow, but if we cannot get the project itself to stick with these simple things, I have little hope that the complicated stuff will ever get done in a sustainable fashion. We already have lots of orphaned code (I wholeheartedly agree to the push for module maintainers, though maybe coordinator would be a better term - as rightfully said, it's not important that the person in charge knows everything, knowing whom to ping in case of trouble is more important). I feel exhausted reading most of them and at this point I try to avoid reading your responses at all. This last response to my email, which was simply a reminder of a current policy, irked me enough to finally say something more explicitly. Well, the announcement irked me because a) it got some facts wrong, b) it presented a conclusion that I consider less than ideal, c) it hinted at a discussion with no way to check the discussion and see how the consensus was reached, iow it was a decree from above, and hence not open to revision and soon going to be gospel to be followed by the letter instead of guidelines where people have a chance to know when it's appropriate to follow them and when not, d) it's very strong language that massively overstates the policy. Not in order of relevance, I think (b) was least relevant to me. I am happy to have a conversation in whatever medium you want about this once you are willing to. I do think we can come up with something worthwhile, as we are both reasonable people. I have started questioning whether SymPy is worthwhile for me. Partly for reasons in the project (the above is an overly long exposition - sorry for that! - of a large part of them), partly for reasons on my side (other projects, dissatisfaction with Python as a language, that kind of stuff). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A3E779.5000305%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 12.07.2015 um 23:17 schrieb Jason Moore: That is what I think, but I'm not asking you to shut up. Rather, I'd like for you to raise legitimate concerns Well, you're telling me I'm a master of bikeshedding, which is a serious insult. Plus you're dismissing arguments on an issue like git workflow that's neither as simple nor as unimportant as shed color. I'm done arguing against that stance. instead of picking apart every single thing I wrote in the first email. That was just to give feedback where I stand on each point. Remember I wasn't in the discussion, so I had to condense all the points I'd have raised into a single post. Those kinds of responses are tiresome and are not focused on being productive. I think you're applying that conclusion to the wrong response. I'm happy to chat about this more if you want. This isn't the first time we disagreed about relevant points without resolution, so I'm sceptical that talking is going to help at all. I'm not too comfortable with chat in general. Right now, I'm also mightily pissed off, and chat wouldn't filter that as well as mail does, so chat could be really destructive. Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A34E0B.1000405%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 12.07.2015 um 00:17 schrieb Jason Moore: FYI: We had a discussion at SymPy on how to synchronize with master and decided that we no longer want to allow or encourage rebasing after a pull request is made to the main SymPy repo. I think that's overstated. I see some reasons against merging: A) A history with merges is harder to read. You need to track multiple parallel developments, and that's particularly hard if merge conflicts were resolved (because some of the code you see didn't get into master, at least not in the form it's committed initially). B) The results from `git bisect` become harder to read if a bug stems from the combination of two changes that were made in parallel branches: the bisect will point at the merge commit, but the actual problem happened in some earlier commit. The more parallel branches in existence, the more prominent this will become. The main reason is that we stall too many new contributors by forcing them to do too much git kung fu. This problem can be mitigated via interactive rebasing, but I agree it's an extra hoop to jump through and cannot be asked of everyone. But there are additional important reasons too: - Once a pull request is public the history should not change because other people may have pull it. Does anybody ever pull from a pull request? I can see that happening when collaborating on a fix, but it's not something affecting newbies. - Rebasing with merge conflicts is much more difficult Only if you try to rebase everything in a single go. You may end up resolving the same conflict over and over for each commit, and that can get confusing very quickly, and it's also annoying and a lot of needless work. However, there is a process that's actually quite easy: 1) `git rebase --interactive` first; this is a rebase *within your working branch*. I also squash commits that were a continuation of previous work. I.e. if I have a sequence of 1.code - 2.reformat - 3.code - 4.bugfix - 5.reformat - 6.code - 7.bugfix - 8.reformat, I like to rearrange this to 1.code - 3.code - 4. bugfix - 6.code - 7.bugfix - 5.reformat - 7.reformat, and then I squash this into two commits, one with 13467 for the coding and 57 for reformatting. If this still is confusing, this can be broken down into a series of primitive steps: (a) swap two commits, leaving all others alone, (b) merge two adjacent commits, leaving all others alone; repeat until the history is rewritten in a way that's easy to read and review. 2) `git fetch master git rebase master`. This will expose the merge conflicts, but now it's far less commits, and it's also giving you much less pain because most conflicts will apply just in one commit. - Reviewers are no longer able to see commit by commit changes in a review process. Only if you squash everything into a single commit. Reordering and squashing commits makes sense if some work jumped between multiple things, such as reformatting, fixing docstrings, and actual code changes (and if the code changes touched multiple loosely-related points, it may make sense to keep these in separate commits anyway). - Github does not manage the diffs in a PR review if a rebase happens. You mean the click here to see outdated diffs thing? Sure, part of the discussion are removed one more click, which means that people won't know to look there and usually won't find them. However, if a discussion is relevant for posteriority, it should have been merged into the commit in some way, either into the commit comment or in a code comment or docstring. After all, people who're looking at `git annotate` or `git log` aren't going to see these discussions either. If you want to rebase then you should do it before you make a pull request, either locally or on your fork's branch. Oh, now I see what's the concern - indeed, rebasing on the main repo is bad, very bad, and a real no-go. But that's a non-issue! For pull requests, they're on separate branches, and people don't work on the PR branch of anybody else (unless they explicitly have agreed to cooperate in that way, in which case the work branch should indeed not be rebased anymore unless all downstream collaborators agree). Newbies don't even have the permissions to modify the main repo. The one point where I see strong language against rebasing justified is when merging into master on the main repo. This is merge, and merge only, and should be written in bold letters into the project maintenance guidelines. For people who contribute pull requests, I do not think that applies. YMMV, but I'd be interested to hear why. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To
Re: [sympy] Merging instead of rebasing
Am 12.07.2015 um 16:36 schrieb Jason Moore: Joachim, Thanks for the start of the bike shedding, you are becoming a master at it. Thanks. If that's what you think, I'll simply shut up. Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A2B412.2060409%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] TypeError: cannot determine truth value of
Am 11.07.2015 um 09:02 schrieb Paul Royik: But this can't be reproduced. It is a bug from time to time. How can this be possible? Some non-deterministic code path, it seems. Calls for a debugging session to find out what's happening. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A0C685.7080800%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Merging instead of rebasing
Am 12.07.2015 um 00:17 schrieb Jason Moore: The development docs have been updated: https://github.com/sympy/sympy/wiki/Development-workflow#synchronization-with-master-sympysympy Where do I find the img/ subdirectory? img/dev-guide-apitoken.png needs removing (the API token section in Account Settings does not exist on GitHub anymore). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55A1E431.7050901%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Interesting library for generating visualizations on open source communities
Am 09.07.2015 um 12:45 schrieb AMiT Kumar: On Thursday, July 9, 2015 at 1:59:01 AM UTC+5:30, Joachim Durchholz wrote: Am 08.07.2015 um 21:59 schrieb Aaron Meurer: Here is the video https://www.youtube.com/watch?v=RdFYj9NwD3g That video is private, so outsiders can't see it. Yesterday, It was public. Mmm... still private. It may be that it was visible to you because you're in the group that it was published to. I don't know who the owner is (Youtube won't tell), but whoever that is, somebody please notify him or her; the restricted access might be an accident. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/559E51ED.6020008%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Interesting library for generating visualizations on open source communities
Am 08.07.2015 um 21:59 schrieb Aaron Meurer: Here is the video https://www.youtube.com/watch?v=RdFYj9NwD3g That video is private, so outsiders can't see it. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/559D8800.2060002%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Convert between numeral systems
Am 03.07.2015 um 14:48 schrieb Robert Pollak: Hello, I have got a newbie question: Does SymPy provide a way to deal with numbers in different numeral systems and e.g. to convert them between different systems? Or do I have to tell my students that they have to program this by theirselves :) ? That's representation, which usually isn't considered a part of symbolic math. So no, SymPy does not offer routines for that. A short internet search showed me that Gmpy should have them, so I suggest looking there. Also, SymPy will use Gmpy if installed AFAIK, so this should work well for your use case. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5596C9CB.8010008%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] very basic question about plotting and matplotlib
(3) On my local machine. I go sage -ipython which launches a copy of python with all the libraries that you could think of, certainly sympy and matplotlib. Again plot(x*x) and plot(x*x).show() fail to display anything. I'm guessing in this case it's a (simple?) matter of telling sympy to talk to matplotlib, and perhaps of telling matplotlib to start itself. I have no idea how to proceed though! SymPy should automatically detect the presence of matplotlib and use it. Do you have it installed locally? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/559428FD.9090400%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] Enabling SymPy for external dependencies
I just hit another situation where I would really have liked to use an external (small) library that was packaging a huge amount of research and knowledge in a relatively small but well-done codebase. (See the end of this message for details.) My realization is that the Python ecosystem has (finally) started to accumulate libraries that are actually worth reusing: Less work to learn and integrate than to write the thing ourselves. So I'd really like to get us into a shape where we can easily use external dependencies. What are the problems? Can we turn them into tasks? How to we complete the tasks? I.e. I want the problems listed with an eye towards how to we solve that, not with a perspective of that's why we do not do that. Obviously, it's not going to be easy, but probably easier than dealing with decorators. Regards, Jo -- FWIW the latest use case that I had (I had more in the past): Decorators. I spend an ungodly amount of time trying to understand them (easy) and their implication (TONS of research, decorators need to understand all protocols that are involved in classes, calls, and introspection, plus there are differences between Python versions). During that research, I found Graham Dumpleton's essay about doing decorators right: http://blog.dscpl.com.au/2014/01/how-you-implemented-your-python.html Turns out there were issues I *still* wasn't aware of. (That guy is simply awesome.) Even better, he went on and wrote wrapt: https://github.com/GrahamDumpleton/wrapt It's making writing decorators easier. You write a decorator function as before, but you get not just the function you wrap, you get its class, and the resulting decorator will properly deal with functions, methods, static methods, and class methods, it will properly forward __name__, __module__, it will work around incomplete/buggy decorator protocol implementations in the standard library, and probably a few other details that I didn't notice. That guy is awesome. I couldn't do what he did, and I know I can do quite a lot. And I want his code. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/558FB1E7.8000102%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Enabling SymPy for external dependencies
(Replying instead of making this part of the initial post, to keep the questions part separate from my and other people's answers.) What are the problems? Can we turn them into tasks? How to we complete the tasks? Here's my stab at this. Fragile downloads - Problem: External dependencies are typically downloaded from another website, which may be offline or unreachable. Solution: Upload all dependencies into the GitHub repository. Either as separate repositories, or into a subdirectory of the main repo. Both ways would work, the workflows and standard git commands would be slightly different. We would need to adapt the build process to avoid packing the dependencies into the installable bundle. (Or maybe we actually want them in. It's something that can be decided upon.) Severity: Critical. We're already being bitten for the few external dependencies that we have. Unreliable libraries Problem: It is hard to assess the quality of a library without actually using it. Backing out of using a library is more work than adding it in, to projects tend to accumulate dependencies on crappy libraries over time. Solution: Require that each and every assumption about a library's behaviour is documented in a test in SymPy before we allow it to go in. New PRs that use parts of the library need to be checked whether they use a new aspect of the library, and have a test added if not. Be very, very, very reluctant about adding new libraries. Severity: Zero on the short term, critical on the long term. Library versionitis --- Problem: We cannot test all combinations of all versions of all used libraries. (We don't even manage to do that for our existing set of dependencies.) Solution: Again, tests for all aspects of all libraries that we use. Also, define a list of versions that we have tested. Run our tests against all versions. Subscribe the SymPy mailing list to the release mailing lists for all external dependencies; each of them should be turned into a GitHub issue to run the test suite against the new version, fix any problems that we find, and extend the list of supported versions. Never add a library that we aren't confident we can run it through this procedure within the week or so. (We need to be really thorough with our tests to reach that level of confidence.) If it comes to the worst (external library develops into something that doesn't benefit us anymore), we can fork the latest-known-working version of the library and either set up a forked project, or integrate the fork in source form into SymPy. Severity: Medium. More time spent on trade-offs - Problem: Being more open to external dependencies means we have a large overhead for automatic testing. It also means more decisions about whether we want a specific external library or not. Solution: Adding a new external dependency carries more-or-less the same implications as adding a new subsystem to SymPy: It's a large piece of code that we need to integrate, we need lots of tests, we need to commit to maintaining it (the code itself if subsystem, the interface code and tests if external library). We simply need to weigh the advantages of the stuff that the library brings against the disadvantages of having to maintain the interface, the tests, and keeping up with the versions against the advantages of not having to deal with some particular library. Severity: Low, we're already dealing with this kind of stuff. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55901D66.3050007%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] Python version monitoring
Hi all, I just set up a wiki page where we can collect which Python versions we may want to support for how long. You can find it at https://github.com/sympy/sympy/wiki/Python-Version for viewing, corrections, and updates. What's missing is Mac OS, but I know too little to retrieve useful links from there. I'm pretty sure the Linux list is woefully incomplete. I have added Fedora and Red Hat as stand-in lines, but I'm pretty sure some prominent distros are missing (plus Fedora and Red Hat are almost the same anyway, at least in some incarnations). One huge gap is Android. I think SymPy is being used there, but I have no information whatsoever about the Python situation there. With the current (incomplete) information, I'm getting this deprecation schedule: 2.6 can go out in 02-2016 with Debian Squeeze LTS EOL. 2.7 is used in platforms without an announced EOL. 3.1 can go out in 02-2016 with Debian Squeeze LTS EOL. 3.2 can go out in 05-2018 with Debian Wheezy LTS EOL. 3.3 can go out right now, no platform ever carried it. 3.4 is used in platforms without an announced EOL. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55895278.7030804%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Python version monitoring
Am 23.06.2015 um 20:04 schrieb Peter Brady: Python 3 is scheduled to be the default for Fedora 23 https://fedoraproject.org/wiki/Changes/Python_3_as_Default. Ah... that's the first step of phasing out 2.7: Making it unneeded for the distro itself. Though that's not going to affect our decisions at this time; we want to support what users can use, and do not care that much about what the distro uses for its own tools. Is there a URL that tells us the timelines for the various versions of interest? And a URL that tells us which Python packages are available for what version? Fedora 22 will be maintained until 1 month after Fedora 24 comes out which likely means May/June 2016. Ah, no ahead-of-time deadlines then. Well, that's an approx. entry then :-) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5589A86E.50802%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Bug with limit
limit(sin(x)**15,x,0,'+') works limit(sin(x)**15,x,0,'-') hangs Actually, both are working. But the second limit is slow. Confirming for Python 2.6. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55899FF0.5000908%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Python version monitoring
Am 23.06.2015 um 22:37 schrieb Jason Moore: Ubuntu 12.04 is crossed out in the page but it is supported until April 2017 (and is still the version Travis uses). We likely need to support 12.04 Python versions longer. Ah right, I somehow picked the HWE date from the minor upgrade lines. Fixed. (Also fixed the end date for RHEL6.) Though Ubuntu still isn't who's keeping 2.7 alive for the longest period of time, that's still Debian 8 and RHEL6, which will provide it until 2020. 2.7 is going to be really ancient by that time... and maybe we'll decide that distro support isn't going to be the most useful metric by then. Please feel free to add more metrics to the wiki page if you know any! I don't think there is much reason for dropping Python 3.3 as you suggest. I meant to say we *can* drop it, not that we *should*. Also I'm pretty sure one or the other distro will have it. The list is incomplete after all. It is still not that old and there aren't any big technical reasons we shouldn't support it. Definitely. Also, it's going to be much easier to say we support versions from w to z instead of we support versions w, y, and z, the latter is bound to be confusing. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5589D516.4060209%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Python version monitoring
Thanks, I updated the table for RHEL6, which uses Python 2.6 and will go out in 10-2020. Mmm... it says Nov 2020. But I guess that's accurate enough for now :-9 If Production Phase 3 is the relevant cutoff phase, I guess we'll need to add 5 as well. And 7 as it's current, too. Are there any URLs that tell us which Python version is available for what Fedora version? Note that I install my own modern stack in RHEL6 using Hashdist (http://hashdist.github.io/), so I use Python 2.7 and 3.4 and I am personally not affected by not supporting Python 2.6. Ah, Hashdist, virtualenv and the bunch are nice to have, but they don't help us decide which versions we need to support for those people who aren't familiar with setting and using toolchains :-) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5589BE49.1030507%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Python version monitoring
Am 24.06.2015 um 03:32 schrieb Peter Brady: Do pip or conda provide stats on which versions are downloaded? I don't know, but I doubt that that's going to give very useful Python version statistics. I found http://www.randalolson.com/2015/01/30/python-usage-survey-2014/ which is somewhat representative of programmers, not so much usage, but maybe still interesting. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/558A15D8.7030104%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Python version monitoring
Am 24.06.2015 um 01:24 schrieb Francesco Bonazzi: I still use Python 2.7. Is there anyone else like me here? I'm using 2.6, but that's so that I won't inadvertently use anything that doesn't work in later Pythons. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/558A060F.3090103%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Tutorial: How is it kept up-to-date?
Am 21.06.2015 um 18:48 schrieb Francesco Bonazzi: On Sunday, 21 June 2015 04:14:11 UTC+2, Aaron Meurer wrote: We should probably remove the dev-py3k docs. I don't think they have been updated in a long time. Maybe it's better to put a 301 status code for a while, before removing them. In this way, google will probably correctly update the search results URLs. Sort-of. It's hard to predict what Google will do. That's intentional, Google needs to stay ahead of link spammers to stay useful to the general public. https://en.wikipedia.org/wiki/HTTP_301 By the way, when looking for SymPy's documentation on google, there are often results from past versions of SymPy, instead of latest. Does anyone know how to tell Google to update the links? Google goes by how many links point to what page. As long as the old pages have more and more relevant links pointing to them, they will stay on top of the search results. The best we can do is to update the old pages with a warning that the page is deprecated, and with a link to the new page; this could also be done for the dev-py3k docs. As people start placing more links to the newer pages, the older ones will start to drop on the results. However, they need to know that newer pages exist, else they'll continue linking to the first that they found in Google, further strengthening the old page's rank. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5586EEF4.7050103%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Tutorial: How is it kept up-to-date?
Am 21.06.2015 um 20:41 schrieb Aaron Meurer: Links ought to point to the latest urls, which will always point to the latest docs. Both kinds of URLs have their uses. Latest URLs are good for doing work with SymPy. Version-specific URLs are good for finished work. Programs that are coded against a specific versions of SymPy, papers citing SymPy results, that kind of stuff. I'd generate everything with version-specific URLs, and use an additional set of latest URLs that are aliases of some specific version. Perhaps we should install Google Analytics into the docs so we can get an idea of where links are coming from. Google Analytics intrudes on our visitors' privacy, I would avoid that if possible. If you have access to the http access log, pick one of the URLs that are misplaced on the search results and scan the log for that URL; the referer (sic) field tells you where the URL was linked from. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55870D8C.1030103%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] Tutorial: How is it kept up-to-date?
I'm talking about this: http://docs.sympy.org/dev-py3k/tutorial/tutorial.en.html It doesn't seem to get updated (it's still referencing SymPy 0.5.12 and code.google.com), and I'm not finding sources for it anywhere. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5585FB85.3000405%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Local-only matplotlib failure
Am 11.06.2015 um 20:33 schrieb j.gonthie...@gmail.com: I think this is actually the error we discussed about here: https://groups.google.com/forum/#!searchin/sympy/gonthier/sympy/CxiRZWdW6KA/8pyTinsRWGgJ Bummer, you're right. Did you open an Issue for this? It's really annoying. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5579EF67.3040401%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Fwd: Please support PR authors setting labels
FYI, here's my interaction with them: -- Hey Jo, These are interesting ideas -- I can see how label permissions control could be helpful in certain workflows. And adding label descriptions makes sense. I can't make any promises, but I'll definitely pass your ideas along to the team for future consideration. Thanks for the feedback! Cheers, Jess Hi guys, I hear that the SymPy guys are currently campaigning for a way to configure write access to labels, and I'd like to offer my 5 cents worth to that. So here goes: What I'd really like is permissions that allow me to implement a workflow using labels. Ingredients: - Permissions are on a per-group level for each label. (So Reviewers can set the Next:QA label but nobody else can.) - Separate permissions for adding and for removing the label. (So Reviewers can add Next:QA but only QA can remove Next:QA.) - I'd want a pseudogroup Author for the person who started a PR/Issue. - I'd want a pseudogroup Everybody for permissions for everybody with read access to the repo. As far as I understand things, the SymPy people want just a separate permission for can edit labels, probably with settings everybody (all readers) and just those with write access. That would be super helpful for me, too - I wouldn't be able to *enforce* a workflow, but it would still be possible to define a workflow by telling people how to do it. There's another proposal I'd like to make about labels: Add descriptions. Display them as pop-ups wherever the label is shown (i.e. on label display and on any buttons that set or remove a label). That way, people can easily remind themselves of what a specific label is good for. If there's anything I can help to make this happen, let me know. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5579293D.4020103%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Error 'EOF in multi-line string'
Am 06.06.2015 um 20:37 schrieb Robert Pollak: as a SymPy newbie, do I do something wrong here? In [1]: solve([x**2 * y**2 = x**2 * y, x**2 * y**2 x**2 * y]) I can't see anything wrong with that. I'm not sure what that unexpected error thing is and why there's any tokenization anywhere. I'm getting this in current master: solve([x**2 * y**2 = x**2 * y, x**2 * y**2 x**2 * y]) Traceback (most recent call last): File console, line 1, in module File /home/jo/Projekte/sympy-workspace/sympy-project/sympy/sympy/solvers/solvers.py, line 813, in solve return reduce_inequalities(f, symbols=symbols) File /home/jo/Projekte/sympy-workspace/sympy-project/sympy/sympy/solvers/inequalities.py, line 589, in reduce_inequalities rv = _reduce_inequalities(inequalities, symbols) File /home/jo/Projekte/sympy-workspace/sympy-project/sympy/sympy/solvers/inequalities.py, line 514, in _reduce_inequalities symbol of interest''')) NotImplementedError: inequality has more than one symbol of interest This seems to be (not) working as expected I'd say, SymPy is telling us that inequalities on more than one variable are not implemented currently. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55793078.7040502%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
Am 09.06.2015 um 23:39 schrieb Jason Moore: Ondrej and I thought that we should ask Github to enable PR authors' ability to modify labels on their own PRs. We should all put in a request for that. Once you put in a request, please post the link so we can add comments. Thanks :-) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5577F7C2.3010701%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
Am 10.06.2015 um 00:34 schrieb Ondřej Čertík: We don't want ready to merge if Travis is okay to be settable by everybody, we want to reserve that for those who can actually do a merge. However, we want to allow the PR author and any reviewer to remove it. First of all, we can trust the PR authors with stuff like this. I'm more worried about mistakes than about intentional deception. (Oh and then there's trolling, but trolls get banned eventually.) The one how does the actual merge must review the PR anyway (since he is ultimately responsible), and see who set what labels. So if the PR author is trying to deceive us, we would found out anyway. Having to check that will be additional work. Though... probably unavoidable, the author could have added more commits before Travis finishes, so okay to merge after Travis success is probably not that useful, I guess such status labels would need to be removed with every update to the PR. Second, in my workflow, I propose only two labels (author's turn / sympy's turn). You can post a comment that you are ok with merging this if tests pass. You're right - I thought each should be settable only by one party and resettable by the other, but after some more thinking, I see that both PR author and SymPy PR gatekeepers need to set and reset both labels. Still, I do see use cases for per-label configuration. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5577F135.4000400%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
Am 10.06.2015 um 00:37 schrieb Ondřej Čertík: It's really about who's turn it is. So that both reviewers as well as authors can see if they need to do anything. Another potential approach is what needs to be done next? The label set that came out of this thought was this: Needs Evaluation: Projekt must find out what needs to be done, more for Issues than for PRs but occasionally for PRs as well. Needs Work: It's clear what to do, for PRs the PR author needs to do something, for Issues somebody needs to pick this up and start working on it. Needs Review: The PR author thinks the PR should be reviewed. Needs More Review: After the first review passed, either reviewer or PR author thinks another review would be beneficial. Needs Merge: PR author and reviewer are happy with it but couldn't merge (either because the reviewer cannot merge, or because Travis hasn't finished yet). Needs Travis Restart: Travis hung and needs to be restarted, but the person who noticed that doesn't have permission to do so. With that, the needs more work label is back, but it lost its potentially harsh overtone because now everybody is being told that they need to do stuff. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5577DC13.6090705%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
I've added few labels related to PR: PR: needs more work (author's turn) PR: waiting for Travis to finish and then we can use them in a query. Only contributors (i.e. people with repository write access) can set or remove these labels. I.e. most authors can't remove needs more work when they think they're done, and they can't set a please review label. I am currently working on a WSGI script that extracts label-setting commands from PRs, e.g. [+WIP] to add the WIP label and [-WIP] to remove it. It's not done yet (and will take a while until it is), but I can set up a GitHub project to share the code if anybody is interested in speeding this up. Those are all PRs that either can be merged or reviewed. If after the review the author needs to do more work, just add the label PR: needs more work (author's turn). E.g. I'd be unable to add that label, just like anybody else who does reviews but does not have write access. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55775922.305%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
Am 10.06.2015 um 00:22 schrieb Ondřej Čertík: That way, each PR is in one (and only one) of the following stages: * tests are in progress (the yellow status) * labelled PR: needs more work (author's turn) * labelled PR: in review How about calling these: PR: author's turn PR: sympy's turn +1. Needs more work tends to look like criticism, and not everybody is happy to receive criticism. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5577684C.9070605%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
Am 09.06.2015 um 23:55 schrieb Jason Moore: I don't think Github cares how we manage our projects. Sort of. There is a GitHub workflow, and not all git workflows are easily mappable to it (git-flow, for example, won't - not easily anyway). Though I agree that they probably don't care about labels. This is only about enabling us to manage it how we want/need. If they have a checkbox in the repo's settings that allows/disallows PR authors to modify labels then we can decide how much freedom we want to give an author. It would need to be settable on a per-label basis. We want some labels to be settable only by people who can merge, and some labels settable by everyone. Similarly for resetting. Examples: We don't want ready to merge if Travis is okay to be settable by everybody, we want to reserve that for those who can actually do a merge. However, we want to allow the PR author and any reviewer to remove it. For the needs more work label, reviewers and the PR author should be able to set and to remove it. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/557767DB.1000903%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Idea for PRs reviewing workflow
Am 09.06.2015 um 23:39 schrieb Jason Moore: Ondrej and I thought that we should ask Github to enable PR authors' ability to modify labels on their own PRs. We should all put in a request for that. Labels such as ready to merge if Travis is okay with it should not be settable by the PR author, so I doubt GH will implement that. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55775EDC.9010600%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] Local-only matplotlib failure
I'm getting a failure for matplotlib when running the test suite
locally, but not on Travis. I'm not sure whether that's a bug in
implicit_plot, or in the test suite, or whether I'm just missing an
installation dependency.
Here's the trace:
$ bin/test test_plot_implicit -k test_matplotlib
= test process starts ==
executable:
/home/jo/Projekte/sympy-workspace/python2.6.9/bin/python
(2.6.9-final-0) [CPython]
architecture: 64-bit
cache: yes
ground types: gmpy 2.0.5
random seed:62402309
hash randomization: on (PYTHONHASHSEED=3575870938)
sympy/plotting/tests/test_plot_implicit.py[1] E [FAIL]
__ sympy/plotting/tests/test_plot_implicit.py:test_matplotlib __
File
/home/jo/Projekte/sympy-workspace/sympy-project/sympy/sympy/plotting/tests/test_plot_implicit.py,
line 70, in test_matplotlib
plot_and_save('test')
File
/home/jo/Projekte/sympy-workspace/sympy-project/sympy/sympy/plotting/tests/test_plot_implicit.py,
line 22, in plot_and_save
plot_implicit(Eq(y, cos(x)), (x, -5, 5), (y, -2,
2)).save(tmp_file(name))
File sympy/plotting/plot_implicit.py, line 375, in plot_implicit
p.show()
File sympy/plotting/plot.py, line 185, in show
self._backend.show()
File sympy/plotting/plot.py, line 1018, in show
self.process_series()
File sympy/plotting/plot.py, line 921, in process_series
points = s.get_raster()
File sympy/plotting/plot_implicit.py, line 81, in get_raster
temp = func(xinterval, yinterval)
File string, line 1, in lambda
NameError: global name 'Eq' is not defined
= tests finished: 0 passed, 1 exceptions, in 0.20 seconds ==
DO *NOT* COMMIT!
This is Python 2.6.9, with the following packages installed:
$ pip list
alabaster (0.7.2)
Babel (1.3)
docutils (0.12)
gmpy2 (2.0.5)
Jinja2 (2.7.3)
MarkupSafe (0.23)
matplotlib (1.4.3)
mock (1.0.1)
mpmath (0.19)
nose (1.3.6)
numpy (1.9.2)
pexpect (3.3)
pip (1.5.4)
Pygments (2.0.2)
pyparsing (2.0.3)
python-dateutil (2.4.2)
pytz (2014.10)
setuptools (2.2)
six (1.9.0)
snowballstemmer (1.2.0)
Sphinx (1.3)
sphinx-rtd-theme (0.1.7)
wsgiref (0.1.2)
Any thoughts?
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/5576EDC6.4060208%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
[sympy] Can we remove all_classes?
It's not in the `sympy` namespace, but it is documented as a part of `sympy.core.core` (not intentionally I suppose, it's just automatically extracted). I.e. the question is whether we guarantee a stable API for just the `sympy` namespace, or for all submodules as well. Motivation: I'm currently trying to eliminate metaclasses by removing unneeded features that they implement, this should make it *much* easier to clean up the metaclass mess we have. (Everything under ManagedProperties is using BasicMeta both as a superclass and a metaclass, which means that __init__ and __new__ are called both for class creation and object creation - eww.) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55741804.2080109%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Tons of LaTeX warnings on Travis
Am 05.06.2015 um 20:02 schrieb Jason Moore: I think we found out timeout issue but the warnings are still odd, especially since we don't get them locally. That's be nice to fix too. I suspect the Travis build is simply missing some packages that the LaTex build needs. I guess the best way to fix this would be to trace what the LaTeX build is actually doing (probably this means pulling out the Sphinx docs and hunting down all the things is calls, and checking what they need); after that, it's probably trying out things and adding packages via `apt-get install` on Travis until the last warnings go away. (Also, remove packages and see which of them are really needed.) It might also be a good idea to make the builds fail if something is amiss, that way we might get better feedback on doc build errors. (Sergey mentioned something in this direction once.) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5571EA47.6050407%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Tons of LaTeX warnings on Travis
Am 05.06.2015 um 21:54 schrieb Jason Moore: All of the LaTeX warnings were causing Travis to truncate the log and it took us a bit to find it. It would be nice to get rid of these. Not only can this throw off people who don't know that Travis truncates logs with 10.000+ lines, the JS that Travis is using slows my browser to a crawl, and I'm getting all kinds of funny malfunctions. Maybe just disabling these warnings is enough. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/557205E0.6000502%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] diff(x^x,x)
Am 31.05.2015 um 22:50 schrieb Aaron Meurer: Perhaps we should make derivatives of booleans give TypeError. That would make it much easier to see what is going on. +1 Similarly, integer-valued functions should (probably?) emit a warning if a derivative is taken. The derivative is technically correct, but usually not what one wanted. It may also be worth it to print a warning in SymPy Live when ^ is used. I'll be all for it if somebody picks that up. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/556B7A6C.4030009%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to equip a Symbol with an additional attribute?
Good points. So I conclude that it would be nice if somebody came up with a way to allow user-defined attributes without running into namespace conflicts. Oh, and the mechanism should be easy to use for the casual user. I have some ideas in that direction, but I'd like to see what others think first. Independently of that, I'd like to see somebody check whether the performace impact of __slots__ is still relevant; this may have changed with newer Python versions and I'd like to have some contemporary figures so we know what the actual trade-off is. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/555B7F6B.10002%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to equip a Symbol with an additional attribute?
Am 18.05.2015 um 15:56 schrieb Carsten Knoll:
I want to equip an Symbol with an additional attribute to store some
specific information right in place.
For 'normal' Python classes it is no problem to dynamically create an
additional attribute for an already existing instance.
However, for sympy Symbols if I try
x = Symbol('x')
x.k = 0
I get the error
AttributeError: 'Symbol' object has no attribute 'k'
That happens because we use __slots__ for performance reasons.
However, storing attributes in that way is a bad idea in general,
because you risk name conflicts with future versions of SymPy. (That's
also the reason why using subclasses to extend a library tends to break
over time.)
Alternative 1: You could set up a dict with a Symbol-to-attributes
mapping: Symbols are hashable (that's a guaranteed property).
Alternative 2: We could add a `userdict` attribute in Symbol, so that
SymPy users can store additional attributes there.
I'm not too happy with either alternative.
Maybe we can give you better help if you describe your use case in some
more detail.
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/555A2182.8070309%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to equip a Symbol with an additional attribute?
Am 19.05.2015 um 00:44 schrieb Carsten Knoll: That happens because we use __slots__ for performance reasons. I was not aware of the __slots__ mechanism. Now I know. However, storing attributes in that way is a bad idea in general, because you risk name conflicts with future versions of SymPy. (That's also the reason why using subclasses to extend a library tends to break over time.) OK. On the other hand syntax looks much cleaner I prefer maintainable over looks nice any day. However, that's just my professional bias because in software engineering, maintenance dwarves all other concerns. Alternative 1: You could set up a dict with a Symbol-to-attributes mapping: Symbols are hashable (that's a guaranteed property). Thats what I meanwhile did (see my other message on this thread). In addition I redefine __setattr__ and __getatrr__ of the Symbol class to hide the dictionary access behind the scene. This feels somehow strange but it works. Lets see how long. Expect some loss of performance with the __getattr__/__setattr__ overrides. Not sure how much - could be large, could be negligible. Alternative 2: We could add a `userdict` attribute in Symbol, so that SymPy users can store additional attributes there. This would be nice from my point of view. But wouldnt this cause performance issues? As I understand, __slots__ is used to prevent every Symbol instance from having a dict. But introducing a `userdict` would negate this effort. The mere existence of a dict does not impact SymPy much, it's a one-time overhead during symbol creation. Unless you create a gazillion of symbols, this should be negligible. Still, I have seen that done (e.g. in JDK's Swing), and it comes with issues. E.g. two different third-party libraries fighting over the namespace inside the `userdict`. Also, all user attributes now being x.userdict.attr instead of x.attr. Also, yet another detail to know about SymPy (as usual, there are alread too many of them; it's adding to the learning curve). Also, the constant temptation to use it for SymPy itself instead of properly refactoring things. An external dictionary isn't ideal but better than this, at least from the maintainer's perspective. Maybe we can give you better help if you describe your use case in some more detail. At some point I create symbols from which I know, that they are derivatives and I want to store their order. Using the classes Function and Derivative is no real option because I want the symbols to behave as symbols on most occasions. Ah. This sounds like a design problem in Derivative to me that we should fix. Can you post what you did, what you'd have needed to get out, and what SymPy gave you? In general, I think there are situations, where it might be useful to store some algorithm-specific extra information to some symbols. For algorithms of SymPy itself, I think the algorithms should be fixed :-) It would be useful for coding external algorithms, but it does come with ramifications (most importantly the potential for namespace conflicts); from a maintenance perpective, it's far better if such an algorithm does its own data management. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/555ACEC7.4060302%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Boolean bug?
Am 15.05.2015 um 03:42 schrieb Duane Nykamp:
I don't think this is the desired behavior.
In [3]: a=Symbol('a')
In [4]: bool(And(2a, a2))
Out[4]: True
The `And` does not simplify, and the bool() conversion turns it into a
Pythonic `True`.
The former happens because assumptions don't know about relations (yet),
see Remarks in http://docs.sympy.org/latest/modules/assumptions/ask.html .
The latter happens because Python is converting an `And` object to
`bool`, and since it's none of the objects that convert to `False`, it
turns it into a `True`.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/A0AF.2010809%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Boolean bug?
I agree that `bool(And(a2, a3))` and `bool(a2)` should show analogous behaviour. At least that's what I'd assume from my current understanding of assumptions and evaluation in SymPy. I'd like to defer to the real experts on these components (I think that's @asmeurer and @certik). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55566659.3010205%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
On reconsideration, I recognize I may have been assuming too much. My question now is: For the project that you have in mind, what would be the task of the Java side? What kind of data would you want to exchange between the Java and SymPy side? I think that has a deep impact on what you actually need. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554C654E.2070509%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
Am 08.05.2015 um 19:04 schrieb Raymond Gong: I believe java wrapper should be useful for many other people. Important advice: Don't try to second-guess the needs of other people, get your needs covered well. Making code more general is a lot of additional work (Fred Brooks assumes a factor of 3), and if you don't guess right, that additional work will be wasted. Unless, of course, you already have concrete other uses in mind. I'd still be rather cautious about trying to be general - you'll be learning lessons in your first, non-general prototype, that's usually enough work. YMMV ;-) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554CEFE0.7020109%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Is there a way to run a specific test with the cache switched off?
Am 06.05.2015 um 23:01 schrieb Peter Brady: Doesn't the test runner do a clear_cache before each test? No. Just at the start of each file. Ah, I missed that because I ran just a single test where I observed that. I'm wondering whether we shouldn't do clear_cache() before each test. If I do that, overall running time of bin/test increases from 5102 to 5244 seconds on my machine, that's an increase of merely 2.8%. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554CDA2B.2040802%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
Am 08.05.2015 um 18:57 schrieb Raymond Gong: from Java side, we are hoping just pass in the symbolic math expression such as polynomials or whatever K12 math expression, the sympy will return the result that java can consume. From java side, the expression is a java string we can construct the expression based on java string, but the key issue is what kind of format that Sympy can consume. I cannot find this kind of information from the tutorial and documentation of sympy. That's essentially just the class of the Python object, i.e. Basic, Expr, Add, Mul, Pow, whatever. I don't know how to construct, write, or read these from the Java side; I'd expect that information to live in the Jython docs if you can use Jython. If Jython does not work, you can use some string representation. Either normal expressions, or via JSON - there's a json module in the Python standard library, from the Java side, you'd use one of the various available JSON libraries. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554CEF36.8050303%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
Am 08.05.2015 um 19:50 schrieb Sudhanshu Mishra: Creating a full featured wrapper for SymPy in Java is an amazing idea. It will open a lot of opportunities and increase use cases of SymPy in the Android community. I'm very sceptical about that. Python's and Java's data model are essentially incompatible, and Java wrapper will essentially have to represent everything from the Python side as a PythonObject, and all Java-side code will have the feel of doing everything through reflection (which means it's going to feel like clunkiness hell). No less clunky than simply exchanging data via JSON, anyway - but that's going to be one-time upfront work. Both alternatives require a running Python interpreter on Android. I googled a bit around, I'd be rather worried about how compatible these interpreters are and how much work installing them on Android would be for the user (some embed the interpreter in the APK so that's less of a problem). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554CFE39.3040208%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
Am 07.05.2015 um 20:10 schrieb Raymond Gong: Hey, this is the first time for me to be here, tried to search any examples or comments or whatever information on usage of sympy in java project. The standard Python interpreter is a standalone program, interacting with that from Java is always tricky because you have to convert all data structures to and from string. Running SymPy inside Jython might be an easier path. Jython is a Java reimplementation of Python. It is quite possible that SymPy cannot run under Jython - last time we tried using it, it would fail because Jython didn't implement all the Python features that SymPy uses. However, Jython might have implemented enough of Python to run SymPy today, so it may be worth a shot. Be sure to run the test suite to see how much breaks, and whether any of the breakage is going to affect your project. I think it's worth a shot; if it works, you should have SymPy running inside a JVM that can be fed with Java data structures directly. Wonderying, anybody ever worked on the similar project? I think we did some Jython testing a while ago. Maybe a search for Jython in the GitHub search on the sympy project will turn up what happened. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554BC873.4050203%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
Am 07.05.2015 um 22:24 schrieb Ondřej Čertík: On Thu, May 7, 2015 at 2:17 PM, Joachim Durchholz j...@durchholz.org wrote: Am 07.05.2015 um 20:10 schrieb Raymond Gong: Hey, this is the first time for me to be here, tried to search any examples or comments or whatever information on usage of sympy in java project. The standard Python interpreter is a standalone program, interacting with that from Java is always tricky because you have to convert all data structures to and from string. Actually, you just call SymPy using Python C/API, i.e. from C. Then you call this C wrapper from Java, so no string conversions. Ah okay. Interfacing C and Java is still quite a PITA though. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554BD1B9.40603%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] How to use Sympy from java?
Am 07.05.2015 um 22:29 schrieb Raymond Gong: Hi Joachim, Thanks a lot for your nice response. Actually I am doing this, I just replied to Ondrej's message on this, but I didn't run Jython testing against sympy, I even don't know how to do it, could you provide some more information or link on this? My approach to installing Jython (no doubt biased by my other Python workflows) would be (all done from the shell): - Use pythonz to download Jython - Use virtualenv to install it into a project directory (so the pythonz download stays unaltered for future experiments) - Use virtualenv to activate the Jython install - cd to the sympy directory and do the normal bin/isympy. This should install Jython and give you a first smoke test whether SymPy is even able to start under Jython. If it doesn't, report the error messages in whatever the bug tracker has for Jython and try some other approach (unless the messages indicate very easily solved issues: the SymPy project may consider officially supporting Jython if it turns out to be little work to keep it that way). Now if isympy can start, Ctrl-D out of isympy and try bin/test. If that reports no errors, or errors only for modules that don't interest you anyway, Jython is a viable path. (Oh. If your project needs to remain executable in the future, you'll also want that the SymPy project officially supports Jython.) Once this all is done, I'd start exploring how to call into Python code from Java. Calling SymPy functions should be easy: They are all available in the sympy module. I.e. if you see exp() somewhere, it will be available as sympy.exp(). You do not need to worry which module defines a specific function; actually, those that do not make it into the sympy module are not part of SymPy's public API and might go away in future SymPy releases (you can still use them if you're willing to take the risk, Python allows you to override all access restrictions at will). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554BD644.8050806%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] Is there a way to run a specific test with the cache switched off?
I'm currently tutoring PR #9376, which fixes a bug that happens only when caching is turned off. We're trying to figure out a way to write a regression test. Our test suite is run with caching switched on, even on Travis, so we need a way to make sure that this single test is running with caching switched off. I gather that the test framework does clear_cache() before each test, but that's not enough - the test seems to be filling the cache on its own, and enough to break the infinite recursion that will happen without caching. So we really need to disable the caching machinery on a per-test basis. Does such a feature exist? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5549BB35.5000908%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Is there a way to run a specific test with the cache switched off?
Am 06.05.2015 um 21:51 schrieb Aaron Meurer: In my experience, you'll want to run the whole test suite without the cache (I know it's slow). Hm. Obviously nobody ever did this since 25 Jun 2014. I.e. - not ever locally for anybody - not ever on Travis - not during testing for two release candidates - not during testing for a release (0.7.6) A lot of cache related issues only show up when the whole test suite is run, because some test will end up mutating some state that affects another test. Doesn't the test runner do a clear_cache before each test? I saw this happen during doctesting, in code that looked like it's run for both normal and doctesting, so I've been assuming it always happens. It's also very hard to predict where a cache related failure will pop up. Sure. I'm about a regression, i.e. something that's already known to be fragile. Look at the diff: @@ -520,7 +520,7 @@ def _check(ct1, ct2, old): if old == self.base: return new**self.exp._subs(old, new) -if old.func is self.func and self.base is old.base: +if old.func is self.func and self.base == old.base: if self.exp.is_Add is False: ct1 = self.exp.as_independent(Symbol, as_Add=False) ct2 = old.exp.as_independent(Symbol, as_Add=False) It's a subtle error that even a Chris Smith can fall prey to, so I think this line is just fragile and needs to be tested, uncached, on at least one path before the next release. Running tests uncached in general on Travis might work (but might be unworkable). Requiring an uncached test run on prerelease might work, too. The disadvantage here is that release blockers might lie undisovered until right before a release, and the best person to fix the blocker might be unavailable. The final option would be to do cache-related regression tests (and *regression* tests only) without the cache. More infrastructure work required, but faster catching with little extra overhead (assuming that tests can be easily trimmed town to minimal examples). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554A7E65.1040400%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Is there a way to run a specific test with the cache switched off?
Am 06.05.2015 um 20:58 schrieb Peter Brady: Absolutely. I was thinking that there was a decently sized set of tests that were going to be run regularly without the cache in which case it might make sense to introduce another mark/option but if it's only a few than specifying them manually is probably better. I'd definitely prefer a mark/decorator/whatever on the test itself. Keeps the information about the test in one place, instead of distributing it across the test code and the test driver. We have more conditional testing like that BTW. Slow tests, Travis-only tests, tests that require numpy or matplotlib, etc. I'm starting to think that we should unify all these into a single decorator and let the test driver filter. Is something like that in Python's test.py? Then we should probably mimick that. ... right, see pytest.org/latest/example/markers.html . -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554A6934.6000107%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Is there a way to run a specific test with the cache switched off?
Am 07.05.2015 um 00:17 schrieb Aaron Meurer: I've done it a few times (although admittedly not in a while), but there have always been errors that have been too hard to fix, even for a release. Ah, I didn't know that. In the light of this, do we even want to return SymPy to a state that works without cache? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/554AFE05.30707%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Sympy solve on interval
I don't actually know; I know a bit about the internals of the assumptions system, but not enough about the user-facing API to tell useful specifics. I recommend googling for assumptions site:docs.sympy.org Am 28.04.2015 um 13:08 schrieb Paul Royik: How? On Tuesday, April 28, 2015 at 2:04:07 PM UTC+3, Joachim Durchholz wrote: Am 28.04.2015 um 12:42 schrieb Paul Royik: How can I solve equation on the interval? For example sin(x)=0, 2pi=x=4pi Apply an assumption to x. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553F6D02.3060400%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 28.04.2015 um 15:27 schrieb Tom Bachmann: One last set of question here: What was your overall strategy when choosing heuristics? Was that strategy in some way derived from the SymPy's term sort order? (If no, improvement and loss will tend to cancel each other out and I can stop worrying about this.) Which heuristics are you referring to? Those in Meijer. I was assuming Meijer is inherently heuristic. In any case, sympy term order has not been taken into account (by me, at least). Okay then. I was worried that any bugs that I might see would be attributed to the sort order. With your answer, I now know that any problems arising from a changed sort order will have to be fixed in the integral code; that's reassuring and I can proceed. Thanks for the answers! Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553F918A.4010505%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Sympy solve on interval
Am 28.04.2015 um 12:42 schrieb Paul Royik: How can I solve equation on the interval? For example sin(x)=0, 2pi=x=4pi Apply an assumption to x. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553F6923.2090609%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: plotting test failure on Sympy master
Am 27.04.2015 um 00:09 schrieb j.gonthie...@gmail.com: Sympy version 0.7.6-git, up-to-date with the current master on github. Okay, so we're seeing the same failure as you do. Note to maintainers: To reproduce the error, install matplotlib and run bin/test plot_implicit The plot_implicit makes use of experimental_lambdify. Looking at the code, this looks indeed quite experimental, the QA section in experimental_lambdify makes me cringe and want to rip it out and replace it with something sane (as the last QA actually suggests). @J.Gonthier: Do you actually use implicit plots? If no, I suggest ignoring the test failure for now, on the assumption that implicit_plot is essentially unimplemented. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553DFED8.2090706%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] plotting test failure on Sympy master
Am 26.04.2015 um 22:42 schrieb j.gonthie...@gmail.com: File sympy/plotting/plot_implicit.py, line 81, in get_raster temp = func(xinterval, yinterval) File string, line 1, in lambda NameError: global name 'Eq' is not defined I can confirm that this error happens. I had to `pip install matplotlib` to see it; I guess most developers don't have matplotlib installed and didn't notice the breakage. Which version of SymPy are you using? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553D593F.3080309%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 19.04.2015 um 15:31 schrieb Tom Bachmann: The testing philosophy I went for with meijerint was to look at a lot of common book integrals and make sure the algorithm can do them. What this means may not be entirely clear. But certainly we want to have a definite integral returned in elementary terms, and non-vacuous conditions under which the result is true. But there is definitely no *correct* answer. So: If you change something about the internals of the algorithm, expect a lot of tests to fail. The thing to do is to ensure the new results are mathematically equivalent So I guess if I find changes that make tests fail, I'll have to verify that old and new result are mathematically equivalent. and at least as nice (simple) as before. This is unfortunately very tedious. This is going to be a real problem. Even if I see some specific integrals become worse, this might be compensated by other integrals becoming better. And vice versa, of course. I have no way to know whether I'm improving or damaging SymPy on that front. One last set of question here: What was your overall strategy when choosing heuristics? Was that strategy in some way derived from the SymPy's term sort order? (If no, improvement and loss will tend to cancel each other out and I can stop worrying about this.) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553C115F.40404%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Should declaring an assumption restrict values substituted?
Am 24.04.2015 um 00:02 schrieb Jason Moore: That makes sense, but I'm not sure whether Garbage in - Garbage Out should apply or whether SymPy should throw and error. If something is invalid, the user needs to be notified. General policy. Otherwise, if the expressions become large, the user will have difficulties finding out where the garbage went in. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5539F85E.30608%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] The great issue cleanup of 2015
Am 17.04.2015 um 23:11 schrieb James Crist: That's just a name change for each label (one-to-one correspondance with existing labels), which can be done easily later. Grouping labels might make it easier to manipulate them using hooks. But then it's probably better to change the names once it's clear what changes should be allowed by which user group. And once it's clear that we can do this hook stuff in the first place. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5536888F.8030904%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] The great issue cleanup of 2015
Am 18.04.2015 um 01:28 schrieb Aaron Meurer: On Fri, Apr 17, 2015 at 2:05 PM, James Crist crist...@umn.edu wrote: I have another label question: - `Needs better patch`: could be useful to indicate PR status to devs, but mostly I feel that it comes off as rude to the person making the PR. I'd like to remove it unless someone makes a strong argument to the contrary. Do people still use this? This is leftover from Google Code when people literally uploaded patches to issues. It and NeedsReview were the only way to keep track of patches so they wouldn't get lost. But now that we have the pull request queue, I feel that it's mostly unnecessary. I'd be using them if I GitHub allowed me to (I'm using square brackets in PR titles instead, like most others). They indicate who's next to work on the PR. Needs better patch triggers the PR author, needs review triggers reviewers (i.e. anybody except PR author). I find that quite useful. How about adding a hook that inspects comments, and places or removes tags depending on what's in square brackets? E.g. [NeedsReview] adds the NeedsReview label, -[NeedsReview] removes it. The hook should check whether the user group has write access for these labels (not all labels should be settable or resettable by everybody). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/553215F6.4060201%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] The great issue cleanup of 2015
Am 17.04.2015 um 07:40 schrieb James Crist: - Brief discussion on labeling system. Actually I think what you're proposing is fine. If it's found lacking, we can easily fix it. - Help labeling. I haven't found a way to enable tagging for people that do not have full write access to the repository. I suspect GitHub does not offer any. This is also the reason why tagging does not happen very much. BTW I'm super happy that you've picked up with the house cleaning. It was long overdue, and really necessary IMHO. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55315249.3070703%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] The great issue cleanup of 2015
One thing I saw proposed elsewhere is to group labels, by naming them group:label. Am 17.04.2015 um 07:40 schrieb James Crist: *Submodule tags (html #FF, blue):* Everything after `sympy.` for the specific submodule. Keep the naming and casing consistent with the sympy namespace. If the relevant submodule is small, group it in with it's parent submodule. Feel free to create new labels if needed. Multiple tags may be used, but only if needed. i.e. area:evalf, area:integrals, etc. *Classifier tags (html #d4c5f9, light purple):* What kind of issue is this. Currently 3 supported: - `valid`: valid bug *in current master* (will be renamed to bug later, see below) - `wontfix`: not a bug, should be tagged and closed (once everyone agrees/explanation given of course!) - `duplicate`: same issue already exists. Main issue should be linked, and the duplicate closed. status:valid, status:wontfix, status: duplicate - `enhancement`: not a bug, but something that would be nice to have type:bug, type:enhancement *Platform tags (html #800080, purple):* Things that have to deal with specific platforms, python versions. This includes `IPython`, `Python 3`, other versions such as `PyPy`, etc..., `Windows`, and `SymPy Gamma`/`SymPy Live`. I feel like the last 2 should be moved to their respective repositorys, but I don't know how to export issues (it may not even be possible). I'd like to consolidate these if possible, but current system isn't terrible. platform:python.3 etc. *Priority tags (html #eb6420, orangeish?):* How important this is to sympy. I don't like these, as almost everything is marked as medium. I feel they don't provide a level of information that we actually care about, and a better triaging system could be used. Mainly, priority is relative - what's important to some users may be irrelevant to others. Really, only the `critical` tag has been used to some success. But, as we were using them before, let's keep them for now. One policy I just saw was we see everything as normal, and have an 'urgent' classification, so we didn't see a need for 'low'. I do not even see a reason for priority:urgent. Different things are urgent for different people, so maybe something like attention:release (for release blockers) attention:security (for security holes - just an example, it's irrelevant for SymPy) attention:whatever team we might else have *Meta tags (html #c7def8, sky blue):* Issues that have to deal with non-code functionality. Testing and documentation tags are obvious, `Maintainability` has to do with how we organize code/code quality/dev environment issues. *Special tags (html #f7c6c7, pink):* Things that need their own issue and need to stand out. Right now this is deprecation warning removal issues, as they're important and should be easily visible, and `Needs decision` labels. That might be attention:release. Or maybe trigger:release-0.7.8 for issues that should have a review trigger. (OTOH I don't like triggers; they tend to be done twice, and afterwards everybody things they's be the second one. It's usually better to have a status that people automatically know when to reset, something labelled trigger: won't make them reset it.) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5531633F.2030802%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Definite getting started document for assumptions
I roughly understand why assumptions are needed. In my mind: so that sympy knows what the numerical values the symbol can assume. Is that a right way of thinking about it? It's one (correct) way of thinking about it. Another way would be: The set of rules that restrict the values the symbol can assume. That's the perspective with the focus on the information that SymPy can use. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/552F66AC.7050406%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] [code quality] - Pure formatting PRs possibly harmful?
Am 14.04.2015 um 19:54 schrieb James Crist: For example, say I make a tiny bug fix in function foo - I could also clean up some of the code in foo. That way the last person to touch foo is not someone who added a space between an operator, but someone who actually changed the functionality of foo. +1 It's what I've been doing all the time. Well, being human: *trying* to do all the time :-) One exception: I don't apply that argument to adding or removing blank lines, or where the change in functionality is more visible elsewhere (e.g. when cleaning up import lists). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/552D7B86.1040902%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 13.04.2015 um 07:13 schrieb Rathmann: Just one data point that may be relevant -- blame shows the comment as dating from 2012. The code for multiset partitions has changed since then. Ah thanks, I didn't notice that. Thanks for the pointer. I'd still like to know what motivated that comment, in particular whether the tests break part of it was tests break because the integration gives wrong results or tests break because the result is different, though still correct. This is going to be cleared up when Tom comes around (he promised to in private mail, he was just too busy with other stuff to deal with the issue right away). Before pull request 1658, by Chris Smith, multiset_partitions gave bad results. 1658 is from about the same time as the comment. Later, (pr 1848) I replaced Chris' implementation with a faster algorithm. The current ordering is deterministic, but I would be surprised if it were the same as the old algorithm. Meijer uses quite small sets, two or at most three elements IIRC. Do you think your changes should have affected the result order given so small sets? I don't claim any knowledge of Meijer integration, but I don't remember breaking any tests there. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/552B8024.5080507%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Drop support for Python 3.2 ?
Am 03.04.2015 um 11:58 schrieb Francesco Bonazzi: I posted some month ago this link: http://astrofrog.github.io/blog/2013/01/13/what-python-installations-are-scientists-using/ Apparently, in November 2012 the user share of Python 3.2 was negligible, they were estimated to be less than Python 2.4 users! It's very likely that nowadays there will be even less users of Python 3.2. Different studies have different biases. E.g. http://blog.frite-camembert.net/python-survey-2014.html says that there are actually more 3.2 coders than 2.5 ones. (Not that I care much about 2.5. Just about biases.) BTW original data is on https://docs.google.com/forms/d/1DqxkNi4GvyTCu54usSdE1DjW29zw1tc52iMeH3z4heg/viewanalytics , here are the numbers for which Python versions do you regularly use: 2.589 1.3% 2.6 609 9.0% 2.7 5501 81.4% 3.2 191 2.8% 3.3 797 11.8% 3.4 2916 43.1% 3.5 238 2.0% Seems like 3.2 is indeed not much in use anymore. Still, it's really easy to cut out too much. If you drop support for anything that's less than 5%, you already lose 6.1% of the user base, or one out of 16 potential users. If we go just by the numbers, we should probably rather drop 3.5... I believe tests should not run on Python 3.2, it's just a waste of time for a Python version that hardly anyone is using. I'm not feeling very strongly either way, actually. It might be a good idea to do the tests in order of descending relevance. I.e. first 2.7 and 3.4 (stable versions), 3.5 (upcoming version), then 3.3, 2.6, and 3.2 (deprecated but still in use, in descending order of usage). -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/551E79DD.3060401%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Drop support for Python 3.2 ?
Am 03.04.2015 um 20:01 schrieb Aaron Meurer: My understanding was that Debian was shipping 3.2, That's indeed the case. Jessie (the next release) will use 3.4. More details on https://wiki.debian.org/Python . and hence it would be good for us to continue to support it. Agreed. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/551EDDA1.20404%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Recommendations for creating symbols
Am 30.03.2015 um 21:33 schrieb Aaron Meurer:
I would definitely test the different alternatives for sympy.abc to
see what's faster.
I just ran bin/test with `a = Symbol('a')` etc.
Runtime went from 56:29 to 56:37, i.e. below the noise threshold.
That was with Python 2.7. I guess the Pyton compiler is fast enough
after all.
It's not too surprising actually: symbol creation happens just once at
first module import, for ~75 symbols, which isn't particularly often.
Other considerations
Error situation:
Importing abc offers the trap that `import * from sympy.abc` overwrites
the COSINEQ single-letter definitions from other SymPy modules. It's a
trap that everybody walks into once, has trouble figuring out, then
knows how to avoid.
For ..., n, m, ... = symbols('... m, n, ...') we have a trap that
everybody walks into, has trouble figuring out, then fixes easily and
knows how to avoid... essentially the same situation as with a star
import. Well, worse because the problem is harder to diagnose with more
varied failure mode, less bad because it bites only those who import a
lot of names from abc.
Static analysis:
Importing from sympy.abc will confuse all static analysis tools because
sympy.abc uses exec with a constructed string.
Using symbols() will not cause that problem.
Performance:
Using symbols() in all contexts might have performance ramifications,
creating new Symbol() objects means more memory pressure than reusing
precreated symbols from sympy.abc (which happen 521 times in SymPy
itself, hopefully just in test code).
Implementation effort:
Switching to symbols() wherever sympy.abc is used would mean touching
521 imports, and checking whether symbol reuse is actually okay for all
uses of the imported names.
Alternate implementation
Implement sympy.abc using this:
--
a, b, c, d, e, f, g, h, i, j = symbols('a, b, c, d, e, f, g, h, i, j')
k, l, m, n, o, p, q, r, s, t = symbols('k, l, m, n, o, p, q, r, s, t')
u, v, w, x, y, z = symbols('u, v, w, x, y, z')
A, B, C, D, E, F, G, H, I, J = symbols('A, B, C, D, E, F, G, H, I, J')
K, L, M, N, O, P, Q, R, S, T = symbols('K, L, M, N, O, P, Q, R, S, T')
U, V, W, X, Y, Z = symbols('U, V, W, X, Y, Z')
alpha, beta, gamma = symbols('alpha, beta, gamma')
delta, epsilon, zeta = symbols('delta, epsilon, zeta')
eta, theta, iota = symbols('zeta, eta, theta, iota')
kappa, lamda, mu = symbols('kappa, lamda, mu')
nu, xi, omicron = symbols('nu, xi, omicron')
pi, rho, sigma = symbols('pi, rho')
tau, upsilon, phi = symbols('sigma, tau, upsilon, phi')
chi, psi, omega = symbols('phi, chi, psi, omega')
--
Error situation: As with importing.
Static analysis: As with symbols().
Performance: As with importing (minimally faster, perhaps).
Implementation effort: Very, very easy.
Also, I wonder what the effect of sympy.abc on the cache is. We have
an LRU cache, and assumedly importing it messes with that, at least
for a little bit.
How can I test this?
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/551CF4A8.5050709%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Question about the management of the pull requests
Am 02.04.2015 um 11:30 schrieb Christophe Bal: Thanks for the answers. Indeed I was hoping that git can manage multi pull requests. If it is not case, Il will build a python scripts such to play with the git --stat outputs. Wait until you have seen some actual merge conflicts :-) It's not usually an issue. Not unless you do something cross-cutting that touches many modules. And even then it does not happen very often that two people touch related lines of code. Now that I know a little git, I will try to participate as soon as possible. That's enough to participate. git expertise comes with use (that's more true for git than for many other tools). Thanks for pycharm but I prefer to use atom. No problem with that. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/551D5469.8050506%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Recommendations for creating symbols
Am 02.04.2015 um 18:46 schrieb James Crist:
Performance:
Using symbols() in all contexts might have performance ramifications,
creating new Symbol() objects means more memory pressure than reusing
precreated symbols from sympy.abc (which happen 521 times in SymPy
itself, hopefully just in test code).
We cache symbol creation, so Symbol('a') is Symbol('a') is True. This means
no additional memory is consumed.
Ah, I wasn't aware of that.
What happens with assumptions - do these persist? (I'm a bit worried
about tests here.)
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/551D7457.6000306%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
[sympy] Recommendations for creating symbols
Hi all,
I'm wondering about the section on creating symbols in
https://github.com/sympy/sympy/wiki/Idioms-and-Antipatterns#strings-as-input
.
It is mildly discouraging importing from sympy.abc because an accidental
from sympy.abc import * would clobber I and Q (and possibly others),
and recommends
import symbols
x, y, z = symbols('x y z')
instead.
Now in https://github.com/sympy/sympy/pull/9219 , I applied this advice to
from sympy.abc import t, w, x, y, z, n, k, m, p, i
and got
t, w, x, y, z, n, k, m, p, i = symbols('t w x y z n k m p i')
I think that's actually really dangerous, because it's easy to swap two
letters without noticing so you essentially get the equivalent of
p = Symbol('i')
i = Symbol('p')
with the devious consequence that everything would still work but any
outputs would be utterly confusing because it would print 'p' wherever
the user expects 'i' and vice versa.
So... should I change the wiki to recommend sympy.abc over symbols()?
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/551916B5.8090808%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Recommendations for creating symbols
Am 30.03.2015 um 13:28 schrieb Francesco Bonazzi:
[with `symbols`,] it's easy to swap two
letters without noticing so you essentially get the equivalent of
p = Symbol('i')
i = Symbol('p')
with the devious consequence that everything would still work but any
outputs would be utterly confusing because it would print 'p' wherever
the user expects 'i' and vice versa.
What about a new code quality test checking for such mistakes?
Sounds like an excellent idea to me.
Solves the basic problem for code in SymPy, so this should definitely be
done (or put up as an Issue so it is not forgotten).
For user code, this does not help, unfortunately.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/551989F3.5040504%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Recommendations for creating symbols
Am 30.03.2015 um 19:58 schrieb Aaron Meurer:
symbols() supports commas, so an easy thing to do here is to use the
form symbols(' t, w, x, y, z, n, k, m, p, i'), so that the left-hand
side of the assignment exactly matches the right-hand side.
Ah, I knew it could do commas but I didn't know that it allows the
comma-plus-space combination as well.
That's going to make replacing `from sympy.abc import ...` with
`symbols('...')` easy enough (and I think I'll fix up any existing calls
as well, just to set the precedent).
Question is: Is this what we want?
grep reports 2200+ mentions of 'abc' in SymPy, that's an awful lot of
work, both for fixing and for review.
My personal main motive that I even started actually doing this has been
to get some more warnings out of the system - static analysis does not
know about the symbols that the exec calls in sympy.abc generates.
I could imagine fixing that by rewriting sympy.abc as
a = Symbol('a')
b = Symbol('b')
...
z = Symbol('z')
A = Symbol('A')
B = Symbol('B')
...
Z = Symbol('Z')
from sympy.printing.pretty.pretty_sombology import g, G
alpha = Symbol(g('alpha'))
beta = Symbol(g('beta'))
...
omega = Symbol(g('omega'))
ALPHA = Symbol(G('ALPHA'))
ΒETA = Symbol(G('BETA'))
...
OMEGA = Symbol(G('OMEGA'))
It's dull, it's dumb, but it gets the work done, and this needs to be
maintained so rarely that it shouldn't be a problem.
It should also make the import of sympy.abc fast (I guess importing
sympy.abc is slow because module initialization runs ~100 one-liners
through the Python compiler, though I haven't checked that it is indeed
as slow as `sympy/__init__.py` suggests).
However, that's just something that I came up with tonight, I'll be
happy to follow whatever course people see as best.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/55199B7D.5030505%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Recommendations for creating symbols
Am 30.03.2015 um 21:33 schrieb Aaron Meurer: I would definitely test the different alternatives for sympy.abc to see what's faster. Also, I wonder what the effect of sympy.abc on the cache is. We have an LRU cache, and assumedly importing it messes with that, at least for a little bit. Preliminary findings: Once isympy is started up (which takes quite a while), doing from sympy import abc takes negligible time, whether via exec_ or directly. Doing $ python bin/sympy_time.py and $ python bin/sympy_time_cache.py both fail, though with different messages. (I'm being called off and can't investigate more.) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5519CB46.5020701%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: How do I construct this rational expression?
Am 28.03.2015 um 21:35 schrieb Aaron Meurer: Except in the tests you should use a more directed, efficient simplification function than simplify(). cancel() should be sufficient for this case. That worked, thanks. Is there a guideline which function to select for what kind of normalization? (I admit I haven't read SymPy's documentation, reading it all has always been a daunting task.) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55172EA4.4020800%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 28.03.2015 um 00:51 schrieb Aaron Meurer: On Fri, Mar 27, 2015 at 5:26 PM, Joachim Durchholz j...@durchholz.org wrote: The other approach would be to accept that some unit tests depend on sort order in a superficial way, and to change the unit tests. (2) The not-so-nice aspect about this one is that the PR must contain both changes: those to the sorting order, and those to all the tests that actually depend on that sorting order (a dozen or two of them). It's not going to be a monster PR, fortunately. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5516A665.5040803%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] How do I construct this rational expression?
I need to update a unit test where integrate now returns something that contains 1/(2*(s+1)). However, when I write that subexpression, SymPy gives me 1/(2*s + 2), which compares unequal. What would be the best way forward? Alternatives that I can think of: - have integrate() do whatever SymPy does when constructing 1/(2*s + 2) - have the unit test do it and leave integrate() as it is - rewrite the unit test to directly construct the Expr object (how?) -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5516BA6D.2090903%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 28.03.2015 um 00:51 schrieb Aaron Meurer: On Fri, Mar 27, 2015 at 5:26 PM, Joachim Durchholz j...@durchholz.org wrote: The other approach would be to accept that some unit tests depend on sort order in a superficial way, and to change the unit tests. (2) Is the result deterministic? And is it still mathematically correct? Deterministic: yes. Mathematically correct: Sort of, one Piecewise condition goes from Ne(1/s, 1) to Ne(s, 1). For SymPy, it is equivalent; for the human reader, it might be considered mathematically almost equivalent due to the singularity at s=0. With a mathematically incorrect result I'd assume a bug in the integration algorithm anyway. Is there a third, better approach? I indeed came up with third approach tonight: keep the existing sort order and remove the comment that it is outdated. Not better, but correct enough to have a place on the list of options. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/551655B5.9050300%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 24.03.2015 um 22:29 schrieb Aaron Meurer: On Tue, Mar 24, 2015 at 4:36 AM, Joachim Durchholz j...@durchholz.org wrote: Is Meijer heuristic? In that case, I think variation due to changed sort order would be expected. Yes, it uses a lot of pattern matching, which is heuristic in nature. I have tracked down the difference to a flatten() call inside the Mul constructor. After that, Meijer is getting its heuristics in a different order. (I have taken a cursory look at the other test failures, and ~75% seem to be integration-heavy math such as quantum physics.) Problem is that if we change Mul to not sort its arguments via flatten, this is going to ripple all over SymPy. That's not a labyrinth I wish to enter. (1) The other approach would be to accept that some unit tests depend on sort order in a superficial way, and to change the unit tests. (2) Is there a third, better approach? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5515D91E.7040509%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: GSoC- 2015 Assumptions
Am 25.03.2015 um 20:11 schrieb Aaditya Nair: Especially the part about ManagedProperties. Aside note: ManagedProperties might get split into two classes one of these days (or weeks (or months, depending on how quickly I can get some preliminaries out of the way)). This isn't going to affect your changes much, except that they might go into a class with a different name. No need to worry about this now, it's just that we may have to coordinate changes if we happen to get to ManagedProperties at the same time. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55132CC4.9010505%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 23.03.2015 um 22:39 schrieb Aaron Meurer: On Mon, Mar 23, 2015 at 4:35 PM, Joachim Durchholz j...@durchholz.org wrote: #2 Now this is asserting Eq(1/s,1) for old and Eq(s,1) for new. These are semantically different for the case s=0 (i.e. integral of just sinh(x)): Old sort order gives a fail, new sort order gives a definite result. Now I'm wondering how this is accidentally improving Meijer heuristics. (Or is the difference mathematically irrelevant?) And I'm wondering where a changed sort order might accidentally worsen the heuristics. If s = 0 in either case Ne(s, 1) and Ne(1/s, 1) will be False, Ah. I'd thought that Ne(1/s, 1) would be None (because 1/0 undefined). so I think in this case they are completely the same. Then they are. The version with s is obviously simpler, but we shouldn't rely on the algorithm to give simple results, unless there are no other changes. Is Meijer heuristic? In that case, I think variation due to changed sort order would be expected. Oh. I find the ordered() call in _rewrite2 isn't dependent on Basic ordering at all, I would try to find some other example that this gives different results for, I won't find anything by myself (not enough integral knowledge on this side of the keyboard), but I'll take a look at the other unit test failure related to integrals. Or, alternatively, we could start torture testing SymPy by making Basic use a random (but consistent-per-run) sort order, e.g. XOR PYTHONHASHROOT into the class names before comparing them. I'm obviously working on making SymPy's unit tests robust against this kind of change, but I'm sceptical that this will be doable for heuristic algorithms. or, preferably, get ahold of Tom Bachmann, and see if he can shed any insight. I'll try to contact him. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/55113020.60804%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] GSoC 15: Improving Assumptions
Just a heads-up: I'm in a bit of a squeeze and won't be able to review the application. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/551130CE.7060503%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Am 23.03.2015 um 22:39 schrieb Aaron Meurer: I would try to find some other example that this gives different results for, or, preferably, get ahold of Tom Bachmann, and see if he can shed any insight. I can't find Tom via github, his account seems to be gone. I tried contacting him via the mail address in the AUTHORS file, but I didn't get an answer yet. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5511D0DC.8000902%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] what does S(0) mean?
Am 23.03.2015 um 00:29 schrieb Aaron Meurer: https://docs.python.org/3/reference/datamodel.html#object.__lt__. That page in general is a good reference for all these sorts of things. Aaah... I've been turning to the 2.7 docs so I don't accidentally do anything 3.x, and the NotImplemented detail isn't documented in the 2.7 version of datamodel.html. -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/550FBB18.6000900%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
[sympy] meijerint.py: Sorting in _mul_as_two_parts, _rewrite2
Hi all, this probably mostly goes to Tom Bachmann and Chris Smith, but maybe others know a bit about Meijer integration. I'm working on something that changes the internal ordering of terms a bit, and Meijer seems to rely on the current ordering for some vaguely-explained benefits; I need to find out whether it's relevant or not. Specifically, during sympy/integrals/tests/test_integrals.py:test_issue_8368 , I see a call to _rewrite2(f, x) with f = Mul: exp(_x)*exp(-_x*s)/2 and x = Dummy: _x (it seems only f is relevant here). The docstring for _rewrite2 talks about multiset_partitions returning stuff in a canonical (but not always optimal) order. Frustratingly, it does not really explain what the problem is, nor what will fail if the order is changed. It might be ultimately irrelevant though, as further processing filters the result through ordered() in _rewrite2. If that's the case, then maybe the docstring of _rewrite2 is wrong about test cases breaking, so I'm unsure whether my current understanding of what's going on is missing something important. Any tips, pointers and explanations appreciated. Regards, Jo -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5510598B.3060405%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] what does S(0) mean?
Am 22.03.2015 um 22:23 schrieb Aaron Meurer: Python operations fallback to the reverse operation when they are not defined, so e.g., x + y does x.__add__(y) and if that returns NotImplemented, it does y.__radd__(x). For the comparison operators, it does the flipped operator, so this would be (0).__le__(x + 3), which returns NotImplemented, so it then calls (x + 3).__ge__(0), which works. Good to know - I was suspecting that that's the case, but wasn't 100% sure. Is this behaviour documented somewhere? I didn't find any reference to it, but maybe I'm looking in the wrong spots. The only downside here is that you end up getting inequality in the reversed order from what you wanted. No big deal as long as all comparison functions are implemented consistently, I suppose. Do I suppose correctly? Ah, one trap: Consistency has to be ensured across classes. Not difficult but requires diligence and quite precise knowledge about Python's comparison semantics. Any other traps? -- You received this message because you are subscribed to the Google Groups sympy group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/550F3F36.7090109%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
