I like this talk. It sounds similar to the talks you gave last year. I've really been sold on this approach in the assumptions system, a la my branch. In the old assumptions and the current new assumptions, to write down a fact, you have to do a lot of logic. You maybe don't need to know the details of how ask() works, but you do need to think about both the fact that you want to implement (say, product of even integers is even), *and* how to write that down so that it works in the system (e.g., an _eval_even in Mul that says "if all(i.is_integer for i in self.args): return all(i.is_even for i in self.args)", or the crazy mess you'd have to write in the new assumptions handlers). In my branch, you just write
(Mul, Implies(AllArgs(Q.integer), Equivalent(AnyArgs(Q.even), Q.even))), Maybe that is less readable than the old assumptions example I had (although once you get the hang of how the logic works, it really isn't), but there are two advantages: - It's symbolic. You can reason things about the (Mul, Implies(...)), version that you can't reason about the if all(...) version (e.g., ask(Q.even(x) | Q.even(y), Q.even(x*y) & Q.integer(x) & Q.integer(y))). You can also do fun things like ship it off to something else (maybe auto generate docs for all assumptions facts, or maybe dump all assumptions facts to prolog and see where you can get with that...). - It doesn't *have* to be less readable. That's just the syntax I came up with. You can keep building higher and higher abstractions. Maybe the Implies(AllArgs(something), Equivalent(something else)) pattern is a common one (it is), and thus should be abstracted somehow. If you want to restructure the old assumptions like this, you'd have to build a completely new pattern in the assumptions itself (like some new method _eval_x_for_domain_y or something). To build it in my branch, just write some new classes (maybe ForDomain(something, Equivalent(something else))). As long as your classes know how to spit out actual logic in the end (or actually, just how to spit out things in terms of lower abstractions really), they can abstract things however they like . And they don't have to touch the core deduction system, or really even care that it exists. The point is, with the old ways, you have to figure out, "how do I make deductions on this fact", whereas with the new way, you just have to figure out, "how do I write down this fact" (and note that the latter is really a prerequisite for doing *anything* with the fact, even understanding it). Sorry if I don't have any suggestions for you talk abstract, other than "hey, give a shoutout to assumptions too." I guess my other suggestion would be that data should be data, and whenever it can be represented symbolically, it should be. You never know what kinds of manipulations someone might want to do with the knowledge you have written down. Maintaining the exact structure of it is your best bet. Aaron Meurer On Mon, Mar 31, 2014 at 11:38 AM, Matthew Rocklin <[email protected]>wrote: > Last minute (this morning) I decided to submit a talk based around some of > my more esoteric programming projects, multiple dispatch, pattern matching, > strategies. I drew a lot of inspiration from SymPy when I was thinking > about these things so if accepted then I'll probably use SymPy heavily for > example use cases. Here is the description and abstract. > > I'll add a disclaimer to this talk that the ideas contained within it are > my own and not necessarily adopted by the SymPy community. As I said, this > is mostly about some of my more wacky projects. I'll probably call upon > uses of multiple dispatch (if we include it), fu trig simplification with > @smichr, and my matrix expressions work with pattern matching (not in > master). > > DescriptionGood solutions to hard problems require both domain and > algorithmic expertise. Domain experts know what to do and computer > scientists know how to do it well. This talk discusses challenges and > experiences trying to reconcile these two groups, particularly within > SymPy. It proposes concrete approaches including multiple dispatch, pattern > matching, and programmatic strategies. Abstract > > Good solutions to hard problems require both domain and algorithmic > expertise. Domain experts know *what* to do and computer scientists know > *how* to do it well. Coordination between the algorithmic and domain > programmer is challenging to do well and difficult to scale. It is also > arguably one of the most relevant blocks to scientific progress today. > > This talk draws from experience supporting mathematical programmers in the > SymPy project. SymPy is a computer algebra system, a complex problem that > requires the graph manipulation algorithms of a modern compiler alongside > the mathematics of several PhD theses. SymPy draws from a broad developer > base with experienced and novice developers alike and so struggles to > maintain a cohesive organized codebase. > > We approach this development problem by separating software engineering > into a collection of small functions, written by domain experts, alongside > an abstract control system, written by algorithmic programmers. We > facilitate this division with techniques taken from other languages and > compiler technologies. Notably we motivate the use of a few general purpose > libraries for multiple dispatch, pattern matching, and programmatic control. > > > > On Mon, Mar 31, 2014 at 9:32 AM, Matthew Rocklin <[email protected]>wrote: > >> I like that you emphasized the utility for numerics, I think that this is >> likely to be a selling point for the SciPy crowd. I think that it's >> correct to inform the reader about what symbolics are but I think that the >> first couple of sentences (which do this) could be stronger/more direct. >> Right now they sound conversational. It's not clear to me how to fix this >> though. >> >> Maybe start with something like "SymPy is a computer algebra system. It >> provides easy access to a wealth of automated mathematics that helps >> programmers to reason about their problem producing more clear and >> efficient numeric solutions." and then go into what symbolics are? >> >> I would cut the top bullet point, e.g. >> >> - Why you should care about symbolic mathematics, even if you are only >> interested in doing numerics. >> - How symbolic mathematics can help you solve problems more effectively >> >> I have a pretty cynical view about people when they're reading text >> though (perhaps this comes from teaching freshmen :)) As a result >> sentences that carry more than one idea seem dirty to me. >> >> Hope this helps, >> -Matt >> >> >> On Sat, Mar 29, 2014 at 6:01 PM, Aaron Meurer <[email protected]> wrote: >> >>> Here is the detailed abstract I have so far for a talk for SciPy. Any >>> suggestions are welcome. The deadline is April 1 (probably 5 PM central or >>> thereabouts). I roughly based it on the matplotlib talk from last year >>> http://conference.scipy.org/scipy2013/presentation_detail.php?id=211. >>> >>> Symbolic computation deals with manipulating mathematical expression >>> symbolically (as opposed to numerically). For instance, representing >>> sqrt(2) without evaluating it is symbolic: representing 1.41421 is numeric. >>> Most software that deals with mathematical expressions symbolically are >>> called computer algebra systems, or CASs for short. SymPy is a computer >>> algebra system written entirely in Python. >>> >>> In this talk, we will look at >>> >>> - Why you should care about symbolic mathematics. Even if you are only >>> interested in doing numerics, how can symbolic mathematics help you to >>> solve your problems more efficiently and/or effectively? >>> - Some of the design decisions that have guided SymPy, such as why we >>> chose Python to write SymPy, and the importance of being able to use SymPy >>> as a library. >>> - How to solve some basic problems in SymPy. >>> - How to interface SymPy with popular numeric libraries, like NumPy. >>> >>> Additionally, we will look at the most interesting recent developments >>> of SymPy, and will also discuss some of our plans for the future. >>> >>> Finally, we will discuss some of what has made SymPy a success, both as >>> a software product, and as a community. >>> >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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/CAKgW%3D6K3OmDsdApN%3DOEvFrRQ4ohEQ1npVfwgUsyxd-K-TLaLOA%40mail.gmail.com<https://groups.google.com/d/msgid/sympy/CAKgW%3D6K3OmDsdApN%3DOEvFrRQ4ohEQ1npVfwgUsyxd-K-TLaLOA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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/CAJ8oX-Ei01ZAgWSJmb2Cdm6Q%2BOovh4L4C25c7p2PwQc2shB5qw%40mail.gmail.com<https://groups.google.com/d/msgid/sympy/CAJ8oX-Ei01ZAgWSJmb2Cdm6Q%2BOovh4L4C25c7p2PwQc2shB5qw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To post to this group, send email to [email protected]. 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/CAKgW%3D6LNmbzZpdysdt_UfNzrn1L3kzLROs0cnT4TEGy8p43qEQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
