Re: [sympy] Re: SymPy 0.7.1 Release
On Wed, Jul 20, 2011 at 7:48 AM, Ronan Lamy wrote: > Le mardi 19 juillet 2011 à 20:49 -0600, Aaron Meurer a écrit : >> On Tue, Jul 19, 2011 at 8:43 PM, Mateusz Paprocki wrote: >> > Hi, >> > >> > On 19 July 2011 20:31, Aaron Meurer wrote: >> >> >> >> On Tue, Jul 19, 2011 at 1:27 PM, Aaron Meurer wrote: >> >> > Well, right now, we need to close the blocking issues, which are not >> >> > many (see >> >> > http://code.google.com/p/sympy/issues/list?can=2&q=Milestone%3DRelease0.7.1+&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary+Stars&cells=tiles). >> >> > The first two I just need someone to review my branch. The third is >> >> > something that would be nice to have, but we could live without if no >> >> > one gets to it. >> >> >> >> After I sent this, I just marked two more issues as milestone. So to >> >> be clear, the QT console one is the one that could potentially be >> >> postponed if no one does work on it. >> > >> > It would be also nice to merge Lambda printer fix. >> > >> >> I just merged it > > That's the Λ(x, 2⋅x) nonsense, right? I would have thought that pushing > in controversial changes just before a release wasn't a good idea. But > OK, I guess, let's clear out the review queue! I am sure that (with enough will) there is a way to allow multiple ways of printing for cases where people have different preferences how to print things (like Lambda). As for this particular thing, I don't think it's nonsense. However, I respect that you have a different opinion Ronan, and I understand your resentment that something got in, that you don't agree with. Given the nature of the patch (that it can be improved upon, allowing different printing styles, see above) and given the fact, that somebody will be unhappy either way (if this patch does or does not go in), I think that it is more important to reduce the number of the open patches in our queue, and so I 100% support Aaron's decision. SymPy is an opensource project, and I do want a lot of people to be involved with the development. The price for that however is, that sometimes, not everybody can be always 100% happy, including myself --- there are patches, that I am +0, or sometimes even a little negative about, but if I can see good will, it is important to move on, and let the momentum rolling, and unless something really fundamentally breaks sympy, it can always be fixed quite easily. So one has to be really careful about patches into sympy core, but for printing patches, or adding new features, it's more important to get it out of the way and improve upon it. Ronan, if you want to talk about this more, as I offered you in private emails, feel free to discuss it on the list, or privately with me (or others). We can also talk over the phone, or any other communication medium, that works for you. Feel free to ping me anytime. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: SymPy 0.7.1 Release
On Thu, Jul 21, 2011 at 8:50 PM, Aaron Meurer wrote: > I have created a 0.7.1 branch in the main repository (this will work > just like it did last time with 0.7.0). Brian has requested that I > not include Tomo's quantum stuff, which was merged a little too soon. I merged that one. I missed Brian's request. The pull request looked good, and there were no -1 on that and all tests passed. > > Assuming tests pass and everything, I will create a release candidate very > soon. Thanks for the work! Once you post the rc, I'll test it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] SymPy 0.7.1 Release Candidate 1
On Sat, Jul 23, 2011 at 4:20 PM, Aaron Meurer wrote: > On Sat, Jul 23, 2011 at 11:32 AM, Vladimir Perić > wrote: >> On Sat, Jul 23, 2011 at 9:36 AM, Aaron Meurer wrote: >>> Hi everyone. >>> >>> I have made the first release candidate for SymPy 0.7.1. You can >>> download the source at >>> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.1.rc1.tar.gz, >>> a Windows32 installer at >>> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.1.rc1.win32.exe, >>> and the docs for this version at >>> http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.1.rc1-docs-html.zip. >>> >>> The release notes are at >>> https://github.com/sympy/sympy/wiki/Release-Notes-for-0.7.1. I will >>> give this in more detail when I do the full release, but the big >>> changes here are that isympy now works in IPython 0.11, which will be >>> released soon, Pyglet is now an optional external dependency, Python >>> 2.4 is no longer supported, and our docs use MathJax to render the >>> LaTeX math. There have also been several bug fixes and new >>> functionality (see the full release notes). >>> >>> So please download the release and test it. Also, since our docs have >>> received a significant update with the MathJax, I ask that you also >>> download the docs and see if they render correctly in your broswer of >>> choice. Some pages that use a lot of MathJax math include >>> modules/simplify/hyperexpand.html, most of the mpmath documentation, >>> and modules/galgebra/GA/GAsympy.html. We also enabled a feature in >>> Sphinx that lets you view the source code of a function in the >>> documentation. So, next to every function definition, there should be >>> a "source" button which takes you to the source code of the function. >>> >>> If there are no major problems, I will do the full release in about a week. >>> >>> Aaron Meurer >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To post to this group, send email to sympy@googlegroups.com. >>> To unsubscribe from this group, send email to >>> sympy+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/sympy?hl=en. >>> >>> >> >> I've run the usual tests on my computer, everything seems fine. One >> issue is the hyperexpand tests. They rely on random numbers so they >> fail occasionally (see the SymPy-hyperexpand job on Jenkins, they fail >> about 1% of the time with ness' latest patch). This is bad because >> users might think this is some more important failure. On the other >> hand, simply reverting the whole patchset is no good either, as it >> does bring nice new features. So, if ness doesn't manage to solve it >> completely in a few days it might be a good idea to apply a patch to >> branch that'll use some specific numbers in the tests. >> >> -- >> Vladimir Perić >> > > I'm not sure if that's a good idea. The point of the random tests is > to increase coverage. Tom, what is your opinion on this? I also don't like random tests, because it is not robust. I think that random tests should be disabled by default, but can be turned on if needed. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: SymPy 0.7.1 Release Candidate 1
On Sun, Jul 24, 2011 at 2:16 PM, Vinzent Steinberg wrote: > On Jul 24, 4:45 pm, Tom Bachmann wrote: >> That would be one possibility; defaulting to a specific, tested seed in >> release tests. >> >> On the other hand my tests have not failed in the last >300 runs on >> jenkins (since I pushed the last fix). This does not mean too much of >> course. > > I think our tests should be determined by default, there should be no > randomness, because it makes it impossible to reproduce failures. (If > the test runner printed the seed and it was possible to pass the seed > to the test runner, this would be something else, but this is > currently not the case.) > > So I suggest we make random tests optional for now. Having random > tests by default needs to be discussed IMHO. I 100% agree. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Avoiding big branches
On Mon, Jul 25, 2011 at 3:24 PM, Aaron Meurer wrote: > Hi everyone. Can you describe what exactly you did with your branch? I.e.: 1) forked sympy in summer 2010, kept adding patches 2) merged with polys1 branch 3) polys12 (incompatible with polys1) merged to master 4) merged with master (thus *conflicting* with polys1, merged to your branch) I think, that maybe all (?) your troubles were caused by merging the polys1 with polys12, which were known to be incompatible, because polys12 was rebased. In other words, maybe this is just a manifestation of "never rebase, only merge", if people are using your branch. I think that as long as the only thing that you do is "merge", things should be much more easier. I have personally worked with some larger branches too (~250 commits easily), and my experience so far is that as long as there is no "double merge" (like polys1 and polys12), things are quite simple. My longest rebase was I think 1h of work. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Avoiding big branches
On Tue, Jul 26, 2011 at 1:48 PM, Aaron Meurer wrote: > Basically, it was like this: > > Mateusz had his polys branch, which had all his polys fixes. Every > time Mateusz wanted to be up to date with master, he rebased, and > created a new branch, polys2, polys3, etc. > > My branch from the start, integration, was based on one of these polys > branches. Then, when I wanted an update from one of the polys > branches, I would rebase over the newest polysn and renumber my > branch, integration2, and then integration3. But at this point, I > realized that rebasing is bad, and I should really not be doing it. > > So from that point on, I have never rebased the branch. This is why > my branch is called integration3 instead of just integration, btw. > > Probably if I had been rebasing over master instead of merging, this > would have been easier. But it would have been a false sense of easy. > This is because only half of the problems came from merge conflicts. > Other things were changes in the code. For example, as_basic was > renamed to as_expr. If I had rebased my branch over maser, not a > single commit in my history would have worked any more, because they > all use as_basic. So my choices would have been: > > 1. Go back and fix each commit in the history so that the tests pass. > This would have been even *harder* than the merge, I think. > > 2. Have a branch were bisecting is basically impossible. > > Another problem with rebasing is that sometimes changes are rebased > out, so you are left with commits that no longer change what they say > that change. I have commits like this in my branch, from when I was > rebasing. For example, > https://github.com/asmeurer/sympy/commit/4fbc80c12aae45f3a95e05740b62c4d546ada337, > which is from my original integration branch, does what it says, it > adds a check for the Python version. But this was backported to master > since my integration3 rebase, so now the corresponding commit > 2ffedb50a3e0a4ae274d117ef87e09834ff8c98b looks confusing, because the > part that does what the commit message says was rebased out. We also > see the problems of rebasing from the original polys merge (not > polys12, but the very first new polys branch). There are a bunch of > commits near the beginning of that branch for which sympy does not > import; you may have noticed these if you've tried bisecting back that > far. No doubt these worked originally, but the rebase broke them > somehow. > > This is why I believe you when you say your longest *rebase* was 1h or > work, because rebasing is easier in the sense that it hides these > problems from you. How long would it have taken if you had done the > right thing and merged instead? My branch was messy, so I didn't want to have it "just merged". Also, I realized, that I think at one occasion, it took me more like 2h. Still though, not a big deal. >From what you say, I think that the conclusions are clear: 1) Mateusz should have just kept merging, and you should have kept merging to his branch. 2) The only time rebase is allowed is on your private branch, that nobody is using (yet). There is also another big problem --- when reviewing pull request, some people just rebase everything, and there is no way for me to check what changes they actually made. I think that a better practice is to do "the best" and submit a good solid pull request. And then just keep adding patches. (Unless it's so screwed up, that a good nice rebase is appropriate, for example when one is new to git, and one should do it at the end of the review, if nobody is using that branch yet) Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] sympy for Quantum Field Theory (QFT)
Hi Cschwan,
On Thu, Aug 4, 2011 at 5:21 AM, cschwan wrote:
> Hello!
>
> I would like to know if sympy can be used for Quantum Field Theory
> calculations. In particular, I would like to compute traces of dirac
> matrices and contract them with four-vectors. For example, the
> following holds true (latex notation):
>
> Tr ( \gamma^\mu \gamma^\alpha \gamma^\nu \gamma^\beta ) p_\alpha n_
> \beta = 4 ( p^\mu n^\nu + n^\mu p^\nu - g^{\mu \nu} p \cdot n )
>
> I am using the following clifford identity to calculate the right hand
> side:
>
> \gamma^\mu \gamma^\nu + \gamma^\nu \gamma^\mu = 2 g^{\mu \nu}
> \cdot 1
>
> The \gamma^\mu are elements of a clifford algebra and at the same time
> are lorentz vectors, g^{\mu \nu} is the metric tensor. Since the
> \gamma^\mu are represented by 4x4 matrices, I can take the trace of
> them. Because of the identity above and
>
> Tr (1) = 4
>
> I can show that
>
> Tr ( \gamma^\mu \gamma^\nu ) = 4 g^{\mu \nu}
>
> By repeatedly applying the clifford identity I can derive identities
> for traces with than two gamma matrices.
>
> Does somebody know if this is possible with sympy? When I looked into
> sympy's documentation I noticed there are already modules for tensors
> and geometric algebra, but I did not find anything to work out the
> traces.
Try to look at this example:
https://github.com/sympy/sympy/blob/master/examples/advanced/qft.py
I wrote it couple years ago. If you would like to help improve this
functionality, that would be absolutely awesome. Let us know.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: sympy for Quantum Field Theory (QFT)
On Fri, Aug 5, 2011 at 12:50 AM, cschwan wrote:
> Thank you for your answers!
>
> Unfortunately, I do not have access to the book Alan mentioned (I
> think of buying it, saw it before when searching for the subject).
> Nevertheless, thank you for your PDF-file, I will have a look into it.
>
> The example from Ondřej is looking very similar to what I am looking
> for. However, I noticed that the gamma matrices are implemented by a
> specific representation. In my opinion it would be better to treat
> them fully symbolically in order to gain results for dimensional
> regularized calculations, which alter the Clifford-identity to the
> following:
>
> \gamma^\mu \gamma^\nu + \gamma^\nu \gamma^\mu = (2-\epsilon) g^{\mu
> \nu}
That's right. There are basically 2 approaches:
1) use some particular representation, and simply multiply all the
matrices and then take a trace
2) do things symbolically using the relations between the matrices
I decided to try 1), as it seemed to me, that it should work fine. But
the resulting matrix is quite a mess, so one would need to figure out
whether there is some good way to simplify the result.
As to 2), I think there the difficulty is in the fact, that one needs
to know which rules to apply and how. If you go this route, I would be
very interested if you manage to get it working.
>
> I seriously think of implementing this functionality.
That would be really great. Whenever you have something, just let us
know on the list and we'll help you with git and patches. Or any other
question you might have.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] A parser for SymPy
On Tue, Aug 9, 2011 at 5:29 PM, Aaron Meurer wrote: > SymPy Gamma and SymPy Live both run on the Google App Engine, which > does all the sandboxing for us. It's a really nice platform, it if > fits your needs. You are limited in what you can put on the server > (no compiled code is allowed, so for example, you can't run numpy). > But if your code is like SymPy and just pure Python, then it's fine. > And it does a very good job of handling things like load balancing for > you (for example, according to Mateusz, SymPy Live has never been > down). > > By the way, SymPy Live is the much more mature project right now. > SymPy Gamma was just a toy project that Ondrej coded up a few years > ago that hasn't really been touched since. The sources are at > https://github.com/sympy/sympy-live/ for Live and > https://github.com/certik/sympy_gamma for Gamma. Yes, in fact, looking at the commits, I started sympy-live a year before sympy-gamma. Neither went down, as far as I know, but sometimes you need to wait a few seconds, before it loads up. GAE allows to pay $9/month, and have 3 reserved instances. I use it for some other project, and that is always responsive. So GAE is a cool platform. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Documentation on Quantum Mechanics
On Mon, Aug 29, 2011 at 6:11 AM, Saptarshi Mandal wrote: > Why not just read the code and put into words what you have > understood? The community can then review your documentation and > provide suggestions/corrections wherever appropriate. That would be great. Any help with the documentation is welcome. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] sympy in sage
On Wed, Sep 14, 2011 at 3:04 PM, David Joyner wrote: > On Wed, Sep 14, 2011 at 5:48 PM, Aaron Meurer wrote: >> What actually needs to be done? > > Well, basically just get a Sage trac account (I think just email > sage-trac-account https://groups.google.com/group/sage-trac-account for that), > click on the trac ticket and click positive review:-) To actually to the > review > correctly, see the appropriate sections of the developer's manual > http://www.sagemath.org/doc/developer/ (for example I like > http://www.sagemath.org/doc/developer/producing_patches.html > to apply patches). > > >> >> On Wed, Sep 14, 2011 at 3:31 PM, David Joyner wrote: >>> Hi all: >>> >>> Just a little reminder: there is a trac item in Sage detailing with >>> the upgrade of >>> Sympy to 0.7.1 (from 0.6.4). I think almost anyone on this email list with >>> sufficient interest could do this review: >>> http://trac.sagemath.org/sage_trac/ticket/11560. >>> It would be great if someone could find the time to do this. >>> I have agree to write a review of a CAS for a December publication, >>> and resolving this ticket would help a lot for examples I could give >>> that mention Sympy. (I am thinking now it would possibly be on Sage >>> but mention Sympy in some examples.) >>> >>> I'd also like to say that, thanks to the improvements to the >>> Sympy 0.7.1 modules for dsolve (mostly due to Aaron Meurer), >>> some DEs are solved by Sympy better than by Maxima - >>> very useful for my day-to-day teaching! >> >> I wrote the initial ODE module, which was first included in 0.6.6, but >> not much has changed since then. But I guess the most recent Sage >> version is 0.6.4. Anyway, I haven't really done much work on it since >> then :) >> >> I did notice at the time, though, that it was more powerful that >> Maxima (or any other open source CAS that I knew of). For example, no >> other open source system (or at least not Maxima) to my memory >> bothered to implement the general nth order case for variation of >> parameters. Also, I don't think things like first order ODEs with >> homogeneous coefficients are implemented in Maxima, if I remember >> correctly. >> >> Anyway, I'm glad to hear that it's been useful to you. >> >> By the way, do you find the hint manager useful for teaching? That > > > Yes, it is. Sadly, it is not in Sage yet though... > > >> was one of the motivations of implementing it, that it would be easy >> to teach, e.g., the Bernoulli method and call dsolve(ode, f(x), >> 'Bernoulli') or dsolve(ode, f(x), 'Bernoulli_Integral'), and it would >> be very instructive, as the output would look exactly like it would if >> you used that method by hand (especially the Integral output). > > > Agreed. And, thanks very much for your hard work on improving > this! David, is this the course that you are teaching from: http://www.usna.edu/Users/math/wdj/teach/sm212/ ? We should put some of the examples into sympy documentation, so far we have this: http://docs.sympy.org/0.7.1/modules/solvers/ode.html but actually doing examples from an ODE course would be cool. For example for the variation of parameters, I remember it was really tedious to do by hand. It'd be cool to add couple more examples, besides what we have here: http://docs.sympy.org/0.7.1/modules/solvers/ode.html#nth-linear-constant-coeff-variation-of-parameters Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] [QSP]: quick sympy poll
On Fri, Sep 16, 2011 at 9:09 AM, smichr wrote: > In https://github.com/sympy/sympy/pull/602 a proposal has been made to > make root(3) default to sqrt(3) with a default n=2 keyword. Should > root be allowed to do this or should one have to write sqrt(3) and > root(3, 2) if they want to get the square root. > > I like the root(3) shorthand. > > Other ideas? Like Aaron, I am not a big fan of the default argument, but I am not against it either, so I am +0. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: sympy.physics.quantum reference/docs/examples
Hi Hans, On Tue, Sep 20, 2011 at 6:27 AM, Hans Harhoff Andersen wrote: > that's ok. I found a way around the problem for now by manually typing > out explicitly what i mean. > whenever the quantum folks take a look at this I'd also like to aks > where the functions density and reduced_density are defined. (They are > mentioned in the paper by Cugini) but I can't find them in the version > of sympy I have 0.7.0 (I just downloaded the git version but I can't > find it there either). Thanks for your interest. The best is to ask Brian about this. I already sent him an email yesterday, so let's wait a few days. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] gaussian optics module
Hi Stefan, On Thu, Sep 22, 2011 at 6:42 PM, Aaron Meurer wrote: > I agree with Chris that you should submit it as a pull request. Absolutely, I would love to have your module in sympy as well. > > One thing that will need to be done before it is merged is that you > should add doctests (examples) to all the docstrings, and also some > regular tests in a test_gaussopt.py file. But you can go ahead and > submit a pull request even before you do this, to start receiving more > feedback on the code. > > Another thing: I'm not sure how imports work in the physics module. > For example, the __init__.py file seems to import only a few things, I think that we just left most of the things in the python files themselves (not importing them in __init__.py), until things settle some more about what things should be imported and how. I think that the best way is to import the most usable things in the respective modules, that is for the wigner module: from sympy.physics.wigner import * or quantum module: from sympy.physics.quantum import * and that sympy.physics itself should not import anything. > and appears to not be up to date. This probably needs to be cleaned > up. One thing that you can do is to define __all__ at the top of the > module so that when someone does "from sympy.physics.gaussopt import > *" it will import all the right things, and none of the internal > variables or classes. I agree with the __all__ statement. Ondrej > > Aaron Meurer > > On Thu, Sep 22, 2011 at 7:34 PM, Chris Smith wrote: >> On Fri, Sep 23, 2011 at 6:09 AM, krastanov.ste...@gmail.com >> wrote: >>> In most (but not all) cases the arguments are directly passed to the >>> constructor of matrices. I suppose that then sympification is not necessary. >>> Am I right? After all I have type(Matrix( (1,) )[0]) == numbers.One. >> >> Yes, you are right. So if the numbers are getting sent to matrix they >> don't need to by sympified. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] papers on sympy?
On Thu, Oct 6, 2011 at 10:10 AM, David Joyner wrote: > On Thu, Oct 6, 2011 at 1:03 PM, william ratcliff > wrote: >> Has the core team thought about making a small publication somewhere for >> sympy? For the academics it might be useful... > > > I'm not in the core team, but I've been asked to write such a paper > on some CAS (eg, sympy) by Communications of the ACM, for the > Dec issue (due in Nov). I was thinking of doing so, if there is no > objection. I would be interested in helping out as well. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
Hi, On Wed, Oct 19, 2011 at 10:56 AM, Aaron Meurer wrote: > Hi. > > Google has invited us to participate in Google Code-In [0], which is a > contest that runs from November 21 to January 16 for pre-university > students aged 13-17. I think we should participate, but only if > enough people are willing to help. This is a lot different from > Google Summer of Code. For this program, we would have to create > several "tasks", which are then completed by the students. The tasks > should be relatively small, independent activities. This can include > things like fixing documentation and writing tests, or just fixing > some issue in the issue tracker. See [1] for more information. > > Since this is a contest to complete the most tasks, we need to have a > high turnaround rate on the review of the tasks. According to [1], > the rate should be no more than 36 hours per task. This means that if > we participate, we will have to have enough people wiling to help > review pull requests so that we can achieve this over the entire > coding period. There is no specific person-to-person mentoring like > with GSoC. Rather, we as a community pass or fail each task. > > Also, we would need to come up with a list of tasks, but this would > not be too hard. We would just create a label in the issue tracker, > and mark any good issues with that label, and also create new issues > for other ideas. > > Finally, I want to remind that these are younger students than were in > GSoC. They will need more hand holding, and the quality of their work > will be much less (and sometimes, it will have to be rejected > outright, but remember that unlike GSoC, this is a contest). > > So would enough people be willing to help out with this? GSoC > students, this is a good chance to take your knowledge of SymPy and > apply it to others. I recommend everyone read through [1] to get a > better idea about this program. If you can or can't contribute, it > would be great if you could let me know soon, as the deadline to apply > is November 1. Especially for the core developers, if you think you > won't have time to help out much, if you could let me know, that would > be great, so I could judge our potential manpower. Aaron, Mateusz and I are now at the Google Mentor Summit, and we all agreed to go for it. We can use our github pull requests for the review, so we just need to finish our review web app (http://reviews.sympy.org/) to run tests automatically for each pull request, and we should be just fine. Would anyone be willing to help out with the reviews? In the application we need to write how many mentors we have available. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
Hi Hector, On Sun, Oct 23, 2011 at 11:39 AM, Hector wrote: > Hi, > > I don't know am I qualified enough or not, but I would like to help in Absolutely you are qualified. Anybody who wants to help is welcomed and since you already contributed to SymPy, you know how things work. > reviewing pull request. I can help with code, documentation, testing for > sure. But I will be engaged between 16th Nov to 10th Dec. Other than that > period, I am more than happy to help. Excellent, thanks! We'll count with you. Ondrej > > - Hector > > 2011/10/23 Ondřej Čertík >> >> Hi, >> >> On Wed, Oct 19, 2011 at 10:56 AM, Aaron Meurer wrote: >> > Hi. >> > >> > Google has invited us to participate in Google Code-In [0], which is a >> > contest that runs from November 21 to January 16 for pre-university >> > students aged 13-17. I think we should participate, but only if >> > enough people are willing to help. This is a lot different from >> > Google Summer of Code. For this program, we would have to create >> > several "tasks", which are then completed by the students. The tasks >> > should be relatively small, independent activities. This can include >> > things like fixing documentation and writing tests, or just fixing >> > some issue in the issue tracker. See [1] for more information. >> > >> > Since this is a contest to complete the most tasks, we need to have a >> > high turnaround rate on the review of the tasks. According to [1], >> > the rate should be no more than 36 hours per task. This means that if >> > we participate, we will have to have enough people wiling to help >> > review pull requests so that we can achieve this over the entire >> > coding period. There is no specific person-to-person mentoring like >> > with GSoC. Rather, we as a community pass or fail each task. >> > >> > Also, we would need to come up with a list of tasks, but this would >> > not be too hard. We would just create a label in the issue tracker, >> > and mark any good issues with that label, and also create new issues >> > for other ideas. >> > >> > Finally, I want to remind that these are younger students than were in >> > GSoC. They will need more hand holding, and the quality of their work >> > will be much less (and sometimes, it will have to be rejected >> > outright, but remember that unlike GSoC, this is a contest). >> > >> > So would enough people be willing to help out with this? GSoC >> > students, this is a good chance to take your knowledge of SymPy and >> > apply it to others. I recommend everyone read through [1] to get a >> > better idea about this program. If you can or can't contribute, it >> > would be great if you could let me know soon, as the deadline to apply >> > is November 1. Especially for the core developers, if you think you >> > won't have time to help out much, if you could let me know, that would >> > be great, so I could judge our potential manpower. >> >> Aaron, Mateusz and I are now at the Google Mentor Summit, and we all >> agreed to go for it. >> >> We can use our github pull requests for the review, so we just need to >> finish our review web app (http://reviews.sympy.org/) to run tests >> automatically for each pull request, and we should be just fine. >> >> Would anyone be willing to help out with the reviews? In the >> application we need to write how many mentors we have available. >> >> Ondrej >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> > > > > -- > -Regards > Hector > Whenever you think you can or you can't, in either way you are right. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Sun, Oct 23, 2011 at 2:10 PM, Joachim Durchholz wrote: > Am 23.10.2011 21:33, schrieb Aaron Meurer: >> >> Another thing: we need to have at least five translation tasks. We >> were thinking to just create tasks for translating tutorials. We need >> to have people who are fluent in the language to evaluate the task. >> Apparently, the task should only be considered as completed if the >> translation is perfect, i.e., from someone who is also fluent, to >> avoid people using machine translations. What languages are people >> fluent in, who are willing to evaluate translations tasks? > > I can review English->German translations. > I did that professionally for a couple of years, so I know what to look for. Thanks. I can do Czech, and Mateusz can do Polish. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Integrating a convex optimization package in Sympy
On Mon, Oct 24, 2011 at 8:07 AM, David Joyner wrote: > On Mon, Oct 24, 2011 at 7:46 AM, Saptarshi Mandal > wrote: >> Hi all, >> I wanted to discuss integrating a convex optimization package called CVXOPT >> into Sympy. It is written in Python and has several algorithms implemented > > > cvxopt is not licensed BSD but GPL3: > http://abel.ee.ucla.edu/cvxopt/copyright.html > > >> to solve various types of optimization problems such semidefinite >> programming, second-order cone programming, nonlinear convex optimization >> and has interfaces to various Fortran libraries. What are your views on the >> matter? Can this go into the roadmap? As David said, it would have to be BSD or MIT licensed. But if you want to use it easily with sympy, you can create a package for it into Qsnake (http://qsnake.com/), then you can use it and build it easily, as well as use it together with SymPy (and it would also be compatible with Sage). What exact change in SymPy would be needed to make it work nicely with it? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Plotting framework
Hi Stefan,
On Wed, Oct 26, 2011 at 12:54 PM, krastanov.ste...@gmail.com
wrote:
> The visual examples are in test.py in the root (the file will be
> deleted/moved if there is ever a version for merging)- it's meant for copy
> pasting or interactive shell, so you can see how it works.
>
> About the differences: The code in newplot is just a *simplified* interface
> to whichever backend you choose (eg matplotlib, textplot, google chart api,
> the current plotting module, etc). Only textplot and matplotlib backends are
> present (and they are fairly simple).
>
> The *only* advantage of using this code instead directly one of the backends
> it's that you have simplified interface for all of the common tasks
> (including for example coloring as a function of parameters). For
> complicated stuff you can directly access the backend.
>
> So instead of typing
>
> x_points = range(N_points)/float(step)
> y_points = [(x**2).eval(subs={x : point}) for point in x_points]
> do_whatever_you_need_to_do_to_use_THE_CHOSEN_BACKEND()
>
> you write
>
> p = Plot(x**2,x,start,end)
> p.backend = THE_CHOSEN_BACKEND.
I would suggest to use:
p = Plot(x**2, (x, start, end))
to be compatible with integrate and other parts in SymPy.
I mentioned this patch to Aaron at the Google Mentor Summit, but
unfortunately we didn't have time to look into it there. It is very
important to improve the plotting support, so many thanks for the
initiative. I'll try to review this soon and provide suggestions.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Wed, Oct 26, 2011 at 1:01 AM, Aaron Meurer wrote: [...] > > Second, once we have at least five of each category, we need to > compile them into a wiki page, so we can put a link to it in our > application. The application is due November 1. Ondrej, Mateusz, and > I already wrote up the responses to the other questions at the summit, > so we just need that. (p.s., Ondrej, should we put that on the wiki > like we did for > https://github.com/sympy/sympy/wiki/GSoC-2010-Organization-Application > ?) Here it is: https://github.com/sympy/sympy/wiki/GCI-2011-Organization-Application Anyone, feel free to edit/improve or send us comments/suggestions. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] papers on sympy?
On Mon, Oct 31, 2011 at 5:37 PM, David Joyner wrote: > On Mon, Oct 31, 2011 at 7:31 PM, Aaron Meurer wrote: >> Comments: >> >> - "as its beautiful logo" should this be "as is its beautiful logo"? > > fixed > >> >> - "However, the most active are..." Maybe rather say "However, the >> most active as of October 2011 are..." to make it clear that this is a >> snapshot into this particular point in time. For example, over the >> summer a different set of developers were most active (i.e., these >> people plus the GSoC students). > > fixed > >> >> - "For example, the following simple Python commands were run from the >> SymPy command line." I would reword this sentence. It sounds like >> SymPy has it's own interpreter, and I think it especially would to a >> user of any other computer algebra system. I'm not sure what the best >> wording is, but make it clear that SymPy just runs inside a normal >> Python interpreter, such as the one that comes with Python or IPython. >> Maybe it would be best to just include a short paragraph about the >> isympy script, which just paraphrases the docstring from that file. > > revised, as suggested > >> >> "Surprisingly, it seems Maxima cannot do this at the present time." If >> I remember correctly, Maxima took the lazy route and only implemented >> second order differential equations (or maybe they can also do higher >> order but only if they are homogeneous, I can't remember). The >> general non-homogeneous case requires either undetermined coefficients >> (if the non-homogeneous term has the correct form), or, in the general >> case, the nth order version of variation of parameters, which is not >> too difficult to implement if you have strong integration routines and >> knowledge of linear algebra (Cramer's rule), but it seems is so rarely >> actually taught that I only found two resources anywhere on the >> internet that dealt with it in the nth case out of the thousands that >> dealt with the 2nd order case, and neither was very good. I discussed >> this on my blog back when I implemented it >> (http://asmeurersympy.wordpress.com/2009/08/01/variation-of-parameters-and-more/). >> In fact, at the time, I couldn't find another open source system that >> implemented this, though I would definitely try to verify this fact >> before putting it in the paper. >> > > I made revisions but I think Axiom has more functionality that Maxima > in this area: > http://www.axiom-developer.org/axiom-website/hyperdoc/equdifferentiallinear.xhtml > > >> "On the >> other hand, perhaps it is not surprising that SymPy is relatively strong in >> the area of differential equations since many or the developers come from >> physics and computational mathematics communities." Actually it's >> mainly because of my GSoC project :) > > > Good point. I changed that. > > New version posted to the usual place:-) Sorry for my late reply. So here I put your sources to github: https://github.com/certik/oscas-sympy then I sent a pull request with my proposed changes: https://github.com/certik/oscas-sympy/pull/1 you can browse there the total diff, or individual patches. If you want my latest tex file, just download it by clicking here: https://raw.github.com/certik/oscas-sympy/changes/oscas-sympy.tex I am posting here my licence quote that is quoted in the article, so that it is public: " Some people say, that GPL had its place in history. Well, maybe it had, maybe not, it's hard to say - let's leave it for historians. But today in 2011, I think that there is no advantage of GPL over BSD. The only thing that matters is to have a solid community, so that lots of people contribute to the project. Also it seems that these days, there are a lot of people who come to open-source, who don't really feel strongly about licensing, they just want their code to be used (no matter how), and thus use BSD. " Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Regarding the work on physics libraries
Hi Amit, On Sat, Oct 29, 2011 at 9:49 PM, Amit Jamadagni wrote: > Sir, > Please provide information on the site to look for the work on > physics. Good start is here: http://docs.sympy.org/dev/modules/physics/index.html but we need to improve our docs and document more physics modules. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Github workflow
On Wed, Nov 2, 2011 at 4:44 PM, Aaron Meurer wrote: >> I'm still confused on two issues: >> 1) How do I update my github fork from upstream? > > A simple "git push github" should do it, assuming you have updated it > locally (you may need to do "git push github master" the first time to > indicate that you want to push the master branch up to your GitHub > fork). > >> 2) How do I tell github to send you a pull request? (Duh. I guess it's >> somewhere on the workflow page. Too tired to look it up, sorry.) > > It is :) > > Go to GitHub and find your branch using the "Current branch" thing on > the right, then click on "Pull request" at the top (there is a screen > shot in the guide, which actually needs to be updated for the new > GitHub interface). See also here: http://help.github.com/send-pull-requests/ Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] sympy grammar
On Sat, Nov 5, 2011 at 3:43 PM, Ricardo Martins de Abreu Silva wrote: > ok, but how I will recognize that a sympy expression is valid? > I would like a grammar for mathematical expression of functions written in > sympy. > I know that if this expression is simple, a parser based on the grammar of > standard python will also recognize it, > because sympy extend the grammar of python. There is a misunderstanding. SymPy does *not* extend the grammar of Python. That is one of the sympy goals actually, to be just a Python library and not extend the Python language. > But it is not true, if my expression uses specific terms in sympy, such that > an integral for example. Integral is just: Integral(x**2, (x, 0, 1)) and that is a valid Python syntax. > So, how i can isolate a grammar just for mathematical expression in sympy, > and consequently in python (because the grammar of sympy extends the grammar > of python in relation to mathematical expressions). SymPy doesn't extend the Python grammar. Maybe you are confused by the fact, that the "Python grammar" is very general, and allows things like the above. Maybe you are looking for some subset of Python. But as Joachim said, it's most probably not worthy. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] how to generate Fortran code
Hi,
I finally needed to generate Fortran code from a SymPy expression. I
couldn't find any documentation for it. Is there any? I found the
FCodeGen object, but
it has no useful docstring So I looked at tests and those are
good. Here is my real life code that I needed today:
from StringIO import StringIO
from sympy.utilities.codegen import FCodeGen, Routine
from sympy import var, legendre, integrate, exp
var("l r12 r1 r2 D")
f = (2*l+1) / (2*r1*r2) * integrate(exp(-r12/D)*legendre(l,
(r1**2-r12**2+r2**2) / (2*r1*r2)), (r12, r1-r2, r1+r2))
routines = []
for _l in range(3):
expr = f.subs(l, _l).doit().simplify()
routines.append(Routine("V%d" % _l, expr))
code_gen = FCodeGen()
output = StringIO()
code_gen.dump_f95(routines, output, "file", False, False)
source = output.getvalue()
print source
This prints:
REAL*8 function V0(D, r1, r2)
implicit none
REAL*8, intent(in) :: D
REAL*8, intent(in) :: r1
REAL*8, intent(in) :: r2
V0 = (-D*exp(-(r1 + r2)/D) + D*exp(-(r1 - r2)/D))/(2*r1*r2)
end function
REAL*8 function V1(D, r1, r2)
implicit none
REAL*8, intent(in) :: D
REAL*8, intent(in) :: r1
REAL*8, intent(in) :: r2
V1 = 3*D*(-D**2*exp(2*r2/D) + D**2 - D*r1*exp(2*r2/D) + D*r1 + D*r2*exp( &
2*r2/D) + D*r2 + r1*r2*exp(2*r2/D) + r1*r2)*exp(-r1/D - r2/D)/(2* &
r1**2*r2**2)
end function
REAL*8 function V2(D, r1, r2)
implicit none
REAL*8, intent(in) :: D
REAL*8, intent(in) :: r1
REAL*8, intent(in) :: r2
V2 = 5*D*(9*D**4*exp(2*r2/D) - 9*D**4 + 9*D**3*r1*exp(2*r2/D) - 9*D**3* &
r1 - 9*D**3*r2*exp(2*r2/D) - 9*D**3*r2 + 3*D**2*r1**2*exp(2*r2/D &
) - 3*D**2*r1**2 - 9*D**2*r1*r2*exp(2*r2/D) - 9*D**2*r1*r2 + 3*D &
**2*r2**2*exp(2*r2/D) - 3*D**2*r2**2 - 3*D*r1**2*r2*exp(2*r2/D) - &
3*D*r1**2*r2 + 3*D*r1*r2**2*exp(2*r2/D) - 3*D*r1*r2**2 + r1**2*r2 &
**2*exp(2*r2/D) - r1**2*r2**2)*exp(-r1/D - r2/D)/(2*r1**3*r2**3)
end function
It looks pretty good. I would like to use "real(dp)" instead of
"REAL*8", as well as probably create the whole module and just put
"implicit none" there just one time. But otherwise it looks good, it
compiles and does the job. Nice!
I just found the documentation here:
http://docs.sympy.org/dev/modules/utilities/codegen.html
So I think I should use the codegen() function. Here is how to use it
to do the same as above:
from sympy.utilities.codegen import codegen
from sympy import var, legendre, integrate, exp
var("l r12 r1 r2 D")
f = (2*l+1) / (2*r1*r2) * integrate(exp(-r12/D)*legendre(l,
(r1**2-r12**2+r2**2) / (2*r1*r2)), (r12, r1-r2, r1+r2))
routines = []
for _l in range(3):
expr = f.subs(l, _l).doit().simplify()
routines.append(("V%d" % _l, expr))
[(f_name, f_code), (interface_name, f_interface)] = codegen(routines,
"F95", "potential", header=False)
print f_code
The f_interface is the f95 interface to the functions above. I don't
use such things in Fortran, I just create a module and then import it
from the module using "use moduly, only: V0". See here for more
details:
https://github.com/qsnake/qsnake/wiki/Fortran-best-practices
But the f_code does what it should. So I think I'll add the
functionality in there, as an optional parameter, to create a regular
Fortran module.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] sympy grammar
On Mon, Nov 7, 2011 at 3:24 PM, Benjamin Gudehus wrote: > Is there a grammar for the sympify-function? Ah, for the sympify() I think the grammar is just like for Python, with our modification in the file sympy/parsing/sympy_parser.py. I think the only modification is 1 -> Integer(1), and then some parsing of numbers. Depending on your application you can most probably ignore everything except the 1 -> Integer(1) thing. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] how to generate Fortran code
On Tue, Nov 8, 2011 at 6:17 AM, Andy Ray Terrel wrote: > Toon put in the basic generator (fcode) and Oyvind worked on doing the > fuller generator but I don't think it was finished. We should > probably have a F95CodeGen and F77CodeGen to separate out the major > differences, but I'm not a Fortran guy so I didn't pay attention to > the minutia when it was built. Exactly, I wasn't a Fortran guy either, but I am now. :) Currently the generated code is a mixture of f77 and f90 (or later), so I think that the f77 solver should simply generate raw functions as it codegen does now for (with the f95 interface as it does now, I think that makes sense). The f90/95 should simply create a Fortran module and that's it. I am still new to Fortran though (started last February), so if there is some experience Fortran programmer around, I'll be happy to learn how to do this properly. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] how to generate Fortran code
On Tue, Nov 8, 2011 at 6:40 AM, Chris Smith wrote:
>>> V2 = 5*D*(9*D**4*exp(2*r2/D) - 9*D**4 + 9*D**3*r1*exp(2*r2/D) - 9*D**3* &
>>> r1 - 9*D**3*r2*exp(2*r2/D) - 9*D**3*r2 + 3*D**2*r1**2*exp(2*r2/D &
>>> ) - 3*D**2*r1**2 - 9*D**2*r1*r2*exp(2*r2/D) - 9*D**2*r1*r2 + 3*D &
>>> **2*r2**2*exp(2*r2/D) - 3*D**2*r2**2 - 3*D*r1**2*r2*exp(2*r2/D) - &
>>> 3*D*r1**2*r2 + 3*D*r1*r2**2*exp(2*r2/D) - 3*D*r1*r2**2 + r1**2*r2 &
>>> **2*exp(2*r2/D) - r1**2*r2**2)*exp(-r1/D - r2/D)/(2*r1**3*r2**3)
>
> It would be much nicer for the reader if textwrap's fill were used for this:
>
import textwrap
text = lambda x: textwrap.TextWrapper(
> ... width=60,
> ... break_long_words=False
> ... ).fill(str(x))
V2 = S('5*D*(9*D**4*exp(2*r2/D) - 9*D**4 + 9*D**3*r1*exp(2*r2/D) -
9*D**3*r1
> - 9*D**3*r2*exp(2*r2/D) - 9*D**3*r2 + 3*D**2*r1**2*exp(2*r2/D) -
> 3*D**2*r1**2 -
> 9*D**2*r1*r2*exp(2*r2/D) - 9*D**2*r1*r2 + 3*D**2*r2**2*exp(2*r2/D) -
> 3*D**2*r2*
> *2 - 3*D*r1**2*r2*exp(2*r2/D) -3*D*r1**2*r2 + 3*D*r1*r2**2*exp(2*r2/D) -
> 3*D*r1*
> r2**2 + r1**2*r2**2*exp(2*r2/D) - r1**2*r2**2)*exp(-r1/D -
> r2/D)/(2*r1**3*r2**3)
> ')
print text(V2)
> 5*D*(9*D**4*exp(2*r2/D) - 9*D**4 + 9*D**3*r1*exp(2*r2/D) -
> 9*D**3*r1 - 9*D**3*r2*exp(2*r2/D) - 9*D**3*r2 +
> 3*D**2*r1**2*exp(2*r2/D) - 3*D**2*r1**2 -
> 9*D**2*r1*r2*exp(2*r2/D) - 9*D**2*r1*r2 +
> 3*D**2*r2**2*exp(2*r2/D) - 3*D**2*r2**2 -
> 3*D*r1**2*r2*exp(2*r2/D) - 3*D*r1**2*r2 +
> 3*D*r1*r2**2*exp(2*r2/D) - 3*D*r1*r2**2 +
> r1**2*r2**2*exp(2*r2/D) - r1**2*r2**2)*exp(-r1/D -
> r2/D)/(2*r1**3*r2**3)
>
> FWIW...
In Fortran, one has to append the line continuation character "&" for
each line above (just like you have to use "\" in Python in most
cases).
This should go into sympy/printing/fcode.py.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] 'diff([cos(t), sin(t), exp(t), t)' does not work on SymPy 0.7.1
On Tue, Nov 8, 2011 at 4:15 PM, Roberto Colistete Jr.
wrote:
> Hi,
>
> On SymPy 0.6.7 the 'diff' function works on lists. But on SymPy
> 0.7.1 it doesn't, for example :
>
> In [1]: diff([cos(t), sin(t), exp(t), t)
> ---
> AttributeError Traceback (most recent call
> last)
> /home/roberto/ in ()
> > 1 diff([cos(t),sin(t),t],t)
>
> /usr/local/lib/python2.6/dist-packages/sympy/core/function.pyc in
> diff(f, *symbols, **kwargs)
> 1104 """
> 1105 kwargs.setdefault('evaluate', True)
> -> 1106 return Derivative(f, *symbols, **kwargs)
> 1107
> 1108 def expand(e, deep=True, modulus=None, power_base=True,
> power_exp=True, \
>
> /usr/local/lib/python2.6/dist-packages/sympy/core/function.pyc in
> __new__(cls, expr, *symbols, **assumptions)
> 672 if evaluate:
> 673 if set(sc[0] for sc in symbol_count
> --> 674 ).difference(expr.free_symbols):
> 675 return S.Zero
> 676
>
> AttributeError: 'list' object has no attribute 'free_symbols'
^^^ I was getting this "no attribute 'free_symbols'" error couple
times when I was trying to integrate something (I think). The error is
not informative and the code should be refactored to produce a
readable error message showing what is wrong and why.
The above error message looks like a bug in sympy.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] 'diff([cos(t), sin(t), exp(t), t)' does not work on SymPy 0.7.1
On Wed, Nov 9, 2011 at 8:35 AM, Aaron Meurer wrote:
> 2011/11/8 Ondřej Čertík :
>> On Tue, Nov 8, 2011 at 4:15 PM, Roberto Colistete Jr.
>> wrote:
>>> Hi,
>>>
>>> On SymPy 0.6.7 the 'diff' function works on lists. But on SymPy
>>> 0.7.1 it doesn't, for example :
>>>
>>> In [1]: diff([cos(t), sin(t), exp(t), t)
>>> ---
>>> AttributeError Traceback (most recent call
>>> last)
>>> /home/roberto/ in ()
>>> > 1 diff([cos(t),sin(t),t],t)
>>>
>>> /usr/local/lib/python2.6/dist-packages/sympy/core/function.pyc in
>>> diff(f, *symbols, **kwargs)
>>> 1104 """
>>> 1105 kwargs.setdefault('evaluate', True)
>>> -> 1106 return Derivative(f, *symbols, **kwargs)
>>> 1107
>>> 1108 def expand(e, deep=True, modulus=None, power_base=True,
>>> power_exp=True, \
>>>
>>> /usr/local/lib/python2.6/dist-packages/sympy/core/function.pyc in
>>> __new__(cls, expr, *symbols, **assumptions)
>>> 672 if evaluate:
>>> 673 if set(sc[0] for sc in symbol_count
>>> --> 674 ).difference(expr.free_symbols):
>>> 675 return S.Zero
>>> 676
>>>
>>> AttributeError: 'list' object has no attribute 'free_symbols'
>>
>>
>> ^^^ I was getting this "no attribute 'free_symbols'" error couple
>> times when I was trying to integrate something (I think). The error is
>> not informative and the code should be refactored to produce a
>> readable error message showing what is wrong and why.
>>
>> The above error message looks like a bug in sympy.
>>
>> Ondrej
>
> If you got this by using regular SymPy input, then it is definitely a
> bug. The problem here was that the input was not SymPy input, so any
> function that assumes that it is would fail (and also, currently
> sympify() does nothing to lists).
The problem was that I was passing some incorrect arguments. So the
user API should say: this argument is incorrect, or can't be converted
to a sympy argument, rather than some "no attribute" error. It took me
couple minutes to figure out that the problem is actually on my side,
that I am passing there some incorrect arguments.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] evalf with subs is oo times slower than without
On Wed, Nov 9, 2011 at 7:46 AM, krastanov.ste...@gmail.com
wrote:
> In [21]: s = summation(k**(-2.1), (k, 1, oo))
> In [23]: %timeit s.evalf()
> 1 loops, best of 3: 196 ms per loop
>
> In [24]: s = summation(k**(-x), (k, 1, oo))
> In [26]: %timeit s.evalf(subs={x : 2.1})
> still calculating
>
> This seems like a bug?
What happens if you do:
s.subs({x: 2.1}).evalf()
?
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] 'diff([cos(t), sin(t), exp(t), t)' does not work on SymPy 0.7.1
On Wed, Nov 9, 2011 at 10:58 AM, Aaron Meurer wrote: > Right. This is of course a lot of work to make all the SymPy > functions do type checking, but if you look at the traceback, it's > actually coming from Function.__new__. So maybe we should just make > sure that the core functions do type checking. > > Or maybe we should add an option to sympify() that raises an exception > if the returned object is not Basic and have the core functions call > that (perhaps _sympify() should do this?). I think it's enough if high level functions like integrate() and diff() do type checking. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Google Plus page for SymPy
Hi, I have created G+ page for sympy: https://plus.google.com/116872266504964122381 I'll be posting there some major updates, like that we were accepted to GCI. If you want to help out, just add it to your circles and I can then allow you to post there. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Wed, Nov 9, 2011 at 12:23 PM, Aaron Meurer wrote: > Hi. > > So Google accepted our application for Google Code-In. This is awesome, I am excited! Time for me to finish the automatic testing of all sympy pull requests. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Re: Feynman Lectures Exercise Challenge
Hi Luke! On Mon, Nov 14, 2011 at 10:40 AM, Luke wrote: > This might be a bit off topic but I think there are enough physicists > on the list who would be interested winning in a free copy of a new > exercise book for the Feynman Lectures on Physics: > > http://feynmanlectures.info/announcement.html > > I worked out the solution, but have been told it is unacceptable > because it involves differential equations. Newton's second law is a > vector differential equation (dp/dt=F, p and F both vectors), so I'm > not clear on how the solution can involve Newtonian mechanics but not > differential equations, as stated in the problem. Maybe somebody here > can figure it out, apparently Feynman did. My solution is here: > > http://dlpeterson.com/FLP_Exercise_Challenge/solution.pdf Haha, very nice! A few points: 1) How did you create the drawing in the pdf? 2) We did this exact example in our undergrad mechanics course at my university using a Lagrangian to derive the equations of motion. I wonder if i can redo it, I would love to put this and similar examples into my notes at theoretical-physics.net. Also with your solution, to show that one can derive the equations of motion in another way. 3) Can pydy derive the equation of motion? 4) Feynman would of course never use your systematic approach, but rather use some trick to find the solution in 2 lines 5) Point 4) is precisely why I don't like Feynman's approach to physics as a way to learn and do physical problems, but I like it as an amusement and to get new physical insight, *after* I have been able to solve the problem using a systematic approach. This is also the motivation behind theoretical-physics.net, to *only* use systematic approach and reject all "tricks". 6) If anyone finds the trick to solve the problem, I would be interested. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Feynman Lectures Exercise Challenge
On Mon, Nov 14, 2011 at 11:00 PM, Luke wrote: > Ondrej, > Great comments! How are you!? We need to get a beer next time you > are coming through -- do you have a regular schedule, maybe Google > Calendar that we can share? Absolutely. I don't go around regularly, but I do from time to time. Last time I left you a message, but you didn't get back to me. :) > >> 1) How did you create the drawing in the pdf? > I used TikZ. I looked into PStricks, which is very powerful, but it > seems like TikZ has a bit nicer design and is a bit higher level. But > other options include Inkscape, which can export pstricks/tikz code to > be included in your latex code. Another cool online tool is: > > http://www.geogebra.org/cms/ > > it will also let you export those formats, but gives you a nice gui > and still lets you easily change the exact values of all the > coordinates, should you want to be precise. Can you post the TikZ source? I like it a lot. > >> 2) We did this exact example in our undergrad mechanics course at my >> university using a Lagrangian to derive the equations of motion. I >> wonder if i can redo it, I would love to put this and similar examples >> into my notes at theoretical-physics.net. Also with your solution, to >> show that one can derive the equations of motion in another way. > > Yeah, Lagrange's is the way to go, I didn't do that approach for the > solution because I figured F=ma would be the "simplest" and least > likely to raise flags about "fancy math" being used. But when F = > dp/dt = ma is not allowed I'm not really sure what technique to > use Yeah. > >> 3) Can pydy derive the equation of motion? > > Definitely, although it is almost overkill :) If you have time, can you create an example for pydy for it? I think it's simple, but not *so* simple, and it would serve as a nice example for pydy. > >> 4) Feynman would of course never use your systematic approach, but >> rather use some trick to find the solution in 2 lines > > One of the perks of being Feynman, I suppose :) > >> 5) Point 4) is precisely why I don't like Feynman's approach to >> physics as a way to learn and do physical problems, but I like it as >> an amusement and to get new physical insight, *after* I have been >> able to solve the problem using a systematic approach. This is also >> the motivation behind theoretical-physics.net, to *only* use >> systematic approach and reject all "tricks". > > Yeah, whenever I hear the word "trick", I get a little uneasy. Cass > said she might remember having seen a "trick" for this problem, but > couldn't find it or remember it. I don't want to memorize a bunch of > "tricks", I want to know a few key principles and concepts and be able > to apply them to lots of different problems. I agree though, after > you understand something, it is nice to see the shortcut. Exactly. > >> 6) If anyone finds the trick to solve the problem, I would be interested. > > I'll let you know. I sent it out to a bunch of physicists and > engineers here at UCD and haven't heard any ideas from any of them. Awesome. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Example plots from the new code
Hi Stefan, On Fri, Nov 11, 2011 at 6:46 AM, krastanov.ste...@gmail.com wrote: > The proposal that I made in https://github.com/sympy/sympy/pull/673 may or > may not became part of sympy but I like it and it's already quite useful for > me. > > Here are some examples. I would like to know what do you think. The 3d stuff > runs only on the latest version of matplotlib _after_ fixing a bug > (mentioned in the commit history, but those will be squashed soon). > > The script to produce them is also attached (as the api is probably more > important than the visuals (the _series[index] stuff is just a workaround > until getters are written)). I like this a lot, and I would suggest to get this into sympy as a new module, after fixing things that Aaron has pointed out. That way, people can start using it and improving it by sending pull requests to sympy. I am +1 to the plot() function, that calls either the new or old Plot() to do plotting. Or just use Plot and put it into a new module, and eventually (later) simply switch the default sympy.Plot from old to new. Either is fine with me. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Latex -> Sympy
On Sun, Nov 13, 2011 at 3:25 AM, Vincent MAILLE wrote:
> OK, thanks for your answers. It's true that LaTeX is complexe to
> parse. My question was juste for very simple expressions :
>
> \frac{..}{..} => (...)/(...)
> 2x+x^2 => 2*x+x**2
I think it's definitely doable, and someone just has to do it for
simple expressions and then (if there is interest) it can be improved
for more complex ones. It will never be able to parse 100% of all
latex, but I can imagine it to work just fine for normal math that
people use.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Feynman Lectures Exercise Challenge
On Wed, Nov 16, 2011 at 1:04 AM, Luke wrote: >> I thought the general idea of the problem was to not use differential >> equations and calculus? (or "other fancy mathematical tricks"). I feel like >> that is the challenge of the problem... > > Yes. I just don't know how to separate Newtonian mechanics from > differential equations so I didn't. My solution won't be > considered for that reason. > > I've been discussing this with some other physicists and our > fundamental stumbling block is that the problem defines the pendulum > via it's natural period. The natural period of a pendulum depends on > the amplitude of oscillation, unlike something more intrinsic, like > the length. So without specifying an amplitude associated with the > period, this way of characterizing a pendulum is somewhat ambiguous. > The relationship between period and length that is familiar, namely T > = 2*pi*sqrt(l/g), I can only obtain from a differential equation. But Ah, if this is the only problem, then I know a tricky derivation. It's super simple: 1) assume, that the period depends on the length "l" and "g" in the following form: T = a * l^b * g^c where a, b, c are constants, possibly zero. We can try to figure out some physical basis for it, I would just say for now, that this is the first order approximation. Why not. >From dimensional analysis: [T] = s [l] = m [g] = m s^-2 we get: s = a * m^b * m^c s^(-2c) so: b + c = 0 1 = -2*c and finally: c = -1/2 b = 1/2 in other words: T = a * sqrt(l/g) it doesn't give you the constant "a", but it gives you the dependence on "l" and "g". > perhaps that relationship is derivable without appealing to > differential equations. In any event, there must be some way to > relate period to length, and if it isn't this relationship, I don't > know what it is or how to rationalize it. Given the above, how would you solve the problem? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Feynman Lectures Exercise Challenge
On Wed, Nov 16, 2011 at 10:18 AM, Aaron Meurer wrote: > On Wed, Nov 16, 2011 at 11:12 AM, Luke wrote: >> Do you mean in my solution that involves differential equations? > > Yes (assumedly the solution will be the same no matter what method you > use to derive it, so long as you always make the "small angles" > approximation). > >> >> I think this dimensional analysis approach may have merit, I just need >> to see all the steps and make sure they can all be justified without >> referencing a differential equation. >> >> ~Luke > > Perhaps this would be easier to see (at least for someone like me who > doesn't remember this particular part of physics very well) if you > added explicit dimensions to all the numbers in your derivation. It's > hard to tell which "1's" are really unit-ed. > > And by the way, I'm still convinced that the "trick" involves deriving > it geometrically somehow, although in my experience, dimensional > analysis is a favorite among the types who like to use little tricks > to derive things. Anyway, thanks Luke for bringing this in! I am positive we can nail this out, or somebody will eventually. In fact, I consider the whole high school physics full of such "tricks". That's why I hated physics back then. Now after lots of years when I can see that one can actually derive everything very systematically using an engineering approach, I actually love physics. So I consider myself more of an engineer than a physicist. But I must say, that after I understand the problem from a systematic engineering perspective, I greatly enjoy these "physical", tricky arguments. In fact, I have great fun deriving all the "tricky" formulas (like currents/forces between wires...) in electromagnetism from a simple classical relativistic formulation, more here: http://theoretical-physics.net/dev/src/elmag/elmag.html the initial section is still a little complex, but I will simplify it over time as I understand things more. Once I understand this example well, I'll put it into this section: http://theoretical-physics.net/dev/src/relativity/classical.html I just started this classical mechanics section about two weeks ago, so it's still very crude. I need to figure out how to derive the basic equations needed there from general relativity: http://theoretical-physics.net/dev/src/relativity/relativity.html But it will take some time. I know how to derive the Newton's law from Einstein equations as well as the gravitational law, but I don't see currently how to connect the Lagrangian formulation with general relativistic Lagrangian formulation. Also how to derive rigid body equations, because one cannot have a rigid body in special relativity, so classical mechanics is a hard subject. But for electromagnetism I think I already understand pretty well how all things follow from the simple relativistic formulation. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Algorithm used to calculate approximation of exp, log, ...
On Tue, Nov 15, 2011 at 10:32 AM, Mateusz Paprocki wrote: > Hi, > > On 15 November 2011 10:28, Christophe BAL wrote: >> >> Hello, >> what are the algorithms used to calculate approximation of exp ? > > I suggest asking this question on mpmath's mailing list. I think it's here: https://github.com/sympy/sympy/blob/master/sympy/mpmath/libmp/libelefun.py#L1151 but it might be some other algorithm depending on the backend. Better ask on the mpmath list. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Translation tasks
On Mon, Nov 21, 2011 at 12:39 PM, Aaron Meurer wrote: > On Mon, Nov 21, 2011 at 1:10 PM, Joachim Durchholz wrote: >> Am 21.11.2011 20:27, schrieb Aaron Meurer: >>> >>> For now, let's just gather the translated documents, until we figure >>> out the best way to deliver them (e.g., do not consider delivery as >>> part of completion for these tasks, only translation). So, for >>> example, if they have a good translation in a fork on GitHub, or even >>> just upload it to the task, that will be sufficient for now. >> >> For now, I think git will be fine. >> >> We should have a terminology repository though. A text file on github would >> do just fine. >> The overall structure that worked well in the times when I worked as a >> professional translator was an entry per term: >> >> A terminology file could look like this: >> >> --- snip --- >> EN: table >> DE: Tabelle >> FR: tableau >> >> EN: (mouse) cursor >> Def: A marker for the mouse position (usually an arrow). >> DE: Mauszeiger >> FR: curseur >> IT: cursore >> >> EN: (text) cursor >> EN: caret >> Def: The vertical blinking bar for text input. >> DE: Schreibmarke >> >> EN: (database) cursor >> Def: A marker for the next row in a database result set >> DE: Cursor >> >> --- snip --- >> >> General structure of each entry is: >> >> EN: >> EN: >> ... >> EN: >> Def: >> XX: >> YY: >> YY_aa: >> >> I have worked with this and similar text files during my years as a >> professional translator, and it has served me well. > > What is the purpose of this file? Where would it go? The purpose of this file is to unify terminology for the given language. So in my case Czech, there are usually multiple ways to translate the given English technical term (that we use in sympy). Having a unified terminology (the file above), then the translation will be consistent if different people translate different parts of the document. Also, at least in Czech, many times there simply doesn't exist an "official" name for some technical terms, that were invented only in English. In our case, things like "assumptions system", name of classes like Rational (we should not rename any classes, but there needs to be a translation so that users who don't speak English understand why the class is named the way it is). "Pretty printing" is another example (currently I have no idea how to translate this to Czech so that it sounds good). And so on, there will be many such cases. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Should we support Python 3.1?
On Mon, Nov 21, 2011 at 12:21 AM, Aaron Meurer wrote: > Hi. > > We don't have to support 3.1 for this release, if no one gets to > fixing all the bugs. But we can support it later if we do. I agree. I think it is perfectly ok to stick with 3.2 and make sure things work robustly there. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Translation tasks
On Mon, Nov 21, 2011 at 8:52 PM, Aaron Meurer wrote: > So where would the document go? I'm assuming that this is some kind > of standard format. Ah, I don't know, I never translated anything professionally. I would put it as a wiki document at github for now I guess. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Translation tasks
On Tue, Nov 22, 2011 at 4:47 PM, Aaron Meurer wrote: > I see. I originally thought that this document was some standard > thing that machine translation software used for various things. I > wonder actually if there is such a standard thing. > > Well, feel free to create it. As I know exactly one language, I won't > be able to help much with it :) One more related thing. I have just updated all the translation issues with a statement: "The translation cannot use any automated tools. It needs to be human translation." At the Google Mentor Summit we were specifically told, that it needs to be a human translation and that students will try to use automated services for it, so that's why a native speaker needs to check this. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Translation tasks
On Tue, Nov 22, 2011 at 11:37 PM, Aaron Meurer wrote: > On Wed, Nov 23, 2011 at 12:12 AM, Joachim Durchholz > wrote: >> Am 23.11.2011 08:01, schrieb Ondřej Čertík: >>> >>> On Tue, Nov 22, 2011 at 4:47 PM, Aaron Meurer wrote: >>> At the Google Mentor Summit we were specifically told, that it needs >>> to be a human translation and that students will try to use automated >>> services for it, so that's why a native speaker needs to check this. >> >> Ah, right, I recall that part. >> >> Professional translators use automated tools and rework the translation >> afterwards. That means the tool does 80% of the work and the translator does >> the other 80% - spotting mistranslations and cleaning up the style is >> essentially a full rewrite after all. >> So I would ask people to start with Google Translate or whatever suits them, >> then read both the original and the automatted translation, and then rewrite >> the page *in their own words", as if they were writing the page from scratch >> in the target language. >> >> Not sure whether that will cause problems with the Google folks though. I >> don't know how pushy they are around their rules. >> >> Regards, >> Jo >> > > Remember two things. First, this is a contest, with a big reward for > the person who completes the most tasks, and also money for everyone > who completes tasks (I think it's $100 for each three tasks, up to > $500). Second, remember that these are mid- to high-school students. > Many of them will see a translation task and think that it will be > easy points, because they can just run it through Google translate, > and it will be "good enough". This is why the translation has to be > "perfect" to be accepted. This is a little different from the code > tasks, where we can let some small insignificant things like code > quality slip through, with the understanding that they are new to > coding. > > As to how they do this, I would leave it up to them to figure out. If > they can run it through Google translate as an initial step, and still > make the translation very good, then that's fine. But I don't think > it's a good idea to suggest it. At least for Czech, I would *not* recommend to use google translate at all, because it gives a bad structure of the sentences, and its very hard to make it right. And rather than having a bad translation I think it's better to have no translation, because everybody can simply put it to google translate to get the idea what the page says, but the official translation (in my opinion) should be a good one, so that people can read it and don't get driven away by mistakes in it, or bad style. > > Frankly, I wouldn't have any translation tasks if Google didn't > require it (though that's partly just because this is the one kind of > task that's impossible for me to review :-). I was surprised too at first, it didn't occur to me that we could/should translate anything in sympy, but now I must say that actually I like it. I think it's a great idea to translate some parts, like the tutorial. It allows to get involved with people who would otherwise not get involved, and also to target people that otherwise would not be targeted. I think there are a lot of people who really prefer to read things in Czech (let's say in my case) rather than English. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Translation tasks
On Wed, Nov 23, 2011 at 1:37 PM, Joachim Durchholz wrote:
> Am 23.11.2011 20:08, schrieb Aaron Meurer:
>>
>> I see what you mean. To degree do you think people who do not speak
>> English at all will use it if only the tutorial is translated (i.e.,
>> the rest of the documentation is not)? We would have to have tons of
>> volunteers to translate *everything* and keep it translated,
>
> GNU gettext helps with that.
> Typical gettext tools will be able to cross-reference old with new English
> texts and present you with the best matching translation for the old text,
> allowing you to keep or adapt it.
>
>> and even
>>
>> then, names in the code are in English, and Python is in English.
>
> Function names cannot be translated, nor can keywords.
> However, docstrings and message texts can, and it's useful. ("Sine" and
> "cosine" are Latin words, and you learned them when you learned math...
> people expect to learn new words for mathematical functions. As long as the
> can read the text that explains what they are.)
>
> That said, translating Sympy would still be a lot of work, and it would add
> a maintenance burden.
>
> On the plus side, if the English messages go out of sync with the
> translation, gettext will simply fall back to English where it does not find
> a translated string.
I myself have always prefer to read and later also write everything
(code+documentation) in English as then I don't need to maintain any
translations and it works for everyone.
But I think there is a high value in having things translated. The
target audience is not me. But I remember when I was about 13 or 12, I
was able to read manuals, mostly, but it was hard. And having things
in Czech would help a lot, or help me realize that there is a Czech
community around the software and I am not stuck with foreign people
in a foreign language. I view it as an outreach.
Given our manpower, I would definitely not translate docstrings and
code, nor even any documentation. But a tutorial, I think that's a
good idea. Web pages, probably as well. We'll see how it goes, and if
we can reasonably manage it.
Jo, would would be a good mechanism to keep the English and translated
tutorials in sync? Should we add a hash into the translated tutorial,
so that we know which exact version was translated? Obviously we will
be updating things in the English part, and then we can just run git
diff (even post a link at github to do it for us) at each translated
page, so that the user can easily check, if it is in sync, or out of
sync and what exact changes are not translated. I think that will work
great.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] need suggestions to the new concept of using SymPy
Hi Think Tanks, On Wed, Nov 23, 2011 at 8:04 PM, The Think Tanks wrote: > Dear All, > We have created one of a kind software for doing mathematics and > programming on touch devices (tablets and smart phones). We Python > language as our core and use SymPy for symbolic computation. Currently > we have implemented the concept in Android platform and we aim at > extending to other platforms in near future. > > You can find the details of the software and the concept from the link > below: > http://www.touchthinktanks.com/scriptblocks/ > > We will be very happy if you can give your views about the concept and > application of the same to SymPy. It looks very interesting. I would be curious to test it out on my android to see how it works. > > If you have an android device, you will be able to use the beta > version of the software free of cost. We are in testing stage, and > there might be some bugs that need to be fixed. I have a little bad connection for couple days, so I'll try it later. I found two applications called ScriptBlocks, one called "essentials" for free and then one "unleashed" for $114. Which one should we install to test it out (I don't want to pay $114 for testing it)? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Mon, Nov 21, 2011 at 10:20 PM, Aaron Meurer wrote: > Don't forget to add the students to the AUTHORS/aboutus when you push > in their code (and also try to keep the aboutus up-to-date when they > submit new stuff, but actually we should be doing that for everybody). > Keep people in the AUTHORS file in the order of contribution. > > Note that there was some talk of the legality of asking the students > for real names, since they are <18 years old. I will try to find out > more about this. Until then, just use the metadata in the commit, or > whatever else you can infer from usernames, etc. I have a few questions: 1) is there some GCI list for mentors? (to ask questions like the above) 2) Is there any way to setup a list to receive all updates from the melange comments? I just spent 20 minutes subscribing to each task, so I am good, but maybe other mentors would like to get updates as well. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] testing instances for sympy-live
Hi, On Fri, Nov 25, 2011 at 4:25 PM, Mateusz Paprocki wrote: > Hi, > > On 25 November 2011 15:08, krastanov.ste...@gmail.com > wrote: >> >> Hi, >> >> You can test the new stuff done for sympy-live (the new design and the new >> mobile interface) on sympy-live-testing-2.appspot.com. >> >> Aaron mentioned quite correctly a number of deficiencies in the new >> sympy-live design. But at that time I have already marked the task as >> closed. He has expressed his concerns on the task discussion page and >> hopefully the student will find the time to address those. I apologizes for >> my failure to notice those. >> > > Just to let you know, this doesn't work very well on small screens (e.g. > 10''). There are overflows and right column is displaced (possibly wrong > floating styles). See the screenshots that I took in this pull request: https://github.com/sympy/sympy-live/pull/13 Stefan --- if you close a task, does it ask you to "really close the task" and then if you agree, it's done forever? I just want to make sure how dangerous is to click on the "close task" button. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Sat, Nov 26, 2011 at 3:54 PM, Aaron Meurer wrote: > 2011/11/26 Ondřej Čertík : >> On Mon, Nov 21, 2011 at 10:20 PM, Aaron Meurer wrote: >>> Don't forget to add the students to the AUTHORS/aboutus when you push >>> in their code (and also try to keep the aboutus up-to-date when they >>> submit new stuff, but actually we should be doing that for everybody). >>> Keep people in the AUTHORS file in the order of contribution. >>> >>> Note that there was some talk of the legality of asking the students >>> for real names, since they are <18 years old. I will try to find out >>> more about this. Until then, just use the metadata in the commit, or >>> whatever else you can infer from usernames, etc. >> >> I have a few questions: >> >> 1) is there some GCI list for mentors? (to ask questions like the above) > > Not as far as I know. They should set one up. > >> >> 2) Is there any way to setup a list to receive all updates from the >> melange comments? I just spent 20 minutes subscribing to each task, so >> I am good, but maybe other mentors would like to get updates as well. > > I guess you could do it manually, but filtering your email and > forwarding it to the list. Ah, that's right. If anyone wants me to do so, let me know. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] testing instances for sympy-live
2011/11/26 Ondřej Čertík : > Hi, > > On Fri, Nov 25, 2011 at 4:25 PM, Mateusz Paprocki wrote: >> Hi, >> >> On 25 November 2011 15:08, krastanov.ste...@gmail.com >> wrote: >>> >>> Hi, >>> >>> You can test the new stuff done for sympy-live (the new design and the new >>> mobile interface) on sympy-live-testing-2.appspot.com. >>> >>> Aaron mentioned quite correctly a number of deficiencies in the new >>> sympy-live design. But at that time I have already marked the task as >>> closed. He has expressed his concerns on the task discussion page and >>> hopefully the student will find the time to address those. I apologizes for >>> my failure to notice those. >>> >> >> Just to let you know, this doesn't work very well on small screens (e.g. >> 10''). There are overflows and right column is displaced (possibly wrong >> floating styles). > > See the screenshots that I took in this pull request: > > https://github.com/sympy/sympy-live/pull/13 > > > Stefan --- if you close a task, does it ask you to "really close the > task" and then if you agree, it's done forever? I just want to make > sure how dangerous is to click on the "close task" button. I closed one task that was finished and the answer is: By clicking on the "close task", it will immediately get closed and there is no way to reopen it (as far as I know), so we need to be careful with that. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] testing instances for sympy-live
On Sat, Nov 26, 2011 at 7:08 PM, Chris Smith wrote: > The Other Online Shells dropdown (in Chrome) doesn't drop down far > enough and the bottom of the letters are clipped; it only drops as far > as the bottom of the bullet. I think it was fixed. Can you try the version at: http://live.sympy.org/ I just tested it in Chrome and it seems to work. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Sat, Nov 26, 2011 at 8:46 PM, Aaron Meurer wrote: > If someone is free tomorrow, can you go through and create tasks for > the Code-In issues in the tracker that do not have the > CodeInImportedIntoMelange label? They extended the deadline to create > new tasks for this round to Monday, so I think if you create them > tomorrow, they will be available for the students now (otherwise, they > will not be available until December 16). I am not sure I understand. Should we find issues in the sympy tracker that we think are good for GCI and mark them with CodeInImportedIntoMelange and create the corresponding task in melange? Or are you asking about something else? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
On Sun, Nov 27, 2011 at 9:49 AM, Aaron Meurer wrote:
> No, there are issues that are already marked for Code-In. The ones
> that don't have the CodeInImportedIntoMelange label need to be
> imported into Melange. Here's a list of all of them:
> http://code.google.com/p/sympy/issues/list?q=label%3ACodeInCategory+-label%3ACodeInImportedIntoMelange.
> The ones with the CodeInMultiple label should be made into multiple
> tasks, either by splitting the issue or duplicating it (depending on
> the issue).
>
> Of course, you can create/mark more issue for CodeIn too, if you want.
> We will need to do that anyway before the 16th so that we have a
> strong set of issues for the second round.
>
> The main thing here is that we can still get them into the first
> round, if we do it by Monday.
Ok, I'll see what I can do. The best way to import them to melange is
to use the csv import? That is, from the documentation:
For bulk uploading tasks please use your favorite spreadsheet editor
that can export data in CSV format. Structure your columns in the
following order.
* Title of the task.
* Description, for markup use HTML.
* Time to complete in hours, as integer.
* Link ID's of mentors for this task, comma separated.
* Difficulty, one of the allowed difficulties (Easy, Medium, Hard, Unknown).
* Task types, one or more of the allowed types (Code, Documentation,
Outreach, User Interface, Research, Training, Translation, Quality
Assurance), comma separated.
* Task tags, any custom tags you want to add, comma separated.
The field separator is the comma character.
If your field contains commas, use double quotes ("field with a ,
comma") to quote the field content.
If your field contains double quotes, escape as two double quotes
("field with "" double quotes").
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Code-In
2011/11/27 Ondřej Čertík :
> On Sun, Nov 27, 2011 at 9:49 AM, Aaron Meurer wrote:
>> No, there are issues that are already marked for Code-In. The ones
>> that don't have the CodeInImportedIntoMelange label need to be
>> imported into Melange. Here's a list of all of them:
>> http://code.google.com/p/sympy/issues/list?q=label%3ACodeInCategory+-label%3ACodeInImportedIntoMelange.
>> The ones with the CodeInMultiple label should be made into multiple
>> tasks, either by splitting the issue or duplicating it (depending on
>> the issue).
>>
>> Of course, you can create/mark more issue for CodeIn too, if you want.
>> We will need to do that anyway before the 16th so that we have a
>> strong set of issues for the second round.
>>
>> The main thing here is that we can still get them into the first
>> round, if we do it by Monday.
>
> Ok, I'll see what I can do. The best way to import them to melange is
> to use the csv import? That is, from the documentation:
>
> For bulk uploading tasks please use your favorite spreadsheet editor
> that can export data in CSV format. Structure your columns in the
> following order.
>
> * Title of the task.
> * Description, for markup use HTML.
> * Time to complete in hours, as integer.
> * Link ID's of mentors for this task, comma separated.
> * Difficulty, one of the allowed difficulties (Easy, Medium, Hard, Unknown).
> * Task types, one or more of the allowed types (Code, Documentation,
> Outreach, User Interface, Research, Training, Translation, Quality
> Assurance), comma separated.
> * Task tags, any custom tags you want to add, comma separated.
>
> The field separator is the comma character.
> If your field contains commas, use double quotes ("field with a ,
> comma") to quote the field content.
> If your field contains double quotes, escape as two double quotes
> ("field with "" double quotes").
Ah, so I guess that the best way is to fill this in in some online
docs and then export into csv and import into melange?
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] testing instances for sympy-live
On Sun, Nov 27, 2011 at 10:01 AM, Aaron Meurer wrote: > This is not so easy to fix, because even if you set the printer width, > it will mess up expressions that have already been printed. I think a > better solution would be to set the printer width to none and do the > multiline wrapping manually in the webapp, so that it can adjust for > all printed expressions in real time as it is resized. I created > http://code.google.com/p/sympy/issues/detail?id=2874 for this. Yeah, it's not so easy. I think this could be a new GCI task. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] framework for translating our webpage
Hi, I have spent several hours and did research how to translate and maintain our webpages. Let's use the .po and .pot files (the unix gettext utility, together with Python's gettext, Babel package and a support for it in Jinja2). I have described it in the pull request: https://github.com/sympy/sympy.github.com/pull/33 It has been a lot of work to prepare this and figure out how to make jinja2 work and finally to make *all* strings in the templates translatable. However, this is now done and it's running at sympy.org. Read the pull request for more technical details. As an example, here is the .po file for the Czech translation: https://github.com/sympy/sympy.github.com/blob/master/i18n/cs.po I have manually copied the translation from the pull request: https://github.com/sympy/sympy.github.com/pull/30, and that's quite time consuming. If you all agree, let's ask students to submit the .po file directly, by adapting the template here: https://github.com/sympy/sympy.github.com/blob/master/i18n/sympy.org.pot This framework also fixes the issue of synchronization. When making any change in the English pages, three cases can occur: 1) the change doesn't touch any translatable string. Then the change will happen in all translated pages without any effort. 2) the change changes some translatable string, but it happen to use some other string, that is already translated in the .po file. Then the translation will automatically work without any effort. 3) the change changes some translatable string into a new string for which the translation is not available yet. Then the .po file has to be regenerated by merging with the new template (by using the msgmerge utility in linux), and by default it will have no translation for the new string. As such, an English translation will be used instead until the string is translated in the po file. As you can see, only the case 3) causes problems, and even then things will be synchronized, just not completely 100% translated. And we can use standard tools that handle the .po and .pot files to manage translations. As far as the tutorial goes, something similar should probably be done, but I don't have time for it, so I suggest to simply have the tutorial in several languages as an html file, but for the webpages, that we need to modify quite often, I think it is very important to use some framework like above, so that we can make sure that it is updated in all languages. So I think that this framework fixes all the problems, and let me know what you think of it and if you agree, let's use it and improve upon it. Most importantly, create new GCI tasks (?) to convert the already done translation pull requests into a .po file, and convert all tasks that weren't yet done to simply submit a .po file. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Re: framework for translating our webpage
> As an example, here is the .po file for the Czech translation: > > https://github.com/sympy/sympy.github.com/blob/master/i18n/cs.po > > I have manually copied the translation from the pull request: > https://github.com/sympy/sympy.github.com/pull/30, and that's quite > time consuming. I forgot to mention that I only copied a few parts, as I don't have time to copy the rest. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Sun, Nov 27, 2011 at 1:10 PM, Vladimir Perić wrote: > Yeah. I always thought .po files would be the way to go, though I > still created a "Research" task for GCI to see if something better > could be found. I didn't look at the exact changes you made, but I > guess any problems will get noticed sooner rather than later. We > should probably do the same for the tutorial (in the long run, I > wouldn't mess around with it for GCI), if we do agree that we want to > keep translating documentation (though, again, I don't really see the > value in that). I would keep the tutorial as a regular page, to keep things simple on everybody. But for the webpages, we need something more robust, so that we can change things easily. Unfortunately, I noticed, that the Czech, German, Polish and Bulgarian translations are already done (https://github.com/sympy/sympy.github.com/pulls), so we'll have to create new issues/tasks to convert the pull request into a .po file. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
Hi Vladimir, On Sun, Nov 27, 2011 at 1:31 PM, Vladimir Perić wrote: > 2011/11/27 Ondřej Čertík : >> On Sun, Nov 27, 2011 at 1:10 PM, Vladimir Perić >> wrote: >>> Yeah. I always thought .po files would be the way to go, though I >>> still created a "Research" task for GCI to see if something better >>> could be found. I didn't look at the exact changes you made, but I >>> guess any problems will get noticed sooner rather than later. We >>> should probably do the same for the tutorial (in the long run, I >>> wouldn't mess around with it for GCI), if we do agree that we want to >>> keep translating documentation (though, again, I don't really see the >>> value in that). >> >> I would keep the tutorial as a regular page, to keep things simple on >> everybody. > > So what happens when we update the tutorial? Or notice a mistake > somewhere and correct it? How will we know if (and what parts) are out > of date. I dunno, like I said, I still think the whole thing is too > much hassle for too little gain. Still... :) Those are valid questions, however, I think that the right question to ask is the following: * given that we already have translations of the tutorial and given our manpower, what is the best way for us to use it? And my own answer is (given how often we will update the tutorial): * Just add a hash of the English original into each tutorial and add it into our documentation. Then if we improve the English tutorial, the translations will be out of date, but they will have a hash/link for more up-to-date English translation. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
>> guess any problems will get noticed sooner rather than later. We >> should probably do the same for the tutorial (in the long run, I >> wouldn't mess around with it for GCI), > > I agree with that. > We can put the translations into the gettext infrastructure after the fact. I have updated tasks that are not done yet with a specific requirement to submit the .po files. I am now trying to convert the Czech translation to a .po file and it is a lot of work, so I think it's much better if the translation itself is in a .po file. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Sun, Nov 27, 2011 at 2:04 PM, Joachim Durchholz wrote:
> Am 27.11.2011 22:50, schrieb Ondřej Čertík:
>>
>> I am now trying to convert the Czech translation to a .po file and it
>> is a lot of work, so I think it's much better if the translation
>> itself is in a .po file.
>
> Hmm... the gettext toolchain is prepared to write your own text extractors.
> (Those for C source code look for _("..."), for example.)
>
> If there's a gettext extractor for the markup used in the tutorial, it
> should be able to automatically extract a skeleton from the English
> originals.
> I think an extractor is the first thing you need to reasonably work with
> gettext. Creating .po files manually is possible, but you'd have to keep
> them in sync with the markup text manually, which makes the whole effort of
> using gettext pointless.
This is already done, see my pull request. We have the English
template (see my pull request), but
we need to fill it in, manually, using the Czech translation, that was
done in the html files directly.
Anyway, I have now finished this as well, it took me about 1h of work.
Here is the result:
http://sympy.org/cs/index.html
>
> BTW you do not need a hash. The gettext tools will simply check whether .po
> and source are in sync.
The tutorials do not use gettext, so we need a hash (I think).
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Sun, Nov 27, 2011 at 2:17 PM, Vladimir Perić wrote:
> On Sun, Nov 27, 2011 at 11:04 PM, Joachim Durchholz
> wrote:
>> Am 27.11.2011 22:50, schrieb Ondřej Čertík:
>>>
>>> I am now trying to convert the Czech translation to a .po file and it
>>> is a lot of work, so I think it's much better if the translation
>>> itself is in a .po file.
>>
>> Hmm... the gettext toolchain is prepared to write your own text extractors.
>> (Those for C source code look for _("..."), for example.)
>
> The Python one works the same, I know GRAMPS uses it (but I've no
> experience with it exactly, I've just translated some things).
It was tricky to get this working with jinja, as the documentation is
scarce. It took me about 4h of work in the morning, but it's done (see
my pull request).
>
>>
>> If there's a gettext extractor for the markup used in the tutorial, it
>> should be able to automatically extract a skeleton from the English
>> originals.
>> I think an extractor is the first thing you need to reasonably work with
>> gettext. Creating .po files manually is possible, but you'd have to keep
>> them in sync with the markup text manually, which makes the whole effort of
>> using gettext pointless.
>>
>> BTW you do not need a hash. The gettext tools will simply check whether .po
>> and source are in sync.
>
> Yeah, if we do decide to do anything with these, I'm absolutely
> positive we should go for gettext integration as it's a very robust
> system and there's really no reason not to. For the moment, though, I
> of course agree with Ondřej - as long as we have the texts we should
> definitely use them. Lets just add a date-stamp to each file and be
> done with "versioning" them.
+1
>
> Still, I'd like to make a case again for *not* doing any translating:
> SymPy is, at it's core, a program that's aimed at academia and people
> with at least some sort of math background. Most of these will have
> good knowledge of English, both mathematicians and physics and
> engineers. Yes, I know how much Czech (French, whoever) people like
> their language, but the fact is that English is the language of
> programming, hence also the language of Python and therefore the
> language of SymPy. Whatever we do our methods are always going to be
> called "solve", "transpose" or whatever, and they'll never use
> translated names. Therefore SymPy will never be usable by someone who
> has no knowledge of English and trying to keep translated
> documentation is going to be tedious at best and plain pointless at
> worst.
>
> On the other hand, I of course recognize the importance of
> translation, as we do live in an international word after all. So I
> support completely all efforts to translate the webpage, or our
> interface if we had one (well, SymPy Live can be considered an UI), I
> just don't think it's worthwhile for us to translate our documentation
> or bother at it at all. Aaron himself said the only reason he added
> translation tasks is because Google required it.
I think it's worthy to translate the webpage, and maybe the tutorial.
I don't think it's worthy to translate everything else, given our
current manpower.
Since we are translating the webpage and the tutorial (and nothing
else), I don't see any problem here.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Mon, Nov 28, 2011 at 8:34 AM, Aaron Meurer wrote: > I agree with this. We have to consider many factors, like what the I also agree with Ronan. > document is, and who can translate it/verify the translation. Right > now, we have exactly one person per language (except I guess we have > two for Czech), so our ability to verify translations, much less make > them is very limited. If we tried to do it outside of Code-In, we > would have to drop the review requirement, as there's simply no one > else to verify it, which makes me a little uneasy about it. As was > mentioned earlier, it's better to have no translation than a poor > translation, and while I'm not saying that anybody is poor at > translating, the fact is, with no quality assurance, we simply don't > know how good it is. We should only translate things, that we can verify to make sure that the language looks good and also that the burden on us is acceptable. I wasn't aware of the gettext framework much, until I spent a lot of time with it yesterday and I must say, that it's actually very nice and manageable. For example, you can use the "poedit" (http://www.poedit.net/) program to edit/translate the po files and so on. > > But I agree that some things, like the webpage or Wikipedia articles, > are very good to translate for outreach purposes. > > So Ondrej, with your work, is > http://www.google-melange.com/gci/task/view/google/gci2011/7127301 > still relevant? If so, can you update it with what still needs to be > done? Otherwise, let's close it. In fact, I have already updated the issue with the task description, which is this one: http://code.google.com/p/sympy/issues/detail?id=2795 suggesting to implement the gettext framework for Sphinx, as Jo independently also suggested above. It's invigorating that I independently either implemented or suggested the same things as Jo, so I think there is good agreement on using gettext. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Translation tasks - tutorial - summary
Hi Stefan, On Mon, Nov 28, 2011 at 5:13 AM, krastanov.ste...@gmail.com wrote: > Hi, > > About a day ago I've merged the bulgarian translation of the tutorial and a > number of problems showed up. I've just gone trough all the translation task > to check for the same problems. Most of them are present. So here is a > summary: Thanks a lot for your summary. We've been quite inconsistent, as it was the first time and we didn't have the infrastructure. After yesterday, I think we agreed to use gettext at least for the webpages. For the tutorials, there is a task: http://www.google-melange.com/gci/task/view/google/gci2011/7127301 http://code.google.com/p/sympy/issues/detail?id=2795 to implement gettext support in sphinx as well. I think that will be the ultimate goal, to have (just) the tutorial in gettext, so that if we change the git English version, we just (automatically) extract the translation strings, merge it with the translation and simply use some tool like "poedit" to see what new strings have to be translated and if they are not, it will simply reuse the English version for that particular string. So things will always be 100% uptodate, possibly not 100% translated (and it will be easy for translators to simply fix the few updates in the translation by sending a pull request with the new po file). So for now I suggest to get the translations in, merge it in some form at least (txt, rst) and then once we implement gettext support, we can maybe create some GCI tasks in December to convert it to it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Mon, Nov 28, 2011 at 10:08 AM, Aaron Meurer wrote: > 2011/11/28 Ondřej Čertík : >> On Mon, Nov 28, 2011 at 8:34 AM, Aaron Meurer wrote: >>> I agree with this. We have to consider many factors, like what the >> >> I also agree with Ronan. >> >>> document is, and who can translate it/verify the translation. Right >>> now, we have exactly one person per language (except I guess we have >>> two for Czech), so our ability to verify translations, much less make >>> them is very limited. If we tried to do it outside of Code-In, we >>> would have to drop the review requirement, as there's simply no one >>> else to verify it, which makes me a little uneasy about it. As was >>> mentioned earlier, it's better to have no translation than a poor >>> translation, and while I'm not saying that anybody is poor at >>> translating, the fact is, with no quality assurance, we simply don't >>> know how good it is. >> >> We should only translate things, that we can verify to make sure that >> the language looks good and also >> that the burden on us is acceptable. >> >> I wasn't aware of the gettext framework much, until I spent a lot of >> time with it yesterday and I must say, that it's actually very nice >> and manageable. For example, you can use the "poedit" >> (http://www.poedit.net/) program to edit/translate the po files and so >> on. >> >>> >>> But I agree that some things, like the webpage or Wikipedia articles, >>> are very good to translate for outreach purposes. >>> >>> So Ondrej, with your work, is >>> http://www.google-melange.com/gci/task/view/google/gci2011/7127301 >>> still relevant? If so, can you update it with what still needs to be >>> done? Otherwise, let's close it. >> >> In fact, I have already updated the issue with the task description, >> which is this one: >> >> http://code.google.com/p/sympy/issues/detail?id=2795 >> >> suggesting to implement the gettext framework for Sphinx, as Jo >> independently also suggested above. It's invigorating that I >> independently either implemented or suggested the same things as Jo, >> so I think there is good agreement on using gettext. >> >> Ondrej >> > > Great. Let's do it then. Don't feel like you have to not fix it to > leave it for some student because it's a GCI task. If it will make > life easier to just fix it yourself, please do so. We should fix it ourselves, so that it's done and in sympy before December 16 for the second round of tasks. However, I don't have time for it. Yesterday I spent all day with the webpages, it was a lot of work, but I think the framework is done at least. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
What I meant was to create gci tasks to convert the tutorial translations to use gettext. Send from mobile phone On Nov 28, 2011 10:45 AM, "Aaron Meurer" wrote: > Will we have more SymPy translation tasks to add for the 16th? I was > thinking of adding tasks to translate the Wikipedia article, but > that's it. What other documents should we have translated? > > Aaron Meurer > > > We should fix it ourselves, so that it's done and in sympy before > > December 16 for the second round of tasks. > > > > However, I don't have time for it. Yesterday I spent all day with the > > webpages, it was a lot of work, but I think the framework is done at > > least. > > > > Ondrej > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
2011/11/28 Ondřej Čertík : > What I meant was to create gci tasks to convert the tutorial translations to > use gettext. And the same for the webpage. Otherwise we'll have to do it yourselves, it took my about 1h of solid work. So times 7 (or how many) translations, for both webpage and tutorial, so that's a lot of work that somebody will have to do. So if we make this the GCI task, it will save us tons of time. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Mon, Nov 28, 2011 at 1:21 PM, Aaron Meurer wrote: > I created http://code.google.com/p/sympy/issues/detail?id=2879 for > this. I don't know much about gettext, so I didn't put much > information there. If you could add more, that would be great. > > Also, I didn't know what difficulty to put (I just put medium for > now), and also what other categories it can go into (is it code?). I think so, it's code. I will try to do it, if I have time, we'll see. This is one of the issues which are not clear how much work it is going to be, because I don't know exactly how to integrate gettext with sphinx. We'll have to experiment. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] SymPy is the second most forked Python project on GitHub (again)
On Mon, Nov 28, 2011 at 1:08 PM, Aaron Meurer wrote: > Hi. > > It looks like that thanks to Google Code-In, SymPy is once again among > the top forked Python projects on GitHub. See > https://github.com/languages/Python. As of this writing, we are > number 2 for this month. Nice. The first project this week and second overall for the last month. I took a screenshot: https://raw.github.com/gist/1339850/a1df02a2c3f01164a9369339dcb3afeffe592eba/Screenshot%20at%202011-11-28%2016:01:01.png it will be cool for our blog post about GCI later. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: framework for translating our webpage
On Tue, Nov 29, 2011 at 11:48 AM, Joachim Durchholz wrote: > Am 29.11.2011 00:49, schrieb Ondřej Čertík: > >> I think so, it's code. I will try to do it, if I have time, we'll see. >> This is one of the issues which are not clear how much work it is >> going to be, because I don't know exactly how to integrate gettext >> with sphinx. We'll have to experiment. > > > Um... does http://sphinx.pocoo.org/latest/intl.html answer that question? > (It was the first Google result for sphinx gettext.) I think that is exactly it! Somebody just has to submit a pull request with implementing this in sympy docs. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] how to compile docs
Hi, Do I need some special extensions to compile docs? I tried the usual "make html", but it failed for me: http://code.google.com/p/sympy/issues/detail?id=2891 Not sure if I did something wrong. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] how to compile docs
On Thu, Dec 1, 2011 at 11:33 AM, krastanov.ste...@gmail.com wrote: > From the readme in the doc directory: > > apt-get install python-sphinx texlive-latex-recommended dvipng > make html > > That works for me on ubuntu oneiric Thanks, I just wanted to make sure. I probably have either too new, or too old sphinx, I'll figure it out. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Releasing SymPy 0.7.2
On Fri, Dec 2, 2011 at 10:42 AM, Aaron Meurer wrote: > On Fri, Dec 2, 2011 at 10:57 AM, Vladimir Perić wrote: >> On Fri, Dec 2, 2011 at 5:05 PM, Aaron Meurer wrote: >>> On Fri, Dec 2, 2011 at 2:22 AM, Mateusz Paprocki wrote: Hi, On 30 November 2011 22:50, Aaron Meurer wrote: > > Yeah, I'm totally free until the end of January, starting in two > weeks. We'll probably need to do some cleaning up from pull requests > and stuff after GCI too (e.g., right now, I'm basically ignoring all > non-critical non-gci pull requests). I also overestimated my spare time before leaving to India. Right now I'm waiting for my flight at Munich airport. Well, at least we started writing release notes, which is good because there are so many changes (over 1400 commits already). >>> >>> Exactly. Releasing takes forever. If we released once a month, we >>> would constantly be in a release cycle. >> >> Ok, we can also brainstorm what is needed to make the release process >> quicker and less painful? Aaron, ideas? You are the only one who >> actually went through it. > > Others have done it too (I've only done the last two). > > The most time consuming thing was fixing all the blocking issues. I > don't know of any way to alleviate that, other than that the less time > it has been since the last release, the fewer things there will be to > do. > > As far as things on https://github.com/sympy/sympy/wiki/New-Release > go, the more automated they can be, the easier it will be. For > example, fixing the PyPI thing will make that part much easier the > next time around. > > Going through that, the things that I remember taking the longest to do were: > > - Running all the tests with tox. This isn't hard, especially if you > already have a ready-to-go tox.ini file, but it takes forever > nonetheless. > > - There are almost always test failures, which have to be fixed. > Sometimes, these happen on all the branches, sometimes, they happen on > just some configurations. If we had some kind of a build-bot, I think > this could be alleviated by fixing them before release time. Also, we > need to get into the habit of running sympy-bot on *every* pull > request before merging it, so that failures don't get into master (a > build-bot would help with this too). > > - Here's something very concrete that we could fix. There are several > things to test at https://github.com/sympy/sympy/wiki/New-Release that > we only test at release time. Since we don't look at it in between, > there are more often than not little problems that crop up with it. > We should add these to setup.py test: > > - Examples: (http://code.google.com/p/sympy/issues/detail?id=698) > > - Plotting: This is to check that the plotting actually works, with > the pictures. This will probably change with the new module, so let's > look at this again once that is in. > > - External tests: If we have a build-bot, we need to make sure that > we test configurations with numpy, scipy, and matplotlib installed. > Also, the sage tests are never run, except at release time. We should > incorporate it into the test runner to actually run them if sage is > installed (there were quite a few sage errors with 0.7.0 because of > this and the fact that they weren't even run for 0.6.7 or 0.6.6). > This is http://code.google.com/p/sympy/issues/detail?id=2481. > > - Authors list: We need to update .mailmap, so that we can directly > compare git log --format="%aN <%ae>" | sort -u exactly with the > AUTHORS file. Then, a simple extension of that shell command will give > you all authors who weren't added to the AUTHORS file, and where they > should be in it. I created a GCI task for this > (http://code.google.com/p/sympy/issues/detail?id=2893). > > - Making the release notes. Any thoughts on how to make the release > notes process easier? I know we discussed this the last time we > released, but we apparently didn't implement any useful suggestions. > > I've made sure that all the relevant issues here are marked for > Code-In, since this seems to be a good way to get things done. > > Other than those things, the best way to make this easier is if other > people help out, instead of just one person doing it all :) I've done tons of sympy releases. I think that we just need to learn how to distribute the work. What are the release blockers for this release? Let me know if you agree, but as to me, I am perfectly fine with releasing what we have, as long as all tests pass and there are no regressions. One thing that is new in this release is the python 3 support -- should we just run the 2to3 tool and create a tarball, or should we create a repository (or branch in sympy?) for it? Or should the 2to3 tool be run when setup.py is called (I don't like that it is slow)? I think one safe option is to create sympy-py3 repository, that would only contain autogenerated code from 2to3 tool. All fixes/development/changes
Re: [sympy] Re: Releasing SymPy 0.7.2
2011/12/2 krastanov.ste...@gmail.com : > On the topic of testing: What is the reason that the pull requests are not > all tested automatically? And tox run every week or so. I thought that all That's the plan, but I got busy to set this up, so it's not done yet. > the code for the automated testing is already written. And there is that > google app engine instance. If it's only a processing power issue I have a > relatively old core2due computer that is almost completely unused and I'll > gladly make an ssh account for you so you install the automated sympy-bot > (or I can do it with your help). Or if I'm wrong and this stuff is not > automated one can just write a one line cron job workaround for it. If you have time to make this work, it'd be really great. I just sent you an invitation for push access to the app engine instance of reviews.sympy.org. The code of which is in the sympy-bot repository, see the web directory [1]. My overall long term goal is to have all pull requests automatically tested on all architectures, every time either the master or the pull request branch changes. To do so, I've already implemented to note down the master hash and branch hash in the pull request. My TODO list is: 1) make the web application accept the master/branch hashes for each submitted test 2) implement "sympy-bot work" mode that would query the web application for a list of pull requests that need updated test run 3) setup github authentication, so that the web application comments into the github pullrequest (currently the sympy-bot itself comments using your github credentials). One needs to figure out the authentication as well as some reasonable reporting, as in general there will be tons of tests executed for each pull request and the webapp should figure out whether a new test should be run or not, depending on the hashes. If you make any work on this, that'd be absolutely awesome. You don't need to follow my TODO list. But try to submit all the code/configuration into the sympy-bot repository, so that other people can reproduce the work and help with the setup. Ondrej [1] https://github.com/sympy/sympy-bot -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Releasing SymPy 0.7.2
On Sat, Dec 3, 2011 at 6:53 AM, Aaron Meurer wrote: > The biggest problem with Jenkins in my opinion is that it has such a > terrible user interface. > > SymPy-Bot is nice in that it allows completely distributed testing. > The script is so simple and self-contained that anyone can just clone > it and run it (I guess there are a few Python dependencies to install, > but we could probably make distribute do that work for us too if we > wanted). > > And testing pull requests is way more important than testing master; > this is attested to by the fact that we still have not implemented > master testing in sympy-bot. In some ways, testing pull requests > tests master as a side effect, because we always merge with master > first. In fact, the only time I run tests on master directly is when > doing a release, and even that's technically some branch. (Don't get > me wrong, though; testing master is important, and we should be doing > it). > > This is kind of analogous to the git/GitHub pull request model where > you review code before pushing it in and the > svn/ model, where you review it after it goes > in. It's pretty clear to me, and I think most others who use GitHub > pull requests, that the former is the superior way of doing things. Exactly. I am sure that Jenkins can be setup to work with github pull requests as well by hooking it up into our sympy-bot webapp and if anybody wants to give it a shot, go ahead. I personally think that the easiest and also robust (given our requirements) is to simply implement the missing parts in sympy-bot. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] review help request
Hi Chris, On Mon, Dec 5, 2011 at 4:42 AM, smichr wrote: > If a GCI review is too time consuming, perhaps you would consider one > of the following pretty targeted reviews. I'll start closing some of > the other larger requests, but these fix deficiencies and really > should be committed: > > https://github.com/sympy/sympy/pull/815 > factor(sqrt(-x)) != I*sqrt(x) > https://github.com/sympy/sympy/pull/813 > solve shouldn't use the posified symbols when checking that the > solutions > match the assumptions on the symbols > https://github.com/sympy/sympy/pull/790 > matrices allow out of bound references for rows > https://github.com/sympy/sympy/pull/812 > constant_renumber's docstring can be a little clearer as to what > it does > https://github.com/sympy/sympy/pull/787 > routines that invert a matrix should check that the matrix is > invertible; > if this is not done, one ends up with expressions that have no > meaning > since they may contain symbolic NaN and infinities > > These aren't related to bugs; the are convenience modifications: > > https://github.com/sympy/sympy/pull/720 > real_root was added to compute real_root(-27, 3) == -3 instead of > 3*(-1)**(1/3) > https://github.com/sympy/sympy/pull/700 > gives you the ability to expand just the numerator or denominator > of a > fraction I merged everything except: 813 (left a comment there) 787 (needs rebase, but otherwise ok) 720 (running tests on it currently) Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: need suggestions to the new concept of using SymPy
On Tue, Dec 6, 2011 at 2:43 AM, Shyam wrote: > Hi Aaron, > A new video has been uploaded in youtube. It explains the steps > required to generate the output. You can find the video at > > http://youtu.be/TAAeCV5QM0Y > > Basically, you need to download the builtin programs (menu::Download > Builtins). Once downloaded, you can run the tutorials provided for > SymPy. Ah, I see. So you can run all the worksheets inside the phone. That's cool. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] SymPy quantum computing paper
Hi Brian, On Tue, Dec 6, 2011 at 12:24 PM, Brian Granger wrote: > Hi, > > We have done a lot of work on SymPy's quantum computing modules and it > is time to write a paper. If you are interesting in helping out, > please read on... > > * The paper will focus on SymPy's quantum computing modules in > sympy.physics.quantum (gate, qubit, qft, etc.). We should also write > a more general paper on sympy.physics.quantum, but that will come > later. Absolutely. It will force me to contribute more general stuff into the quantum module. :) > * We will have a short introduction to SymPy and sympy.physics.quantum. > * It will be submitted to either Physical Review X (open online > journal) or a more specialized quantum information journal. Phys. Rev > X would be ideal as it is completely free and open, but the cost is > $1500. I will see if I can come up with that money though. > * The author list will be determined as follows: 1) anyone who has > done significant work on the quantum information stuff will > automatically be co-authors 2) anyone who is a contributor to SymPy > and wants to help write/read/proof the paper is also welcome to be a > co-author > * Much of the paper will be code demos with nice latex output. This > will be done as a set of IPython notebooks. I would like to publish > these with the paper. > > Here is the repo where this work is going to happen: > > https://github.com/ellisonbg/sympy-qcpaper Thanks a lot for the initiative. Here is my first pull request: https://github.com/ellisonbg/sympy-qcpaper/pull/1 Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] assumptions
On Wed, Dec 7, 2011 at 11:58 AM, Ronan Lamy wrote:
> Le mercredi 07 décembre 2011 à 20:36 +0100, krastanov.ste...@gmail.com a
> écrit :
>> How should assumptions be used? More precisely why the following code
>> does what it does
>>
>> In [18]: global_assumptions.clear()
>>
>> In [19]: x = Symbol('x', positive=True)
^^^ This is old assumptions, that will be eventually removed
>>
>> In [20]: ask(Q.positive(x)) # Why does it return None?
New assumptions.
>>
>> In [21]: x > 0
>> Out[21]: True
Old assumptions.
And so on. We need to write documentation how to use the new
assumptions. I hit the same problems. Here is an example:
+>>> from sympy import var, solve, S, refine, Q
+>>> var("a z")
+(a, z)
+>>> f = z / (a**2+z**2)**(S(5)/2)
+>>> solve(f.diff(z), z)
+[-a/2, a/2]
+>>> f.subs(z, a/2)
+16*sqrt(5)*a/(125*(a**2)**(5/2))
+>>> refine(f.subs(z, a/2), Q.positive(a))
+16*sqrt(5)/(125*a**4)
and we just need to document it well, then improve refine and other
things, and then eventually remove the old assumptions.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] assumptions
On Wed, Dec 7, 2011 at 12:11 PM, krastanov.ste...@gmail.com
wrote:
>
>
> 2011/12/7 Ondřej Čertík
>>
>> On Wed, Dec 7, 2011 at 11:58 AM, Ronan Lamy wrote:
>> > Le mercredi 07 décembre 2011 à 20:36 +0100, krastanov.ste...@gmail.com a
>> > écrit :
>> >> How should assumptions be used? More precisely why the following code
>> >> does what it does
>> >>
>> >> In [18]: global_assumptions.clear()
>> >>
>> >> In [19]: x = Symbol('x', positive=True)
>>
>>
>> ^^^ This is old assumptions, that will be eventually removed
>>
>> >>
>> >> In [20]: ask(Q.positive(x)) # Why does it return None?
>>
>> New assumptions.
>>
>> >>
>> >> In [21]: x > 0
>> >> Out[21]: True
>>
>> Old assumptions.
>>
>> And so on. We need to write documentation how to use the new
>> assumptions. I hit the same problems. Here is an example:
>>
>> + >>> from sympy import var, solve, S, refine, Q
>> + >>> var("a z")
>> + (a, z)
>> + >>> f = z / (a**2+z**2)**(S(5)/2)
>> + >>> solve(f.diff(z), z)
>> + [-a/2, a/2]
>> + >>> f.subs(z, a/2)
>> + 16*sqrt(5)*a/(125*(a**2)**(5/2))
>> + >>> refine(f.subs(z, a/2), Q.positive(a))
>> + 16*sqrt(5)/(125*a**4)
>>
>> and we just need to document it well, then improve refine and other
>> things, and then eventually remove the old assumptions.
>
> Does this mean that every instance of is_something must be changed to ask()?
Eventually yes, but from my talks with Mateusz at the Google Mentor Summit,
unfortunately it is not easy to do it step by step, because for various
technical reasons one will have to remove the old assumptions in one step
(and fix some solvers that depend on it).
> Is it plausible in the meantime to have (is_something or ask(..))? Of course
> in some cases 'or' wont be the correct operator.
I think it is currently completely independent, and we should simply start using
the new assumptions.
Ondrej
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] should radical removal be optional or automatic with as_content_primitive
On Tue, Dec 6, 2011 at 4:19 AM, smichr wrote: > as_content_primitive removes Rational content from an expression. Does > it make sense to remove radical content, too, but leave it as a factor > with the primitive portion? > > >>> (sqrt(2+2*x)+sqrt(10+10*x)).as_content_primitive() > (1, sqrt(2)*(sqrt(x + 1) + sqrt(5)*sqrt(x + 1))) > > > see https://github.com/sympy/sympy/pull/824 I think that's fine. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Getting rid of tiny imaginary parts in eigenvalues
On Sat, Dec 10, 2011 at 10:37 AM, pedda wrote: > I have tried to do it non-symbolically, but I think it is rather > inelegant. I am also trying to promote the use of python/sage over the > use of Mathematica with my fellow students and it is somewhat > important to show that they can do the same thing for free with other > advantages. Since Mathematica is able to calculate the eigenvalues > without any problem or delay, it is hard to convince someone to switch > to a system that takes so much longer and is not as reliable. Mathematica is old and well tested and polished system, so it's currently more reliable. SymPy is improved by people like you or me, who have a problem, and want to solve it using opensource tools (because we believe in opensource), as opposed to just feed it to Mathematica and be done with it. All you need are just eigenvalues of this matrix? Or also eigenvectors? What is the algorithm that Mathematica uses? In particular, what is the best algorithm for this type of matrix to get the eigenvalues? Let's get it implemented in SymPy so that we can solve these kind of matrices. I would be very interested in that myself. I do my PhD in atomic electronic structure, I do things numerically using LAPACK or other libraries, but I would love to be able to solve simpler physical systems symbolically in sympy. With Brian, we want to be able to do such things in the sympy.quantum module. Would you be willing to contribute some example of how you generate the matrices? Anyway, if you know the right algorithm for your matrix, I would help you implement it in SymPy. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Getting rid of tiny imaginary parts in eigenvalues
2011/12/10 Ondřej Čertík : > On Sat, Dec 10, 2011 at 10:37 AM, pedda wrote: >> I have tried to do it non-symbolically, but I think it is rather >> inelegant. I am also trying to promote the use of python/sage over the >> use of Mathematica with my fellow students and it is somewhat >> important to show that they can do the same thing for free with other >> advantages. Since Mathematica is able to calculate the eigenvalues >> without any problem or delay, it is hard to convince someone to switch >> to a system that takes so much longer and is not as reliable. > > Mathematica is old and well tested and polished system, so it's > currently more reliable. > SymPy is improved by people like you or me, who have a problem, and want to > solve it using opensource tools (because we believe in opensource), > as opposed to just feed it to Mathematica and > be done with it. > > All you need are just eigenvalues of this matrix? Or also eigenvectors? > > What is the algorithm that Mathematica uses? In particular, what > is the best algorithm for this type of matrix to get the eigenvalues? > > Let's get it implemented in SymPy so that we can solve these kind of matrices. > I would be very interested in that myself. I do my PhD in atomic > electronic structure, > I do things numerically using LAPACK or other libraries, but I would love > to be able to solve simpler physical systems symbolically in sympy. > With Brian, we want to be able to do such things in the sympy.quantum module. > > Would you be willing to contribute some example of how you generate > the matrices? > > Anyway, if you know the right algorithm for your matrix, I would help > you implement it > in SymPy. So in particular -- can you send us a script, that generates the matrix above, just for smaller number of electrons, so that we can solve it in sympy (and check that the eigenvalues are correct)? Then we'll try to scale it up and see why it gets slow and then let's see how we can improve the algorithm. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Getting rid of tiny imaginary parts in eigenvalues
On Sun, Dec 11, 2011 at 2:40 AM, pedda wrote: > Hello everyone, > > thank you very much for your participation! I have attached the code. > It is probably not the cleanest you can find, but it works for now.. > You can control the size of the matrix by setting the variables sites, > n_up, and n_down which I have moved to the top of the script. The goal > was to make it work with (6,3,3). Can you please post it into gist at https://gist.github.com/? google groups have reformatted your message, so when you copy-paste it and run it, you get tons of syntax errors. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] sympy-bot crashes when PR is not mergeable
On Sun, Dec 11, 2011 at 1:42 PM, krastanov.ste...@gmail.com wrote: > Hi, > > Am I the only one to get this error: > > Auto-merging doc/src/modules/assumptions/index.txt > Auto-merging sympy/core/expr.py > CONFLICT (content): Merge conflict in sympy/core/expr.py > Automatic merge failed; fix conflicts and then commit the result. > Done. > > View log at: /tmp/sympy-bot-tmpmSdoXH/out/log > Traceback (most recent call last): > File "./sympy-bot", line 279, in > main() > File "./sympy-bot", line 97, in main > review(n, options) > File "./sympy-bot", line 244, in review > master_hash = result["master_hash"] > KeyError: 'master_hash' That was a bug as a leftover from my implementation of reporting the hashes. I sent a pull request fixing it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Import combinatorics in __init__
Hi Matt, On Sun, Dec 11, 2011 at 6:40 PM, Matt Habel wrote: > So, I was doing a GCI task that involved cleaning up doctests in > combinatorics, and I thought, why isn't this imported initially? So, I > imported it, ran timeit tests with and without it being imported, and > the difference is only about .04-.05 seconds (.36 - ~.4). What do you > think about keeping it as a constant import? Thanks for asking. So in particular, we are talking about importing the following symbols from sympy/combinatorics/__init__.py: from sympy.combinatorics.permutations import Permutation from sympy.combinatorics.prufer import Prufer from sympy.combinatorics.generators import cyclic, alternating, symmetric, dihedral from sympy.combinatorics.subsets import Subset I am +1 for importing the Permutation by default (it's available by default in Mathematica too for example). I personally don't like to import "cyclic", "alternating" etc., because it is not clear from the name what it does, and it is easy to do: from sympy.combinatorics import cyclic if needed. If you think such symbols would be very often used, it should have a better name. For example, in Mathematica, this is called: http://reference.wolfram.com/mathematica/ref/RotateLeft.html What do others think? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Open Source Blog post about SymPy
On Mon, Dec 12, 2011 at 4:15 PM, Aaron Meurer wrote: > Hi. > > Google has posted a wrap-up post for Google Summer of Code for SymPy > on their open source blog at > http://google-opensource.blogspot.com/2011/12/students-add-to-sympy.html. > I've also cross-posted this on the official SymPy blog at > http://sympy.blogspot.com/2011/12/google-summer-of-code-2011-wrap-up.html. > > Congratulations once again to all the Google Summer of Code students. > And thanks to Stephanie Taylor, who runs the Google open source blog. I also posted it at the SymPy G+ page: https://plus.google.com/116872266504964122381/posts/Wk3z5AP2m6H Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Import combinatorics in __init__
On Mon, Dec 12, 2011 at 12:58 PM, Aaron Meurer wrote: > Aside from naming conventions, I think another thing we should > consider when looking what (if anything) to import is which are SymPy > objects and which are just regular Python functions. For example, > Permutation is Basic, but everything in generators is a Python > function (a generator). Great point. I think we should import classes (if they are available), right? Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] how to only list the merge conflicts with git
Hi, I have implemented reporting of merge conflicts in sympy-bot, here is an example of the report: http://reviews.sympy.org/report/agZzeW1weTNyDAsSBFRhc2sYyM0IDA if you scroll down, you can see, that I am just using "git diff" and it prints the long diff. This particular conflict is quite large, however there are lines that are not in conflict, for example: + from sympy.core.compatibility import callable, reduce, SymPyDeprecationWarning import random + import warnings These are just fine. Is there any way to force git not to show these lines? I would like to only show conflicts between the lines: ++<<< HEAD ... ++>>> origin/master together with the filename where it occurs. I guess I can write some Python script for it, but I was wondering whether git already has support for this. I didn't find any option for it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] new features in sympy-bot
Hi, Here are some new features in sympy-bot that we implemented (https://github.com/sympy/sympy-bot): * Review "all" and "mergeable": Use it like this: sympy-bot review all or sympy-bot review mergeable and it will review all open pull requests or all mergeable pull requests. It will ask for your login (once) and then just keep running. I leave it running in the "screen" environment on my server. If you have some spare cycles, just run the following from time to time: sympy-bot review mergeable sympy-bot -3 review mergeable you can run this over night. * Report conflicts Now the log shows conflicting files *and* the actual conflicts. So from now on, we can simply click on the full report and see the conflicts and if it is some easy conflict (typically changed imports), one can choose to simply fix it manually and merge the pull request. If the conflict is large, one would ask the reviewer to rebase. * "-m" option One can now merge with a custom commit (or not merge at all). See the README. I think the last big piece of the puzzle is to implement "sympy-bot work" to wait for "orders" from the web application (by polling it). And the web application would send it some high priority pull requests (like the newly open ones) and so on. This I would simply leave running at the server. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] how to compile docs
2011/12/1 Ondřej Čertík : > On Thu, Dec 1, 2011 at 11:33 AM, krastanov.ste...@gmail.com > wrote: >> From the readme in the doc directory: >> >> apt-get install python-sphinx texlive-latex-recommended dvipng >> make html >> >> That works for me on ubuntu oneiric > > Thanks, I just wanted to make sure. I probably have either too new, or > too old sphinx, I'll figure it out. Looking at the stacktrace: https://gist.github.com/1470743 It seems that it is coming from the numpydoc.py extension that we have there. However, it clearly works for you, so I don't know what is happening. It needs more debugging. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] how to only list the merge conflicts with git
On Mon, Dec 12, 2011 at 8:57 PM, Aaron Meurer wrote: > I wonder how git decides to show that extra stuff. The things that it > actually merged fine are hidden (you can see them with git diff > --cached). Those are the things that are staged automatically. I think what happens is that if the *whole* file is ok, then it is staged and "git diff" doesn't show it. If there is some conflict (even if just one line), it will diff the whole file (thus showing all the nonconflicting differences). Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] should radical removal be optional or automatic with as_content_primitive
On Sun, Dec 11, 2011 at 7:34 PM, Chris Smith wrote: > On Mon, Dec 12, 2011 at 4:54 AM, Aaron Meurer wrote: >> Some better information about this is at >> http://planetmath.org/encyclopedia/ContentOfPolynomial.html. >> > I'm not trying to factor numbers algebraically, just remove a common > radical in the same way that content factors out a rational so > `sqrt(2)+sqrt(10)` -> `sqrt(2)*(1 + sqrt(5))` and `sqrt(2) + sqrt(2 + > 2*x)` -> sqrt(2)*(1 + sqrt(1 + x))` Exactly. That seems fine to me, given the (not so complex) patch. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Removing auto-distribution of constants
On Sun, Nov 27, 2011 at 5:01 PM, Kate MacInnis wrote: > So last spring, I started working on removing the auto-distribution of > constants. Life got busy, and I had to set that project aside for > awhile. When I decided to come back to it over the long weekend, I > decided to start fresh. I've now got almost all tests passing. :-) Excellent, thanks for working on that. Others have commented on the issues. What are the remaining problems? Maybe if you post them here, other people can join and help you fix them. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Google Open Source Blog post about SymPy
On Mon, Dec 12, 2011 at 11:02 PM, Joachim Durchholz wrote: > Am 13.12.2011 01:15, schrieb Aaron Meurer: > >> Hi. >> >> Google has posted a wrap-up post for Google Summer of Code for SymPy >> on their open source blog at >> http://google-opensource.blogspot.com/2011/12/students-add-to-sympy.html. >> I've also cross-posted this on the official SymPy blog at >> http://sympy.blogspot.com/2011/12/google-summer-of-code-2011-wrap-up.html. > > > The translators are missing. Do you mean the Google Code-In translators? The above blog post is for the Summer of Code. I am not aware of any translators. We'll post a separate blog post once the Code-In is over. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] new features in sympy-bot
On Tue, Dec 13, 2011 at 2:04 AM, krastanov.ste...@gmail.com wrote: > That's great. I'll start using it. Still, I have a few questions: > > Is it a bad idea to run it like this: """while ((1)); do ./sympy-bot all; > done;""" ? That way I can leave it and it will run forever. I have That's fine. But see below. > .sympy-bot config file so it will not ask for password. > > If two developers are running it at the same time what stops them from > making duplicate reports? I suppose that before each test it checks if tests > were already done (instead of checking this at the beginning when building > the list of open pull requests before running any tests). But this still > leaves about 20 minutes (between the start of the tests and their posting) > for somebody else to start a duplicate test. > > And how does it check if tests were already done (it pools the GAE app > probably and it also checks the architecture)? Are tests on different python > versions and different architecture considered different? Unfortunately this is *not* implemented yet. So you still have to use your script. The GAE app should decide how many tests we need for each pull request for the given platform (typically just one). Usually, your platform might be different than mine (you might be 32, I am 64, or you might have a different version of Python like 2.6 and I have 2.7, and so on). Imho there should be just a few actuall comments in the github pull request with the report, everything else should go into the web app (so that we don't spam the pull request, but still have all the tests). What we can do is to modify sympy-bot to *only* upload to the webapp, then you can simply leave it running in a loop and we will have all the tests and no spamming. Then the webapp just needs to decided somehow when and how to report into the pull request. I think that's a great solution for now. So let's make a special option in sympy-bot to only upload to the web app and *not* commenting into the pull request, and then let's run this in a loop at my server for 2.x and 3.x pythons. It will not be super efficient, but we don't have that many pull requests and it just takes a few hours to run tests on all pull requests, so that's a good engineering solution for now. Once we have that, the only thing to do is to start improving the GAE app to be more clever about all the data that it has. One idea is that for example once it has both 2.x and 3.x tests for at least one platform, it can post a link to the GAE pull request page into the github pull request. So that we can just click the link and see the latest status. Ondrej > > Stefan > > 2011/12/13 Ondřej Čertík >> >> Hi, >> >> Here are some new features in sympy-bot that we implemented >> (https://github.com/sympy/sympy-bot): >> >> * Review "all" and "mergeable": >> >> Use it like this: >> >> sympy-bot review all >> >> or >> >> sympy-bot review mergeable >> >> and it will review all open pull requests or all mergeable pull >> requests. It will ask for your login (once) and then just keep >> running. >> I leave it running in the "screen" environment on my server. If you >> have some spare cycles, just run the following from time to time: >> >> sympy-bot review mergeable >> sympy-bot -3 review mergeable >> >> you can run this over night. >> >> >> * Report conflicts >> >> Now the log shows conflicting files *and* the actual conflicts. So >> from now on, we can simply click on the full report and see the >> conflicts and if it is some easy conflict (typically changed imports), >> one can choose to simply fix it manually and merge the pull request. >> If the conflict is large, one would ask the reviewer to rebase. >> >> * "-m" option >> >> One can now merge with a custom commit (or not merge at all). See the >> README. >> >> >> I think the last big piece of the puzzle is to implement "sympy-bot >> work" to wait for "orders" from the web application (by polling it). >> And the web application would send it some high priority pull requests >> (like the newly open ones) and so on. This I would simply leave >> running at the server. >> >> Ondrej >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.
Re: [sympy] how to compile docs
On Tue, Dec 13, 2011 at 4:38 AM, Alexey U. Gudchenko wrote: > 13.12.2011 09:27, Ondřej Čertík пишет: >> 2011/12/1 Ondřej Čertík : >>> On Thu, Dec 1, 2011 at 11:33 AM, krastanov.ste...@gmail.com >>> wrote: >>>> From the readme in the doc directory: >>>> >>>> apt-get install python-sphinx texlive-latex-recommended dvipng >>>> make html >>>> >>>> That works for me on ubuntu oneiric >>> >>> Thanks, I just wanted to make sure. I probably have either too new, or >>> too old sphinx, I'll figure it out. >> >> Looking at the stacktrace: >> >> https://gist.github.com/1470743 >> >> It seems that it is coming from the numpydoc.py extension that we have >> there. However, it clearly works for you, so I don't know what is >> happening. It needs more debugging. >> >> Ondrej >> > > > For information, it is NOT work for me too, with the same exception. > > $ virtualenv --no-site-packages test > $ source test/bin/activate > (test)$ pip install sphinx > (test)$ make html > > With the similar stacktrace: > > https://gist.github.com/1471949 > > (test)$ deactivate > > > But, fortunately, with clear python 2.7.2 I have not this problem: > > $ virtualenv --no-site-packages -p python2.7 test > $ source test/bin/activate > (test)$ pip install sphinx > (test)$ make html > > "Build finished. The HTML pages are in _build/html." > > (test)$ deactivate Exactly. It is imho related to some package that is installed in that environment (virtualenv in your case, Qsnake in my case). My guess is that it imports some package and then it breaks. I wonder which package causes it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
