Skip to content
mschuene edited this page Jul 5, 2013 · 13 revisions

Objectives

Expresso aims to be the definitive library in Clojure for the representation and manipulation of algebraic expressions and also to provide specific expression manipulations, like solving and optimizing an expression.

The Objectives of the GSoC expresso project are as follows:

  • Complete the first public release version of the expresso library
  • Interoperate with core.matrix to enable more powerful numerical applications for Clojure
  • Provide useful working functionality to end-users
  • Ensure complete documentation and test suites for users and future maintainers

Key design decisions

Design decisions represent current best hypothesis. Should be modified if issues are discovered / a better solution is found.

  • Logic Engine : expresso will build upon the logic programming capabilities of core.logic
  • Expression representation (user) : expressions will be regular Clojure s-expressions
  • Expression representation (internal) : expressions will be regular Clojure s-expressions annotated with metadata (potential alternative: s-expressions wrapped in custom deftype)
  • Rule representation (user) : There will be convenient syntax for creating a rule, but also the possibility to encode arbitrary manipulations as a rule
  • Rule representation (internal) : Rules are a vector of a syntactical pattern (optional with a guard relation) and a transformation (relation or pattern)
  • Representation of mathematical properties : Open Question at this point, certainly in metadata, but how is not clear.
  • Application of Rules : The first applicable rule succeeds. There are multiple ways to walk an expression and transform it, expresso wants to support more than one.

Features

Expresso should be able to support a wide range of use cases, to prove flexibility, usefulness and extensibility. Not all cases need to be implemented in full during the GSoC project, but enough work should be done on each to prove that the architecture / design is capable of supporting them effectively.

All features should be demonstrated with test cases using the User API - these may also serve as examples to document use cases of expresso.

User API / use cases

  • Natural expression representation for users
  • Users can write their own rules easily
  • Simplifying expressions
  • Optimizing it for excecution ontop of core.matrix ** Could, to an extent, include doing analysis of mathematical properties of the expressions And use them for example to exchange common functions for special ones
  • Taking derivative of expressions
  • Rearranging expression in terms of arbitrary variable - where possible
  • Solving simultaneous equations with substitutions - or other means
  • Solving vector/matrix/n-dimensional array equations
  • ....

Mathematical function types

Expresso should have knowledge of the properties of (and rules to simplify expressions containing)

  • Simple arithmetic functions
  • Matrix / array functions
  • Trigonometric functions
  • Exponential / logarithmic functions
  • Array / matrix functions (e.g. inner product)
  • Logical expressions (implies, and, not etc. with boolean arguments)

Extensibility

  • User can extend rule set with additional functions
  • User can extend rule set with own rules
  • User can specify properties of additional functions (e.g. commutativity) which make rules for the properties applicable to the function

Future Objectives

These features are certainly interesting for expresso but propably out of scope for gsoc

  • Compute a wide range of Integrals
  • Compile optimized expressions to native code
  • achieve high performance
  • ...

Performance / non-functional requirements

  • Expresso should be efficient for common expression types (at least the design should make it possible to optimize it for performance without a complete rewrite)
  • API should be convenient for a user at the REPL
  • API should be convenient for programmatic usage (e.g. in macros or using generated expressions)
  • Code should follow Clojure library coding standards
  • Public API should have complete docstrings
  • Design should be "simple" / make use of composable functional components
  • ....

Bonus Objectives

Just ideas!

  • Get to top of front page of Hacker News
  • Get live usage in a production app at a startup
  • Make and share a video demonstration
  • Include a type system? (not realistic I think)

Milestones

  • 5 July
  • Agree GSoC plan
  • Outline design / architecture ...
  • 29th July
  • Mid-term evaluations
  • 16 Sep
  • Project complete "pencils down date"