Re: [sympy] Re: Google Season of Docs
The org applications for Google Season of Docs are now open. https://developers.google.com/season-of-docs/docs/get-started/. The deadline is April 23 which is in about two weeks. Jason, we should schedule a time to work on it. If anyone else is interested in helping let me know. Aaron Meurer > On Mar 15, 2019, at 2:49 PM, Jason Moore wrote: > > Potentially both. I will try to read about it this weekend. > > Jason > moorepants.info > +01 530-601-9791 > > >> On Fri, Mar 15, 2019 at 9:55 AM Aaron Meurer wrote: >> Thanks Jason. Just to clarify, are you able to help with both the >> application (due April 23) and the mentoring? >> >> I also think we should apply. I read some more on their site. >> Apparently as part of their pilot, they are only going to have 50 >> slots, with a max of 2 slots per project >> (https://developers.google.com/season-of-docs/docs/faq#slot-allocation). >> I guess this means they will be accepting about 25 orgs, so depending >> on how popular this is, we may need to work extra hard to get >> accepted. >> >> Here are the instructions for the application >> https://developers.google.com/season-of-docs/docs/organization-application-hints. >> If you want to start thinking of project ideas, that would be helpful. >> Feel free to start a page on the wiki for this. We won't know what the >> actual application form looks like until it opens on April 2. >> >> Aaron Meurer >> >> On Fri, Mar 15, 2019 at 9:18 AM Jason Moore wrote: >> > >> > > Should SymPy apply? >> > >> > Yes! >> > >> > I'm willing to help with that (likely). >> > >> > Jason >> > moorepants.info >> > +01 530-601-9791 >> > >> > >> > On Wed, Mar 13, 2019 at 1:59 PM Arif Ahmed >> > wrote: >> >> >> >> The SymPy docs are quite fine but I feel most of the modules could use a >> >> lot more comments(in-line and block, existing docstrings are already >> >> quite good !) >> >> It would make it easier for contributors(especially new ones) to fix bugs >> >> if there were comments explaining the underlying algorithm/math. >> >> >> >> Here is a good example of what I mean(lines 846 to 1066 have a fairly >> >> decent explanation of the process used). Unfortunately such comments seem >> >> rare to me throughout the library. >> >> >> >> >> >> On Thursday, March 14, 2019 at 12:35:31 AM UTC+5:30, Aaron Meurer wrote: >> >>> >> >>> Google is starting a new program, Google Season of Docs (GSoD). I'd >> >>> like to gauge the community's interest in applying. >> >>> >> >>> Full information about the program is here: >> >>> https://developers.google.com/season-of-docs/ >> >>> >> >>> The program is very similar to Google Summer of Code, but unlike GSoC, >> >>> it focuses on documentation instead of code. Also unlike GSoC, the >> >>> program is aimed toward people with technical writing experience >> >>> rather than students. The idea is to give open source projects a >> >>> chance to have a professional technical writer help them with their >> >>> documentation. The technical writers learn more about open source >> >>> technologies and get something they can add to their resume. >> >>> >> >>> Should SymPy apply? The application period intersects with GSoC a bit, >> >>> but the actual mentoring period does not >> >>> (https://developers.google.com/season-of-docs/docs/timeline). >> >>> >> >>> Aaron Meurer >> >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "sympy" group. >> >> To unsubscribe from this group and stop receiving emails from it, send an >> >> email to sympy+unsubscr...@googlegroups.com. >> >> To post to this group, send email to sympy@googlegroups.com. >> >> Visit this group at https://groups.google.com/group/sympy. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/sympy/76b1e451-00ac-490c-a26b-1cc0d9ccec00%40googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "sympy" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to sympy+unsubscr...@googlegroups.com. >> > To post to this group, send email to sympy@googlegroups.com. >> > Visit this group at https://groups.google.com/group/sympy. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sympy/CAP7f1AiGuyJm4FcY4opBms9iC3xZ%3DjRXeFXDK%2Bgz9w2%2BCad3Zw%40mail.gmail.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sympy+unsubscr...@googlegroups.com. >> To post to this group, send email to sympy@googlegroups.com. >> Visit this group at https://groups.google.com/group/sympy. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAKgW
Re: [sympy] Subclassing sympy symbols and functions to attach additional attributes
In that case, it would be better to model your object after Predicate and
AppliedPredicate, which work the same way (except in Boolean expressions).
Aaron Meurer
> On Feb 5, 2016, at 5:37 PM, Bogdan Opanchuk wrote:
>
> Hi Aaron,
>
> Thank you for your reply.
>
>> If you want to give the fields names I guess you should use
>> UndefinedFunction. Note that UndefinedFunction('f') dynamically creates a
>> subclass of AppliedUndef called "f".
>
> The problem is that I need this object to participate in expressions even
> without being applied (that is, both `f` and `f(x)` should be usable in
> expressions), and UndefinedFunction cannot do that. I was thinking about
> subclassing a Symbol and overriding __call__ to return an applied function
> (that's where the error checking will happen, too). Another variant would be
> to give the user a function applied to native dimensions right away, and
> override __call__ in the UndefinedFunction derivative (that would make
> printing more verbose than necessary, but I can live with that). Which way do
> you think fits better in sympy design?
>
>> I think what you are doing is right, although let us know if you run into
>> issues (SymPy has many bugs where things don't work correctly if you
>> subclass things). It's clear to me that we should make this sort of thing
>> easier, though.
>
> The main problem is that I do not know which conventions should my subclassed
> objects conform to (besides the primary invariant). For instance, do I
> understand it correctly that sympy caches objects purely for performance
> reasons, and for two objects to be equal it is enough to have equal
> _hashable_content()? If I want a custom differentiation behavior (e.g.
> `f.diff(x)` equivalent to `f(x).diff(x)`), do I need to override diff(), or
> some underscored method?
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/ab71d1a9-8f3e-4006-8cbd-7632dedcb4a1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/54697D30-C37C-411A-B7C4-ABA6C0CEEA27%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Symbolic probability expression
It seems like a good idea to me. There are some identities that hold for variance and covariance independent of the probability distribution and it would be cool to be able to apply those identities symbolically. Aaron Meurer > On Dec 15, 2015, at 11:05 AM, Francesco Bonazzi > wrote: > > I started recently some work on a symbolic expression for variance and > covariance in sympy.stats module: > > https://github.com/sympy/sympy/pull/10247 > > The current stats module defines functions such as P (probability), E > (expectation), variance, covariance, moment, and so on, to perform the > integral given random variables or conditions on random variables. > > I think it's convenient to also have the possibility to operate at a higher > level of abstraction, by keeping unevaluated symbolic expressions and > operating with their properties on them. > > The idea is to define a class with the same name of the function, with > capital first letter: > Expectation( ) vs expectation( ) > Probability( ) vs probability( ) > Variance( ) vs variance( ) > ... and so on ... > The latter ones are the existing functions, whereas the first ones are > classes that create the unevaluated expression. > > > > The method .doit() calls the corresponding function to perform the integral. > > > > A similar relationship already exists in SymPy: > > Integral( ) vs integrate( ) > Derivative( ) vs diff( ) > Sum( ) vs sum( ) > .doit() calls the function. > > > > I'd like to have some feedback before going on. Do you think this is a good > idea? Would you merge this once it's finished? > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at https://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/d0dff984-3457-4e53-89ea-bb2b120beb1c%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CF242E27-9108-4E7A-B8D6-A30BFE5B6790%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Re: Windows, 0.7.6, fourier_transform error
The exe installer is built using the standard setup.py command. bdist_win32 or something like that. By the way, I forgot that Matthew Brett has a bot that should have build Windows installers for this release. I'll need to check on it and see if they work. Aaron Meurer > On Nov 26, 2014, at 3:10 PM, Colin Macdonald wrote: > >> On 24/11/14 19:45, Aaron Meurer wrote: >> Hmm, I think py2exe changes some behavior of the interpreter. I've >> seen some issues on StackOverflow in the past where it couldn't >> compile SymPy, for instance. In this case, it looks like it sets >> __doc__ on a method to be None instead of the docstring. This really >> looks like a but in py.exe or py2exe. > > Is there anything special about the sympy/ directory from the windows > .exe installer? CRLF endlines? Anything else? I ask b/c I took sympy/ > from the source .tar.gz file not the .exe installer. > > I'd like to debug a little further, then take up with the py.exe > maintainer, given that it works for Abhas Bhattacharya with py.exe (!) > > thanks, > Colin > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/54764FB8.6060401%40maths.ox.ac.uk. > For more options, visit https://groups.google.com/d/optout. > <0xC5326EE5.asc> -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3CE599D7-4049-463E-A7D1-2763C3F2790B%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [sympy] Discussion regarding the series expansion project
All I remember was that there was an introduction in another language (French possibly), and it was on a mailing list discussion with Tom. I can probably find it with a little searching when I get to my computer. Aaron Meurer Sent from my iPhone. > On Feb 26, 2014, at 6:51 PM, someone wrote: > > Hi, > >> There was some paper about computing limits with oscillating >> functions. Maybe you can find the reference if you search the mailing >> list archives (or probably Raoul will remember it). > > Let me search for it. I think I know which one you refer to. > However there was little concrete information in there: > > "Asymptotic estimation of oscillating functions using an interval calculus" > by John Shakell > > "On the computation of limsups" > by Joris van der Hoeven > > Probably the best reference to read in case we really want to go beyond what > Gruntz can do is the thesis "Automated Asymptotics" of Joris van der Hoeven. > It is very advanced on the mathematics side though. > > Let me know if you need more information. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/7BB99270-9153-4EF8-8FA3-980B3E15AC04%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Re: Issue migration from Google Code to GitHub
Yes, let's get it done. Should I freeze the google code issues? Aaron Meurer Sent from my iPhone. > On Mar 5, 2014, at 11:11 AM, Ondřej Čertík wrote: > > On Wed, Mar 5, 2014 at 10:02 AM, Sergey B Kirpichev > wrote: >> On Wed, Mar 05, 2014 at 09:20:52AM -0700, Ondřej Čertík wrote: >>> What remains to be done before we can do the migration? >> >> Decide if we want to do import "Live"-labeled issues >> to the sympylive repo. > > Either is fine with me. We are talking about 36 issues: > > http://code.google.com/p/sympy/issues/list?q=label:Live > > Is it difficult to report them against sympylive repo? > >> >> If not, we can start import right now. Script >> https://github.com/skirpichev/google-code-issues-migrator/blob/my2/exportissues.py >> do issues export in ~1/2hr. Not sure how long it's take from the github's >> support side. But >> usually they respond wery quickly. >> >> Probably, now we can shift issue numbering to 3100 (there will >> be a gap ~100 issues/pulls), something like this: >> python exportissues.py --issues-start-from=3100 \ >>--milestones-start-from=10 \ >>--issues-link=https://github.com/sympy/sympy/issues sympy > > I would migrate soon, so that we are done with it. Aaron, what do you think? > > Ondrej > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CADDwiVCw%2BskOknOcRRBuimHY6rLzjaK%2Bai%2Bqtd1ZcCoLD8U5pA%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/B1C3C795-54D3-46D3-99DC-6BE442A3A9C9%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] init_printing() in IPython Notebook should do use_latex=True
> On Mar 4, 2014, at 9:57 PM, Ondřej Čertík wrote: > >> On Tue, Mar 4, 2014 at 6:47 PM, Aaron Meurer wrote: >> You should use SymPy 0.7.5. There were some issues with >> init_printing() in recent older versions, but they should have all >> been straightened out. Don't use 0.7.2. That was released in 2012! > > That's right, I didn't realize 0.7.2 is so old... I just upgraded it > in Hashdist: Yes, and we can release a lot more often now. > > https://github.com/hashdist/hashstack/pull/135 Since hashdist builds from source couldn't this happen automatically? > > and now it works out of the box. So it was a bug in 0.7.2, that was fixed > later. I think older sympy works with older python. Newer Ipython broke it somehow. But you should always use newest versions. > >> >> The priority for init_printing() with no arguments should be >> >> - MathJax LaTeX in the notebook >> - LaTeX printing with latex itself in the qtconsole if latex is installed >> - LaTeX printing with matplotlib in the qtconsole if matplotlib is >> installed (note that this currently falls back to unicode pretty >> printing for things matplotlib can't handle, which currently includes >> matrices and lists, which print like matrices) >> - Unicode pretty printing anywhere, if Unicode support is detected >> (this detection only works in tty terminals) >> - ASCII pretty printing > > Very good, I agree with this order. > >> >> See >> http://docs.sympy.org/latest/tutorial/printing.html#setting-up-pretty-printing >> for pictures. > > Yes, nice. > >> >> You can pass in arguments to init_printing to override any of these >> (see the docstring). > > Yes, that works even in 0.7.2. There are new arguments in the newer versions to specify exact things, like matplotlib or png. > > Thanks for your help! > > Ondrej > >> >> Aaron Meurer >> >>> On Tue, Mar 4, 2014 at 3:44 PM, Ondřej Čertík >>> wrote: >>> Thanks for this. For me it sometimes works and sometimes it doesn't, >>> and I haven't quite nailed it out yet, >>> whether it depends on IPython version, or SymPy version or what. I use: >>> >>> IPython 1.1.0 >>> SymPy 0.7.2 >>> >>> Ondrej >>> On Tue, Mar 4, 2014 at 2:19 PM, Jason Moore wrote: Attachment from master. Jason moorepants.info +01 530-601-9791 > On Tue, Mar 4, 2014 at 4:14 PM, Jason Moore wrote: > > I don't have this same issue. I use init_printing() and get LaTeX by > default in IPython. > > > Jason > moorepants.info > +01 530-601-9791 > > > On Tue, Mar 4, 2014 at 4:08 PM, Ondřej Čertík > wrote: >> >> Hi, >> >> It used to be the case, that I just did: >> >> init_printing() >> >> in IPython Notebook and it initialized the Latex (mathjax) printing by >> default. >> Now when I do init_printing(), it uses unicode ascii art printing >> instead. I have to do: >> >> init_printing(use_latex=True) >> >> only then it starts using Latex printing. That's quite annoying to >> always type this by hand. >> >> Is there any reason not to make init_printing() to always use >> use_latex=True in IPython notebook? >> >> Ondrej >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sympy+unsubscr...@googlegroups.com. >> To post to this group, send email to sympy@googlegroups.com. >> Visit this group at http://groups.google.com/group/sympy. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CADDwiVC5F1u4oGVs0r%2B3ds_tFGQf3hHXHCxUFVR%2BtTR6Br1tvg%40mail.gmail.com. >> For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AiXgai8bbEHhEPq1GNANQqwZG4bJjHD-ptnbWhFpnu4gg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to sympy+unsubscr...@googlegroups.com. >>> To post to this group, send email to sympy@googlegroups.com. >>> Visit this group at http://groups.google.com/group/sympy. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CADDwiVCu3dBCiTMCBoRbzNjPGhP0QWPvxn4skx5TBo
Re: [sympy] Re: Happy Holidays !!!!!
Merry Christmas to all. I added a little surprise to the website, courtesy of Anna Bujak (one of our GCI students). 🎄🎁 Aaron Meurer > On Dec 24, 2013, at 10:58 PM, Manoj Kumar > wrote: > > Thanks and Happy Hoildays to everyone :) > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Re: 2to3 script appears to be missing a conversion
docscrape currently only works in python 2. We need to backport the python 3 version. The compatibility one is probably not an issue. The rest likely are. By the way, running pyflakes in python 3 and looking for undefined variables might uncover more of these issues. Aaron Meurer Sent from my iPhone. > On Nov 25, 2013, at 9:31 AM, Chris Smith wrote: > > OK, we don't use 2to3...but there are several uses of iteritems still in the > codebase. These must be uncovered lines which don't cause anybody trouble if > they aren't running in 3. We should clean them up, though, shouldn't we? > > C:\Users\chris.smith\sympy\doc\ext\docscrape.py (1 hits) > Line 379: for section, references in idx.iteritems(): > C:\Users\chris.smith\sympy\doc\ext\docscrape_sphinx.py (1 hits) > Line 138: for section, references in idx.iteritems(): > C:\Users\chris.smith\sympy\sympy\core\compatibility.py (1 hits) > Line 542: return 1 + sum(_nodes(k) + _nodes(v) for k, v in > e.iteritems()) > C:\Users\chris.smith\sympy\sympy\functions\elementary\trigonometric.py (1 > hits) > Line 585: a = [n//x**y for x, y in > factorint(r.q).iteritems()] > C:\Users\chris.smith\sympy\sympy\polys\polycontext.py (1 hits) > Line 43: [ '%s=%r' % (key, value) for key, value in > self.__options__.iteritems() ]) > > In this file, a workaround is given by not using the attribute, but bu > defining a 2x or 3x compatible function, `iteritems`: > C:\Users\chris.smith\sympy\sympy\mpmath\calculus\differentiation.py (7 hits) > Line 5: iteritems = dict.iteritems > Line 7: iteritems = dict.items > Line 372: R = dict((c+(0,),v) for (c,v) in iteritems(R)) > Line 374: for powers, count in iteritems(R): > Line 380: for powers, count in iteritems(R): > Line 443: for powers, c in iteritems(dpoly(i)): > > I'll post this as an issue that can be closed if I am wrong about the need to > eliminate this. > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] ODE code generation
Assumedly if it doesn't, then you would be able to tell just by applying the sympy cse and seeing if it makes a significant difference in the run time. Aaron Meurer > On Nov 5, 2013, at 6:45 PM, Matthew Rocklin wrote: > > Sadly I'm not an expert in C compilers and I no longer have an awesome > compilers-post-doc-office-mate. I don't know what they'll do in this > situation. His no-CSE statement would still hold if the input pointers point > to dynamically allocated memory. I don't recall what he said if they point > to statically allocated memory; I think it was a big nebulous "it depends." > > >> On Tue, Nov 5, 2013 at 5:35 PM, Jason Moore wrote: >> Got it. >> >> SymPy's code generators in codegen and autowrap don't support evaluating a >> SymPy matrix as the expression. I'd like to improve those so that you can >> pass in a sequences of Matrices and it returns a function that evaluates all >> of the matrices in a single C/Fortran/etc file. >> >> Here is a simple example of the c file I'm generating from two SymPy >> matrices: >> https://github.com/PythonDynamics/pydy-code-gen/blob/master/pydy_code_gen/tests/expected_cython/desired_mass_forcing_c.c >> >> >> Jason >> moorepants.info >> +01 530-601-9791 >> >> >>> On Tue, Nov 5, 2013 at 5:41 PM, Matthew Rocklin wrote: >>> My previous statement was that Theano won over autowrap.ufuncify because >>> theano did CSE internally (theano's basic data structure is a DAG). >>> >>> My understanding is that your C friend is correct IF the code is written in >>> the standard way, declaring each variable individually. I remember looking >>> at older code of your groups in which all of the variables were stored in a >>> dynamically allocated array. My C friend mentioned that most compilers >>> won't dare touch such a structure because it's verify that transformations >>> are safe. I have no idea what your various code generators are doing under >>> the hood. >>> >>> By the way I did not intend to raise the issue of CSE. I'm mostly curious >>> about the poor performance of Theano and I don't think this is that issue. >>> >>> On Tue, Nov 5, 2013 at 10:48 AM, Aaron Meurer wrote: I would still benchmark running cse and not. If cse() is fast enough, it might out-balance the overhead of the code generation, especially if it significantly reduces the resulting code size. Aaron Meurer On Tue, Nov 5, 2013 at 11:36 AM, Jason Moore wrote: > My roommate who's a C guy suggested that CSE was a waste of time if you > have > a good compiler. He claimed that the compiler will do CSE anyways, so > doing > it in the C code was not useful. I need to compare my Cython code output > with and without CSE (it currently uses CSE). > > How would I use CSE with theano_function? I'm not doing that currently > and > it wasn't apparent to me how to go about that. > > > Jason > moorepants.info > +01 530-601-9791 > > > On Tue, Nov 5, 2013 at 1:30 PM, Matthew Rocklin > wrote: >> >> In my experiments with sympy-theano earlier this year I found that it >> was >> competitive with our Fortran code generation (autowrap.ufuncify) on >> single >> array outputs and outperformed it when CSE were involved. I don't have >> anything recorded that profiles scalar operations. >> >> Frederic might have some intuition on Theano's performance on large >> scalar >> computations. I've brought this up in the past and don't actually >> remember >> the answer. >> >> >> On Tue, Nov 5, 2013 at 9:51 AM, Jason Moore >> wrote: >>> >>> Ok, so I think I'm comparing things correctly then. It is surprising >>> that >>> the compiled Theano code doesn't seem to execute that fast. The >>> functions >>> I'm generating are essentially evaluating very long sympy expressions, >>> maybe >>> Theano isn't great at that... >>> >>> >>> Jason >>> moorepants.info >>> +01 530-601-9791 >>> >>> >>> On Tue, Nov 5, 2013 at 12:48 PM, Matthew Rocklin >>> wrote: `sympy.printing.theanocode.theano_function` calls `theano.function` The result of `theano_function` is a compiled theano function. On Tue, Nov 5, 2013 at 9:27 AM, Jason Moore wrote: > > > > > Jason > moorepants.info > +01 530-601-9791 > > > On Tue, Nov 5, 2013 at 8:46 AM, Frédéric Bastien > wrote: >> >> Hi, >> >> Just to know, witch version of Theano did you used? I have speed up >> a >> little the optimization phase of the compilation and I have a PR >> that >> will optimi
Re: [sympy] default_sort_key does not always reproduce behavior of sort()
I don't think the key makes any guarantees, other than that the prefer will be
platform and python version independent. It also should be very hard to produce
two different objects with the same key.
It was probably originally designed to give the same ordering to reduce the
pain of transition, but I don't see any reason why it should stay that way
forever.
Aaron Meurer
Sent from my iPhone.
> On Oct 2, 2013, at 2:53 PM, Matthew Brett wrote:
>
> Hi,
>
> I just noticed this:
>
> In [38]: a = sympy.Symbol('a')
>
> In [39]: b = sympy.Dummy('b')
>
> In [40]: sorted([a, b])
> Out[40]: [a, _b]
>
> In [41]: sorted([a, b], key=sympy.default_sort_key)
> Out[41]: [_b, a]
>
> for sympy versions 0.7.0 through 0.7.3. Sorting without a key raises
> an error for current trunk.
>
> Is the difference between 'sort' and 'sort(key=default_sort_key)' intended?
>
> I guess, now sympy raises an error without a key, there isn't much to
> do, but maybe the change is worth recording, even if only in this
> email.
>
> Thanks,
>
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sympy] Graph thoery in sympy
During some of the discussions from GSoC, we decided that reimplementing one of the dozen of graph theory modules (including networkx) in SymPy would be a waste of time. However, if the graph theory were done in a symbolic way, so that it would really require SymPy to be implemented, then I think that would be something that could be implemented in SymPy. Aaron Meurer On Jun 22, 2011, at 1:41 PM, David Joyner wrote: > On Wed, Jun 22, 2011 at 12:48 PM, Sam Magura wrote: >> Hi everyone, >> >> Are there any plans to include graph theory in future versions of >> sympy? > > > Graph theory in sympy would be nice but are you aware of networkx? > In any case, I recommend you ask Dima Pasechnik for his > opinion on implementation any isomorphism algorithms. I am > cc'ing him since I don't think he is on this list. > > >> >> The reason I ask is I've found the need to test graph isomorphism in a >> research project I'm working on. Specifically, I am looking at this >> algorithm: http://www.dharwadker.org/tevet/isomorphism/ I am >> considering implementing the algorithm in Python, rather than using >> the C++ version provided by the paper. Is this something I could >> contribute to sympy? I'd also be willing to work on adding other >> algorithms and graph visualization features to sympy in the future. >> >> Thanks, >> Sam Magura >> >> -- >> 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] Test failure in 0.7.0 pysics.quantum.matrixcache
On Jun 22, 2011, at 8:51 AM, Ondrej Certik wrote:
> On Wed, Jun 22, 2011 at 12:09 AM, Aaron Meurer wrote:
>> So far, I've coded up an import_module function, that wraps the try,
>> except ImportError logic into a single unified function. It has
>> support for checking the module version and the Python version and
>> returning None if they are too old, even if the module is installed,
>> and it also supports raising warnings when the module cannot be used.
>> You can see the code at
>> https://github.com/asmeurer/sympy/tree/external.
>>
>> I've yet to apply this everywhere in SymPy (I will do it tomorrow). I
>> still need to decide if it will be good enough to use
>> import_module('numpy', min_python_version=(2, 6)) everywhere in the
>> quantum module, or if I should centralize numpy importing in that
>> module even further.
>>
>> But it should a *lot* less code, i.e., instead of
>>
>> import sys
>> import warnings
>>
>> try:
>>if sys.version_info < (2, 6):
>>warnings.warn("Python version too old to use numpy")
>>raise ImportError
>>import numpy
>> except ImportError:
>>
>>
>> in every single quantum file that uses numpy (including the tests), we
>> would just have
>>
>> from sympy.external import import_module
>> numpy = import_module('numpy', min_python_version=(2, 6))
>> if not numpy:
>>
>>
>> Aaron Meurer
>>
>> On Mon, Jun 20, 2011 at 6:11 PM, Aaron Meurer wrote:
>>> It should at least be in a separate file for the quantum code. I
>>> didn't consider to make one file for it for all of SymPy. I'm waiting
>>> to see what Brian Granger thinks, since he knows the most about the
>>> quantum module.
>
> So numpy is optionally imported in the quantum module, and sympy fails
> to import with a particular version of numpy and python2.5?
>
> If it's just a test failure on a particular combination of
> numpy/python and it's not easy for us to fix currently, I would just
> document it in the release notes and release.
>
> Ondřej
The problem is that it's more than a test failure. Importing the quantum
module fails, which kills the test runner completely. So actually, it's not
really correct that numpy is optionally imported. If it's installed, it's
always imported and used.
And it's not too hard to fix. We just need to disable numpy in the quantum
code in Python 2.4/2.5. I wrote this helper function to make it easier to do
this.
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.
Re: [sympy] Test failure in 0.7.0 pysics.quantum.matrixcache
On Jun 22, 2011, at 6:55 AM, Ted Horst wrote:
> Seem like it would be more consistent to raise an ImportError rather than
> return None. That would also mean less change to existing code.
That would defeat the whole purpose of the function, except when we need to
check for versions or you want to emit a warning. Remember that this is for
*optional* dependencies, so it will always be used in the case where we catch
the ImportError and do some handling.
> Thinking a bit further, could this be done in an import hook (I haven't done
> one myself, so not sure)?
I've never heard of those. I'll check it out and see if it's any better.
Aaron Meurer
>
> Ted
>
> On 2011-06-22, at 02:09, Aaron Meurer wrote:
>
>> So far, I've coded up an import_module function, that wraps the try,
>> except ImportError logic into a single unified function. It has
>> support for checking the module version and the Python version and
>> returning None if they are too old, even if the module is installed,
>> and it also supports raising warnings when the module cannot be used.
>> You can see the code at
>> https://github.com/asmeurer/sympy/tree/external.
>>
>> I've yet to apply this everywhere in SymPy (I will do it tomorrow). I
>> still need to decide if it will be good enough to use
>> import_module('numpy', min_python_version=(2, 6)) everywhere in the
>> quantum module, or if I should centralize numpy importing in that
>> module even further.
>>
>> But it should a *lot* less code, i.e., instead of
>>
>> import sys
>> import warnings
>>
>> try:
>> if sys.version_info < (2, 6):
>> warnings.warn("Python version too old to use numpy")
>> raise ImportError
>> import numpy
>> except ImportError:
>>
>>
>> in every single quantum file that uses numpy (including the tests), we
>> would just have
>>
>> from sympy.external import import_module
>> numpy = import_module('numpy', min_python_version=(2, 6))
>> if not numpy:
>>
>>
>> Aaron Meurer
>>
>> On Mon, Jun 20, 2011 at 6:11 PM, Aaron Meurer wrote:
>>> It should at least be in a separate file for the quantum code. I
>>> didn't consider to make one file for it for all of SymPy. I'm waiting
>>> to see what Brian Granger thinks, since he knows the most about the
>>> quantum module.
>>>
>>> Aaron Meurer
>>>
>>> On Mon, Jun 20, 2011 at 6:06 PM, Ted Horst wrote:
Thanks for investigating, Aaron. Maybe numpy importing should be pulled
out
into its own module. This would probably be necessary anyway if someone
implements the "numpy array for sympy" idea that was talked about a while
back.
Ted
On 2011-06-20, at 00:42, Aaron Meurer wrote:
> The way the quantum code is written, it's not very easy to disable
> numpy globally. I could do it, but it would require copying the same
> four lines checking the system version and emitting a warning in the
> half dozen files that import numpy.
>
> So, to fix this right, I need advice from Brian and others who know
> the quantum code. Where would be the best place to put some kind of
> global parameter defining if numpy is supported for the quantum code
> (similar to what the polys use for gmpy)?
>
> Aaron Meurer
>
> On Sun, Jun 19, 2011 at 8:38 PM, Aaron Meurer wrote:
>>
>> OK, this is definitely a bug in numpy (or Python). I created a file
>> numpyfloattest.py with the following contents:
>>
>> import numpy
>>
>> class A(object):
>> def __float__(self):
>> return 2.0
>> def __complex__(self):
>> return 5.0j
>>
>> a = A()
>>
>> print numpy.matrix([[a]], dtype='complex')
>>
>> And ran:
>>
>> Aaron-Meurer:sympy aaronmeurer(0.7.0$%)$python2.5 numpyfloattest.py
>> [[ 2.+0.j]]
>> Aaron-Meurer:sympy aaronmeurer(0.7.0$%)$python2.7 numpyfloattest.py
>> [[ 0.+5.j]]
>>
>> So for some reason, in Python 2.5, it runs complex(float()) on the
>> data. Of course, this doesn't work very well if the numbers are
>> complex, like sympy.I.
>>
>> I have created http://projects.scipy.org/numpy/ticket/1872 for this.
>> In the meanwhile, I will just disable numpy in the quantum code in
>> Python 2.5.
>>
>> Aaron Meurer
>>
>> On Sun, Jun 19, 2011 at 8:04 PM, Aaron Meurer wrote:
>>>
>>> I think I have a lead. In numpy 1.6, this instead gives
>>>
>> numpy.matrix([[0, I]], dtype='complex')
>>>
>>> Traceback (most recent call last):
>>> File "", line 1, in
>>> File
>>> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/matrixlib/defmatrix.py",
>>> line 257, in __new__
>>> arr = N.array(data, dtype=dtype, copy=copy)
>>> File "sympy/core/expr.py", line 129, in __float__
>>> raise ValueError("Symbolic value, can't compute")
>>> ValueError: Symbolic value, can't compute
>
Re: [sympy] Perpendicular distance from Point to Line
I think he was not using the git version at all. To get those features Chris mentioned, you need to use the development version, or else use the 0.7.0 version that will be coming out in a few days. Aaron Meurer On Jun 22, 2011, at 5:57 AM, Chris Smith wrote: > Sometimes you have two sympy installations, e.g. one in site-packages and one > somewhere else. Figuring out which one is getting used is the trick. I > haven't really spent the time to figure out how to get my IDE to use the one > that is in my git directory. I just know what I have to do to use the git one > to work. Others may be of more help. > > I see that you found Rational(str(...)) to work. That's good, too. If you > ever get nsimplify or S to work they are good for situations where the Float > is buried in an expression. But your application can easily target the Float > so Rational works more directly. > > Glad it's working. One thing I like about python is the way you can write an > adapting function so easily (as you have done) to deal with a new situation. > > Best regards, > Chris > > -- > 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] SymPy simplification. Distinct simplifications for group, ring, field, reals etc?
Hi.
I'm not sure if it will be the same as how you envision this to work, but these
are all supported in SymPy:
In [7]: a, b = symbols('a b', commutative=False)
In [8]: a*b - b*a
Out[8]: a⋅b - b⋅a
Note the symbols are complex by default.
In [9]: x = Symbol('x')
In [10]: sqrt(x**2)
Out[10]:
╱ 2
╲╱ x
In [11]: x = Symbol('x', positive=True)
In [12]: sqrt(x**2)
Out[12]: x
There's a fairly complete list of simplification functions at
http://docs.sympy.org/dev/modules/simplify.html.
Aaron Meurer
On Jun 17, 2011, at 9:23 AM, Yrogirg wrote:
> Hello! I don't know python and sympy, I'm justing trying to figure out
> whether sympy fits my needs.
>
> So, my question is, what are the rules applied by various
> simplification algorithms (or other algorithms of that kind) ? Are
> there distinct simplification rules for expressions meant to represent
> elements from non-commutative ring, field, real numbers or other
> structures?
>
> For example if I want to simplify an expression for non-commutative
> ring simplification should not use a*b = b*a rule.
>
> Is there anywhere a list of rules applied by various simplification
> functions?
>
> --
> 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] Poly*Expr
By the way, I forgot to mention that I think it would be better to just support negative exponents directly in Poly rather than creating a LaurentPoly class. At the very least, Poly shouldn't pretend it is doing Laurent polynomials (like with Poly(x + 1/x)) when it really isn't. Aaron Meurer On Jun 16, 2011, at 6:19 PM, Aaron S. Meurer wrote: > Well, the thing that bugs me the most is that you can do the same things with > what would appear to be rational functions: > > In [7]: Poly(1/x) > Out[7]: Poly(1/x, 1/x, domain='ZZ') > > In [8]: Poly(1/x)*x > Out[8]: Poly(x*1/x, 1/x, domain='ZZ[x]') > > In [9]: Poly(1/x)*x - 1 > Out[9]: Poly(x*1/x - 1, 1/x, domain='ZZ[x]') > > In [10]: (Poly(1/x)*x - 1).is_zero > Out[10]: False > > This was the original problem in issue 2032. > > On Jun 16, 2011, at 2:51 PM, Mateusz Paprocki wrote: > >> Hi, >> >> On 16 June 2011 13:28, Aaron Meurer wrote: >> This is related to >> http://code.google.com/p/sympy/issues/detail?id=2032. The polys >> pretend that they can work in K[x, 1/x], but they actually do not >> implement things properly, which can lead to wrong results: >> >> In [3]: Poly(exp(-x)) >> Out[3]: Poly(exp(-x), exp(-x), domain='ZZ') >> >> In [4]: Poly(exp(-x))*exp(x) >> Out[4]: Poly(exp(x)*exp(-x), exp(-x), domain='ZZ[exp(x)]') >> >> In [5]: Poly(exp(-x))*exp(x) - 1 >> Out[5]: Poly(exp(x)*exp(-x) - 1, exp(-x), domain='ZZ[exp(x)]') >> >> In [6]: (Poly(exp(-x))*exp(x) - 1).is_zero >> Out[6]: False >> >> And I could go further, as an incorrect is_zero result can easily be >> exacerbated to larger wrong results, but you get the idea. >> >> Result [6] is actually a valid result, because generators of polynomial >> expressions are assumed to be algebraically independent, so in [6] you can >> write (Poly(u)*v - 1).is_zero (which of course is False) as well. If you >> want [6] to give True, then you would have to imply an algebraic relation >> between exp(-x) and exp(x) (really u and v). A reasonable solution I see to >> this problem is to implement LaurentPoly which would allow negative >> exponents, which in turn would mean that exp(-x) and exp(x) would result in >> the same generator, with exponent -1 and 1 respectively. >> Another solution would be to add postprocessor to Poly, which would apply >> known algebraic relations of generators, after performing the main >> computation. > > This is a great idea. You see, there is actually a complete algorithm to > find algebraic relations on elementary functions, called the Risch structure > theorems. > > The transcendental Risch algorithm requires that each elementary extension be > transcendental over the others, or else certain results (namely nonelementary > results) will not be correct. The algorithm not only determines if a function > is transcendental over a differential extension, but provides the algebraic > relation when it is not. > > So it was necessary to implement this algorithm. So far, only the algorithm > for exponentials and logarithms has been implemented, but there is also an > algorithm for tangents, arctangents, and nonelementary extensions (functions > defined in terms of a nonelementary integral of a transcendental function, > like erf()). You can handle cosine and sine by first converting them to > tangents. > > If you want to play around with this, the easiest way is to import > DifferentialExtension from sympy.integrals.risch in my integration3 branch > and create a differential extension out of the expression. For example, you > can see it handles the above example with ease > > In [1]: from sympy.integrals.risch import DifferentialExtension > > In [2]: DifferentialExtension(exp(x) + exp(-x), x) > Out[2]: (Poly(_t0**2 + 1, _t0, domain='ZZ'), Poly(_t0, _t0, domain='ZZ'), > [Poly(1, x, domain='ZZ'), Poly(_t0, _t0, domain='ZZ')], [x, _t0], [Lambda(_i, > exp(_i))], [], [1], [x], [], []) > > The output consists of a lot of stuff, but the main thing is that the first > two Polys are the numerator and denominator of the resulting expression, and > the list of Lambdas near the end gives the function definition of t0, t1, t2, > etc. So in this case, we see that it has rewritten exp(x) + exp(-x) as > (exp(x)**2 + 1)/(exp(x)). Note that I have implemented heuristics to take > the exponentials in such a way to avoid algebraic relations, like > > In [3]: DifferentialExtension(exp(x) + exp(x/2) + exp(2*x), x) > Out[3]: (Poly(_t0**4 + _t0**2 + _t0, _t0, domai
Re: [sympy] Problem with evaluating rotation operator
On Jun 16, 2011, at 11:17 PM, Ondrej Certik wrote:
> On Thu, Jun 16, 2011 at 10:06 PM, Aaron Meurer wrote:
>> On Thu, Jun 16, 2011 at 11:00 PM, Ondrej Certik
>> wrote:
>>> On Thu, Jun 16, 2011 at 8:34 PM, Ondrej Certik
>>> wrote:
On Thu, Jun 16, 2011 at 6:38 PM, Ondrej Certik
wrote:
> On Thu, Jun 16, 2011 at 12:04 AM, Sean Vig wrote:
>> Hi all,
>> In working on some stuff with spin states, I ran into some problems with
>> the
>> current implementation of the Wigner small-d matrix, Rotation.d in
>> sympy.physics.quantum.spin. I had written methods to change bases using
>> the
>> Wigner D-function [0] and in testing decided to try
> qapply(JzBra(1,1)*JzKet(1,1).rewrite('Jx'))
>> which should be 1, as the spin ket is rewritten in the Jx basis and then
>> back to the Jz basis to apply the innerproduct, but I have that it gives
>> 0.
>> I traced this back to a bug in the Rotation.d function, which currently
>> has
>> an open issue [1]. For the Wigner D-function and the small d-matrix, the
>> conventions laid out in Varshalovich "Quantum Theory of Angular
>> Momentum".
>> It seems the d-matrix is fine for positive values of angle argument, but
>> does not obey the symmetry d(j,m,mp,-beta)=(-1)**(m-mp)*d(j,m,mp,beta)
>> and
>> does not agree with the tables in Varshalovich. Those terms that fail for
>> the j=1 case are in an XFAIL test in my branch. What is odd is that when
>> I
>
>
> I think there is a bug in the code. See my comment here:
>
> http://code.google.com/p/sympy/issues/detail?id=2423#c3
>
> The correct results for general beta are:
>
> d(1, 0, 1, beta) = sin(beta)/sqrt(2)
> d(1, 1, 0, beta) = -sin(beta)/sqrt(2)
>
> However, sympy gives:
>
Rotation.d(1,0,1,beta)
> ⎽⎽⎽
> ╲╱ 2 ⋅(2⋅cos(β) + 2)
>
> 4
Rotation.d(1,1,0,beta)
> ⎽⎽⎽
> -╲╱ 2 ⋅(cos(β) + 1)
> ───
> 2
>
> Which is wrong (it looks quite ok, that it changes sign, as it should,
> but something is wrong with the cos(beta) thing). The sympy code
> implements the "Eq. 7 in Section 4.3.2 of Varshalovich."
>
>
>> ran the equation used to define the d-matrix through Mathematica, I got
>> results that agreed with the sympy output, so the problem may be in the
>> equation and not a bug in the code. If anyone could take a look at that,
>> I'd
>> appreciate it.
>
> Which *exact* equation did you run through Mathematica? Eq. 7 in
> section 4.3.2? What *exactly* did you get? Did you get an expression
> involving cos(beta), just like sympy above? Can you paste here the
> Mathematica code? I'll run it with my Mathematica, to verify, that we
> didn't make a mistake.
>
>
> Now we just need to systematically look at it, and nail it down. We
> need to get the correct expressions:
>
> d(1, 0, 1, beta) = sin(beta)/sqrt(2)
> d(1, 1, 0, beta) = -sin(beta)/sqrt(2)
>
> one way or the other, for general beta. Then things will start to work.
>
> Sean, let me know if you have any questions to the above.
>
> Once we fix this, we'll move on to the other problems you raised.
>
> I am CCing Brian, who implemented that code in SymPy. However, we
> should be able to fix this ourselves Sean all we need to do is to
> take the eq. (7), and see what expression we get for J=1, M=1, M'=0,
> just put it there by hand (don't use mathematica) and see what you
> get.
>
> Post here your results, and I'll verify them with my independent
> calculation and we'll nail it down.
Ok, I think that I have nailed it down. There are actually several
problems:
1) First of all, this is the range for beta:
0 <= beta <= pi
see Varshalovich, page 74.
2) See the attached screenshot of my calculation, which calculates
d(j, 0, 1, beta) from the equation (7) on page 75, and shows, that it
is equal to
sin(beta)/sqrt(2), consistent with Varshalovich result in the table 4.4.
As such, from 2) it follows, that the sympy result (see my previous
email) is *wrong*, as can be checked by substituting beta = pi/3 and
checking against sin(beta)/sqrt(2). For beta=pi/2, it happens to be
equal, but that is pure accident.
From 1) it follows, that you can't call it for beta=-pi/2, you need to
adjust alpha and gamma instead.
>>>
>>> Actually, I wasn't very clear here. You use the formula (7) to
>>> calculate the wigner d function for *any* J, M, M', for 0<=beta<=pi.
>>> In particular, you get the formulas:
>>>
>>> d(1, 1, 0, beta) = -sin(beta)/sqrt(2)
>>> d(1, 0, 1, beta) = +sin(beta)/sqrt(2)
>>>
>>> And I am stressing here that this is *only* valid f
Re: [sympy] Poly*Expr
Well, the thing that bugs me the most is that you can do the same things with what would appear to be rational functions: In [7]: Poly(1/x) Out[7]: Poly(1/x, 1/x, domain='ZZ') In [8]: Poly(1/x)*x Out[8]: Poly(x*1/x, 1/x, domain='ZZ[x]') In [9]: Poly(1/x)*x - 1 Out[9]: Poly(x*1/x - 1, 1/x, domain='ZZ[x]') In [10]: (Poly(1/x)*x - 1).is_zero Out[10]: False This was the original problem in issue 2032. On Jun 16, 2011, at 2:51 PM, Mateusz Paprocki wrote: > Hi, > > On 16 June 2011 13:28, Aaron Meurer wrote: > This is related to > http://code.google.com/p/sympy/issues/detail?id=2032. The polys > pretend that they can work in K[x, 1/x], but they actually do not > implement things properly, which can lead to wrong results: > > In [3]: Poly(exp(-x)) > Out[3]: Poly(exp(-x), exp(-x), domain='ZZ') > > In [4]: Poly(exp(-x))*exp(x) > Out[4]: Poly(exp(x)*exp(-x), exp(-x), domain='ZZ[exp(x)]') > > In [5]: Poly(exp(-x))*exp(x) - 1 > Out[5]: Poly(exp(x)*exp(-x) - 1, exp(-x), domain='ZZ[exp(x)]') > > In [6]: (Poly(exp(-x))*exp(x) - 1).is_zero > Out[6]: False > > And I could go further, as an incorrect is_zero result can easily be > exacerbated to larger wrong results, but you get the idea. > > Result [6] is actually a valid result, because generators of polynomial > expressions are assumed to be algebraically independent, so in [6] you can > write (Poly(u)*v - 1).is_zero (which of course is False) as well. If you want > [6] to give True, then you would have to imply an algebraic relation between > exp(-x) and exp(x) (really u and v). A reasonable solution I see to this > problem is to implement LaurentPoly which would allow negative exponents, > which in turn would mean that exp(-x) and exp(x) would result in the same > generator, with exponent -1 and 1 respectively. > Another solution would be to add postprocessor to Poly, which would apply > known algebraic relations of generators, after performing the main > computation. This is a great idea. You see, there is actually a complete algorithm to find algebraic relations on elementary functions, called the Risch structure theorems. The transcendental Risch algorithm requires that each elementary extension be transcendental over the others, or else certain results (namely nonelementary results) will not be correct. The algorithm not only determines if a function is transcendental over a differential extension, but provides the algebraic relation when it is not. So it was necessary to implement this algorithm. So far, only the algorithm for exponentials and logarithms has been implemented, but there is also an algorithm for tangents, arctangents, and nonelementary extensions (functions defined in terms of a nonelementary integral of a transcendental function, like erf()). You can handle cosine and sine by first converting them to tangents. If you want to play around with this, the easiest way is to import DifferentialExtension from sympy.integrals.risch in my integration3 branch and create a differential extension out of the expression. For example, you can see it handles the above example with ease In [1]: from sympy.integrals.risch import DifferentialExtension In [2]: DifferentialExtension(exp(x) + exp(-x), x) Out[2]: (Poly(_t0**2 + 1, _t0, domain='ZZ'), Poly(_t0, _t0, domain='ZZ'), [Poly(1, x, domain='ZZ'), Poly(_t0, _t0, domain='ZZ')], [x, _t0], [Lambda(_i, exp(_i))], [], [1], [x], [], []) The output consists of a lot of stuff, but the main thing is that the first two Polys are the numerator and denominator of the resulting expression, and the list of Lambdas near the end gives the function definition of t0, t1, t2, etc. So in this case, we see that it has rewritten exp(x) + exp(-x) as (exp(x)**2 + 1)/(exp(x)). Note that I have implemented heuristics to take the exponentials in such a way to avoid algebraic relations, like In [3]: DifferentialExtension(exp(x) + exp(x/2) + exp(2*x), x) Out[3]: (Poly(_t0**4 + _t0**2 + _t0, _t0, domain='ZZ'), Poly(1, _t0, domain='ZZ'), [Poly(1, x, domain='ZZ'), Poly(1/2*_t0, _t0, domain='QQ')], [x, _t0], [Lambda(_i, exp(_i/2))], [], [1], [x/2], [], []) Notice that t0 is exp(x/2). If we had made t0 exp(x), then exp(x/2) would have been sqrt(t0), which is no good for the Risch algorithm (and also in the polys), because we can't handle algebraic relations yet. Note that the algorithms here are very powerful, and can handle much more nontrivial cases than any heuristic would In [4]: DifferentialExtension(log(exp(x) + 1) + log(exp(-x) + 1), x) Out[4]: (Poly(2*_t1 - x, _t1, domain='ZZ[x]'), Poly(1, _t1, domain='ZZ'), [Poly(1, x, domain='ZZ'), Poly(_t0, _t0, domain='ZZ'), Poly(_t0/(1 + _t0), _t1, domain='ZZ(_t0)')], [x, _t0, _t1], [Lambda(_i, exp(_i) ), Lambda(_i, log(1 + _t0))], [], [1], [x], [2], [1 + _t0]) (rewrote log(exp(x) + 1) + log(exp(-x) + 1) as 2*log(exp(x) + 1) - x. The nature of the algorithms is to always rewrite the expression in terms of some part of the res
Re: [sympy] Possible Code Sprint Next Week?
Sorting by the number of comments does't seem to be implemented, so I created http://code.google.com/p/support/issues/detail?id=5446. Aaron Meurer On Jun 14, 2011, at 12:58 AM, Aaron Meurer wrote: > This already exists. The star is a way for users to vote for issues. > The issue tracker is set to sort issues by milestone, then priority, > then number of stars, so the default order you see at > http://code.google.com/p/sympy/issues/list is roughly the order of > priority. I didn't think of including discussion count as a tie > braker. I'll see if I can add that, so it would be milestone, then > priority, then stars, then number of comments, then issue id. > > And by the way, if you have the ability to edit labels, feel free to > up the priority of an issue. > > Aaron Meurer > > On Tue, Jun 14, 2011 at 12:53 AM, Chris Smith wrote: >> It might be a nice thing if issues could be ranked by how "liked" they are. >> Those that have a lot of discussion or are starred by many people might be >> indicative of fruitful issues to resolve...or vice versa since the more >> discussed an issue is, the more controversial it may be. >> Alternatively, it might be nice if there were some way to vote for issues >> that we most want resolved. >> >> -- >> 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] Possible Code Sprint Next Week?
I think SymPy fits this need. It only really requires git and Python to develop in (though depending on what you are doing, you may need other tools as well). And since it is written in Python, the deveopment turnover time is fast, meaning that you can get a lot done in a sprint. Our issue tracker is at http://code.google.com/p/sympy/issues/list and we have tagged some issues as "easy to fix" http://code.google.com/p/sympy/issues/list?q=label:EasyToFix. Of course, we're also open to more ambitious contributions, like implementing new features. We also have a ton of documentation that could be written or improved, which requires little to no programming experience. Aaron Meurer On Jun 13, 2011, at 7:56 PM, David Shein wrote: > Greetings, > My name is Dave Shein, and I'm an Adjunct Faculty at Rochester Institute of > Technology. Along with Chris Tyler of Seneca College, we are hosting a week > long POSSE boot-camp at the RIT campus from June 20th -24th. POSSE, sponsored > by Red Hat, is a week long educational hand-on seminar in open source > process, collaboration, and education. The central purpose of POSSE is to > increase awareness and opportunities for Open Source participation in the > university setting. All of POSSE participants are university staff or faculty > who will take what they learn in POSSE and use that knowledge in CS and > related curricula, to spread the word about open source collaboration, and to > provide increased educational opportunities for CS related students. Our > first two days are spent acclimating our participants to tools and resources > of the open source community, but on the third and fourth day of POSSE we > will have our participants do a code-sprint. We are looking for opportunities > in existing open source projects which have a quick learning curve and setup > time for folks with a CS background but who in most cases will not have a > great depth of experience working in open source languages. We are > particularly interested in having our participants hack on Fedora based > projects. The students will have a Fedora F14 & F15/Linux work environment > setup as part of their initial orientation, and we are looking for projects > that will not have lengthy setup beyond the participants' initial setup. > We obtained information about your open source project through OpenHatch, and > would like to know if your project would have elements that would be amenable > to our sprint. There will be approximately fifteen to twenty participants > working on the sprint in teams of 3 to 5 people each, of whom most are > coders. IN ADDITION we are also looking for a project participation > opportunity for 3 to 4 non-coders, possibly in the form of testing, > copywriting, or editing work. Ideally we would also like to coordinate with a > point-person in your organization during the period of the sprint, a person > to whom participants could direct questions, perhaps via IRC in real time. > If this is of interest to you please contact me at your earliest convenience. > I hope that we can work together soon. > David Malcom Shein > Rochester Institute of Technology > IRC# ProfSheinRIT on freenode > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sympy/-/TQT7Mrjtcn8J. > 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] isympy in newest ipython
There's a sample script at http://code.google.com/p/sympy/issues/detail?id=1797. I don't know if it's still relevant. Aaron Meurer On Jun 13, 2011, at 12:31 AM, Ondrej Certik wrote: > Hi, > > when I try to import "isympy" in the newest ipython (installed in > Qsnake from qsnake.com), I get: > > Qsnake: ondrej@eagle:~/repos/sympy(cg_coeff)$ bin/isympy > Traceback (most recent call last): > File "bin/isympy", line 180, in >main() > File "bin/isympy", line 177, in main >init_session(ipython, **args) > File "sympy/interactive/session.py", line 122, in init_session >ip = IPython.ipapi.get() > AttributeError: 'module' object has no attribute 'ipapi' > > > What is the best way that we should fix this? I would add some > conditional imports into sympy, but I wanted to ask, what the final > import line will be once ipython gets released. > > Thanks, > 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.
[sympy] Re: SymPy 0.7.0 Release Candidate 1
Well, I just noticed that sympy does not import under Python 2.4. I have fixed this in the 0.7.0 branch. Please report any other problems that you find, and I'll roll them out into a 0.7.0.rc2. Aaron Meurer On Jun 11, 2011, at 11:48 PM, Aaron Meurer wrote: > After weeks of work, and more than a year since the last release, > we've finally reached a point where we can release a release candidate > for SymPy 0.7.0. I talked with Ondřej, and we agreed that the best > way to do a release would be to follow the following steps (also > described at https://github.com/sympy/sympy/wiki/New-Release): > > 1. Fix all blockers (i.e., issues marked with the label > Milestone-Release0.7.0). > 2. Create a new branch 0.7.0, do the release patches in it. > 3. Continue in master just like if nothing was happening. > 4. Create rc1 from the 0.7.0 branch, test it, push fixes to 0.7.0. do > rc2 etc. do final release. > 5. Wait for some time and see if all is ok, possibly do some release > fixes (like wait for one week). > 6. Merge 0.7.0 with master, delete the branch. > 7. If more fixes are needed, simply fork from the latest 0.7.0 tag, > and push more fixes, release and merge. > > We are currently at step 4. I have pushed a branch named 0.7.0, for > which the latest commit is tagged sympy-0.7.0.rc1 to the main > repository. I have also created tarball distributions. > > Please test these distributions. All tests should pass with Python > 2.4-2.7, both 32- and 64-bit, and with gmpy installed or not > installed. Please test that this is the case from the tarballed > distributions themselves by running > > ./setup.py --prefix= install > > From the unpacked tarballs, and running the tests from that prefixed > path. You can also run sandboxes tests using tox. > > Also, I would really appreciate it if people could test the Windows > installer. I don't have Windows, so I can't even verify that it works > at all. > > Finally, you should review the changes I've made since master in the > 0.7.0 branch. Most of them are commits that fix tests. > > I have uploaded the tarballs to > http://code.google.com/p/sympy/downloads/list. I would have attached > the files to this email, but they were too large, and furthermore, > GMail does not allow sending .exe attachments. > > In accordance with the above steps, please continue to push patches to > master as if no release were happening. Push a patch into the 0.7.0 > branch if and only if it is critical for the release (e.g., fixes a > test failure in the release candidate). > > 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.
[sympy] Warning in numpy tests
If you have numpy installed, then you will get the following sympy/test_external/test_numpy.py[20] Warning: invalid value encountered in power [OK] This is because the test tests array([3, 8, -1])**5.5 and the -1**5.5 gives that error. Can this be changed to not use -1? Why do we even test array**int, which doesn't use sympy at all. If you change it to use S(5.5) no warning is generated, and it produces -1.0*I in the last entry. I don't know much about numpy or this test, so I didn't want to change anything, but we need to get rid of that warning in the tests. This is from line 52 of sympy/test_external/test_numpy.py 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.
Re: [sympy] Why is Symbol subclassed from Boolean?
I think it's so that we can use symbols in boolean expressions, like In [2]: x & y Out[2]: x ∧ y But I think this is a bad design. We should rather have a BooleanSymbol to do this. Aaron Meurer On Jun 8, 2011, at 2:41 PM, krastanov.ste...@gmail.com wrote: > Why is it necessary? -- 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] bugs in units
See the issue page. It has something to do with the new default lexicographic ordering for printing. Aaron Meurer On Jun 8, 2011, at 2:20 AM, Luke wrote: > I was writing some documentation for physics/units.py and discovered > some infinite recursion RuntimeError: > from sympy.physics.units import joule joule > > File "/home/luke/repos/sympy/sympy/core/expr.py", line 140, in __lt__ >return C.StrictInequality(self, other) > File "/home/luke/repos/sympy/sympy/core/relational.py", line 128, in __new__ >return rop_cls._eval_relation(lhs.evalf(), rhs.evalf()) > File "/home/luke/repos/sympy/sympy/core/relational.py", line 185, in > _eval_relation >return lhs < rhs > File "/home/luke/repos/sympy/sympy/core/decorators.py", line 75, in > __sympifyit_wrapper >return func(a, sympify(b, strict=True)) > File "/home/luke/repos/sympy/sympy/core/expr.py", line 137, in __lt__ >dif = self - other > File "/home/luke/repos/sympy/sympy/core/decorators.py", line 75, in > __sympifyit_wrapper >return func(a, sympify(b, strict=True)) > File "/home/luke/repos/sympy/sympy/core/decorators.py", line 115, in > binary_op_wrapper >return func(self, other) > File "/home/luke/repos/sympy/sympy/core/expr.py", line 86, in __sub__ >return Add(self, -other) > File "/home/luke/repos/sympy/sympy/core/expr.py", line 70, in __neg__ >return Mul(S.NegativeOne, self) > File "/home/luke/repos/sympy/sympy/core/cache.py", line 100, in wrapper >return func_cache_it_cache[k] > File "/home/luke/repos/sympy/sympy/core/numbers.py", line 1100, in __hash__ >return super(Integer, self).__hash__() > File "/home/luke/repos/sympy/sympy/core/numbers.py", line 797, in __hash__ >return super(Rational, self).__hash__() > File "/home/luke/repos/sympy/sympy/core/numbers.py", line 193, in __hash__ >return super(Number, self).__hash__() > RuntimeError: maximum recursion depth exceeded while calling a Python object > > > Bug report filed here: > http://code.google.com/p/sympy/issues/detail?id=2461 > > ~Luke > > -- > "Those who would give up essential liberty to purchase a little > temporary safety deserve neither liberty nor safety." > > -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 > > -- > 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] Solving f(x) congruent to 0 mod (n)
On Jun 7, 2011, at 2:58 AM, Hector wrote: > > > On Tue, Jun 7, 2011 at 1:32 PM, Mateusz Paprocki wrote: > Hi, > > On 7 June 2011 09:57, Hector wrote: > > > On Tue, Jun 7, 2011 at 4:01 AM, Aaron Meurer wrote: > Yes, make a pull request (though I can already see problems with your > code, like whitespace errors and that you need to wrap the text in > your docstrings). > > Aaron Meurer > > > I made the pull request (#390) and I will be thankful if anyone pin-point > where I need to improve the code. > Thanks. Good that you added tests. There are a few things that will have to > be fixed/improved (e.g. doctests, imports of ZZ and gcdex(), coefficient > domain handling). I will help you with this tomorrow. > > Well thank you for showing the interest. I am waiting for your help. > Meantime, is there anything else from number theory that can be added to > SymPy or is number theory tools are not our main aim and hence we just need > bare minimum functions in it? I wouldn't say number theory isn't our main aim. SymPy aims to be a full featured CAS, so anything that belongs in a CAS (like number theory) belongs in SymPy. Aaron Meurer > > > > On Mon, Jun 6, 2011 at 3:06 PM, Hector wrote: > > > > > > On Tue, Jun 7, 2011 at 1:04 AM, Aaron S. Meurer wrote: > >> > >> On Jun 6, 2011, at 10:44 AM, Hector wrote: > >> > >> > >> On Tue, Mar 29, 2011 at 5:42 AM, Mateusz Paprocki > >> wrote: > >>> > >>> Hi, > >>> > >>> On 28 March 2011 16:40, Aaron S. Meurer wrote: > >>>> > >>>> If this is implemented anywhere, it would be on the polys module. So I > >>>> would check there. I don't remember off the top of my head right now if > >>>> it > >>>> has been implemented or not. > >>> > >>> It's not implemented, but all necessary tools are in galoispolys.py. The > >>> algorithm itself is described in one of books that were mentioned in this > >>> module's docstrings. > >>> > >>>> > >>>> Aaron Meurer > >>>> > >>>> On Mar 28, 2011, at 1:06 AM, Hector wrote: > >>>> > >>>> > Hello ppl, > >>>> > > >>>> > I was browsing the code and realized that some of my earlier written > >>>> > codes can be implemented if they are already not present. So I started > >>>> > to > >>>> > dig more but couldn't find any function for solving f(x) congruent to > >>>> > 0 mod > >>>> > (n). Does any function exists in SymPy to solve this? If yes, where is > >>>> > it? > >>>> > If no, where can I add this function? > >>>> > > >>>> > > >>>> > -- > >>>> > -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. > >>>> > >>> > >>> Mateusz > >>> -- > >>> 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/
Re: [sympy] Solving f(x) congruent to 0 mod (n)
On Jun 6, 2011, at 10:44 AM, Hector wrote: > > > On Tue, Mar 29, 2011 at 5:42 AM, Mateusz Paprocki wrote: > Hi, > > On 28 March 2011 16:40, Aaron S. Meurer wrote: > If this is implemented anywhere, it would be on the polys module. So I would > check there. I don't remember off the top of my head right now if it has > been implemented or not. > > It's not implemented, but all necessary tools are in galoispolys.py. The > algorithm itself is described in one of books that were mentioned in this > module's docstrings. > > > Aaron Meurer > > On Mar 28, 2011, at 1:06 AM, Hector wrote: > > > Hello ppl, > > > > I was browsing the code and realized that some of my earlier written codes > > can be implemented if they are already not present. So I started to dig > > more but couldn't find any function for solving f(x) congruent to 0 mod > > (n). Does any function exists in SymPy to solve this? If yes, where is it? > > If no, where can I add this function? > > > > > > -- > > -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. > > > Mateusz > > -- > 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. > > Hello falks, > > Apologies for the long silence. > I wrote a function gf_csolve and necessary sub-functions to compute it[0]. > This looks fine till now and I am ready to open a pull request expect the > fact that I am not able to use gcdex ( line nos 2037-2038) if I declare it at > the starting of file or anywhere outside the function linear_congruence. I > face similar problem with ZZ. I am unable to use it in > sympy/polys/galoistools.py > > Thank you for any suggestions. And as I am currently working in number > theory, I would like to know is there any other function in number theory > that can be added to sympy. > > -- > -Regards > Hector > > Whenever you think you can or you can't, in either way you are right. > > [0] > https://github.com/hector1618/sympy/commit/6ade183e72aea76d579c9a9460e00eee35802a1b If I understand you correctly, this is a circular import problem, and just importing it from within the function is the correct solution. 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.
Re: [sympy] Question about diff() and Derivative()
This has actually been discussed quite a bit before (a lot of people want to use Lagrangians). You can search the mailing list. From what I've seen, you will either have to write your own custom diff routine or do clever substitution of functions and derivatives with symbols. I don't think I've ever seen anyone suggest extending Symbol to hold a time derivative, which is essentially just a more formal way of doing the substation method. It might work. Aaron Meurer On Jun 3, 2011, at 6:05 PM, Gilbert Gede wrote: > Hi, > I was trying to implement some functionality for PyDy for this year's GSoC, > and was looking for some advice. > In dynamics problems, you usually have time-varying quantities, like > generalized coordinates, speeds, and accelerations. Often, you want to take > the partial derivative of an expression with respect to the time derivative > of one of these quantities. This come up when using Lagrange's Method (or > Kane's Method). It's described to some degree here: > http://en.wikipedia.org/wiki/Lagrangian_mechanics > https://gist.github.com/1005937 > In Lagrange's Method, you end up taking the partial derivative of the energy > with respect to the time derivative of a generalized coordinate. I'm trying > to figure out a way to make this work in PyDy/SymPy. Derivative won't take in > anything but a Symbol. > The only idea I have come up with is to extend Symbol and write my own > .diff() method for it which returns a new symbol representing the time > differentiation of the original extended Symbol. Once my new object is > inside a Mul or Add sympy object, then my .diff() method is no longer called. > > Can anyone give some insight into how I could get this desired behavior, > taking the derivative of an expression wrt a time-differentiated symbol, to > work in a way consistent with existing SymPy behavior? Thanks. > > -Gilbert > > -- > 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] Pull Requests
You should submit a pull request only if you feel that your code is ready to be merged in. So 2. If you just want feedback, you can write to the list with a link to your branch on GitHub. It's even possible for people to leave comments on lines of code without you creating a pull request. You can also create an issue in the issue tracker and put a link to your branch there. Aaron Meurer On Jun 3, 2011, at 1:50 PM, Matthew Rocklin wrote: > Hi Folks, > > Regarding pull requests there are (for me) two competing interests: > > 1) I want feedback on my unfinished code > 2) I want to present a polished product to the SymPy community > > At what stage in my code's development is it proper to submit a pull request? > > -Matt > -- 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: Borrowing ideas from Polys to Matrix
On Jun 2, 2011, at 10:09 PM, Ronan Lamy wrote: > Le jeudi 02 juin 2011 à 21:28 -0600, Aaron S. Meurer a écrit : >> On Jun 2, 2011, at 9:21 PM, Ronan Lamy wrote: >> >>> Le jeudi 02 juin 2011 à 17:07 -0600, Aaron S. Meurer a écrit : >>>> On May 31, 2011, at 11:11 AM, Ronan Lamy wrote: >>>> >>>>> Le mardi 31 mai 2011 à 09:43 -0700, Vinzent Steinberg a écrit : >>>>>> On May 30, 9:52 pm, Mateusz Paprocki wrote: >>>>>>> That could work: >>>>>>> >>>>>>> ZZ.sum([1, 2, 3]) -> sum([1, 2, 3]) >>>>>>> RR.sum([1.0, 2.0]) -> mpmath.fsum([1.0, 2.0]) >>>>>>> EX.sum([x, y, z]) -> Add(*[x, y, z]) >>>>>>> >>>>>>> etc. >>>>>> >>>>>> This is exactly what I have been thinking of. >>>>> >>>>> But do we really need lots of different sum() functions? Is there a >>>>> difference between ZZ.sum([1, 2, 3]) and EX.sum([1, 2, 3])? >>>> >>>> Yes. You can sum integers perfectly efficiently just by passing them >>>> to the built-in sum() (also remember that ZZ(1) != S(1) in general >>>> because of the ground types, but EX(1) == S(1) always). >>> >>> ZZ(1) != S(1), but only some times, is rather counter-intuitive. I don't >>> understand what ZZ is really supposed to mean anyway. If it's the ring >>> of integers, why can its value change? And why is it instantiable? >> >> ZZ(1) means 1 in the current ground type. If the ground type is Python, >> it returns int(1). If it's gmpy, it returns mpz(1). Actually, ZZ(1) >> == S(1) only if you manually choose the sympy ground types. Note that >> I am using "==" here to mean actually something more like "is". I >> should really have said "type(ZZ(1)) != type(S(1))". __eq__ itself >> works as expected regardless of the underlying type. >> > OK. So "ZZ" means "integer type". That's what I find counter-intuitive > then. > >> In general, ZZ stands for the domain of integers, and you can pass it >> to Poly under the domain option (you can also do stuff like ZZ[x] to >> create the domain of polynomials in x with integer coefficients). >> ZZ(1) is just syntactic sugar that makes it easy to coerce elements to >> that domain. > > OK. By domain, you mean type, right? (That 'ZZ[x]' is a rather confusing > bit of syntactic sugar that seems to suggest a mathematical meaning it > doesn't really have and looks weird when you replace ZZ with any of its > possible values) Yeah, ZZ, QQ, etc. are all just about syntactic sugar that makes things much shorter to type. You can do all of the stuff equivalently in much longer forms. And by the way, the ZZ[x] syntax just exists because that's the mathematical notation (the square brackets). The real confusing thing is that ZZ(x) is not the field of rational functions in x with integer coefficients (for that you need ZZ.frac_field(x)). > >>> >>>> But something >>>> like Add(*(x, -x, x, x, -x)) is almost two times faster than sum((x, >>>> -x, x, x, -x)): >>> >>> That's rather an implementation detail, and using Add(*[...]) is wrong >>> anyway, if we want to allow extensions of sympy. Besides, it doesn't >>> explain why EX.sum([n, -n, n, n]) should be different from ZZ.sum([n, >>> -n, n, n]). >> >> Do you mean that n is symbolic? If so, then ZZ.sum([n, -n, n, n]) >> doesn't make sense. >> > It would make sense if 'ZZ' meant 'the ring of integers'. Actually, even > though that's not the case, it works anyway because ZZ.sum is always > just sum. That depends on if type checking happens on this level or not (and if it does work, it's only by accident). Aaron Meurer > >> Aaron Meurer >> >>> >>>> >>>> In [1]: Add(*(x, -x, x, x, -x)) >>>> Out[1]: x >>>> >>>> In [2]: %timeit Add(*(x, -x, x, x, -x)) >>>> 1000 loops, best of 3: 170 us per loop >>>> >>>> In [3]: sum((x, -x, x, x, -x)) >>>> Out[3]: x >>>> >>>> In [4]: %timeit sum((x, -x, x, x, -x)) >>>> 1000 loops, best of 3: 313 us per loop >>>> >>>> In [16]: b = map(S, range(100)) >>>> >>>> In [24]: %timeit Add(*b) >>>> 1000 loops, best of 3: 546 us per loop >>>> >>>> In [25]: %timei
Re: [sympy] Re: Borrowing ideas from Polys to Matrix
On Jun 2, 2011, at 9:21 PM, Ronan Lamy wrote: > Le jeudi 02 juin 2011 à 17:07 -0600, Aaron S. Meurer a écrit : >> On May 31, 2011, at 11:11 AM, Ronan Lamy wrote: >> >>> Le mardi 31 mai 2011 à 09:43 -0700, Vinzent Steinberg a écrit : >>>> On May 30, 9:52 pm, Mateusz Paprocki wrote: >>>>> That could work: >>>>> >>>>> ZZ.sum([1, 2, 3]) -> sum([1, 2, 3]) >>>>> RR.sum([1.0, 2.0]) -> mpmath.fsum([1.0, 2.0]) >>>>> EX.sum([x, y, z]) -> Add(*[x, y, z]) >>>>> >>>>> etc. >>>> >>>> This is exactly what I have been thinking of. >>> >>> But do we really need lots of different sum() functions? Is there a >>> difference between ZZ.sum([1, 2, 3]) and EX.sum([1, 2, 3])? >> >> Yes. You can sum integers perfectly efficiently just by passing them >> to the built-in sum() (also remember that ZZ(1) != S(1) in general >> because of the ground types, but EX(1) == S(1) always). > > ZZ(1) != S(1), but only some times, is rather counter-intuitive. I don't > understand what ZZ is really supposed to mean anyway. If it's the ring > of integers, why can its value change? And why is it instantiable? ZZ(1) means 1 in the current ground type. If the ground type is Python, it returns int(1). If it's gmpy, it returns mpz(1). Actually, ZZ(1) == S(1) only if you manually choose the sympy ground types. Note that I am using "==" here to mean actually something more like "is". I should really have said "type(ZZ(1)) != type(S(1))". __eq__ itself works as expected regardless of the underlying type. In general, ZZ stands for the domain of integers, and you can pass it to Poly under the domain option (you can also do stuff like ZZ[x] to create the domain of polynomials in x with integer coefficients). ZZ(1) is just syntactic sugar that makes it easy to coerce elements to that domain. > >> But something >> like Add(*(x, -x, x, x, -x)) is almost two times faster than sum((x, >> -x, x, x, -x)): > > That's rather an implementation detail, and using Add(*[...]) is wrong > anyway, if we want to allow extensions of sympy. Besides, it doesn't > explain why EX.sum([n, -n, n, n]) should be different from ZZ.sum([n, > -n, n, n]). Do you mean that n is symbolic? If so, then ZZ.sum([n, -n, n, n]) doesn't make sense. Aaron Meurer > >> >> In [1]: Add(*(x, -x, x, x, -x)) >> Out[1]: x >> >> In [2]: %timeit Add(*(x, -x, x, x, -x)) >> 1000 loops, best of 3: 170 us per loop >> >> In [3]: sum((x, -x, x, x, -x)) >> Out[3]: x >> >> In [4]: %timeit sum((x, -x, x, x, -x)) >> 1000 loops, best of 3: 313 us per loop >> >> In [16]: b = map(S, range(100)) >> >> In [24]: %timeit Add(*b) >> 1000 loops, best of 3: 546 us per loop >> >> In [25]: %timeit sum(b) >> 1000 loops, best of 3: 268 us per loop >> >> (all run without the cache, as suggested above). Note that [16] >> ensures that sum(b) goes through Add. Otherwise, you get >> >> In [26]: %timeit Add(*range(100)) >> 1000 loops, best of 3: 1.45 ms per loop >> >> In [27]: %timeit sum(range(100)) >> 10 loops, best of 3: 2.7 us per loop >> >> which just proves what we already know, which is that Python ints are >> (apparently 10x) faster than SymPy Integers. >> >> 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. > -- 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] Borrowing ideas from Polys to Matrix
I created http://code.google.com/p/sympy/issues/detail?id=2445 for this. Aaron Meurer On Jun 2, 2011, at 9:01 PM, Aaron S. Meurer wrote: > I see. It would be nice to have a function, call it timings_graph() or > something, that acts similar to the timed() function. You just pass it some > lists of source code that you want to plot (or maybe multiple lists for > multiple lines), a list of x-axis values, and other information like axes > labels, and it would just create a plot like this. It would be great way to > look at asymptotic behavior and to compare multiple implementations. We > could put it in utilities/timeutils.py. It would be useful to me to compare > risch_integrate() and integrate(), for example. > > Aaron Meurer > > On Jun 2, 2011, at 8:40 PM, Mateusz Paprocki wrote: > >> Hi, >> >> On 3 June 2011 01:15, Aaron S. Meurer wrote: >> > In [1] you will find a very simple comparison of Integer, int and mpz. >> > This applies to the rational case as well, just the difference is even >> > bigger. >> >> Did you make those graphs manually, or do you have some program that >> automates it? It would be nice to have something that can make timing >> graphs like that with very little work. >> >> It's semi-automated. You can find source code here: >> >> https://github.com/mattpap/masters-thesis/blob/master/bench/bench.py >> >> >> 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. >> >> >> Mateusz >> >> -- >> 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] Borrowing ideas from Polys to Matrix
I see. It would be nice to have a function, call it timings_graph() or something, that acts similar to the timed() function. You just pass it some lists of source code that you want to plot (or maybe multiple lists for multiple lines), a list of x-axis values, and other information like axes labels, and it would just create a plot like this. It would be great way to look at asymptotic behavior and to compare multiple implementations. We could put it in utilities/timeutils.py. It would be useful to me to compare risch_integrate() and integrate(), for example. Aaron Meurer On Jun 2, 2011, at 8:40 PM, Mateusz Paprocki wrote: > Hi, > > On 3 June 2011 01:15, Aaron S. Meurer wrote: > > In [1] you will find a very simple comparison of Integer, int and mpz. This > > applies to the rational case as well, just the difference is even bigger. > > Did you make those graphs manually, or do you have some program that > automates it? It would be nice to have something that can make timing graphs > like that with very little work. > > It's semi-automated. You can find source code here: > > https://github.com/mattpap/masters-thesis/blob/master/bench/bench.py > > > 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. > > > Mateusz > > -- > 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: Problem with user-defined functions
Is there a specific reason why you want to use evalf() to do your lookups, or
is it just because you want something that will recurse down the expression
tree?
Aaron Meurer
On Jun 2, 2011, at 2:10 PM, luke wrote:
> My bad, sorry for my inexperience with sympy, final code: (this is
> really working!)
>
> class SUM(Function):
>nargs = 1
>def _eval_evalf(cls, prec):
>print cls.args
>map = Code("""function () {
>emit("sum",{%(field)s:this.%(field)s});
> }""" % {'field':cls.args[0]})
>reduce = Code("""
>function(key, values) {
> var sum = 0;
> values.forEach(function(doc) {
>if (doc.%(field)s != undefined){
>sum += doc.%(field)s;
>}
> });
> return {%(field)s:sum};
>};""" % {'field':cls.args[0]})
>result = db.people.map_reduce(map, reduce, "myresults")
>return result.find_one()['value'][unicode(cls.args[0])]
>
> On Jun 2, 9:36 pm, luke wrote:
>> Nope in spite of my enthusiasm cls.args wont work properly as it will
>> give me a and not a :) I'll put back my eval since
>> it worked. Hope that was of any help!
>>
>> On Jun 2, 9:32 pm, luke wrote:
>>
>>
>>
>>
>>
>>
>>
>>> WAIT, I didn't see that you use
>>> self.arg[0]!! that's why my code was giving me 57, I just need to call
>>> cls.arg[0], great now I can remove the eval ;)! thanks again
>>
>>> On Jun 2, 9:30 pm, luke wrote:
>>
Actually you're wrong. Every instance of a class in python has its own
attributes and editing the attributes of one instance of a class wont
modify the attributes of the other classes.
Try:
>>
class MyClass:
def __init__(self,var):
self.var=var
>>
then execute:
>>
>>> a = MyClass(10)
>>> print a.var
>>> 10
>>> b = MyClass(20)
>>> print b.var
>>> 20
>>> print a.var, b.var
>>> 10 20
>>
This said, my code might effectively not be the best one but my issue
is that in _eval_evalf(cls,arg) the value of arg is not a symbol but
is a float (57 in my case, probably is an index of some internal
variable.. I can't find any documentation about that). So it's pretty
unusable, that's why I set cls.arg. However the code is working so
thanks everybody.
>>
On Jun 2, 7:01 pm, Ronan Lamy wrote:
>>
> Le jeudi 02 juin 2011 à 09:35 -0700, luke a écrit :
>>
>> Yes, that worked. But I had to restructure the code
>>
>> class SUM(Function):
>> nargs = 2
>> @classmethod
>> def eval(cls, arg):
>> cls.arg=arg
>> @classmethod
>> def _eval_evalf(cls, arg):
>> map = Code("""function () {
>> emit("sum",{%(field)s:this.%(field)s});
>>}""" % {'field':cls.arg})
>> reduce = Code("""
>> function(key, values) {
>> var sum = 0;
>> values.forEach(function(doc) {
>> if (doc.%(field)s != undefined){
>> sum += doc.%(field)s;
>> }
>> });
>> return {%(field)s:sum};
>> };""" % {'field':cls.arg})
>> result = db.people.map_reduce(map, reduce, "myresults")
>> return result.find_one()['value'][unicode(cls.arg)]
>> Because arg in _eval_evalf was strangely enough a float (more
>> precisely 57, have no clue why :) ).
>> Thank you all guys!
>>
> Your implementation won't work correctly: _eval_evalf needs to be an
> ordinary method of the instance in order to access to the argument of
> the function. Note that SUM is a class and that SUM('some_field') is an
> instance of it, so each time you set SUM.arg, all SUM calls will see it
> and since it's reset every time you call SUM(...), you'll get this:
>>
a = SUM('some_field'); SUM('other_field')
a.evalf()
>>
> -> result for SUM('other_field')
>>
> So you do need to follow my advice exactly - and remove eval().
>>
>> On Jun 2, 6:07 pm, Ronan Lamy wrote:
>>> Le jeudi 02 juin 2011 à 08:03 -0700, luke a écrit :
>>
Oh, thanks a lot. Now it's working fine.
Now the only problem is that the code is evaluated when calling
sympify, and not when calling evalf.
Could I ask you what is the way to keep the function lazy? I explain
myself better. Since the function SUM has to operate on a database if
I have something like that:
>>
>>> SUM('field') + SUM('field') + SUM('field') #not lazy, computes
>>> immediately three queries
>>> 1234
>>
I'm doing the same operation three
Re: [sympy] Re: Problem with user-defined functions
This is indeed a very interesting application of SymPy. Here we see one
example of the power of symbolic computer algebra systems, which is that
symbolic preprocessing, even very simple preprocessing like what we have here,
can greatly optimize arbitrary code execution.
If your expressions are complicated enough (like polynomials or rational
functions in your functions), you could probably optimize them even further by
applying simplification functions to expressions. And for your use case, cse()
could be a useful optimization.
Aaron Meurer
On Jun 2, 2011, at 9:03 AM, luke wrote:
> Oh, thanks a lot. Now it's working fine.
> Now the only problem is that the code is evaluated when calling
> sympify, and not when calling evalf.
> Could I ask you what is the way to keep the function lazy? I explain
> myself better. Since the function SUM has to operate on a database if
> I have something like that:
>
SUM('field') + SUM('field') + SUM('field') #not lazy, computes immediately
three queries
1234
>
> I'm doing the same operation three times and this is not very good in
> terms of performances, what I expected would have been:
>
a = SUM('field') + SUM('field') + SUM('field') -> 3SUM('field') # one
single query
print a
3*SUM('field')
print N(a)
1234
>
> just like other functions work. e.g.
>
log(10)+log(10)+log(10)
3*log(10)
>
> On Jun 2, 9:38 am, Mateusz Paprocki wrote:
>> Hi,
>>
>> On 2 June 2011 09:07, luke wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Hi eveyone,
>>> I'm developing an web application which has to interact with "user-
>>> defined formulas" of some financial kpis.
>>> I decided to use sympy to have a more solid math engine.
>>> Basically the input I reiceve is very simple, it might be in the worst
>>> case something like:
>>
>>> kpi -> "(log(sum('production'))*count('sales')/min('spread')" (this
>>> formula is totally made-up)
>>
>>> I defined some functions to interact with the database according to
>>> the official docs and they seem to be working:
>>
>>> For example defining
>>
>>> from sympy.core.function import Function
>>
>>> class SUM(Function):
>>>nargs = 2
>>>@classmethod
>>>def eval(cls, arg):
>>>map = Code("""function () {
>>>emit("sum",{%(field)s:this.%(field)s});
>>> }""" % {'field':arg})
>>>reduce = Code("""
>>>function(key, values) {
>>> var sum = 0;
>>> values.forEach(function(doc) {
>>>if (doc.%(field)s != undefined){
>>>sum += doc.%(field)s;
>>>}
>>> });
>>> return {%(field)s:sum};
>>>};""" % {'field':arg})
>>>result = db.people.map_reduce(map, reduce, "myresults")
>>>return result.find_one()['value'][unicode(arg)]
>>
>>> #EOF
>>
>>> Then from the command line I can type:
>>
>> print SUM("field")
>> 1923
>>
>> Very interesting application. I'm not sure if you are familiar with this,
>> but staying on the safe side note here that SUM("field") doesn't do exactly
>> what you expect, but the outcome is fine. Usually, SymPy's functions don't
>> accept raw string arguments, but sympify() them:
>>
>> In [1]: class fun(Function):
>>...: nargs = 1
>>...: @classmethod
>>...: def eval(cls, arg):
>>...: print type(arg)
>>...:
>>...:
>>
>> In [2]: fun('abc')
>>
>> Out[2]: fun(abc)
>>
>> So in eval() you got a symbol not string 'abc', but as str() of a Symbol is
>> simply the name of the symbol, then this (and your code) works as expected:
>>
>> In [3]: print "---%s---" % Symbol('abc')
>> ---abc---
>>
>>
>>
>>> But when I try to use sympify my function doesn't evaluate..
>>
>> print sympify("SUM('field')").evalf()
>> SUM(field)
>> N("SUM('field')")
>> SUM(field)
>>
>> The problem here is that SymPy, precisely speaking sympify(), doesn't know
>> what SUM() is, because SUM() resides in the global namespace of the
>> interpreter, which is unknown to sympify(), e.g.:
>>
>> In [4]: sympify("whatever(10)")
>> Out[4]: whatever(10)
>>
>> whatever() is unknown to sympify(), so a new Function object is constructed
>> for it. The same for fun() which I defined above:
>>
>> In [6]: sympify("fun(10)")
>> Out[6]: fun(10)
>>
>> To overcome this, pass globals() to sympify(), e.g.:
>>
>> In [7]: sympify("fun(10)", globals())
>>
>> Out[7]: fun(10)
>>
>> (in your case this will be sympify("SUM('field')", globals())).
>>
>>
>>
>>> Am I doing anything wrong?
>>> Thanks in advance!
>>
>>> --
>>> 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
Re: [sympy] Solving equations with exp
Yeah, it would be cool to have assumptions for functions. Stuff like one-to-one, onto, increasing, strictly increasing (implies one-to-one), continuous, etc. Aaron Meurer On Jun 2, 2011, at 12:52 PM, Christophe BAL wrote: > Hello. > > >>> On the other hand, maybe solve should be able to tell > >>> that f(x) - f(y) == 0 implies the solution x == y > >>> (but there may be more solutions unless f is one-to-one). > > Ir could be a nice feature to have the possibility to declare a function to > be one-to-one so as to solve the very simple preceding equation not treated > by sympy. > > Best regards. > C. > > -- > 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: A simple idea regarding groundtypes for Matrix
On Jun 2, 2011, at 10:13 AM, sherjiloz...@gmail.com wrote: > Yes and no and no. > Numpy/scipy matrices have their backend in C/fortran types. Arbitrary objects > can't be put inside them. > > That's where sympy comes in and finds a market for its use. I'm adding a > dtype(the usgae of this name might be wrong) argument to sympy matrices. 6 > basic types, ints, rationals, reals, polys, rational functions, and finally > Exprs will be built in. It will have an 'other' option which will the user to > put in any arbitrary type as elements of the matrix which support the > fundamental operations required for matrix algorithms. > > Possibly, a template could be provided to the user to have provide the sympy > matrix with domain.sum, domain.typify, etc.. I'd say this already exists as the super class of the poly domains. Aaron Meurer > > Still, 90% of symbolic matrix needs would be covered by the 6 builtins. > Sent on my BlackBerry® from Vodafone > > -Original Message- > From: Brian Granger > Sender: sympy@googlegroups.com > Date: Thu, 2 Jun 2011 08:56:29 > To: > Reply-To: sympy@googlegroups.com > Subject: Re: [sympy] Re: A simple idea regarding groundtypes for Matrix > > I am a bit confused here as well. > > Are you considering adding a dtype argument to sympy.Matrix? > Are you consider making sympy.Expr objects work inside numpy matrices? > Are you considering making sympy.Expr work inside scipy.sparse matrices? > > Cheers, > > Brian > > On Wed, Jun 1, 2011 at 9:27 PM, SherjilOzair wrote: >> scipy.sparse implements a dtype kwarg argument, but which currently >> cannot take in arbitrary unknown types though. >> One thing that can be done about this, is to define an interface for >> the dtype. It would be taken for granted that it will have +, *, / >> defined. Checks will be used in algorithms if it has pow, inverse >> defined or not. >> The caller will be provided with a dtype function argument in the >> Matrix constructor. >> >> I list some built-in dtypes that sympy has and can provide. With only >> these 6 dtypes, Matrix should suffice for 90% of symbolic matrix >> needs. Possibly, if the caller doesn't want any of these dtypes, then >> he should specify 'other' in the dtype argument. >> >> Int, numeric, can employ addition, multiplication, raising to positive >> integral power. >> Rational, numeric, can employ addition, multiplication, division, >> inverse, raising to integral power. >> Real, numeric, can employ addition, multiplication, division, inverse, >> raising to any power. >> Poly (Or one of its internals), symbolic, to support addition, >> multiplication, division by scalar, *not* inverse, raising to positive >> integral power. >> Rational Function, symbolic, to support addition, multiplication, >> division by scalar, inverse, raising to integral power. >> Expr, symbolic, to support addition, multiplication, division by >> scalar, inverse, raising to all powers. >> >> -- >> 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. >> >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgran...@calpoly.edu and elliso...@gmail.com > > -- > 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] Re: A simple idea regarding groundtypes for Matrix
On Jun 2, 2011, at 9:48 AM, Brian Granger wrote: > On Thu, Jun 2, 2011 at 1:28 AM, Mateusz Paprocki wrote: >> Hi, >> >> On 2 June 2011 04:09, Brian Granger wrote: >>> >>> Is there a link somewhere to documentation about the groundtypes in >>> polys? I am interested why such things are needed? It sort of sounds >>> like there are two semi-independent code bases living here... >> >> See my previous response. Unfortunately, currently there isn't much >> documentation on this topic. As to two code bases, there are actually two >> cores, one (should be) purely symbolic (sympy.core) and the other algebraic >> (sympy.polys and sympy.polys.domains, later should be extracted to a >> separate top-level module, to make it reusable in other parts of SymPy). > > Then I don't understand what polys has to do with Matrices. Surely > matrices can contain expressions other than polynomials. This is > really what I am wondering about. Are we talking about a special > Matrix subclass that *only* contains polynomials? It isn't related to the polys in the sense the that matrix elements are polynomials. Rather, think of the coefficients of a polynomial. Poly(2*x**3 + x + 4) is stored internally as [2, 0, 1, 4]. The problems that arise when working with coefficients of polynomials are very similar to the ones that arise when working with matrices. Mateusz has modularized the coefficients of Poly pretty well so that there are different classes for integer coefficients or rational coefficients or even rational function coefficients (like Poly((1 + y)/y**2*x, x)). The integer and rational number coefficient domains are written so that they can use gmpy if it's installed, or else it uses Python, and all automatically. This should all be adapted to the matrices, because it makes the code cleaner and, more importantly, it makes things much faster. Aaron Meurer > >>> >>> >>> On Wed, Jun 1, 2011 at 6:31 PM, Aaron Meurer wrote: I think the key point that should be made here is that the matrices should try to use the *exact* same ground types/domains as the polys, so that there is no code duplication. This will probably involve improving and even changing a little bit the design of the polys classes (but this is good, because it will make them more modular, which is the goal anyway). On Sun, May 29, 2011 at 3:44 PM, Mateusz Paprocki wrote: > Hi, > > On 29 May 2011 23:10, Tom Bachmann wrote: >>> >>> On May 30, 12:13 am, Tom Bachmann wrote: How is this at all different from what Polys does? I'm not saying it's bad, I'm just not seeing your point. Basically what you call ground types are called domains in polys, and they are in polys/domains ... >>> >>> I need usable types. For example, you mentioned that one usable type >>> is DMF, and it is in poly/polyclasses. >>> How many other such types exist and where ? >>> >> >> DMF is already higher level. The things you should probably be looking >> at >> are in polys/domains. > > Well, DMF is low-level. In domains you will find FractionField domain > that > uses DMF a ground type. > >> >> There's a lot there, and it's a bit of a shame that there's not much >> documentation. > > There isn't that much, but main ideas are described in my thesis (ch. > 2). If > more information is needed, I can always provide it (as long as a > question > is specific). There would be more, as I wrote doctests for all those things back in https://github.com/asmeurer/sympy/tree/polydocs. But the domains code was all moved to polys/domains and the API changed so much that I never bothered to transfer the doctests. If you need to know how a module works and there is no documentation, writing doctests for all the functions/methods is a great way to fix both problems. This is how I learned how the polys in general worked at the beginning of last summer (see the above linked branch). In this case, you could just work on transferring my doctests that were never transferred. Aaron Meurer > >> >> I think construct_domain should somehow construct a domain that can >> hold >> your data. If you need to divide, or take square roots, etc, you >> presumably >> have to figure out what larger domain you need. There are probably >> functions >> for this, but I don't know about them. Ask Mateusz about anything >> specific. >> >> As for ground types, they work roughly like this: >> > from sympy.polys.domains import FF >> >> This imports a constructor for finite fields. As I understand it, this >> will automatically use gmpy or python types depending on what is >> available. >> >> >> Construct a domain for arithmetic m
Re: [sympy] Borrowing ideas from Polys to Matrix
> In [1] you will find a very simple comparison of Integer, int and mpz. This > applies to the rational case as well, just the difference is even bigger. Did you make those graphs manually, or do you have some program that automates it? It would be nice to have something that can make timing graphs like that with very little work. 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.
Re: [sympy] Re: Borrowing ideas from Polys to Matrix
On May 31, 2011, at 11:11 AM, Ronan Lamy wrote: > Le mardi 31 mai 2011 à 09:43 -0700, Vinzent Steinberg a écrit : >> On May 30, 9:52 pm, Mateusz Paprocki wrote: >>> That could work: >>> >>> ZZ.sum([1, 2, 3]) -> sum([1, 2, 3]) >>> RR.sum([1.0, 2.0]) -> mpmath.fsum([1.0, 2.0]) >>> EX.sum([x, y, z]) -> Add(*[x, y, z]) >>> >>> etc. >> >> This is exactly what I have been thinking of. > > But do we really need lots of different sum() functions? Is there a > difference between ZZ.sum([1, 2, 3]) and EX.sum([1, 2, 3])? Yes. You can sum integers perfectly efficiently just by passing them to the built-in sum() (also remember that ZZ(1) != S(1) in general because of the ground types, but EX(1) == S(1) always). But something like Add(*(x, -x, x, x, -x)) is almost two times faster than sum((x, -x, x, x, -x)): In [1]: Add(*(x, -x, x, x, -x)) Out[1]: x In [2]: %timeit Add(*(x, -x, x, x, -x)) 1000 loops, best of 3: 170 us per loop In [3]: sum((x, -x, x, x, -x)) Out[3]: x In [4]: %timeit sum((x, -x, x, x, -x)) 1000 loops, best of 3: 313 us per loop In [16]: b = map(S, range(100)) In [24]: %timeit Add(*b) 1000 loops, best of 3: 546 us per loop In [25]: %timeit sum(b) 1000 loops, best of 3: 268 us per loop (all run without the cache, as suggested above). Note that [16] ensures that sum(b) goes through Add. Otherwise, you get In [26]: %timeit Add(*range(100)) 1000 loops, best of 3: 1.45 ms per loop In [27]: %timeit sum(range(100)) 10 loops, best of 3: 2.7 us per loop which just proves what we already know, which is that Python ints are (apparently 10x) faster than SymPy Integers. 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.
Re: [sympy] Re: repr and srepr
On Jun 1, 2011, at 9:35 PM, Ronan Lamy wrote:
> Le mercredi 01 juin 2011 à 20:12 -0600, Aaron Meurer a écrit :
>> A few things:
>>
>> - Even if we made isympy play nice, doctests assume just a regular
>> pure Python shell. So any doctest of a function that somehow has a
>> list, tuple, or dict of sympy objects would have to be changed to
>> either use less nice format (srepr()), or to use a printer that gets
>> around it.
>>
> Well, we're already running doctests under our own printer - that's why
> we had to essentially fork doctest from the stdlib. I think bin/doctest
> doesn't actually execute any __repr__() method from sympy objects.
>
>> - If we fix issue 2359, then I'd say about 90% of "typical" SymPy
>> expressions would work with eval(str(x)) == x, assuming that Symbols
>> have been instantiated (both str and srepr require "from sympy import
>> *"). And as we know, sympify(str(x)) == x should *always* work
>> assuming the expression is "generic" enough (i.e., standard functions
>> like sin() or exp() haven't been overridden, Symbols have default
>> assumptions, etc.).
>>
>> srepr() also does things like Add(Symbol('x'), Symbol('y')) instead of
>> Symbol('x') + Symbol('y'), which I guess is more efficient so should
>> probably stay as long as srepr() is the *really* long form of an
>> expression.
>>
>> - I use .args mainly to get at some part of an expression that I don't
>> want to re-type. If this always return the srepr() expression, that
>> would be useless. Granted, I always use isympy, which uses pprint,
>> not str, but I just wanted to point out that .args is not just used
>> for debugging.
>>
>> - But even considering debugging, the srepr() form is, in my opinion,
>> less useful for SymPy expressions than str(). From what I gathered
>> from the discussions I saw on this on the Python mailing list and
>> elsewhere, SymPy is rather unique in the fact that str(expr) <
>> srepr(expr) by quite a bit for all but trivial expressions.
>> Pow(Add(Symbol('x'), Mul(Symbol('x'), Symbol('y')), Pow(Symbol('x'),
>> Integer(2))), Rational(1, 2)) is only more useful than sqrt(x**2 + x*y
>> + x) if you want the eval(repr(x)) == x, which (unfortunately) doesn't
>> really apply in list/tuple/dict's calling of __repr__ with __str__.
>>
>
> OK, srepr(x**2 + x*y + x) is unreadable, but it could be improved by
> indenting and falling back to a more condensed representation beyond a
> certain depth in the expression tree. For instance:
>
> Pow(
>Add(Symbol('x'), Mul(x, y), Pow(x, 2)),
>Rational(1, 2)
> )
But then what's the point? If you are going to have a bare x without Symbol('
') around it why not just stick with the __str__ output, which is easy to read.
By the way, out of curiosity, what exactly are the uses of repr(). When do you
need to be able to eval(repr(x))?
Aaron Meurer
>
>> Aaron Meurer
>>
>> On Sun, May 29, 2011 at 1:07 PM, Ronan Lamy wrote:
>>> Le dimanche 29 mai 2011 à 08:25 -0700, Vinzent Steinberg a écrit :
On 28 Mai, 17:40, Ronan Lamy wrote:
> I don't care about that, because we don't put stuff inside containers
> that often, because I usually want the repr when I look at .args, and
> because the only shell I really care about is ipython, which prints this
> nicely in any case.
I care about pure python shells. However, I could live with it if
there was a trivial way to setup printing as in isympy (calling
init_printing() probably already does this).
>>> There is:
>>>
>>> ronan@ronan-desktop:~/Projets/sympy-git$ python
>>> Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
>>> [GCC 4.5.2] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>> from sympy import *
>> import sys
>> sys.displayhook = pprint
>> class A(object):
>>> ... def __str__(self): return "A"
>>> ...
>> A()
>>> A
>> [A()]
>>> [A]
>> str([A()])
>>> [<__main__.A object at 0x9d2024c>]
>>>
> What matters is that:
> * we can't change it
> * people new to sympy who know Python expect it
> * there is a lot of code outside sympy that takes this behaviour for
> granted and works with/around it.
On the other hand, eval(repr(x)) == x does not hold in general, see
for example lambda, functions, numpy arrays etc.
>>>
>>> Sure. But what I meant by "this behaviour" is the fact that str() is
>>> supposed to be the nice, human-friendly representation of the object,
>>> while repr() shows what's actually inside the object, and that the str()
>>> of built-in containers isn't actually nice enough for most uses.
>>>
>>> --
>>> 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] Trying out Tox
Do you know if there is a way to have a tox.ini file that is tracked by git, but to still locally set somehow the paths to various Python binaries (for example, I have two binaries for each version of Python, one 32-bit and one 64-bit)? Aaron Meurer On May 28, 2011, at 1:42 PM, Vlada Peric wrote: > As you may or may not know, SymPy is looking for a replacement for buildbot > (see the issue[0] on it and my blog post about continuous integration servers > and such[1]). This is a part of my GSoC project and, as explained I believe > using Tox in combination with Jenkins is the way forward. As Tox is a very > powerful tool in it's own right, I think we should start using it locally > too, to streamline tests. The way Tox works is explained in my blog post, and > there are instruction on the wiki on how to set it up: > > https://github.com/sympy/sympy/wiki/Using-Tox > > Please try it and comment on any issues that might arise. > > > [0] http://code.google.com/p/sympy/issues/detail?id=1117 > > [1] http://vperic.blogspot.com/2011/05/continuous-integration-and-sympy.html > > -- > Vlada Perić -- 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] why does terms_gcd clear the denominators of an expression
Shouldn't it return 1? Aaron Meurer On May 27, 2011, at 3:14 PM, smichr wrote: > There are two questions, really: > > 1) why does gcd(2/3, 4/9) give 2/9 instead of (the greater) 2/3? I > know what the code is doing...but should it be doing that? I read > that > >> This definition is consistent with the idea that `a / gcd(a,x)' should yield >> an integer for any `a' and `x'. > > But why should it yield an integer; you started with fractions, I > would expect to only end with integers if one number was an integer > multiple of the other, which 2/3 and 4/9 are not -- they are powers of > each other. > > 2) regardless of the answer to 1, perhaps terms_gcd could get the > option to not clear the denominators? But on the other hand, why would > you want to keep the fractions? Hmm.. > > -- > 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] integer_nthroot and factorint -> iroot and ifactor
I don't think it's worth it. Aaron Meurer On May 26, 2011, at 11:59 PM, smichr wrote: > What do you think about changing the names integer_nthroot and > factorint -> iroot and ifactor? -- 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 + mpmath findroot
Well, it still fails there with the subs. Like I said, it's a bug. Can you
open an issue for it?
Aaron Meurer
On May 26, 2011, at 9:09 PM, Matthew Emmett wrote:
> Thanks for the quick reply Aaron. I will get the latest git version
> and run with it. BTW, I was running the sample on 0.6.7.
>
> Thanks again,
> Matt
>
> On Thu, May 26, 2011 at 08:28:51PM -0600, Aaron S. Meurer wrote:
>> If I try this with mpmath 0.16 (the version we currently have in sympy in
>> the latest git master), I get:
>>
>> In [22]: print 'subs: ', mpmath.findroot(lambda xi: p.subs(x, xi), 1.0)
>> subs:
>> ---
>> ValueErrorTraceback (most recent call last)
>>
>> /Users/aaronmeurer/Documents/python/sympy/sympy/ in
>> ()
>>
>> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/mpmath/calculus/optimization.pyc
>> in findroot(ctx, f, x0, solver, tol, verbose, verify, **kwargs)
>>968 '(%g > %g)\n'
>>969 'Try another starting point or tweak
>> arguments.'
>> --> 970 % (norm(f(*xl))**2, tol))
>>971 return x
>>972 finally:
>>
>> ValueError: Could not find root within given tolerance. (6.67917e-33 >
>> 1.71057e-49)
>> Try another starting point or tweak arguments.
>>
>> Another option for Poly is eval. I get this:
>>
>> In [37]: print 'eval: ', mpmath.findroot(lambda xi: p.eval(x, xi), 1.0)
>> eval: 0.774596669241483377035853079956479922166584341
>>
>> In [38]: print 'exact: ', mpmath.sqrt(mpmath.mpf('3.0')/mpmath.mpf('5.0'))
>> exact: 0.774596669241483377035853079956479922166584341
>>
>> In [39]: print 'lambda:', mpmath.findroot(lambda x: 5.0*x**3/2.0 -
>> 3.0*x/2.0, 1.0)
>> lambda: 0.774596669241483377035853079956479922166584341
>>
>> So I'd say there is some kind of bug with subs.
>>
>> Aaron Meurer
>>
>> On May 26, 2011, at 8:21 PM, Matthew Emmett wrote:
>>
>>> Hi everyone,
>>>
>>> I am having trouble combining mpmath's findroot function with sympy.
>>> Here is a short example of what I am trying to accomplish:
>>>
>>> import sympy
>>> import mpmath
>>>
>>> mpmath.mp.dps = 45
>>>
>>> x = sympy.var('x')
>>> p = (5.0/2.0*x**3 - 3.0/2.0*x).as_poly()
>>>
>>> print 'subs: ', mpmath.findroot(lambda xi: p.subs(x, xi), 1.0)
>>> print 'lambda:', mpmath.findroot(lambda x: 5.0*x**3/2.0 - 3.0*x/2.0,
>>> 1.0)
>>> print 'exact: ', mpmath.sqrt(mpmath.mpf('3.0')/mpmath.mpf('5.0'))
>>>
>>>
>>> The output is:
>>>
>>> subs: 0.77459666924148342341315597798728447146706553
>>> lambda: 0.774596669241483377035853079956479922166584341
>>> exact: 0.774596669241483377035853079956479922166584341
>>>
>>>
>>> That is, when using mpmath.findroot, substituting into a SymPy
>>> polynomial does not produce the same result as using a lambda form
>>> with a handwritten version of the polynomial. Is there a way to the
>>> SymPy subs method to work as expected?
>>>
>>> Thanks,
>>> Matt
>>>
>>> --
>>> 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.
>
--
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 + mpmath findroot
If I try this with mpmath 0.16 (the version we currently have in sympy in the
latest git master), I get:
In [22]: print 'subs: ', mpmath.findroot(lambda xi: p.subs(x, xi), 1.0)
subs:
---
ValueErrorTraceback (most recent call last)
/Users/aaronmeurer/Documents/python/sympy/sympy/ in ()
/Users/aaronmeurer/Documents/python/sympy/sympy/sympy/mpmath/calculus/optimization.pyc
in findroot(ctx, f, x0, solver, tol, verbose, verify, **kwargs)
968 '(%g > %g)\n'
969 'Try another starting point or tweak
arguments.'
--> 970 % (norm(f(*xl))**2, tol))
971 return x
972 finally:
ValueError: Could not find root within given tolerance. (6.67917e-33 >
1.71057e-49)
Try another starting point or tweak arguments.
Another option for Poly is eval. I get this:
In [37]: print 'eval: ', mpmath.findroot(lambda xi: p.eval(x, xi), 1.0)
eval: 0.774596669241483377035853079956479922166584341
In [38]: print 'exact: ', mpmath.sqrt(mpmath.mpf('3.0')/mpmath.mpf('5.0'))
exact: 0.774596669241483377035853079956479922166584341
In [39]: print 'lambda:', mpmath.findroot(lambda x: 5.0*x**3/2.0 - 3.0*x/2.0,
1.0)
lambda: 0.774596669241483377035853079956479922166584341
So I'd say there is some kind of bug with subs.
Aaron Meurer
On May 26, 2011, at 8:21 PM, Matthew Emmett wrote:
> Hi everyone,
>
> I am having trouble combining mpmath's findroot function with sympy.
> Here is a short example of what I am trying to accomplish:
>
> import sympy
> import mpmath
>
> mpmath.mp.dps = 45
>
> x = sympy.var('x')
> p = (5.0/2.0*x**3 - 3.0/2.0*x).as_poly()
>
> print 'subs: ', mpmath.findroot(lambda xi: p.subs(x, xi), 1.0)
> print 'lambda:', mpmath.findroot(lambda x: 5.0*x**3/2.0 - 3.0*x/2.0,
> 1.0)
> print 'exact: ', mpmath.sqrt(mpmath.mpf('3.0')/mpmath.mpf('5.0'))
>
>
> The output is:
>
> subs: 0.77459666924148342341315597798728447146706553
> lambda: 0.774596669241483377035853079956479922166584341
> exact: 0.774596669241483377035853079956479922166584341
>
>
> That is, when using mpmath.findroot, substituting into a SymPy
> polynomial does not produce the same result as using a lambda form
> with a handwritten version of the polynomial. Is there a way to the
> SymPy subs method to work as expected?
>
> Thanks,
> Matt
>
> --
> 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: Random Variables
You might also look at the discussion at http://code.google.com/p/sympy/issues/detail?id=135. We used to override __eq__ to retune Eq(), but we changed it to be like it is now. You can see at around comment 22 that the main reason for the change was for performance purposes. But I would argue for it just in terms of functionality. Exact comparison is used 100 more often than Eq(), so the nice syntax should go to that. Also, it's more Pythonic (it's how everything else works). And as Robert pointed out, it is necessary for hashing to work correctly in some cases to make __eq__ implement equality. Aaron Meurer On May 25, 2011, at 9:30 PM, Robert Kern wrote: > On Wed, May 25, 2011 at 19:32, Matthew wrote: >> Is the only issue with overloading __eq__ that hashing goes away (thus >> not allowing use of SymPy objects inside dicts/sets, etc...)? > > No. Having the ability to ask if two sympy expressions are > structurally the same is important in some manipulations of those > structures. > >> Apparently numpy gets around this by defining a __hash__ method. > > No, it doesn't. First, numpy arrays are mutable and so cannot be > hashed; we don't get around anything. Second, in order to be hashable, > you must also define an __eq__() such that if (x==y) then > (hash(x)==hash(y)). dicts and sets use an equality comparison when two > objects fall into the same hash bucket to actually determine whether > the object is in the dict/set. The __hash__ is just an optimization, > not the whole of the operation. This is actually why the mutability of > arrays forbids them from being dict keys: if the array changes its > values after it has been hashed and assigned a hash bucket in the > dict, then later comparisons will be incorrect. > >> Could >> we do the same? Are there other concerns with overloading __eq__? >> >> Consider the following example. >> > class foo: >> ... def __init__(self, a, b): >> ... self.a, self.b = a, b >> ... def __eq__(self, other): >> ... return other >> ... def __hash__(self): >> ... return hash((self.a, self.b)) > f = foo(1,2) > f == 5 >> 5 > set((f, 5)) >> set([<__main__.foo instance at 0x9866bcc>, 5]) > > Yes, it believed you that it could hash the foo object and faithfully > put it into the right bucket given the hash code you calculated. > However, you will run into problems actually *using* the set, checking > for containment, and adding and removing items. > > [~] > |1> class foo(object): > ..> def __init__(self, a, b): > ..> self.a = a > ..> self.b = b > ..> def __eq__(self, other): > ..> return other > ..> def __hash__(self): > ..> return hash((self.a, self.b)) > ..> > > [~] > |2> f = foo(1,2) > > [~] > |3> s = set([f, 5]) > > [~] > |4> s > set([<__main__.foo at 0x4e9fed0>, 5]) > > [~] > |5> (1,2) in s > True > > > This happens because hash((1,2)) == hash(f), so the set looks in f's > bucket for items that actually equal the test object. So it runs > f.__eq__((1,2)), gets back (1,2), passes it to bool() to interpret it > as a real boolean, gets True, so it thinks (1,2) is an object that is > already in there. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > > -- > 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] polys domain woes
On May 25, 2011, at 3:01 AM, Mateusz Paprocki wrote:
> Hi,
>
> On 25 May 2011 10:43, Aaron S. Meurer wrote:
> What happens if you make it use an algebraic domain, i.e., set extension=True?
>
> That's a good suggestion. Usually polys (domains or whatever else) in not the
> problem (unless there is some bug and there are still quite a few there), but
> the way the module is used. We can't expect that polys will work in all
> contexts without fine tuning (see sympy/polys/polyoptions.py). polys are
> optimized for symbolic manipulation (simplification etc.) so in other
> contexts you may need to override the defaults. Look for example into
> gosper_normal() in sympy/concrete/gosper.py (the first line). Two options
> (field and extension) had to be specified to adjust polys behavior to make it
> useful in the context of Gosper's algorithm. Similar thing happens in
> solve(). Unfortunately solve() was updated to use polys properly.
>
> btw.
>
> Did you notice this odd printing (- -):
>
> In [37]: F = [(x - 5)**2 + (y - 5)**2 - 4, -(-x + 5)*(-x - 2*2**(1/S(2)) + 5)
> - (-y + 5)*(-y + 5)]
>
> In [38]: F
> Out[38]:
> ⎡ 2 2 ⎛ ⎽⎽⎽⎞ 2⎤
> ⎣(x - 5) + (y - 5) - 4, - -(x - 5)⋅⎝-x - 2⋅╲╱ 2 + 5⎠ - (-y + 5) ⎦
I bisected this, and it shouldn't be any surprise what caused it:
commit b8d6252ea115032f7da8c46aca60af0b6a75fd36
Author: Ronan Lamy
Date: Thu Jan 13 23:43:00 2011 +
Set keep_sign = True
I created http://code.google.com/p/sympy/issues/detail?id=2425 for this.
Aaron Meurer
>
>
> Aaron Meurer
>
> On May 24, 2011, at 10:14 PM, smichr wrote:
>
> > One of the problems I am running into with polys is this:
> >
> >>>> p1,p2=[(x - 5)**2 + (y - 5)**2 - 4, -(-x + 5)*(-x - 2*2**(1/
> > S(2)) + 5) - (-y
> > + 5)*(-y + 5)]
> >>>> solve([p1,p2])
> >Traceback (most recent call last):
> > File "", line 1, in
> > File "sympy\solvers\solvers.py", line 236, in solve
> >solution = _solve(f, *symbols, **flags)
> > File "sympy\solvers\solvers.py", line 607, in _solve
> >soln = solve_poly_system(polys)
> > File "sympy\solvers\polysys.py", line 45, in solve_poly_system
> >return solve_generic(polys, opt)
> > File "sympy\solvers\polysys.py", line 179, in solve_generic
> >result = solve_reduced_system(polys, opt.gens, entry=True)
> > File "sympy\solvers\polysys.py", line 149, in
> > solve_reduced_system
> >raise NotImplementedError("only zero-dimensional systems
> > supported (finite n
> >umber of solutions)")
> >NotImplementedError: only zero-dimensional systems supported
> > (finite number of s
> >olutions)
> >
> > The two expressions end up getting different domains:
> >[Poly(x**2 - 10*x + y**2 - 10*y + 46, x, y, domain='ZZ'),
> > Poly(-x**2 + (-2*2**(1/2) + 10)*x - y**2 + 10*y - 50 +
> > 10*2**(1/2), x, y, domain='EX')]
> >
> > If I get rid of the sqrt(2) then the domains are both ZZ and it works.
> >>>> p2
> >-(-x + 5)*(-x - 2*2**(1/2) + 5) - (-y + 5)**2
> >>>> _.subs(sqrt(2),2)
> >(-x + 1)*(x - 5) - (-y + 5)**2
> >>>> solve([p1,_])
> >[(4, -3**(1/2) + 5), (4, 3**(1/2) + 5)]
> >
> > What's the best way to make solve flexible so it will handle this?
> >
> > --
> > 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.
>
>
> Mateusz
>
> --
> 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] polys domain woes
What happens if you make it use an algebraic domain, i.e., set extension=True?
Aaron Meurer
On May 24, 2011, at 10:14 PM, smichr wrote:
> One of the problems I am running into with polys is this:
>
p1,p2=[(x - 5)**2 + (y - 5)**2 - 4, -(-x + 5)*(-x - 2*2**(1/
> S(2)) + 5) - (-y
> + 5)*(-y + 5)]
solve([p1,p2])
>Traceback (most recent call last):
> File "", line 1, in
> File "sympy\solvers\solvers.py", line 236, in solve
>solution = _solve(f, *symbols, **flags)
> File "sympy\solvers\solvers.py", line 607, in _solve
>soln = solve_poly_system(polys)
> File "sympy\solvers\polysys.py", line 45, in solve_poly_system
>return solve_generic(polys, opt)
> File "sympy\solvers\polysys.py", line 179, in solve_generic
>result = solve_reduced_system(polys, opt.gens, entry=True)
> File "sympy\solvers\polysys.py", line 149, in
> solve_reduced_system
>raise NotImplementedError("only zero-dimensional systems
> supported (finite n
>umber of solutions)")
>NotImplementedError: only zero-dimensional systems supported
> (finite number of s
>olutions)
>
> The two expressions end up getting different domains:
>[Poly(x**2 - 10*x + y**2 - 10*y + 46, x, y, domain='ZZ'),
> Poly(-x**2 + (-2*2**(1/2) + 10)*x - y**2 + 10*y - 50 +
> 10*2**(1/2), x, y, domain='EX')]
>
> If I get rid of the sqrt(2) then the domains are both ZZ and it works.
p2
>-(-x + 5)*(-x - 2*2**(1/2) + 5) - (-y + 5)**2
_.subs(sqrt(2),2)
>(-x + 1)*(x - 5) - (-y + 5)**2
solve([p1,_])
>[(4, -3**(1/2) + 5), (4, 3**(1/2) + 5)]
>
> What's the best way to make solve flexible so it will handle this?
>
> --
> 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] deleted ode test
That is a very old commit. If the reduction was hard, then it was probably moved to an XFAIL test. Are you sure it isn't in one of those? Aaron Meurer On May 24, 2011, at 8:28 PM, Chris Smith wrote: > e12fb20c2405b4fdcac8dff980c0b6637c46ec06 -- 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: Google Summer of Code has Started
Just a reminder to students that this means that you need to blog at some point this week. You don't have to do it until the end of the day on Saturday. But it's just a reminder that it needs to be done. If you don't have anything to blog about because you haven't done much yet, then a suggestion would be to blog a little bit about what you hope to achieve this summer with your project. Aaron Meurer On May 23, 2011, at 5:02 PM, Aaron Meurer wrote: > Hi. > > This is just a reminder to our nine Google Summer of Code students, > the mentors, and to the community in general, that Google Summer of > Code has official started as of today. The list of accepted projects > and student blogs is at > https://github.com/sympy/sympy/wiki/Gsoc-2011-report. Good luck to > all students and happy coding! > > 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.
Re: [sympy] Re: Singleton Inequalities
On May 24, 2011, at 7:41 PM, Matthew wrote:
> Cool. I'm going ahead with the changes. I'm currently blocking on the
> reduce_poly_inequalities function.
> It assumes that it's dealing with a list of Intervals which it then
> will return or turn into a relational. I have generalized this
> as_relational process to all sets but am having difficulty when it
> needs to create sets with inexact arithmetic.
>
> This python file has a special interval_evalf function used just for
> this one case which makes new intervals with evaluated numbers rather
> than exact ones. i.e.
> Interval(interval.left.evalf(), interval.right.evalf() )
>
> I don't want to make a union_evalf , finiteset_evalf, etc... but if I
> push this into a ._eval_evalf method then I'll end up overwriting the
> existing Interval._eval_evalf method which seems to be creating
> multiprecision intervals which are used for some other purpose.
>
> I guess I'm not sure exactly why the inexact bits are needed. When I
> remove this functionality it doesn't seem to break any tests. I'm not
> knowledgeable enough to know if this is important or not.
>
> Thoughts?
>
> Also, unrelated question. There are some tests which fail when I run
> bin/test but which pass when I run them from ipython or isympy. I
> suspect this is just something screwy with how I have things set up.
> Sound familiar to anyone?
>
> -Matt
Is it this issue: http://code.google.com/p/sympy/issues/detail?id=1379 ?
Aaron Meurer
>
>
>
>
> On May 24, 7:50 pm, Mateusz Paprocki wrote:
>> Hi,
>>
>> On 24 May 2011 17:42, Aaron S. Meurer wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Hi.
>>
>>> On May 24, 2011, at 5:50 PM, Matthew Rocklin wrote:
>>
>>>> Hi Everyone,
>>
>>>> I'm revamping Sets a bit as a precursor to my GSoC project. The first
>>> part of this is creating a FiniteSet object to go along with Intervals (like
>>> (0, 1] ) and Unions (like [-1,0) U (0, 1] ).
>>
>>>> I changed the default behavior of Interval(1,1) (interval from 1 to 1
>>> inclusive, i.e. [1, 1] ) to be just the FiniteSet {1} .
>>
>>>> Unfortunately it appears that Interval(a,a) has been used extensively in
>>> the inequalities module for things like
>>
>>>> reduce_poly_inequalities([[Eq(x**2, 1)]], x, relational=False) ==
>>> [Interval(-1,-1), Interval(1, 1)]
>>
>>>> My code changes the result to the FiniteSet {-1, 1} which I think makes
>>> more sense. I'm a little uneasy about going in and changing this much in
>>> modules with which I have little experience. Are people ok with this? Is
>>> there anyone I should converse with while dealing with this particular
>>> problem? (someone involved in inequalities)
>>
>>>> Best,
>>>> -Matt
>>
>>> So first off, you should run the tests. If they still pass, then it means
>>> that the code still works. This is why we have tests.
>>
>>> In this particular case, I think it's fine. That probably would have used
>>> a finite set anyway, if they had existed at the time. Mateusz wrote this
>>> code, so he could tell you more. But I personally am +1 to making
>>> Interval(a, a) return FiniteSet(a).
>>
>> That should work fine, but as Aaron said, change this run tests and see what
>> it the outcome.
>>
>>
>>
>>> 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.
>>
>> Mateusz
>
> --
> 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] Singleton Inequalities
Hi.
On May 24, 2011, at 5:50 PM, Matthew Rocklin wrote:
> Hi Everyone,
>
> I'm revamping Sets a bit as a precursor to my GSoC project. The first part of
> this is creating a FiniteSet object to go along with Intervals (like (0, 1] )
> and Unions (like [-1,0) U (0, 1] ).
>
> I changed the default behavior of Interval(1,1) (interval from 1 to 1
> inclusive, i.e. [1, 1] ) to be just the FiniteSet {1} .
>
> Unfortunately it appears that Interval(a,a) has been used extensively in the
> inequalities module for things like
>
> reduce_poly_inequalities([[Eq(x**2, 1)]], x, relational=False) ==
> [Interval(-1,-1), Interval(1, 1)]
>
> My code changes the result to the FiniteSet {-1, 1} which I think makes more
> sense. I'm a little uneasy about going in and changing this much in modules
> with which I have little experience. Are people ok with this? Is there anyone
> I should converse with while dealing with this particular problem? (someone
> involved in inequalities)
>
> Best,
> -Matt
>
So first off, you should run the tests. If they still pass, then it means that
the code still works. This is why we have tests.
In this particular case, I think it's fine. That probably would have used a
finite set anyway, if they had existed at the time. Mateusz wrote this code,
so he could tell you more. But I personally am +1 to making Interval(a, a)
return FiniteSet(a).
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.
Re: [sympy] deleted ode test
What is the SHA1 of the commit? Aaron Meurer On May 24, 2011, at 3:38 PM, smichr wrote: > I see that a test which is proving difficult to verify was deleted in > the commit that made this change: > > def test_1st_homogeneous_coeff_ode2(): > eq1 = f(x).diff(x) - f(x)/x+1/sin(f(x)/x) > eq2 = x**2 + f(x)**2 - 2*x*f(x)*f(x).diff(x) > eq3 = x*exp(f(x)/x) + f(x) - x*f(x).diff(x) > sol1 = Eq(f(x), x*acos(log(C1*x))) > sol2 = [Eq(f(x), sqrt(C1*x + x**2)), Eq(f(x), -sqrt(C1*x + > x**2))] > sol3 = Eq(f(x), log(log(C1/x)**(-x))) > # specific hints are applied for speed reasons > assert dsolve(eq1, f(x), > hint='1st_homogeneous_coeff_subs_dep_div_indep') == sol1 > assert dsolve(eq2, f(x), hint='1st_homogeneous_coeff_best') == > sol2 > assert dsolve(eq3, f(x), > hint='1st_homogeneous_coeff_subs_dep_div_indep') == sol3 > -assert checksol(eq1, f(x), sol1) > -assert checksol(eq2, f(x), sol2[0]) > -assert checksol(eq2, f(x), sol2[1]) > -assert checksol(eq3, f(x), sol3) <=== THIS ONE > +assert checksol(eq1, f(x), sol1, 1) > +assert checksol(eq2, f(x), sol2[0], 1) > +assert checksol(eq2, f(x), sol2[1], 1) > > Do you recall anything about this, Aaron? Or does anyone else see how > to verify the solution? > > -- > 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] Cancel with floating point numbers
That's basically correct. The problem is that certain polynomial algorithms
(in this case, polynomial division) rely on the ability to determine zero
equivalence in the coefficients. But floating point numbers, as we all know,
have the problem where they will often give something like 1e-14 instead of 0.
The solution is to replace the RR domain with RR(eps) domain, where eps is the
cutoff for zero (if 0 <= a < eps, then consider a == 0).
By the way, if anyone is interested, the problem comes from while loop at line
1268 of densearith.py. The loop breaks when the degree of r is less than the
degree of g, but in this case, on the final iteration where it should be less,
the leading term of r has a coefficient somewhere on the order of 1e-13 instead
of 0, so it goes through the loop one too many times. Since the loop
decrements N each time, this ends up becoming negative. This is the "negative
power" it complains about later.
Mateusz, would a suitable temporary fix for this be to put chop=True in key
places in the RR domain? I think a lot of people use floating point
coefficients, and they won't be happy to see errors like this one.
Aaron Meurer
On May 24, 2011, at 1:20 PM, Tom Bachmann wrote:
> Presumably mateusz (or aaron) know better than me, but the problem is simply
> that polys does not really work well with Floats.
>
> There is also an open issue (2384) related to this.
>
> On 24.05.2011 20:13, Chris Smith wrote:
>> Andy Ray Terrel wrote:
>>> Quite strange indeed.
>>>
>>> On my Mac Python 2.7, sympy.__version__ = 0.6.7 I get:
>>>
>>> In [17]: expr = (2.1 - 2.1*y**2 + 2*x)/x**3
>>>
>>> In [18]: sympy.simplify(expr)
>>> Out[18]: -inf
>>>
>> This raises an error for me:
>>
>> raise ValueError("can't raise polynomial to a negative power")
>> ValueError: can't raise polynomial to a negative power
>>
>> But if I nsimplify(..., rational=True) everthing works ok:
>>
>> h[12]>>> e1= (2.1 - 2.1*y**2 + 2*x)/x**3
>> h[12]>>> e2= (2.1*x*(1-y)**2+2*y*x)/ x**3
>> h[12]>>> e3= (sympy.Rational(21,10)*x*(1-y)**2 + 2*y*x) / X**3
>> h[12]>>> for e in [e1,e2,e3]:
>> ... print simplify(nsimplify(e,rational=True))
>> ...
>> (20*x - 21*y**2 + 21)/(10*x**3)
>> (21*y**2 - 22*y + 21)/(10*x**2)
>> x*(21*y**2 - 22*y + 21)/(10*X**3)
>>
>> CAUTION: you used an X instead of an x in the last equation.
>>
>
> --
> 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] imposing commutation relation
Actually, it looks like if you are using SymPy 0.6.7, there is a bug that makes
this return a wrong result:
In [1]: x, y = symbols('x y', commutative=False)
In [2]: a = expand((x + y)**3)
In [3]: a.subs(x*y, y*x + 1).expand().subs(x*y, y*x + 1).expand()
Out[3]:
22
1 + x + y + 2⋅y⋅x
The output below was from the latest development branch, and will be present in
the next release.
Aaron Meurer
On May 23, 2011, at 11:06 PM, Aaron S. Meurer wrote:
> Hi.
>
> On May 23, 2011, at 10:55 PM, Rajeev Singh wrote:
>
>> Hi,
>>
>> I asked this question on sage mailing list already and it seems appropriate
>> to ask here as well. I wish to simplify some calculation that appear in
>> quantum mechanics. To begin we use non-commutative variables as -
>>
>> sage: x, y = sympy.symbols('xy', commutative=False)
>> sage: sympy.expand((x+y)**3)
>> x**2*y + y**2*x + x*y**2 + y*x**2 + x**3 + y**3 + x*y*x + y*x*y
>
> Just a heads up, starting in the next release, symbols('xy') will create one
> symbol named xy, not two symbols x and y. To get around this, you should do
> symbols('x y') or symbols('x, y') (this works in the older release too, so
> you can start to change your code now).
>
>>
>> I want to impose the commutation relation [x,y]=1 and bring the expression
>> to normal form (i.e. in all terms y appears before x, e.g. x*y gets replaced
>> by y*x + 1). Is it possible to do this?
>
> You can do this by repeatedly calling subs and expanding, i.e.,
>
> In [9]: x, y = symbols('x y', commutative=False)
>
> In [10]: a = expand((x + y)**3)
>
> In [11]: a
> Out[11]:
>22 3 22 3
> x⋅y⋅x + x⋅y + x ⋅y + x + y⋅x⋅y + y⋅x + y ⋅x + y
>
> In [12]: a.subs(x*y, y*x + 1)
> Out[12]:
>3 2 2 3
> x⋅(1 + y⋅x) + x + y⋅x + y⋅(1 + y⋅x) + y ⋅x + y + (1 + y⋅x)⋅x + (1 + y⋅x)⋅y
>
> In [13]: a.subs(x*y, y*x + 1).expand()
> Out[13]:
>3 2 2 3
> 2⋅x + x⋅y⋅x + x + 2⋅y + y⋅x⋅y + 2⋅y⋅x + 2⋅y ⋅x + y
>
> In [16]: a.subs(x*y, y*x + 1).expand().subs(x*y, y*x + 1)
> Out[16]:
>3 22 3
> 2⋅x + x + 2⋅y + 2⋅y⋅x + y⋅(1 + y⋅x) + 2⋅y ⋅x + y + (1 + y⋅x)⋅x
>
> In [17]: a.subs(x*y, y*x + 1).expand().subs(x*y, y*x + 1).expand()
> Out[17]:
>3 2 2 3
> 3⋅x + x + 3⋅y + 3⋅y⋅x + 3⋅y ⋅x + y
>
> This could easily be automated with a while loop (repeat until a is
> unchanged).
>
>>
>> If not then can I get the expression such that x*y**2 appears as x*y*y?
>
> That would be more difficult to do, because y*y is automatically converted to
> y**2. But, as you can see, subs is smart enough to handle x*y**2 correctly,
> so there's no need to use this much less simple form.
>
> Aaron Meurer
>
>>
>> Thanks in advance.
>>
>> Regards,
>> Rajeev
>>
>> --
>> 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] imposing commutation relation
Hi.
On May 23, 2011, at 10:55 PM, Rajeev Singh wrote:
> Hi,
>
> I asked this question on sage mailing list already and it seems appropriate
> to ask here as well. I wish to simplify some calculation that appear in
> quantum mechanics. To begin we use non-commutative variables as -
>
> sage: x, y = sympy.symbols('xy', commutative=False)
> sage: sympy.expand((x+y)**3)
> x**2*y + y**2*x + x*y**2 + y*x**2 + x**3 + y**3 + x*y*x + y*x*y
Just a heads up, starting in the next release, symbols('xy') will create one
symbol named xy, not two symbols x and y. To get around this, you should do
symbols('x y') or symbols('x, y') (this works in the older release too, so you
can start to change your code now).
>
> I want to impose the commutation relation [x,y]=1 and bring the expression to
> normal form (i.e. in all terms y appears before x, e.g. x*y gets replaced by
> y*x + 1). Is it possible to do this?
You can do this by repeatedly calling subs and expanding, i.e.,
In [9]: x, y = symbols('x y', commutative=False)
In [10]: a = expand((x + y)**3)
In [11]: a
Out[11]:
22 3 22 3
x⋅y⋅x + x⋅y + x ⋅y + x + y⋅x⋅y + y⋅x + y ⋅x + y
In [12]: a.subs(x*y, y*x + 1)
Out[12]:
3 2 2 3
x⋅(1 + y⋅x) + x + y⋅x + y⋅(1 + y⋅x) + y ⋅x + y + (1 + y⋅x)⋅x + (1 + y⋅x)⋅y
In [13]: a.subs(x*y, y*x + 1).expand()
Out[13]:
3 2 2 3
2⋅x + x⋅y⋅x + x + 2⋅y + y⋅x⋅y + 2⋅y⋅x + 2⋅y ⋅x + y
In [16]: a.subs(x*y, y*x + 1).expand().subs(x*y, y*x + 1)
Out[16]:
3 22 3
2⋅x + x + 2⋅y + 2⋅y⋅x + y⋅(1 + y⋅x) + 2⋅y ⋅x + y + (1 + y⋅x)⋅x
In [17]: a.subs(x*y, y*x + 1).expand().subs(x*y, y*x + 1).expand()
Out[17]:
3 2 2 3
3⋅x + x + 3⋅y + 3⋅y⋅x + 3⋅y ⋅x + y
This could easily be automated with a while loop (repeat until a is unchanged).
>
> If not then can I get the expression such that x*y**2 appears as x*y*y?
That would be more difficult to do, because y*y is automatically converted to
y**2. But, as you can see, subs is smart enough to handle x*y**2 correctly, so
there's no need to use this much less simple form.
Aaron Meurer
>
> Thanks in advance.
>
> Regards,
> Rajeev
>
> --
> 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: syntax for results of solve and dsolvev
On May 23, 2011, at 6:23 PM, Ronan Lamy wrote:
> Le lundi 23 mai 2011 à 18:01 -0600, Aaron S. Meurer a écrit :
>> On May 23, 2011, at 4:43 PM, Ronan Lamy wrote:
>>
>>> Le lundi 23 mai 2011 à 12:53 -0600, Aaron S. Meurer a écrit :
>>>> On May 22, 2011, at 9:50 AM, Chris Smith wrote:
>>>>
>>>>> Ronan Lamy wrote:
>>>>>> Le dimanche 22 mai 2011 à 14:38 +0545, Chris Smith a écrit :
>>>>>>>
>>>>>>> I think that sets make more sense, too, but it's useful to
>>>>>>> have the
>>>>>>> variables in the output, and dicts are the easiest way to
>>>>>>> handle them.
>>>>>>> What about using sets of frozen dicts? Frozen dicts aren't
>>>>>>> builtins
>>>>>>> but there are simple free implementations (I just adapted one
>>>>>>> from
>>>>>>> http://code.activestate.com/recipes/414283/), that work in
>>>>>>> all python
>>>>>>> versions. They can easily be converted to/from dicts and subs
>>>>>>> should
>>>>>>> be able to use them directly.
>>>>>>>
>>>>>>> The way 1694ms is designed now, the solve routine is just a wrapper
>>>>>>> to _solve (which contains the core solving routines). It would be
>>>>>>> easy to add keywords to control the output in any variety of ways.
>>>>>>> _solve will return [(x1, x2, ...), (v11, v12, ..), (v21, v22, ...)
>>>>>>> ...] where the xi are the symbols and vij is the jth solution for
>>>>>>> variable i; solve can then remap this to whatever we decide upon.
>>>>>>>
>>>>>> But this can't generalise to infinite solution sets. Why do you want
>>>>>> to
>>>>>> repeat part of the input (the variables) in the output? In
>>>>>> solve(Eq(x**2, 1), x), x should be a bound variable. If you put it in
>>>>>> the output, you make it free.
>>>>>
>>>>> Because as long as we support symbol guessing (so solve(x - 3) works AND
>>>>> solve([x + y - 2, x - y - 3]) works) we need to disambiguate the output
>>>>> for the multi-equation system since it gives rise to ambiguity as I
>>>>> recently showed: you can't know if you are getting x, y pairs or y, x
>>>>> pairs.
>>>>>
>>>>> We could say that the results will always be sorted according to the free
>>>>> symbols of the equations if the symbols were guessed, but then the user
>>>>> has to assemble that in order to interpret the output...which defeats the
>>>>> purpose of symbol_guessing. If we had a free_symbols function then I
>>>>> guess we could make it work with an iterable so someone could do
>>>>>
>>>>> eqs = [x + y - 2, x - y - 3]
>>>>> syms = free_symbols(eqs)
>>>>> solve(eqs, *syms)
>>>>>
>>>>> But with that much typing they may as well have just looked and typed x,
>>>>> y after 'eqs,' So let's get rid of symbol guessing?
>>>>
>>>> -1. Even without guessing, referencing the solutions by the symbol
>>>> makes things easier to read and to reference programmatically. It's
>>>> much easier to say sol[x] than to figure out what position x was in and
>>>> call sol[i].
>>>
>>> OK, let's say it's a hassle to have to remember that x is in position 0
>>> after typing solve(equations, (x, y, z)) or to have to write
>>> dict(zip(variables, solution)). The dict solution has bigger problems:
>>> * no way to extend it to infinite solution sets
>>
>> Why not? There are an infinite number of solutions, but still a finite
>> number of variables.
>>
> Sure, but the problem is how to return an infinity of dicts. With just
> the values, you can have solve(x**2 > 1) == Interval(-1, 1). How do you
> handle that with dicts?
{x: Interval(-1, 1)}
>
>>> * you need to remember the variable in the univariate case
>>> * you can't use the solution without knowing the variables. This makes
>>> it very cumbersome to use a function like the following:
>>> def solve_stuff(...):
>>> x, y, z = [Dummy() for _ in range(3)]
>>> f = Lambda(...
Re: [sympy] Re: syntax for results of solve and dsolvev
On May 23, 2011, at 4:43 PM, Ronan Lamy wrote: > Le lundi 23 mai 2011 à 12:53 -0600, Aaron S. Meurer a écrit : >> On May 22, 2011, at 9:50 AM, Chris Smith wrote: >> >>> Ronan Lamy wrote: >>>> Le dimanche 22 mai 2011 à 14:38 +0545, Chris Smith a écrit : >>>>> >>>>> I think that sets make more sense, too, but it's useful to >>>>> have the >>>>> variables in the output, and dicts are the easiest way to >>>>> handle them. >>>>> What about using sets of frozen dicts? Frozen dicts aren't >>>>> builtins >>>>> but there are simple free implementations (I just adapted one >>>>> from >>>>> http://code.activestate.com/recipes/414283/), that work in >>>>> all python >>>>> versions. They can easily be converted to/from dicts and subs >>>>> should >>>>> be able to use them directly. >>>>> >>>>> The way 1694ms is designed now, the solve routine is just a wrapper >>>>> to _solve (which contains the core solving routines). It would be >>>>> easy to add keywords to control the output in any variety of ways. >>>>> _solve will return [(x1, x2, ...), (v11, v12, ..), (v21, v22, ...) >>>>> ...] where the xi are the symbols and vij is the jth solution for >>>>> variable i; solve can then remap this to whatever we decide upon. >>>>> >>>> But this can't generalise to infinite solution sets. Why do you want >>>> to >>>> repeat part of the input (the variables) in the output? In >>>> solve(Eq(x**2, 1), x), x should be a bound variable. If you put it in >>>> the output, you make it free. >>> >>> Because as long as we support symbol guessing (so solve(x - 3) works AND >>> solve([x + y - 2, x - y - 3]) works) we need to disambiguate the output for >>> the multi-equation system since it gives rise to ambiguity as I recently >>> showed: you can't know if you are getting x, y pairs or y, x pairs. >>> >>> We could say that the results will always be sorted according to the free >>> symbols of the equations if the symbols were guessed, but then the user has >>> to assemble that in order to interpret the output...which defeats the >>> purpose of symbol_guessing. If we had a free_symbols function then I guess >>> we could make it work with an iterable so someone could do >>> >>> eqs = [x + y - 2, x - y - 3] >>> syms = free_symbols(eqs) >>> solve(eqs, *syms) >>> >>> But with that much typing they may as well have just looked and typed x, y >>> after 'eqs,' So let's get rid of symbol guessing? >> >> -1. Even without guessing, referencing the solutions by the symbol >> makes things easier to read and to reference programmatically. It's >> much easier to say sol[x] than to figure out what position x was in and >> call sol[i]. > > OK, let's say it's a hassle to have to remember that x is in position 0 > after typing solve(equations, (x, y, z)) or to have to write > dict(zip(variables, solution)). The dict solution has bigger problems: > * no way to extend it to infinite solution sets Why not? There are an infinite number of solutions, but still a finite number of variables. > * you need to remember the variable in the univariate case > * you can't use the solution without knowing the variables. This makes > it very cumbersome to use a function like the following: > def solve_stuff(...): >x, y, z = [Dummy() for _ in range(3)] >f = Lambda(...) >return solve(f(x, y, z), (x, y, z)) > * you can't cache solve results in any useful way, because solve(x-1) != > solve(y-1) > * putting the variables in the dict lets temporary symbols escape the > scope they were created in - this is exactly the kind of situation that > prevents Vinzent's local assumptions hack from making new-style > assumptions a viable alternative to the old ones. I don't understand how they escape the scope. 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.
Re: [sympy] Re: syntax for results of solve and dsolvev
On May 22, 2011, at 9:50 AM, Chris Smith wrote: > Ronan Lamy wrote: >> Le dimanche 22 mai 2011 à 14:38 +0545, Chris Smith a écrit : >>> >>>I think that sets make more sense, too, but it's useful to >>>have the >>>variables in the output, and dicts are the easiest way to >>>handle them. >>>What about using sets of frozen dicts? Frozen dicts aren't >>>builtins >>>but there are simple free implementations (I just adapted one >>>from >>>http://code.activestate.com/recipes/414283/), that work in >>>all python >>>versions. They can easily be converted to/from dicts and subs >>>should >>>be able to use them directly. >>> >>> The way 1694ms is designed now, the solve routine is just a wrapper >>> to _solve (which contains the core solving routines). It would be >>> easy to add keywords to control the output in any variety of ways. >>> _solve will return [(x1, x2, ...), (v11, v12, ..), (v21, v22, ...) >>> ...] where the xi are the symbols and vij is the jth solution for >>> variable i; solve can then remap this to whatever we decide upon. >>> >> But this can't generalise to infinite solution sets. Why do you want >> to >> repeat part of the input (the variables) in the output? In >> solve(Eq(x**2, 1), x), x should be a bound variable. If you put it in >> the output, you make it free. > > Because as long as we support symbol guessing (so solve(x - 3) works AND > solve([x + y - 2, x - y - 3]) works) we need to disambiguate the output for > the multi-equation system since it gives rise to ambiguity as I recently > showed: you can't know if you are getting x, y pairs or y, x pairs. > > We could say that the results will always be sorted according to the free > symbols of the equations if the symbols were guessed, but then the user has > to assemble that in order to interpret the output...which defeats the purpose > of symbol_guessing. If we had a free_symbols function then I guess we could > make it work with an iterable so someone could do > > eqs = [x + y - 2, x - y - 3] > syms = free_symbols(eqs) > solve(eqs, *syms) > > But with that much typing they may as well have just looked and typed x, y > after 'eqs,' So let's get rid of symbol guessing? -1. Even without guessing, referencing the solutions by the symbol makes things easier to read and to reference programmatically. It's much easier to say sol[x] than to figure out what position x was in and call sol[i]. 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.
Re: [sympy] os invariant?
On May 23, 2011, at 12:49 PM, Mateusz Paprocki wrote: > Hi, > > On 23 May 2011 20:46, Aaron S. Meurer wrote: > > On May 23, 2011, at 12:40 PM, Chris Smith wrote: > > > Aaron S. Meurer wrote: > >>> On May 22, 2011, at 9:31 PM, Renato Coutinho wrote: > >>> > >>>> On Mon, May 23, 2011 at 12:28 AM, Mateusz Paprocki > >>>> wrote: > >>>>> Hi, > >>>>> > >>>>> On 23 May 2011 05:18, smichr wrote: > >>>>>> > >>>>>> Will list(e.free_symbols) be OS independent? > >>>>> > >>>>> .free_symbols is implemented using sets so it is platform (hash) > >>>>> dependent (I mean order of elements). > >>>> > >>>> But sets don't have any ordering (except for printing or iterating, > >>>> but you shouldn't use it). I think sorted(list(e.free_symbols)) > >>>> should > >>>> be safe. > >>>> > >>>> Cheers, > >>>> Renato > >>> > >>> No, sorted uses __le__, which for symbols uses the hash, so that too > >>> will be platform dependent (granted it's better than list(set), > >>> which might return a different thing within the same session). > >>> > >>> Why do you need to have a list instead of a set? > >>> > > If you have `solve([x+y-3,x-y-1])` you need an unambiguous way to return > > the tuples if you aren't going to return the results with the symbols. You > > could get set([Tuple(1, 2)]) or set([Tuple(2, 1)]) so you need a way to > > internally send back something unambiguous. > > > > I think it should just return the result with the symbols. > > Or use sorted_key to get hash independent ordering. Even then, it isn't clear at all to the user what refers to what. I think we should return a dictionary. Aaron Meurer > > > 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. > > > Mateusz > > -- > 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] os invariant?
On May 23, 2011, at 12:40 PM, Chris Smith wrote: > Aaron S. Meurer wrote: >>> On May 22, 2011, at 9:31 PM, Renato Coutinho wrote: >>> >>>> On Mon, May 23, 2011 at 12:28 AM, Mateusz Paprocki >>>> wrote: >>>>> Hi, >>>>> >>>>> On 23 May 2011 05:18, smichr wrote: >>>>>> >>>>>> Will list(e.free_symbols) be OS independent? >>>>> >>>>> .free_symbols is implemented using sets so it is platform (hash) >>>>> dependent (I mean order of elements). >>>> >>>> But sets don't have any ordering (except for printing or iterating, >>>> but you shouldn't use it). I think sorted(list(e.free_symbols)) >>>> should >>>> be safe. >>>> >>>> Cheers, >>>> Renato >>> >>> No, sorted uses __le__, which for symbols uses the hash, so that too >>> will be platform dependent (granted it's better than list(set), >>> which might return a different thing within the same session). >>> >>> Why do you need to have a list instead of a set? >>> > If you have `solve([x+y-3,x-y-1])` you need an unambiguous way to return the > tuples if you aren't going to return the results with the symbols. You could > get set([Tuple(1, 2)]) or set([Tuple(2, 1)]) so you need a way to internally > send back something unambiguous. > I think it should just return the result with the symbols. 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.
Re: [sympy] Ideas for extending Mul
On May 22, 2011, at 7:43 PM, Andy Ray Terrel wrote: > On Sun, May 22, 2011 at 7:27 PM, Aaron S. Meurer wrote: >> >> On May 22, 2011, at 12:12 PM, Mateusz Paprocki wrote: >> >> Hi, >> >> On 22 May 2011 18:17, Aaron S. Meurer wrote: >>> >>> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])? >> >> It works: >> In [2]: import operator >> In [3]: reduce(operator.mul, [x, y, z]) >> Out[3]: x⋅y⋅z >> In [4]: type(_) >> Out[4]: >> but I wouldn't use it on large examples because it takes O(n**2) steps to >> canonicalize the inputs (similar problem with sum([x,y,z]), we have even an >> issue open for this). >> >> No, I mean is there a way for literally "x*y*z" to call (essentially) >> reduce(operator.mul, [x, y, z])? >> But like you said, it is O(n**2), so I guess it doesn't matter (unless you >> can also do it O(n)). >> Aaron Meurer > > > Well it wouldn't work either. It would be an infinite loop. > operator.mul just calls the dispatches to the appropriate > .__mul__/.__rmul > > — Andy Well, that's why I said "essentially". Actually, obviously just vanilla "x*y*z" is equivalent to reduce(operator.mul, [x, y, z]). The problem comes when you associate the arguments, like (x*y)*z or x*(y*z). That's where even the double dispatch can mess up. Though one might argue that it should mess it up, since that is the way to make it do another thing. Aaron Meurer > >> >> >>> >>> Aaron Meurer >>> >>> >>> On May 21, 2011, at 9:11 PM, Andy Ray Terrel >>> wrote: >>> >>>> My experience with developing languages in Ignition, is largely the >>>> same as what Brian outlined. Another solution though is to instead of >>>> doing much of the Mul(args) in the core, to do reduce(operator.mul, >>>> args). Since things get expanded into Mul objects they don't hit my >>>> own mul objects. Right now I have to do ugly hack that fix things up >>>> after the fact. >>>> >>>> -- Andy >>>> >>>> On Sun, Jul 25, 2010 at 1:04 PM, Brian Granger >>>> wrote: >>>>> >>>>> >>>>> On Sat, Jul 24, 2010 at 5:14 PM, Ronan Lamy >>>>> wrote: >>>>>> >>>>>> Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit : >>>>>>> >>>>>>> I written tests for this now. >>>>>>> >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger >>>>>>> wrote: >>>>>>>Here is an addition patch that adds this capability to all >>>>>>>binary special methods in Expr: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1 >>>>>>> >>>>>>> >>>>>>>The performance penalty is still around 1%. If there is >>>>>>>support for this approach, I would like to merge it to trunk >>>>>>>soon as this issue is holding up the quantum stuff. Also I >>>>>>>was thinking that in the long run this could improve >>>>>>>performance. Here is the idea. Currently, all of the basic >>>>>>>operation classes (Mul, Add, Pow) have to have custom logic to >>>>>>>non commutative entities. With the new priority based binary >>>>>>>operations, we could implement an NCMul, and NCPow classes >>>>>>>that have all of that logic. The result is that the work Mul >>>>>>>and Pow have to do decreases. It would also be much simpler. >>>>>> >>>>>> I'm not sure this is the best design, but it's better than the current >>>>>> situation, so +1 on the idea. Two remarks though: >>>>> >>>>> Any other ideas of different approaches? I followed this one because it >>>>> has >>>>> been well tested in numpy. >>>>> >>>>>> >>>>>> * Since the whole point of this is to untie binary operators from Expr, >>>>
Re: [sympy] os invariant?
On May 22, 2011, at 9:31 PM, Renato Coutinho wrote: > On Mon, May 23, 2011 at 12:28 AM, Mateusz Paprocki wrote: >> Hi, >> >> On 23 May 2011 05:18, smichr wrote: >>> >>> Will list(e.free_symbols) be OS independent? >> >> .free_symbols is implemented using sets so it is platform (hash) dependent >> (I mean order of elements). > > But sets don't have any ordering (except for printing or iterating, > but you shouldn't use it). I think sorted(list(e.free_symbols)) should > be safe. > > Cheers, > Renato No, sorted uses __le__, which for symbols uses the hash, so that too will be platform dependent (granted it's better than list(set), which might return a different thing within the same session). Why do you need to have a list instead of a set? 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.
Re: [sympy] planet.sympy.org update
On May 22, 2011, at 11:12 AM, Ondrej Certik wrote: > On Sun, May 22, 2011 at 8:47 AM, Aaron S. Meurer wrote: >> >> On May 21, 2011, at 10:10 PM, Ondrej Certik wrote: >> >>> Hi, >>> >>> I have refactored all the code running planet.sympy.org and it is now >>> fully hosted by github. The repository is here: >>> >>> https://github.com/sympy/planet.sympy.org >>> >>> see the README for information how it works. The blogs subscriptions >>> are in planet.ini: >>> >>> https://github.com/sympy/planet.sympy.org/blob/master/planet.ini >>> >>> can you please send me updates with your blog feed url (e.g. all new >>> GSoC students)? >> >> The GSoC student blog links are all at >> https://github.com/sympy/sympy/wiki/Gsoc-2011-report. > > Those are only the blog links, but not the feeds. We need the feeds, > e.g. some people might choose to have all their blog to appear at > planet.sympy.org, some other people might only choose a specific tag > (like I did). So we need the actual feeds. > > Ondřej You can get the feeds from the blog. In Safari (and I think Firefox too), there is an RSS button to the right of the address bar that gives it to you. And in any rate, there will be a link on the blog somewhere. Of course, if a student blogs about other stuff and the sympy stuff is under a particular tag, then he should give us the link for the feed for only that tag. 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.
Re: [sympy] Ideas for extending Mul
On May 22, 2011, at 5:16 PM, Andy Ray Terrel wrote: > On Sun, May 22, 2011 at 1:49 PM, Andy Ray Terrel > wrote: >> On Sun, May 22, 2011 at 1:12 PM, Mateusz Paprocki wrote: >>> Hi, >>> >>> On 22 May 2011 18:17, Aaron S. Meurer wrote: >>>> >>>> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])? >>> >>> It works: >>> In [2]: import operator >>> In [3]: reduce(operator.mul, [x, y, z]) >>> Out[3]: x⋅y⋅z >>> In [4]: type(_) >>> Out[4]: >>> but I wouldn't use it on large examples because it takes O(n**2) steps to >>> canonicalize the inputs (similar problem with sum([x,y,z]), we have even an >>> issue open for this). >>> >> >> Yes this was my fear. Maybe Ronan's comment on the double dispatch >> will work better. > > > Just to be clear, the problem is not so much when the class Mul calls > the Mul constructor but when other classes (like Add or simplify) call > Mul directly instead of the operators. The style in sympy seems to > prefer this to using the algebraic operators. These calls will > basically always route around *any* dispatch system unless it is tied > into the expression constructors. > > One solution would be to have _op_priority checked inside the > constructor, that way the canonicalization could remain O(n) but the > correct constructor could then be called. Mul's internals could call a > private constructor to side step check every call. > > — Andy Even if we used the double dispatch, we could make Mul check the arguments to see if they are dispatchable before canonizing them. The only problem here might be the performance, because you would have to call __mul__ or __rmul__ on each object to see if it returns something or returns NotImplemented. Maybe we could require objects to implement some obj.__has_mul(other) that would quickly indicate whether obj.__mul__(other) would return NotImplemented or something else (and the same for __mul__). We could probably implement further optimizations for regular sympy objects that will always just combine in the Mul, like some property of those objects that would just be set to True and you don't have to call the function. Does that sound like it would work? Does it make sense? Aaron Meurer > >> >> -- Andy >> >>>> >>>> Aaron Meurer >>>> >>>> >>>> On May 21, 2011, at 9:11 PM, Andy Ray Terrel >>>> wrote: >>>> >>>>> My experience with developing languages in Ignition, is largely the >>>>> same as what Brian outlined. Another solution though is to instead of >>>>> doing much of the Mul(args) in the core, to do reduce(operator.mul, >>>>> args). Since things get expanded into Mul objects they don't hit my >>>>> own mul objects. Right now I have to do ugly hack that fix things up >>>>> after the fact. >>>>> >>>>> -- Andy >>>>> >>>>> On Sun, Jul 25, 2010 at 1:04 PM, Brian Granger >>>>> wrote: >>>>>> >>>>>> >>>>>> On Sat, Jul 24, 2010 at 5:14 PM, Ronan Lamy >>>>>> wrote: >>>>>>> >>>>>>> Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit : >>>>>>>> >>>>>>>> I written tests for this now. >>>>>>>> >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger >>>>>>>> wrote: >>>>>>>>Here is an addition patch that adds this capability to all >>>>>>>>binary special methods in Expr: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1 >>>>>>>> >>>>>>>> >>>>>>>>The performance penalty is still around 1%. If there is >>>>>>>>support for this approach, I would like to merge it to trunk >>>>>>>>soon as this issue is holding up the quantum stuff. Also I >>>>>>>>was thinking that in the long run this could improve >>>>>>>>performance. Here is the idea. Currently, all of the basic >
Re: [sympy] Ideas for extending Mul
On May 22, 2011, at 12:12 PM, Mateusz Paprocki wrote: > Hi, > > On 22 May 2011 18:17, Aaron S. Meurer wrote: > Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])? > > It works: > > In [2]: import operator > > In [3]: reduce(operator.mul, [x, y, z]) > Out[3]: x⋅y⋅z > > In [4]: type(_) > Out[4]: > > but I wouldn't use it on large examples because it takes O(n**2) steps to > canonicalize the inputs (similar problem with sum([x,y,z]), we have even an > issue open for this). No, I mean is there a way for literally "x*y*z" to call (essentially) reduce(operator.mul, [x, y, z])? But like you said, it is O(n**2), so I guess it doesn't matter (unless you can also do it O(n)). Aaron Meurer > > > Aaron Meurer > > > > On May 21, 2011, at 9:11 PM, Andy Ray Terrel wrote: > > My experience with developing languages in Ignition, is largely the > same as what Brian outlined. Another solution though is to instead of > doing much of the Mul(args) in the core, to do reduce(operator.mul, > args). Since things get expanded into Mul objects they don't hit my > own mul objects. Right now I have to do ugly hack that fix things up > after the fact. > > -- Andy > > On Sun, Jul 25, 2010 at 1:04 PM, Brian Granger wrote: > > > On Sat, Jul 24, 2010 at 5:14 PM, Ronan Lamy wrote: > > Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit : > I written tests for this now. > > > Brian > > On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger > wrote: >Here is an addition patch that adds this capability to all >binary special methods in Expr: > > > > http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1 > > >The performance penalty is still around 1%. If there is >support for this approach, I would like to merge it to trunk >soon as this issue is holding up the quantum stuff. Also I >was thinking that in the long run this could improve >performance. Here is the idea. Currently, all of the basic >operation classes (Mul, Add, Pow) have to have custom logic to >non commutative entities. With the new priority based binary >operations, we could implement an NCMul, and NCPow classes >that have all of that logic. The result is that the work Mul >and Pow have to do decreases. It would also be much simpler. > > I'm not sure this is the best design, but it's better than the current > situation, so +1 on the idea. Two remarks though: > > Any other ideas of different approaches? I followed this one because it has > been well tested in numpy. > > > * Since the whole point of this is to untie binary operators from Expr, > the mechanism (i.e. call_other()) shouldn't be implemented in expr.py. > > OK > > > * The repetitiveness of the code should be abstracted away in a > decorator. > > > I was thinking that as well. This is especially true because people who > want to define their won special methods that respect the priority will need > to use the decorator. > Cheers, > Brian > > > > -- > 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. > > > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > bgran...@calpoly.edu > elliso...@gmail.com > > -- > 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+unsu
Re: [sympy] Ideas for extending Mul
Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])? Aaron Meurer On May 21, 2011, at 9:11 PM, Andy Ray Terrel wrote: My experience with developing languages in Ignition, is largely the same as what Brian outlined. Another solution though is to instead of doing much of the Mul(args) in the core, to do reduce(operator.mul, args). Since things get expanded into Mul objects they don't hit my own mul objects. Right now I have to do ugly hack that fix things up after the fact. -- Andy On Sun, Jul 25, 2010 at 1:04 PM, Brian Granger wrote: On Sat, Jul 24, 2010 at 5:14 PM, Ronan Lamy wrote: Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit : I written tests for this now. Brian On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger > wrote: Here is an addition patch that adds this capability to all binary special methods in Expr: http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1 The performance penalty is still around 1%. If there is support for this approach, I would like to merge it to trunk soon as this issue is holding up the quantum stuff. Also I was thinking that in the long run this could improve performance. Here is the idea. Currently, all of the basic operation classes (Mul, Add, Pow) have to have custom logic to non commutative entities. With the new priority based binary operations, we could implement an NCMul, and NCPow classes that have all of that logic. The result is that the work Mul and Pow have to do decreases. It would also be much simpler. I'm not sure this is the best design, but it's better than the current situation, so +1 on the idea. Two remarks though: Any other ideas of different approaches? I followed this one because it has been well tested in numpy. * Since the whole point of this is to untie binary operators from Expr, the mechanism (i.e. call_other()) shouldn't be implemented in expr.py. OK * The repetitiveness of the code should be abstracted away in a decorator. I was thinking that as well. This is especially true because people who want to define their won special methods that respect the priority will need to use the decorator. Cheers, Brian -- 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. -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- 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] Re: Remove _op_priority before the release?
On May 22, 2011, at 9:34 AM, Andy Ray Terrel wrote: > On Sat, May 21, 2011 at 10:51 PM, Ondrej Certik wrote: >> On Sat, May 21, 2011 at 8:21 PM, Andy Ray Terrel >> wrote: >>> On Sat, May 21, 2011 at 10:10 PM, Ronan Lamy wrote: Le samedi 21 mai 2011 à 21:50 -0500, Andy Ray Terrel a écrit : > On Sun, May 15, 2011 at 6:54 PM, Brian Granger > wrote: >> On Sat, May 14, 2011 at 1:49 PM, Vinzent Steinberg >> wrote: >>> On 14 Mai, 18:31, Ronan Lamy wrote: _op_priority was designed to help with implementing arithmetic operations, particularly for things that aren't "calculus expressions" yet have meaningful __add__, __mul__, __pow__, etc. such as vectors and operators of various kinds. But it turns out that it doesn't really help (http://groups.google.com/group/sympy/browse_thread/thread/810e127bc41...) and it isn't used anywhere currently. It also has fundamental flaws that prevent it from ever evolving into a complete solution to the problem: it assumes that the priority order is the same for all operations and turns this order into a total order, introducing couplings between objects that would otherwise have no knowledge of each other. So, I think that there's little benefit in including into 0.7.0, but it would have the significant drawback of committing us to support this feature for who knows how long, and therefore of making much more difficult to refactor this critical mechanism. And if _op_priority does turn out to be useful, it can easily be added back in after the release by reverting the removal. >>> >>> If it is not used, I think we can remove it. >> >> +1 >> > > Please don't do this. I use op_priority all the time. Its the one > reason I haven't release my code because I depend on this > functionality. You're a bit late: it's been removed already, in 041995d37563f1e0743c75a311035b553f66741e. But we could revert that commit. Can you open an issue and link to code that uses _op_priority? >>> >>> Hmm the last three weeks have been a blur for me. >>> >>> My whole tensor library [0] depends on it, and I thought it was a great >>> idea even if it seems incomplete because core code will just call Mul, >>> Add, ... never giving the custom call a callback. >>> >>> issue opened at [1] >> >> Does anyone know a better solution to fix this problem? >> >> If not, then I am +1 to push it back in, and improve upon it later. >> >> Andy -- is sympy missing some tests, that your library depends on? If >> so, we should add it into sympy, so that we make sure things don't get >> broken. Once somebody implements a better solution, we'll simply >> provide an upgrade path. > > test_priority from that commit was what I was using. But roughly I > need multiple dispatch so I can override the dispatch of the algebraic > operators. If SymPy doesn't want to support this I can move to the > pymoblics system. > > -- Andy > >> >> Ondřej _op_priority is kind of a bad way to do this, in my opinion, but I don't know of another way to do it that would be as easy to implement. Does anyone have any ideas? Otherwise, I suggest we use and support it until we come up with a better system. 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.
Re: [sympy] planet.sympy.org update
On May 22, 2011, at 9:47 AM, Aaron S. Meurer wrote: > > On May 21, 2011, at 10:10 PM, Ondrej Certik wrote: > >> Hi, >> >> I have refactored all the code running planet.sympy.org and it is now >> fully hosted by github. The repository is here: >> >> https://github.com/sympy/planet.sympy.org >> >> see the README for information how it works. The blogs subscriptions >> are in planet.ini: >> >> https://github.com/sympy/planet.sympy.org/blob/master/planet.ini >> >> can you please send me updates with your blog feed url (e.g. all new >> GSoC students)? > > The GSoC student blog links are all at > https://github.com/sympy/sympy/wiki/Gsoc-2011-report. > > Aaron Meurer > Except for Saptarshi's. Saptarshi, can you add the link to your blog there? Aaron Meurer >> >> For example my blog is http://ondrejcertik.blogspot.com, and my blog >> feed is: http://ondrejcertik.blogspot.com/feeds/posts/default/-/sympy, >> which means that only blogposts that I tag with "sympy" will appear on >> planet.sympy.org. You can send a pull request, or just send me the >> link and I'll update it. >> >> Ondřej > -- 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] planet.sympy.org update
On May 21, 2011, at 10:10 PM, Ondrej Certik wrote: > Hi, > > I have refactored all the code running planet.sympy.org and it is now > fully hosted by github. The repository is here: > > https://github.com/sympy/planet.sympy.org > > see the README for information how it works. The blogs subscriptions > are in planet.ini: > > https://github.com/sympy/planet.sympy.org/blob/master/planet.ini > > can you please send me updates with your blog feed url (e.g. all new > GSoC students)? The GSoC student blog links are all at https://github.com/sympy/sympy/wiki/Gsoc-2011-report. Aaron Meurer > > For example my blog is http://ondrejcertik.blogspot.com, and my blog > feed is: http://ondrejcertik.blogspot.com/feeds/posts/default/-/sympy, > which means that only blogposts that I tag with "sympy" will appear on > planet.sympy.org. You can send a pull request, or just send me the > link and I'll update it. > > Ondřej -- 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] Reorganise the package structure
On May 20, 2011, at 8:44 PM, Ronan Lamy wrote: > I think it would be good to tidy up our package structure before the > release, because we won't get another opportunity to do so for quite a > while. Here's a list of things to consider in no particular order, > bearing in mind that compatibility with 0.6.7 shouldn't be broken > without a good reason but that anything that wasn't in 0.6.7 is fair > game: > * All modules should be accessible by name, meaning that after 'import > sympy.foo.bar', sympy.foo.bar should be the imported module. This is a > problem mostly for sympy.series (cf. issue 2263) and sympy.simplify. > * sympy.simplify contains much more than just simplify(), so it deserves > a more generic name, maybe 'manipulation', and could possibly include a > few more modules from sympy.utilities and sympy.core (exprtools). How about sympy.simplification, sympy.simplifying, or sympy.simplifiers? Those both suggest module names to me, and would never be function names. > * Code generation should get its own subpackage. +1 > * The distinction between sympy.logic and sympy.assumptions doesn't make > that much sense. I'd prefer them to be merged into sympy.logic I agree with Christian here. Logic is separate from assumptions, and could be expanded a lot. > * sympy.matrices could be renamed sympy.linalg (impacts Sherjil's > project) If Sherjil's project will break compatibility in other things in the module, then this can wait. > * sympy.concrete has a weird name. I can guess it doesn't refer to the > construction material, but I don't see what's particularly concrete > about it, compared to most other subpackages. Why not 'discrete'? It comes from a book by Knuth (http://en.wikipedia.org/wiki/Concrete_mathematics). I like the name concrete. To me, "discrete" suggests more things, like set theory (especially relating to finite sets), combinatorics, discrete probability, graph theory, etc. (these are all topics taught in a course at my university called "discrete mathematics", and I believe that word is in the textbook title as well). > * Inside sympy.polys, all the 'whatevertools' and 'polythingy' should > just be called 'whatever' and 'thingy' respectively, though I don't know > what to do about 'polytools'. I think the poly*.py files are algorithms that directly go up to the Poly class. And I think "tools" has some meaning there. For example, densebasic.py holds the most basic dense polynomial algorithms (like dmp_zero_p, the low level equivalent of Poly.is_zero), and densetools.py holds more advanced ones (like the decomposition algorithm from decompose()). There's also densearith.py for arithmetical operations (like multiplication). Maybe Mateusz could chime in on this. > * 'sympy.core.core' is awkward. Maybe 'sympy.core.meta' instead? > > What do you think? And do you see anything else? How much of a compatibility break would renaming these things be, do you think? Probably most people don't import things by module name. 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.
Re: [sympy] Wolfram|Alpha
This is kind of similar to the oeis() function (issue 2203). Maybe we should create a module for these kinds of things. It should to in utilities. Aaron Meurer On May 21, 2011, at 2:11 PM, Ondrej Certik wrote: > On Sat, May 21, 2011 at 12:27 PM, Vinzent Steinberg > wrote: >> Hi, >> >> apparently it is possible to use a JSON api [1] to Wolfram|Alpha with >> 2000 noncommercial calls per month. I think we could integrate it into >> sympy, with having each user specify his own Wolfram ID. This might be >> useful for e.g. quickly checking an integral and comparing it with >> sympy's result etc. >> >> What do you think? > > At least to be able to produce a correct wolfram alpha JSON query from > a sympy expression. What the user does with it is his own thing. > > Just like we have Mathematica printer, and just like we aim with our > Plot function to also be able to return a correct google chart api. > > So definitely. > > 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: Symbolic Combinatorics: Permutations
I agree. Like I said, unless you want to create very abstract objects that represent permutations with symbolic n, which would be implemented completely differently from the explicit permutations, then don't worry about symbolic support for this one. The main thing for the issue of making things symbolic is to make things that return Expr instances (like numbers) be classes instead of functions. Aaron Meurer On May 18, 2011, at 2:08 PM, Alexey U. Gudchenko wrote: > 18.05.2011 17:15, Haz пишет: >> On Wed, May 18, 2011 at 8:47 AM, Vinzent Steinberg < >> vinzent.steinb...@googlemail.com> wrote: >> >>> >>> I'm a bit worried about performance if you use Expr instances. Maybe >>> have a low-level integer representation, so you can implement a high- >>> level interface later which works for arbitrary elements, but does the >>> computations using the fast representation? This could be an object >>> that stores the mapping between your arbitrary finite set and the >>> integers together with the integer representation, and maps back >>> automatically for printing etc. >>> >> >> This was precisely the plan from what I gather (Saptarshi can correct me >> if I'm wrong), but the question was primarily what the interface to the >> function should be (in the context of keeping things as symbolic as >> possible). >> >> Cheers, >> Christian >> > > If I understand the thread correctly, you want to *apply* the > permutation to the various lists of symbols. > > You wrote about: >> Specific algorithms that operate on permutations will be implemented > to work with arbitrary Expr objects as best possible. > > But (the others seems have said it similar) I should like to separate > the problems of the creation/usage of the permutations itself (the > notation of it, its internal representations and algorithms) on the one > hand and applying of some permutations to the lists or tuples on the > other hand. So, interface e.g. > > creation, notation: Permutation([1, 3, 2]) ># or Permutation(1, 3, 2) >Permutation(1, 3, 2) pprint Permutation(1, 3, 2) # representation >(1. 3, 2) > pprint Permutation([2, 1], [5, 4]) # (only cycles) >(2, 1, 3, 5, 4) print Permutation([2, 1], [5, 4]).short_notation() >(2, 1)(5, 4) > > > Apply to some lists: > p = Permutation([1, 3, 2]) p.reorder([x, y, z]) # or something else >[x, z, y] > > > In this case it is not needed to operate with specific algorithms (for > representation symbols) into the permutation realization. We use pure > permutations (1..n) with its own algorithms and only then apply > permutation to the objects which we like. > > Also, one can use the binding of the representation symbols with > permutation: > p = Permutation([1, 3, 2]) p.bind_symbols(x, y, z) p >(x, z, y) > > But interesting how the permutations with different bindings will be > work together in this case. So, I think, it is not needed indeed. > > Alexey U. > > -- > 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: Symbolic Combinatorics: Permutations
So I guess it might be less useful to do this with permutation per se than for
some of the other things in Saptarshi's GSoC project. The example I gave in
the comment to his proposal was that he should do things like
class Totient(Expr):
def __init__ ...
instead of
def totient(n):
...
Even if there aren't any fancy symbolic manipulations that you can do on a
Totient object, you still get the advantage of being able to manipulate it
symbolically in other expressions. This might make less sense for Permutation,
which wouldn't even be Expr. But definitely for those functions that would
just return a number, you should be able to give the symbolic arguments, like
>>> n = Symbols('n', integer=True)
>>> a = Totient(n)**2
>>> a
2
φ (n)
>>> a.subs(n, 42)
12
There probably *are* things you could do with symbolic permutations, even where
n is symbolic, but they would probably be completely different algorithms, so
if you don't want to focus on that, you could skip it, I think. But it could
be useful. For example, if you had some kind of abstract tensor module, it
could be the underlying data structure that handles things like epsilon_{1,
..., n}.
Aaron Meurer
On May 17, 2011, at 2:14 PM, Mike Hansen wrote:
> On May 17, 12:35 pm, Haz wrote:
>>> You don't have this issue if your data structure is say a list of
>>> cycles or a dict, but you do if you want to, say, compute the number
>>> of inversions or descents.
>>
>> Aye, I guess what I'm saying is that because of the canonical ordering, we
>> have an implicit dict from the provided list -- the identity permutation
>> being the sorted order.
>
> Yep, it's just not obvious what that order is until you actually
> compute it. Also, it's possible that order may change in the future
> depending on sympy's implementation. I think it's best to stick to
> 1,...,n for now unless you have a specific use case in mind. It will
> make the implementation faster and more straightforward.
>
> --Mike
>
> --
> 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] Sympy on Android (SL4A with Python)
I don't own an Android, but can you not somehow cd into the sympy directory and run ./setup.py install? Aaron Meurer On May 8, 2011, at 5:11 AM, Roberto Colistete Jr. wrote: >Hi, > >It is my first participation here : how can I install Sympy on > Android (using SL4A with Python) ? I tried copying the "sympy" tree to > "/sdcard/com.googlecode.pythonforandroid/extras/python/" but I try > loading sympy (with "import sympy", for example) I get many error > messages. > >I use Sympy on Symbian/S60v3 (N95, E63, etc) without problems > (only without graphics). I also use Sympy on Maemo OS 5 (Nokia N900) > and Ubuntu 10.04 64 bits (notebook). > > Keep the nice work on Sympy, > > Roberto -- 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: Assumptions
On May 6, 2011, at 6:09 PM, Alexey U. Gudchenko wrote: > 02.05.2011 20:25, Ronan Lamy пишет: >> Le dimanche 01 mai 2011 à 23:37 -0700, Ondrej Certik a écrit : > >>> >>> You should assume it. Non commutative symbols are just making things >>> very complicated, and it was a mistake to add them into the core of >>> sympy. They should start in sympy.quantum, and only after they are >>> being used a lot, we should start thinking how to handle them >>> properly. >> >> I agree on this. Non-commutative Symbols don't make a lot of sense. If >> we didn't have them (and severed the inheritance from Boolean), we could >> say that Symbols are complex variables. Instead, we have a murky >> definition. >> Anyway, is_commutative is just an extreme example. Most .__new__() >> and .eval() methods check one assumption or other. We'd have to throw >> all that code away and rewrite it from scratch. >> > > > Non-commutative Symbols are generalization, commutative Symbols are > specialization. (Remarking that it is a pure mathematica, not a quantum - > because there are no physical lows used when we consider Non-commutative > Symbols), > but I agree that temporary it can be placed in sympy.quantum for tactic aims. > > In any case it would be convinient (and for effective core - to avoid > unnesesary checking) to isolate in the core the possibility to work with > commutative Symbols and possibility to work with non-commutative Symbols (or > even with non-associative symbols). Now, as I understand, in the SymPy core > the non-commutative core is not isolated, and at the same time by defult the > is_commutative is switch off (False) - but many unnecessary checking are used > further and we continue to deal with commutative. Basically, the Mul (in Mul.flatten()) keeps track of a commutative and non-commutative part of an expression. The problem with keeping it in the core is that every function has to properly handle non-commutatives. There are quite a few cases where functions make the assumption that the expression is entirely commutative and return wrong results as a result. This also goes back to the extensibility/editability of the core. If you want to modify the core, and do it correctly, you need to make sure non-commutative expressions are handled correctly. Aaron Meurer > > So the isolation is needed in any case (effective core) - even after "we > should start thinking how to handle them properly". > > May be the interface of objects can be used for this. > > This type of assumption is classified as related with algebraic fields/rings. > (For this type of assumptions may be meaningless to attach assumption to > symbols at whole ) > > -- > Alexey U. -- 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 May 6, 2011, at 10:32 AM, Ronan Lamy wrote:
> Le jeudi 05 mai 2011 à 20:18 +0100, Tom Bachmann a écrit :
>> First of all thanks alexey, for steering the discussion into an
>> important direction!
>>
>> On 05.05.2011 19:42, Alexey U. Gudchenko wrote:
>>> Well, when I have concerned the assumptions, I noticed, first of all,
>>> that they are used for this users aims:
>>>
>>> (a) simplification.
>>> Assumption help us to simplify expressions for the user.
>>> he typical example:
>>>
>> sqrt(x**2)
>>> abs(x) # x is Real
>> _
>>> x # x is positive.
>>>
>>> Complex case (related with expression):
>> sqrt((x + y)**2)
>>> abs(x + y)# (x + y) is Real
>> _
>>> (x + y) # (x + y) is positive.
>>>
>>>
>>>
>>> BTW. It would be good when the CAS can analyze some complex expression,
>>> and offer to the user what assumptions can simplify those expressions.
>>>
>> how_to_simplify(sqrt(x**2))
>>> [assume that x is positive: then sqrt(x**2) --> x, ...]
>>>
>>>
>>> BTW, the assumption `x is positive` have nothing better than `x is
>>> grater then, saying, 7`. The reasons of its existence are the same.
>>>
>>> BTW, `is_positive` assumptions have special classification type (it is
>>> distinguished from assumption `is_zero` which related with another sort
>>> of assumption).
>>>
>>>
>>> (b) Mathematical assumptions. The typical example: whether we are on
>>> some field or on another.
>>>
>>> BTW, This construction can resolve problem to ask assumption system
>>> permanently during the calculations.
>>> if we have some nested or sets of general function {`A`, `B`, `C`}, and
>>> every of them internally analaze the assumptions and have code blockes
>>> like "A: A_complex if arg complex, A_real, if arg real...", so they can
>>> grouped to sets {`A_real`, `B_real`, `C_real`} without internal asking
>>> about assumptions.
>>>
>>> One can say that those methods has domain parameter, like in Sage, or in
>>> Polys in SymPy (if I am not mistaken).
>>>
>>> I have sowen that Tom already added at the wiki page about connection
>>> asuumptions with algebras (That's good).
>>>
>>> (c) In general, especially when we consider them from programmatic side
>>> (not mathematically) Assumptions plays the role of rules how to
>>> calculate or simplify expressions. Nothing else.
>>>
>>> The typical example is:
>> 1/0
>>> oo (assume that we are deal with reals)
>> 1/0
>>> zoo (assume that we in complex)
>>>
>>> (In this case an assumption must not be related with symbols)
>>>
>>> I noticed that (c) (assumtions are the rules not only for symbols, but
>>> for operations too, how to deal with them) is a general case of the
>>> assumption system. Is not it? But we must catch the balanse how to
>>> describe assumtions
>
> For me, (c) isn't part of the assumption system. It's rather an
> interpreter setting that should only be used by client code and not
> within sympy (counting isympy as client code). Also, I'm not sure if
> that's exactly what you're suggesting, but having Integer(1)/Integer(0)
> return different results based on context is bad - for exactly the same
> reasons as Basic.keep_sign.
I agree. Having global directives like this is a bad idea, if just because it's
extremely annoying to test. To do it correctly, you would have to run the
tests with it off and then again with it on, which causes a combinatorial
explosion in the number of combinations we have to test. Of course, in
reality, if the module is well tested on its own, you should only have to run
the tests for that module (like in theory, you should only have to run the
polys tests in the different ground types). But furthermore, if some test sets
the global parameter (like was happening with keep_sign), you get different
results depending on what order the tests are run in.
This is one of the reasons why I'm presently leaning toward some kind of local
assumptions implementation, like Vinzent's.
Aaron Meurer
>
From it immediately followed that it is not quite correct:
>>>
>>> 01.05.2011 23:35 +0400, Tom Bachmann
Every assumption is about symbols.
>>>
>>
>> I think that my statement is true, or at least should be true.
>> Everything that is not a symbol (or involves a symbol) is some concrete
>> mathematical entity, and all of its properties are settled (in
>> principle, in practice it might be hard to find out if a certain number
>> is e.g. positive, even if it is specified uniquely).
>>
>> So basically I'm saying that things like "I'm an integer" or "I'm
>> commutative" are not really assumptions, they are type information if
>> you will. Integer(1) is not the same as Rational(1) is not the same as
>> eye (identity matrx).
>>
>> So in particular ExtendedReal(1)/ExtendedReal(0) = oo,
>> ExtendedComplex(1)/ExtendedComplex(0) = zoo, Real(1)/Real(0) = nan, or
>> perhaps even an exception [unless we do some auto-conversion].
>>
>> So we t
Re: [sympy] Re: Assumptions
On May 5, 2011, at 1:00 PM, Haz wrote: > > > On Thu, May 5, 2011 at 12:29 PM, Aaron Meurer wrote: > > The big questions that remain are those involving (1): it is generally > > accepted that the old assumption system should give way to the new one, but > > to what extent we remove the old ones from the core? How the new ones > > replace the old ones? What is the syntax that we will use for them? What > > "assumptions" will we make about the assumption system? (i.e., local -vs- > > global context by default) > > Well, one of the biggest problems with having the assumptions in the > core is that any time you want to edit the assumptions you have to > edit the core. Having them separate should make them much more > extensible. > > It's worth picking apart that sentiment. When I say "to what extent we > remove the old ones from the core?", I am considering the fact that > is_positive may still remain as a function of Expr. The fact that it > internally calls an ask(...) of the new assumption system is besides the > point. I mean that for example the logic to compute sqrt(x**2) => abs(x) or x is all in the core (that's just Pow(Pow(x, 2), S(1)/2)). If we want to add a new assumption that doesn't exist yet, we would have to modify all the core methods to handle it correctly. But if the core is just calling Ask() everywhere, or even better if simplification is left to some handle function like refine(), then this isn't a problem. Aaron Meurer > > Also, maybe I am wrong, but I think it would be easier to have > something like Ask(expr, Q.whatever, Assume(x>y)) with the new system. > At any rate, this sort of things cannot be done with our current > is_assumption system (how do you assume x>y using that?). > > These are a level of complex assumptions that are out of the scope of what > the new assumption system can handle. It requires a higher form of reasoning > (potentially FOL, etc). > > Cheers -- 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: Assumptions
On May 4, 2011, at 4:52 PM, Tom Bachmann wrote: > >>> Singleton objects are useful for more important things than optimising >>> '==' with 'is'. They represent 'sui generis' objects that have specific >>> behaviour. But that wasn't my point (not that you could have known it, >>> given that I forgot half the words in my final parenthesis). I meant >>> that having Integer(42) and Rational(42) being different, barely related >>> objects, is unintuitive and makes it hard to extend an existing >>> structure with additional objects. IIUC, to have something like >>> S.Infinity in Sage, you'd need to create a >>> TwoPointCompactifiedExtendedRealLine algebra and convert all your real >>> objects to it (granted, the last one seems to happen automagically). >> >> +1. When I was working on the doctests in the polys, I was fixing some bugs >> in the domains, and I noticed that it's much cleaner to have QQ(2, 1) not >> automatically convert to ZZ(2). The SymPy domain required all kinds of >> special code to check for singletons and automatic casting like that, which >> would break if, for example, a new number was made into a singleton. >> > > I think you are actually +1-ing here the opposite of Ronan's statement, or do > I mis-understand what you are saying? Well, I guess at least one of us is misunderstanding Ronan. Let's just say that I am +1 to my own statement :) Aaron Meurer > I would agree to that latter interpretation: Integer(1) and Rational(1) > *should* be clearly distinguished, although related objects. This is even so > in "ordinary mathematics", as can be seen with some (admittedly contrived) > questions like "what is the cardinality of 1?". > -- 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: Assumptions
On May 4, 2011, at 2:06 PM, Ronan Lamy wrote:
> Le mercredi 04 mai 2011 à 20:09 +0200, Fredrik Johansson a écrit :
>> On Tue, May 3, 2011 at 11:24 PM, Ronan Lamy wrote:
>>> Le mardi 03 mai 2011 à 22:02 +0100, Tom Bachmann a écrit :
On 03.05.2011 21:47, Ondrej Certik wrote:
> On Tue, May 3, 2011 at 8:44 AM, Fredrik Johansson
> wrote:
>> On Tue, May 3, 2011 at 3:00 PM, Tom Bachmann wrote:
>>> Actually how does this relate to the following wiki page:
>>>
>>> https://github.com/sympy/sympy/wiki/Algebras-in-SymPyCore
>>
>> It's roughly the same thing.
>
> I also think that what Fredrik says might be a good idea. I don't have
> much experience with this to have a clear opinion though. The reason I
> have just used Add/Mul/Pow classes for everything in SymPy (long time
> ago) is that it is conceptually a super simple idea, and it got us
> very far. E.g. from the Zen of Python:
>
> 1) Simple is better than complex (Add/Mul/Pow is simpler than all the
> algebras+other machinery)
> 2) Complex is better than complicated (the algebras are probably
> better than the complicated entangled assumptions+cache)
>
>
> As such, I now that we can get very fast just with Add/Mul/Pow (see
> the csympy code: https://github.com/certik/csympy), and when using
> Refine() and other things, we should be able to have core not using
> assumptions nor cache, be fast, and using the new assumptions in
> refine(). That fixes the current sympy, using pretty much the same
> architecture.
>
I don't find that a very convincing argument (which is not saying you
are wrong, of course). Given a specific problem everyone (given enough
time, energy, and general cleverness) can come up with a nice and clean
solution that is also fast. The problem with comparing this to current
sympy is that current sympy does *a lot* more. E.g. all of the core
classes (Mul, Pow etc) treat orders, non-commutative symbols, etc etc.
Now you may rightly argue that this should not be in core, but I suppose
you do not want to throw it away either...
This is why I think the algebras approach is better: there different
algebras can manage expressions of different complexity. So lots of
things that are in current core and slow us down can just become part of
more specialised algebras. Note also that csympy would/could then become
the "core" algebra, achieving a final synthesis of approaches.
>>>
>>> I don't understand that argument. You could just as well say, with
>>> sympy's current design, that different expressions can be implemented by
>>> different classes, etc. The big issue I see with these algebras is that
>>> it creates a design that's more functional than object-oriented and
>>> destroys the identity of objects that belong to several structures (e.g.
>>> in Sage, Integer(1) are different objects).
>>
>> I don't see how this is "more functional than object-oriented". On the
>> contrary, using a class to encapsulate the notion of an algebra is
>> more object-oriented than spreading the equivalent code across various
>> methods in an ad-hoc fashion (for example, having Mul know about lots
>> of different mathematical objects that can be multiplied) and choosing
>> between options mostly by passing flags to functions. The code in Sage
>> is quite clean, and very easy to extend (often easier than doing the
>> same thing in SymPy).
>>
> Calling algebra.mul(a, b) instead of a.__mul__(b) is what I mean when I
> say "more functional than object-oriented". Now, it's true that
> Mul.flatten() is a cesspit of ugliness, but that's precisely because
> __mul__ methods call Mul() instead of the other way round.
>
>> That's not to say SymPy should necessarily adopt an identical
>> approach, but it's worth thinking about using explicit objects
>> (whether they are called "algebras", "rings", "contexts", etc) to
>> distinguish between different classes of mathematical objects and to
>> store options.
>
> I'm not sure about options, but having explicit objects representing
> mathematical types is certainly a good idea. The natural way of doing
> that in Python is to use a class.
>
>> Whether singleton objects are used for special values like 1 is rather
>> a trivial issue and completely orthogonal to other design
>> considerations. AFAIK, the current design exists only for performance
>> reasons ('is' is much faster than '==' in Python, but this is mostly
>> irrelevant with C-based types, and it can be worked around fairly
>> easily in Python anyhow).
>>
> Singleton objects are useful for more important things than optimising
> '==' with 'is'. They represent 'sui generis' objects that have specific
> behaviour. But that wasn't my point (not that you could have known it,
> given that I forgot half the words in my final parenthesis). I meant
> that having Integer(42) and Ration
Re: [sympy] Re: Assumptions
On May 3, 2011, at 6:30 PM, Ondrej Certik wrote: > On Tue, May 3, 2011 at 2:02 PM, Tom Bachmann wrote: >> On 03.05.2011 21:47, Ondrej Certik wrote: >>> >>> On Tue, May 3, 2011 at 8:44 AM, Fredrik Johansson >>> wrote: On Tue, May 3, 2011 at 3:00 PM, Tom Bachmann wrote: > > Actually how does this relate to the following wiki page: > > https://github.com/sympy/sympy/wiki/Algebras-in-SymPyCore It's roughly the same thing. >>> >>> I also think that what Fredrik says might be a good idea. I don't have >>> much experience with this to have a clear opinion though. The reason I >>> have just used Add/Mul/Pow classes for everything in SymPy (long time >>> ago) is that it is conceptually a super simple idea, and it got us >>> very far. E.g. from the Zen of Python: >>> >>> 1) Simple is better than complex (Add/Mul/Pow is simpler than all the >>> algebras+other machinery) >>> 2) Complex is better than complicated (the algebras are probably >>> better than the complicated entangled assumptions+cache) >>> >>> >>> As such, I now that we can get very fast just with Add/Mul/Pow (see >>> the csympy code: https://github.com/certik/csympy), and when using >>> Refine() and other things, we should be able to have core not using >>> assumptions nor cache, be fast, and using the new assumptions in >>> refine(). That fixes the current sympy, using pretty much the same >>> architecture. >>> >> >> I don't find that a very convincing argument (which is not saying you are >> wrong, of course). Given a specific problem everyone (given enough time, >> energy, and general cleverness) can come up with a nice and clean solution >> that is also fast. The problem with comparing this to current sympy is that >> current sympy does *a lot* more. E.g. all of the core classes (Mul, Pow etc) >> treat orders, non-commutative symbols, etc etc. Now you may rightly argue > > Please list the "etc., etc.": > > * Non-commutative symbols should not be handled by the core. And if > they do, it's easy to create an NCMul class, as it used to be long > time ago in sympy. > > * orders: don't understand this point, why it should cause any problems This is probably the same sort of thing that we worked on in Los Alamos. The core should be rewritten so that it doesn't specifically know about things that combine into other things, like Order, infinity, etc. See http://code.google.com/p/sympy/issues/detail?id=1941. I'm also +1 on removing non-commutativity from the core. How should we do it. Should we just have an NCMul class whose first argument is a Mul (or Atom), which would be the non-commutative part? Aaron Meurer > >> that this should not be in core, but I suppose you do not want to throw it >> away either... > > The noncommutative symbols not assumptions are used a lot, except in > special cases here and there in tests. Those tests should be made to > pass obviously, but we should not be constrained by the fact, that we > "can't throw away old assumptions". Christian's branch showed that > indeed that is possible. > > Ondřej > -- 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] SymPy's mission
So there has been some discussion recently, both on and off list, as to what SymPy is and what it should be. That is why I think that we need to have a mission statement, which clearly outlines what SymPy is and where it should go. Fortunately, I think we have really had one all along. I think the standard description of SymPy at the top of our website, the Google Code page, and a bunch of other places is a perfect mission statement. This is it, except I have added "open source," because I think that's important to have in there. "SymPy is an open source Python library for symbolic mathematics. It aims to become a full-featured computer algebra system (CAS) while keeping the code as simple as possible in order to be comprehensible and easily extensible. SymPy is written entirely in Python and does not require any external libraries." To break this up into its component parts: "SymPy is an open source…" SymPy is BSD licensed, which means that people can incorporate the code in non-open source projects. This is a good thing, because it lets people use SymPy who otherwise wouldn't be able to. BSD is a good choice for libraries like SymPy. But the core library code should always be open source. I don't think anyone would disagree with this, but it's important to have it in the statement. … Python library…" SymPy should be written in Python. See below. "… for symbolic mathematics. It aims to become a full-featured computer algebra system (CAS)…"" This is one of the places where we have had disagreements recently. The core goal of SymPy is to become a full-featured CAS. This means that we should try to become just as powerful as any of the great CASs out there, like Maple, Mathematica, Axiom, etc. So if you could see something being implemented in one of those, then it can be implemented in SymPy to. Just take a look at the diversity of our GSoC projects this year. Some of them are very core CAS, like the Groebner bases project or the Meijer G-Function integration project. Others are a little more external, like the quantum projects or the PyDy project. But these all belong on SymPy because they are things that you could easily see being part of a CAS like Maple, and they all relate to symbolic manipulation. We have things that are not directly related to symbolic manipulation, like the mpmath numerical library and plotting. But of course, these things belong in a CAS (it's hard to imagine Maple or Mathematica being unable to do plotting, for example). "… while keeping the code as simple as possible in order to be comprehensible and easily extensible." I don't think there is much to elaborate on here, and I doubt many people will disagree with this. One thing that I want to mention is that the fact that SymPy is written in Python, which is a very clean language, means that the algorithms will be very easy to read. Python also makes the source code very accessible. So it is very easy for someone to dig in and learn how something works. "SymPy is written entirely in Python and does not require any external libraries." This is important. You should be able to use SymPy with nothing but Python installed. Sure, some features might require some external library or further dependencies (like plotting for example), but you should be able to use the core functionality of SymPy with nothing but Python. The lack of any required external dependencies is also important. It makes it very easy to use SymPy anywhere. For example, a high school student could use SymPy on his personal account on the school computers, so long as those computer have Python installed, even if he doesn't have any administrative privileges on those computers, simply by downloading the tarball and running isympy out of the bin directory. I'm sure others will have some examples of why this is a good idea. 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.
Re: [sympy] Re: Assumptions
I agree that Frederik's idea is an interesting one, but we would need to have other people who understand it well if we were to attempt to implement it. If you could write something up on the wiki, it would go a long way towards this. Aaron Meurer On May 2, 2011, at 11:49 AM, Haz wrote: > A summary would indeed help. I have another fear though, that this idea > (while enticing) is not largely understood (afaik). This puts the burden of > re-working SymPy into mainly your hands, Fredrik, where patching SymPy to > work with the new assumptions can be jointly tackled (evidenced by the vast > number of branches that exist for doing just that). > > On Mon, May 2, 2011 at 1:42 PM, Tom Bachmann wrote: > On 2 Mai, 18:26, Fredrik Johansson > wrote: > > On Mon, May 2, 2011 at 5:46 PM, Haz wrote: > > > Tom: Apologies, but I'm having trouble inferring what you github username > > > is > > > -- where is the branch? > > > Fredrik: I like the idea, but that seems like a massive shift in the SymPy > > > core that I don't feel is possible in the time frame that the assumptions > > > need to be fixed in. > > > > I don't think it's necessarily that much work. The only essential > > thing that needs to be done is to provide every expression object with > > a reference to its parent algebra, and to overwrite sympification to > > convert inputs to have the same parent. Everything else can be > > implemented gradually. The major obstacles ought to be caching and the > > current assumptions -- which need to go anyway. > > > > Would it be too much to ask for a coherent outline of this proposal on > the wiki? (By coherent I don't mean "less confused" but "more > complete".) What you describe indeed sounds nice and clean to me, but > I have difficulty piecing things together (in particular I know e.g. > nothing about sage). > > Tom > > -- > 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] Re: Assumptions
On May 1, 2011, at 2:40 PM, Haz wrote: > This is the chunk that things get done in: > - https://github.com/sympy/sympy/blob/master/sympy/core/cache.py#L75 > > Have a global variable called working, and a local variable called first. > Put this at the top of wrapper: > > first = False > > if not working: > working = True > first = True > > ...and just before returning anything: > > if first: > working = False > clear_cache() # Or whatever equivalent is needed to flush it out. If I understand it correctly, this assumes that the cache is needed only within calls of the outermost decorated function, but not between them. Does this hold for the Gruntz code that uses the caching? Aaron Meurer > > Essentially you only enable the cache for the time that sympy is computing > something. And yes, gruntz uses some assumptions during it's calculations, > but that is a rare case and can be handled with local assumption contexts or > cleaning the assumptions they use if it is global (which is how I handled it > last summer). > > The only overhead this should impose is cleaning the cache at the end of a > computation -- minimal I would suspect. > > On Sun, May 1, 2011 at 3:52 PM, Tom Bachmann wrote: > On 1 Mai, 20:45, Haz wrote: > > > > The example may sound contrived, but it does arise in practice, and > > > > was > > > a > > > > headache to debug. > > > > > Well there must be an end to it, right? Every assumption is about > > > symbols. Every symbol x that depends in any way on another symbol y > > > has y in its free_symbols. In fact any exrpession has all symbols it > > > depends on (recursively) in its free_symbols. Hence it would be enough > > > to pull all assumptions involving any free symbols into the hash > > > computation. > > > > > Right? [If not then one point in the above chain of argument must be > > > wrong; this is very well possible :-)] > > > > x may not depend on y if the right assumptions exist on y, and x is > > simplified. What you're suggesting may work if the hash is computed before > > the simplification occurs, but then you're bringing information about the > > equation into the hash before the equation is dealt with (and as Aaron > > points out, this could have some performance issues). > > > > I'm not sure I understand. The result of any given invocation of a > function should depend only on the arguments passed, and possibly on > assumptions on the arguments. If the assumptions are stored with the > arguments we are fine, if the assumptions are passed around > explicitely (as ondej suggests) we are fine, if the assumptions are > stored separately, they have to be pulled in. > > > But back to my original suggestion -- can anyone see something wrong with > > flushing the cache after a sympy command is invoked? The reason this has > > potential for solving the problem is because the assumptions aren't apt to > > changing while sympy is computing a result (only in between commands). This > > means the gruntz can still do its thing with the cache, etc. > > This still feels wrong to me. Firstly, how do you even define "after a > sympy command"? Sympy is a library with many entry opints (at least I > see it as such). > Secondly, even inside sympy assumptions can be changed. For example > the gruntz algorithm always (locally) adds an assumption to the > variable with respect to which the limit is being taken (it currently > uses a fresh Dummy, but with flexible assumptions in place this would > not be necessary). > > -- > 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] Re: Assumptions
On May 1, 2011, at 1:35 PM, Tom Bachmann wrote: > On 1 Mai, 16:40, Haz wrote: >> The cache issue runs deeper -- variable x, that depends on variably y, may >> simplify to something that doesn't even involve y because of the assumptions >> that come with y. In this case, a result is stored for x that is only valid >> under the right assumptions for y, and we would need to be very careful >> about what cache entries change when we delete y. >> >> The example may sound contrived, but it does arise in practice, and was a >> headache to debug. >> > > Well there must be an end to it, right? Every assumption is about > symbols. Every symbol x that depends in any way on another symbol y > has y in its free_symbols. In fact any exrpession has all symbols it > depends on (recursively) in its free_symbols. Hence it would be enough > to pull all assumptions involving any free symbols into the hash > computation. > > Right? [If not then one point in the above chain of argument must be > wrong; this is very well possible :-)] > > Of course then we want a quick way to find all assumptions involving a > given symbol. The easiest would be to have the symbol store a list of > assumptions it is involved in. … Which brings us back to ronan's > comment that all this is not much different from storing assumptions > with the symbols anyway. Even if we were to decide that this was a good idea (I'm personally still not convinced), we also need to consider the speed implications. Hash computation should be very fast. Aaron Meurer > >> On Sat, Apr 30, 2011 at 2:21 PM, Tom Bachmann wrote: >> >> >> It should also be emphasized that it isn't just a simple notion of cleaning up assumptions after yourself -- the cache interacts in quite an intertwined way. Under the right assumptions, expressions will be simplified, and variables will be assigned certain values. If that's >>> stored in the cache, changing any related assumption will invalidate the result. >> >>> Why not make assumptions part of the hash of an object? At least to >>> the extent that the cache is concerned? >> >>> -- >>> 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] Re: SymPy Bot
On May 1, 2011, at 12:44 PM, Ondrej Certik wrote: > On Sun, May 1, 2011 at 10:30 AM, Aaron S. Meurer wrote: >> On Apr 30, 2011, at 11:13 PM, Ondrej Certik wrote: >> >>> On Sat, Apr 30, 2011 at 4:10 PM, Vinzent Steinberg >>> wrote: >>>> On Apr 30, 11:59 pm, Ondrej Certik wrote: >>>>> Well, that would not be the biggest problem. The biggest problem is >>>>> that gist doesn't have API for uploading yet, see here: >>>>> >>>>> http://develop.github.com/p/gist.html >>>> >>>> This is the oldest API (v1). The newest one has full gist support: >>>> >>>> http://developer.github.com/v3/gists/ >>> >>> Wow, thanks for this! I was not aware of the v3 API at all. Well in >>> that case, gist is a possibility. Let's see if pastehtml goes down >>> again, and if it does, we can switch to gist (maybe there is even some >>> way to serve html, but maybe not). >>> >>> Ondřej >>> >> >> If you upload html source and click on "raw", it shows the webpage. For >> example, I copied the source of wikipedia.org at >> https://gist.github.com/raw/950664/92f51a583bd4be1c104859cc0a66cb6e3c83ac7b/wikipedia.html, >> and you can see the webpage just as the original at >> https://gist.github.com/raw/950664/92f51a583bd4be1c104859cc0a66cb6e3c83ac7b/wikipedia.html >> (it might matter that I named the gist "wikipedia.html"). > > For me (Ubuntu, Chrome), both links show the html source, not the actual page. > > Ondřej Ah, so it must depend on the browser. It does that for me in Chrome too, and also in Firefox, but in Safari it works. There should be a way to make it work anywhere, though, but I don't know enough about html or web browsers to know what that might be. By the way, I meant for the first link to be https://gist.github.com/950664. 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.
Re: [sympy] Re: Assumptions
Hi.
Can everyone add these ideas to that wiki page? So there should be global
assumptions, local assumptions, etc., with links to the relevant branches, and
explanations of the idea, the pros, the cons, etc. I think it will be a lot
easier to just read through the wiki page whenever we make a decision, rather
than trying to read through this and other discussions.
On May 1, 2011, at 10:36 AM, Ondrej Certik wrote:
> On Sun, May 1, 2011 at 8:18 AM, Vinzent Steinberg
> wrote:
>> On May 1, 8:47 am, Ondrej Certik wrote:
>>> I am still very much convinced, that this disconnect-assumptions-2 is
>>> the simplest and easiest way to get rid of the old assumptions, so
>>> that we can start speeding up the core, and start using some other
>>> system for them.
>>
>> I'm not convinced, because it uses global assumptions, and I think
>> they are broken by design. Global assumptions basically let us do the
>> garbage collection manually, a regression compared to the old system.
>
> There is some misunderstanding (possibly on my side): I thought that
> the branch has removed the assumptions completely, thus it uses no
> assumptions. Then the idea was to use *local* assumptions, by using
> the Assume class.
>
> Can you clarify what you mean by "global assumptions" in this branch?
> I am aware that the code in sympy/assumptions also (besides other
> things) allows to use global assumptions, and I stress that this is
> not the approach I am voting for I am voting for using a local
> Assume (or AssumeContext) whatever you want to call it.
>
>>
>>> I would be interested in the community vote on this idea. I vote +1. I
>>> am aware that Ronan voted -1 last year. What do others think?
>>
>> I don't think that any branch is ready to be merged now, so maybe
>> let's rather discuss about the approach for future development. For
>
> Yes, I am voting for that approach in the branch. Of course it has to
> be rebased on top of the latest master (or redo from scratch, whatever
> is easier).
>
>> instance, what do you think about the local assumptions approach (see
>> the wiki page and issue 1884)? It's a hack, but I think it is much
>> better than using global assumptions.
>
> I looked at the code, most importantly here:
>
> https://github.com/vks/sympy/commit/bfc837b8859992c7ce43bd4967902bfcec756252
>
> and even though the hack is simple, it is still a hack, so my gut
> feeling is telling me, that this will bite is quite substantially in
> the future. (E.g. if you want to rewrite the core in C/C++, will this
> design still work?)
If I remember correctly, it would be easier to implement in C, because there
you have pointers. Also, you wouldn't need a hack in Python 3, because there
you have nonlocal (or is this something else completely?)
See also issue 1884. Also, would the idea from comment 3 of that issue
(wrapping something around a mutable object) work to make it less hackish?
Aaron Meurer
>
> However, apart from this hack, your approach seems identical to what I
> have in mind --- except that I would pass the AssumptionContext (that
> you embed automatically in the local scope) around by hand explicitly
> ("explicit is better than implicit").
>
> Ondřej
--
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 Bot
On Apr 30, 2011, at 11:13 PM, Ondrej Certik wrote: > On Sat, Apr 30, 2011 at 4:10 PM, Vinzent Steinberg > wrote: >> On Apr 30, 11:59 pm, Ondrej Certik wrote: >>> Well, that would not be the biggest problem. The biggest problem is >>> that gist doesn't have API for uploading yet, see here: >>> >>> http://develop.github.com/p/gist.html >> >> This is the oldest API (v1). The newest one has full gist support: >> >> http://developer.github.com/v3/gists/ > > Wow, thanks for this! I was not aware of the v3 API at all. Well in > that case, gist is a possibility. Let's see if pastehtml goes down > again, and if it does, we can switch to gist (maybe there is even some > way to serve html, but maybe not). > > Ondřej > If you upload html source and click on "raw", it shows the webpage. For example, I copied the source of wikipedia.org at https://gist.github.com/raw/950664/92f51a583bd4be1c104859cc0a66cb6e3c83ac7b/wikipedia.html, and you can see the webpage just as the original at https://gist.github.com/raw/950664/92f51a583bd4be1c104859cc0a66cb6e3c83ac7b/wikipedia.html (it might matter that I named the gist "wikipedia.html"). Also, remember a gist is just a git repository, so you can upload any kind of file (html, images, whatever). 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.
Re: [sympy] Re: TableForm
On Apr 30, 2011, at 10:52 PM, Ondrej Certik wrote: > On Sat, Apr 30, 2011 at 3:53 PM, Ondrej Certik wrote: >> On Sat, Apr 30, 2011 at 3:38 PM, Aaron S. Meurer wrote: >>> On Apr 30, 2011, at 4:22 PM, Ondrej Certik wrote: >>> >>>> Hi, >>>> >>>> thanks Ronan, Vinzent, Aaron, Mateusz and Brian for participating in >>>> the discussion. First of all, I would like to assure you that there >>>> are no hard feelings on my side, and hopefully we can learn something >>>> form it, and resolve things. I would like to write my very clear >>>> opinion on some of the issues raised in this thread: >>>> >>>> 1) This feature is a core feature, that SymPy should have >>>> >>>> 2) It is ok to give -1 for reviews, as long as you give a plan for the >>>> author of the patch, how he can fix it, so that it is acceptable. It >>>> is also ok to give -1 without saying anything else (this case), but >>>> then this stops progress, because it is not clear what I can do to get >>>> this in. As such, when you do such "-1" as a reviewer, you should >>>> think twice what this is going to cause, and initiate a discussion >>>> about this. >>>> >>>> 3) Vinzent asked, why I was upset. So the reason being, that something >>>> that I personally strongly believe belongs into sympy was given -1 >>>> without any constructive technical criticism. As far as I know, we >>>> have never pushed in a patch, that was clearly given -1 as this one. >>>> So as such, I felt, that this means, this can't go in. And as such I >>>> was upset, because suddenly I will not be able to achieve the goal to >>>> be able to do things that people do with Mathematica with SymPy, not >>>> because the code was not there, but because some of sympy developers >>>> gave it -1, because they don't share my vision. And as such, I was >>>> upset. I think that's understandable, isn't it? :) In any case, let me >>>> reiterate, that I am upset at the situation, not Ronan, or anybody >>>> else. >>>> >>>> 4) So now the question is what to do now. Well, my first idea was to >>>> convince Ronan to give it +1. That's of course the best. But if that >>>> is not possible, we can of course push it in anyway (given all the +1 >>>> that it got from other developers). But that is really something, that >>>> I, as a democratic person, really hate to do. Because "-1" is like a >>>> veto. That's how it worked so far. Maybe this point needs further >>>> discussion among us. At least I always considered "-1" as a veto. And >>>> as such, the code can't be pushed in, unless the situation is >>>> resolved. >>>> >>>> Ondřej >>> >>> Well, to me, the definition of "democratic" means a majority :) >>> >>> As the community gets larger, I think it will be necessary to not always >>> have a unanimous decision on everything. Certainly we should aim for it, >>> and we shouldn't just ignore −1's (especially if it is a technical issue). >>> But if it comes down to a disagreement that isn't going to change, we will >>> have to just look to see if there is a majority opinion, or at least if >>> there is a consensus in a looser sense of the word (like 5 +1's vs. 1 −1). >>> >>> If you really want a unanimous decision every time, you will only end up >>> getting the highest quality code being pushed in, and you shouldn't >>> complain when anything less doesn't make it. But I think that that is a >>> bad way to do things, for the same reason that you should "release early >>> and release often" (see >>> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html). >> >> >> I think that the rule of thumb can be simply said -- do your best to >> "keep all sympy devs happy". If one of them gives -1, do the best to >> get it resolved (one way or another). > > > Unless somebody has something else to add, given the controversy of > the patch, Aaron, can you go ahead and push this in as it is, or > provide directions how I can improve the patch, so that it can go in? > > Thanks, > Ondřej > Were we ever actually +1 on the patch itself, i.e., did anyone checkout the branch and run the tests, etc.? 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.
Re: [sympy] Re: Assumptions
By the way, the discussion at this issue is relevant:
http://code.google.com/p/sympy/issues/detail?id=1884
Aaron Meurer
On Apr 30, 2011, at 5:20 PM, Vinzent Steinberg wrote:
> On Apr 30, 7:36 pm, Haz wrote:
>>> I think the only problem could be that ask() is much slower for
>>> trivial queries, needs to be verified. This should be not too hard to
>>> fix though.
>>
>> I don't think this is the case. Trivial queries (those that already have
>> obvious implications) are compiled into quick reference dictionaries. In
>> particular:
>> -https://github.com/sympy/sympy/blob/master/sympy/assumptions/ask.py#L114
>
> Thanks for clarifying. I made a quick unrepresentative benchmark:
>
> In [1]: x = Symbol('x', positive=True)
>
> In [2]: global_assumptions.add(Assume(x, Q.positive))
>
> In [3]: %timeit x.is_positive
> 100 loops, best of 3: 418 ns per loop
>
> In [4]: %timeit ask(x, Q.positive)
> 1 loops, best of 3: 97.3 us per loop
>
>
> I think this is fast enough. (Even if it is about 200 times slower.)
>
> Vinzent
--
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: Assumptions
On Apr 30, 2011, at 1:24 PM, Ronan Lamy wrote:
> Le samedi 30 avril 2011 à 13:36 -0400, Haz a écrit :
>> So a few things to respond to...
>>
>>
>> Tom:
>>> Can you describe what went wrong with these branches? In particular,
>>> why can the following naive strategy not work:
>>>
>>> 1. Make the new system at least as good as the old one. That is
>>> whenever I can write foo.is_bar I can write ask(foo, Q.bar) and I
>> will
>>> get at least as good an answer. In particular Symbol('x',
>>> positive=True) should register automatically in the global
>> assumptions
>>> that x > 0 (if I understand correctly how the new system works...).
>>> 2. Replace all queries foo.is_bar by ask(foo, Q.bar).
>>> 3. Remove all implementations of the is_bar properties.
>>> 4. Remove all remaining remnants of the old system.
>>
>>
>> This is what was largely tried with a branch last summer:
>> - https://github.com/haz/sympy/tree/disconnect-assumptions-2
>>
>>
>> There was push-back from the community since removing the
>> Symbol('x', positive=True) syntax was largely frowned upon.
>
> As I recall, the problems were that it was slow and broke a lot of
> things. Symbol(x, positive=True) is easy to hack back in.
>
>>
>> Vinzent:
>>> I think the only problem could be that ask() is much slower for
>>> trivial queries, needs to be verified. This should be not too hard to
>>> fix though.
>>
>>
>> I don't think this is the case. Trivial queries (those that already
>> have obvious implications) are compiled into quick reference
>> dictionaries. In particular:
>> - https://github.com/sympy/sympy/blob/master/sympy/assumptions/ask.py#L114
>>
> I think that the problem is with non-trivial queries, for which that
> code does nothing.
>
>>
>> In the end, everything in the new assumption system is done with a
>> particular assumption context -- design decisions must be made on
>> which context is used in the ambiguous cases. There is also an issue
>> (feature request) that makes things more natural that will be worked
>> on after the assumptions shift has taken place -- things like the
>> following would be possible:
>>
>>
>> with :
>>
>>
>>
>> This gives the assumptions an explicit local scope. The branch from
>> last summer was mostly filled with fixing test cases so they used the
>> new assumption system (with the global assumptions), and then cleaned
>> up after themselves.
>>
>>
>> It should also be emphasized that it isn't just a simple notion of
>> cleaning up assumptions after yourself -- the cache interacts in quite
>> an intertwined way. Under the right assumptions, expressions will be
>> simplified, and variables will be assigned certain values. If that's
>> stored in the cache, changing any related assumption will invalidate
>> the result. For this reason, I had to manually clear the cache on a
>> regular basis. I think that the cache is only really needed for
>> lengthy solve algorithms (so you don't recompute an expression over
>> and over), in which case we can probably wipe it after any sympy
>> command is invoked (i.e., only use the cache while sympy is computing
>> things, and then flush it just before returning the result). However,
>> the branches from last summer never made it this far.
>>
> The cache is the source of a lot of problems. We should try to use it as
> little as possible, even if it's not really possible to remove it at
> this time.
If a specific algorithm is slow without the cache, I think it should be
rewritten to not do duplicate calculations.
>
>>
>> I think a few things are generally universally accepted (correct me
>> if I'm wrong though):
>> 1. sympy/core/assumptions.py should be removed, and everything patched
>> up to use sympy/assumptions/*
>> 2. sympy/core/logic.py should be removed and replaced with
>> sympy/logic/*
>> 3. Assumptions should probably have the right references to be
>> properly deleted from a context when their symbol is deleted -- this
>> goes for any AssumptionContext (not just the global one)
>>
> I'm not sure about 1: sympy/core/assumptions.py and sympy/assumptions/*
> should be merged, but I don't know how exactly the merge should happen.
>
>>
>> Ronan: Can you elaborate on this? (my memory is failing me at the
>> moment)
>>> * Remove the cumbersome and confusing Assume() syntax
>
> The idea is to write '~Q.real(x)' instead of 'Assume(x, Q.real, False)'.
> It's shorter, easier to understand and doesn't suggest wrongly that
> creating the object does anything beyond that.
>
+1. And I agree that Assume() can be confusing (especially considering that
Maple's assume() actually does create global assumptions, for example).
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/gro
Re: [sympy] Re: TableForm
On Apr 30, 2011, at 4:22 PM, Ondrej Certik wrote: > Hi, > > thanks Ronan, Vinzent, Aaron, Mateusz and Brian for participating in > the discussion. First of all, I would like to assure you that there > are no hard feelings on my side, and hopefully we can learn something > form it, and resolve things. I would like to write my very clear > opinion on some of the issues raised in this thread: > > 1) This feature is a core feature, that SymPy should have > > 2) It is ok to give -1 for reviews, as long as you give a plan for the > author of the patch, how he can fix it, so that it is acceptable. It > is also ok to give -1 without saying anything else (this case), but > then this stops progress, because it is not clear what I can do to get > this in. As such, when you do such "-1" as a reviewer, you should > think twice what this is going to cause, and initiate a discussion > about this. > > 3) Vinzent asked, why I was upset. So the reason being, that something > that I personally strongly believe belongs into sympy was given -1 > without any constructive technical criticism. As far as I know, we > have never pushed in a patch, that was clearly given -1 as this one. > So as such, I felt, that this means, this can't go in. And as such I > was upset, because suddenly I will not be able to achieve the goal to > be able to do things that people do with Mathematica with SymPy, not > because the code was not there, but because some of sympy developers > gave it -1, because they don't share my vision. And as such, I was > upset. I think that's understandable, isn't it? :) In any case, let me > reiterate, that I am upset at the situation, not Ronan, or anybody > else. > > 4) So now the question is what to do now. Well, my first idea was to > convince Ronan to give it +1. That's of course the best. But if that > is not possible, we can of course push it in anyway (given all the +1 > that it got from other developers). But that is really something, that > I, as a democratic person, really hate to do. Because "-1" is like a > veto. That's how it worked so far. Maybe this point needs further > discussion among us. At least I always considered "-1" as a veto. And > as such, the code can't be pushed in, unless the situation is > resolved. > > Ondřej Well, to me, the definition of "democratic" means a majority :) As the community gets larger, I think it will be necessary to not always have a unanimous decision on everything. Certainly we should aim for it, and we shouldn't just ignore −1's (especially if it is a technical issue). But if it comes down to a disagreement that isn't going to change, we will have to just look to see if there is a majority opinion, or at least if there is a consensus in a looser sense of the word (like 5 +1's vs. 1 −1). If you really want a unanimous decision every time, you will only end up getting the highest quality code being pushed in, and you shouldn't complain when anything less doesn't make it. But I think that that is a bad way to do things, for the same reason that you should "release early and release often" (see http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html). 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.
Re: [sympy] TableForm
On Apr 30, 2011, at 4:03 PM, Ondrej Certik wrote: > On Fri, Apr 29, 2011 at 8:37 PM, Brian Granger wrote: >>> I am not sure I understand what your idea is, but it seems that's >>> exactly how I implemented it? TableForm is an object (it's not an >>> issue for me whether or not it is derived from Basic, currently it is >>> from technical reasons, but this can be changed), and then I have >>> enhanced the printers to be able to print TableForm nicely in all our >>> output printers. Because I want to use it with ascii (in terminal), in >>> latex (when I write articles, it would be so much easier to just >>> create the table in sympy, instead of wrestling with latex by hand), >>> html, and so on. >>> >>> Is there a better design for such a thing? >> >> In Mathematica, TableForm is not itself a data structure, but only >> something that takes a data structure and prints it in different > > Here is the definition: > > http://reference.wolfram.com/mathematica/ref/TableForm.html > > So the way I understand is, that it *is* a data structure, that holds > the data, and that can be printed in many formats, but maybe I am > wrong. In any case, I want to be able to do all of their examples. Well, just because Mathematica does it this way, doesn't mean we have to also :) To me, the data structures and the printers should be separate, because that allows for the best modularity. So the underlying data structure should be some kind of two dimensional array, which then has printers, which can print using ascii, or rst, or latex, or whatever. Aaron Meurer > >> forms. Is this similar to your implementation? > > > As such, I have implemented TableForm as a Python class, that printers > know how to print. This allows me to replicate Mathematica examples. > If anyone has a better way to do it, patches/ideas welcome. :) > >> But I do think we want this type of functionality in sympy, especially something like TreeForm (I think that is what it is called) that displays a nice expression tree. >>> >>> Great, I agree. >> >> OK, Cool. I do think we want this in sympy as a table is an >> appropriate way of displaying symbolic expressions. If TableForm were > > +1 > >> focused more on displaying non-symbolic data, then I would say sympy >> is probably not the place for it. I can imagine numpy implmenting > > TableForm is for displaying any kinds of data, mainly including symbolic data. > >> something like this, but surely it won't be tied into sympy and handle >> all of our different printing formats. I am still +1 on 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. > -- 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: Better management between GitHub and Google Code
Well, I just noticed something that could be a problem. GitHub uses the same numbering scheme for pull requests and issues. This means that pull request 42 is also considered to be issue 42. For example, see the issues for the website: https://github.com/sympy/sympy.github.com/issues. Issue #24 is an actual issue that I just created. Issues 1-23 are actually pull requests 1-23. It also means that they consider pull requests to *be* issues, which is a little different from how we have been treating them (for example, we can close pull requests and reopen them, but issues should only be closed when they are fixed). Aaron Meurer On Apr 30, 2011, at 7:37 AM, Vinzent Steinberg wrote: > On Apr 30, 12:42 am, "Aaron S. Meurer" wrote: >> Technically, Google Code has a better tag system, because it lets you have >> tags like our Priority, Status, and Type that can only take one value per >> issue. > > Yeah, multi-value labels are lacking. > >> Also, the default labels functionality doesn't seem to be as strong. It >> also doesn't seem to have the ability to automatically do things based on >> labels (like in Google Code, we send updates of issues with the review >> labels to the patches list). > > Provided they have a good API, this could be easily done by sympy-bot. > Also we wouldn't need it, because on github pull request are tied > closely enough with the issues. Everyone who wants an email can tell > github to send one for every pull request. > > Vinzent -- 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: faster groebner algorithm
On Apr 30, 2011, at 10:40 AM, mario wrote:
> Hi,
> I have put on github a partial rewrite of rmpoly, using sympy
> monomials
> instead of packed integers, see
> https://github.com/pernici/sympy
>
> With it groebner is often a bit faster, sometimes a few times
> faster.
> Series have a low-level API only, but are usually orders of
> magnitude faster.
>
> Here are a few examples.
>
> Groebner basis:
>
from time import time
from sympy.polys import groebner
from sympy import *
x,y,z = [Symbol(xx) for xx in ('x','y','z')]
You can just use
x, y, z = symbols('x y z')
Aaron Meurer
>
> example from http://groups.google.com/group/sympy/msg/bca6f5de43fff305
> :
>
I = [x**3+x+1, y**2+y+1, (x+y)*z-(x**2+y)]
t0=time(); g=groebner(I,x,y,z,order='lex');'%.2f'%(time()-t0);g[-1]
> '0.03'
> 13 - 46*z + 89*z**2 - 82*z**3 + 41*z**4 - 7*z**5 + z**6
>
> against 0.04s in master.
>
> modify it a little
>
I = [x**3+x+1, y**3+2*y**4+y**2+y+1, (x+y)**2*z-(x**2+y)]
t0=time(); g=groebner(I,x,y,z,order='lex');'%.2f'%(time()-t0);g[-1]
> '2.09'
> 1048 + 2404*z - 8314*z**2 - 27305*z**3 + 75117*z**4 + 15406*z**5 -
> 19752*z**6 + 61568*z**7 + 109354*z**8 + 68358*z**9 + 6290*z**10 -
> 1495*z**11 + 2209*z**12
>
> against 16.1s in master.
>
> The speed difference tends to increase with the order of the equations
> defining the algebraic numbers x and y;
> e.g. for 2*x**4+x**3+x+1, 2*y**4+y**2+y+1
> the timings are 12s against 337s with master; Sage takes 0.33s
>
> sage: R. = PolynomialRing(QQ,order='lex')
> sage: I = Ideal([2*x**4+x**3+x+1, 2*y**4+y**2+y+1,(x+y)**2*z-
> (x**2+y)])
> sage: time g = I.groebner_basis()
> Wall time: 0.33 s
>
>
>
> Series:
> Here is a series example from
> http://sage.math.washington.edu/home/fredrik/flint/timings.html
>
from time import time
from sympy import *
from sympy.polys.lpoly import *
h = 10
x = Symbol('x')
lp,X = lgens('X',QQ,O_lex)
t0=time();p=((1 + X + X**2).nth_root(-2,'X',h) + X).sqrt('X',h); \
> ... p1=p.tobasic(x); '%.4f'%(time()-t0);p1
> '0.0057'
> 1 + x/4 - 3*x**2/32 + 31*x**3/128 - 429*x**4/2048 + 247*x**5/8192 +
> 6889*x**6/65536 - 22097*x**7/262144 - 294717*x**8/8388608 +
> 3881835*x**9/33554432
>
> compared to
>
t0=time();p2=series(sqrt(x + 1/sqrt(1 + x + x**2)),x,0,h); \
> ... '%.2f'%(time()-t0)
> '148.80'
>
> Let us modify this example putting a parameter a in the series
>
a = Symbol('a')
lp,A,X = lgens('A,X',QQ,O_lex)
t0=time();p=((1 + A*X + 2*A*X**2).nth_root(-2,'X',h) + X).sqrt('X',h); \
> ... p1=p.tobasic(a,x); '%.3f'%(time()-t0)
> '0.017'
>
> I stopped series(sqrt(x + 1/sqrt(1 + a*x + 2*a*x**2)),x,0,h) after
> 2000s;
> compare it with
>
> sage: time taylor(sqrt(x + 1/sqrt(1 + a*x + 2*a*x**2)),x,0,9)
> CPU times: user 0.04 s, sys: 0.01 s, total: 0.06 s
> Wall time: 1.23 s
> which is 72x slower than lpoly
>
> Mario
>
>
> --
> 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: Assumptions
I think using __del__ is a bad idea. See
http://docs.python.org/reference/datamodel.html?highlight=__del__#object.__del__.
Basically, __del__ is *not* called when you do "del x". First off, "del x"
reduces the reference count of x by 1, whereas x.__del__ is only called if the
reference count reaches zero. So if you do
a = [x]
del x
x.__del__ won't be called, because there is still a reference to x in b.
Second, I think that __del__ is not guaranteed to happen immediately, but only
at the next garbage collection event (I might be wrong here, though). But I
think that __del__ should only be used for cleanup magic that doesn't happen
automatically with the regular garbage collector. Implementing a feature like
assumptions in it isn't what it was made for.
By the way, Ronan, Vinzent, Christian, and Tom, can you all add the ideas you
have mentioned here as ideas on that wiki page?
Aaron Meurer
On Apr 30, 2011, at 8:25 AM, Tom Bachmann wrote:
>
>>> 1. Make the new system at least as good as the old one. That is
>>> whenever I can write foo.is_bar I can write ask(foo, Q.bar) and I will
>>> get at least as good an answer.
>>
>> I think the only problem could be that ask() is much slower for
>> trivial queries, needs to be verified. This should be not too hard to
>> fix though.
>>
>>> In particular Symbol('x',
>>> positive=True) should register automatically in the global assumptions
>>> that x > 0 (if I understand correctly how the new system works...).
>>
>> That is is not that easy, because this approach does not work with
>> global assumptions. Symbol('x', positive) only affects local symbols,
>> global assumptions affect *all* symbols.
>>
>> In other words, you have to manually clean the global assumptions, so
>> this can't be used as a drop-in replacement for Symbol('x',
>> positive=True). Imagine running the test suite and global_assumptions
>> being spammed with hundreds of assumptions.
>>
>
> Couldn't symbol.__del__ just remove all global assumptions involving
> the about-to-be-deleted symbol? I suppose assumptions would have to
> store weak references for this to work.
>
> Note: I come from a background of explicit memory allocation, so this
> might either not be feasible or not pythonic.
>
>> A solution would be to implement local assumptions, imitating Python's
>> local scoping. I tried this approach some time ago, it is quite
>> hackish, but I got it working for Symbol(), but not really for
>> symbols() or var(). See my local_assump branch.
>>
>
> That would of course still be handy to have.
>
>>> 2. Replace all queries foo.is_bar by ask(foo, Q.bar).
>>
>> I we fix the two things I mentioned above, we could still have
>> foo.is_bar as a (maybe deprecated) shortcut.
>>
>>> 3. Remove all implementations of the is_bar properties.
>>> 4. Remove all remaining remnants of the old system.
>>
>> Vinzent
>
> --
> 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: Assumptions
I don't think that would work if we have assumptions that are separate from the objects themselves. In other words, if the assumptions change, then the hash would have to change. Aaron Meurer On Apr 30, 2011, at 12:21 PM, Tom Bachmann wrote: > >> It should also be emphasized that it isn't just a simple notion of >> cleaning up assumptions after yourself -- the cache interacts in quite an >> intertwined way. Under the right assumptions, expressions will be >> simplified, and variables will be assigned certain values. If that's stored >> in the cache, changing any related assumption will invalidate the result. > > Why not make assumptions part of the hash of an object? At least to > the extent that the cache is concerned? -- 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: Better management between GitHub and Google Code
Yes, clever scripts would solve all of our problems :) But there is the issue of having a server to run these scripts on, not to mention writing the scripts in the first place. Aaron Meurer On Apr 29, 2011, at 4:44 PM, Haz wrote: > I think some clever scripts using the github api would solve most of that, no? > > On Fri, Apr 29, 2011 at 6:42 PM, Aaron S. Meurer wrote: > Technically, Google Code has a better tag system, because it lets you have > tags like our Priority, Status, and Type that can only take one value per > issue. > > Also, the default labels functionality doesn't seem to be as strong. It also > doesn't seem to have the ability to automatically do things based on labels > (like in Google Code, we send updates of issues with the review labels to the > patches list). > > Aaron Meurer > > On Apr 29, 2011, at 4:23 PM, Vinzent Steinberg wrote: > > > It seems that github supports any feature (including tags) I currently > > can think of, so maybe we should really consider a move. > > > > BTW, I just read [1], so there is a gist API, we can consider it for > > sympy-bot. > > > > Vinzent > > > > > > [1] https://github.com/blog/846-new-issues-and-gist-api > > > > On Apr 29, 10:16 pm, Haz wrote: > >>>> We could also use the tools that that script uses > >>>> (http://code.google.com/p/support/wiki/IssueTrackerAPI > >>> andhttps://github.com/ask/python-github2) to write the bot that I was > >>> talking about below. > >> > >>> Aaron Meurer > >> > >>> On Apr 29, 2011, at 1:49 PM, Haz wrote: > >> > >>> -https://github.com/cfinke/googlecode2github > >> > >>> <https://github.com/cfinke/googlecode2github> ? > >> > >>> On Fri, Apr 29, 2011 at 3:48 PM, Aaron S. Meurer > >>> wrote: > >> > >>>> Well, it does indeed seem that they've improved. > >> > >>>> Show me a way to transfer issues from Google Code to GitHub, and you may > >>>> have sold me. > >> > >>>> Aaron Meurer > >> > >>>> On Apr 29, 2011, at 1:42 PM, Haz wrote: > >> > >>>> Integration with pull requests > >>>> -https://github.com/blog/712-pull-requests-2-0 > >> > >>>> New issue stuff: > >>>> -https://github.com/blog/831-issues-2-0-the-next-generation > >> > >>>> <https://github.com/blog/712-pull-requests-2-0> What about a gradual > >>>> migration? Prohibit new issues on Google, and gradually close them all > >>>> off. > >> > >>>> On Fri, Apr 29, 2011 at 3:15 PM, Aaron S. Meurer > >>>> wrote: > >> > >>>>> Well, first off, I'm not even sure if that would solve the problem. How > >>>>> well does GitHub integrate their issues with their pull requests. > >> > >>>>> Anyway, the conditions for moving to any other issue tracker would be: > >> > >>>>> - It would need to be at least as powerful as Google Code. Ideally, if > >>>>> we are going through the hassle to move, it should be more powerful. > >>>>> This > >>>>> is talking about things like labels and stuff (I'd need to check to see > >>>>> how > >>>>> good GitHub is with this). > >> > >>>>> - We would need to transfer all the current issues over to the new > >>>>> tracker, keeping all numbers the same. This is the most important one, > >>>>> and > >>>>> also the most difficult. It's important because we have references to > >>>>> issue > >>>>> numbers *everywhere*: in the code, in the commit log, in the mailing > >>>>> list, > >>>>> etc. > >> > >>>>> Currently, Google Code makes it kind of hard to export the issues (you > >>>>> have to do it manually; there's no xml or svn output). > >> > >>>>> Personally, I'm pretty content with the Google Code issue tracker, other > >>>>> than the issues I mentioned below. It works well, and has some nice > >>>>> features (like the advanced search). > >> > >>>>> I haven't played with GitHub's issue tracker too much, but from what I > >>>>> saw, it isn't as good (yet). > >> > >>>>> Aaron Meu
