Re: GSoC Report: Expresso, symbolic manipulation of Algebraic Expressions in clojure
Great work Maik!
It's an impressive library - the fact that you can implement a general
purpose symbolic analysis technique like extremata in a dozen lines of
Clojure shows just how powerful this is.
On Monday, 23 September 2013 23:38:47 UTC+8, Maik Schünemann wrote:
GSoC ends today and I can announce the 0.2.0 version of the expresso [1]
library.
It is build on top of core.logic and core.matrix and provides symbolic
manipulation of algebraic expressions.
What's there?
1. An api/dsl for manipulation of algebraic expressions which doesn't get
in your way. Expresso's expressions are
just clojure s-expressions and can be manipulated with rich set of
clojure sequence functions
2. useful manipulations for mathematical expressions: simplify,
multiply-out, differentiate, ...
3. An equation solver which is capable of solving a single equation and
multiple equations for unknowns.
4. An optimizer which transforms a mathematical expression to a
semantically equivalent but performanter one
5. An expression compiler to compile an expression to an efficient clojure
function
6. A semantic rule based translator on top of which many of expresso's
features are implemented
The code is fully documented and I wrote a tutorial and showcase of
expresso, the expresso-tutorial [2].
GSoC has been a really fun and valuable time for me. I learned a lot. Of
course I will continue developing expresso!
Expresso and core.matrix are the first steps in the direction of a full
computer algebra system for clojure. I hope that it will help clojure to be
an attractive choice for scientific computing projects in the future.
Showcase:
Here are two examples of expresso's facility to manipulate mathematical
expressions. They can be found and are explained in the expresso-tutorial
[2].
1. solving word problems:
(solve 'blue
(ex (= pencils (+ green white blue red)))
(ex (= (/ pencils 10) green))
(ex (= (/ pencils 2) white))
(ex (= (/ pencils 4) blue))
(ex (= red 45))) ;= #{{blue 75N}}
2. Analyzing roots and extremata of functions. This code shows how easy
one can implement tasks involving symbolic manipulation with expresso:
(defn roots
returns the set of roots of the expression in regard to var
[var expr]
(solve var (ex (= ~expr 0
(defn extremata
gets the extrema of the expression in regard to var. Returns a map with the
keys :maxima and :minima
[var expr]
(let [d1 (differentiate [var] expr)
d2 (differentiate [var] d1)
candidates (roots var d1)]
(if (seq candidates)
(let [extremata
(- candidates
(map (fn [candidate] [candidate (evaluate d2 {var
candidate})]))
(remove #(== 0 (second %)))
(group-by #( 0 (second %]
{:maxima (map first (get extremata false))
:minima (map first (get extremata true))}
(defn analyse-function
returns a map with the :roots, the :maxima and the :minima of the
expression
in regard to var
[var expr]
(assoc (extremata var expr)
:roots (roots var expr)))
(analyse-function 'x (ex (- (** x 4) (** x 2
;= {:roots #{0 -1 1},
;; :maxima (0),
;; :minima (0.7071067811865476 -0.7071067811865476)}
Ideas/feedbacks etc are greatly appreciated!
Enjoy,
Maik
[1] https://github.com/clojure-numerics/expresso
[2] https://github.com/mschuene/expresso-tutorial
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: NDArray for core.matrix
Great work Dmitry! It's superb that we now have a general purpose N-dimensional array implementation that is comparable with NumPy, written in pure Clojure. This will be a big boost for people doing data science / scientific computing with Clojure. You've also shown that it's possible to write some pretty high performance numerical code in Clojure (with a bit of macro magic, of course!) On Tuesday, 24 September 2013 05:25:25 UTC+8, Dmitry Groshev wrote: Today Google Summer of Code finally ends. NDArray is pretty stable now and will be the default implementation used by core.matrix in the upcoming release. It was an epic journey through bugs, unexpected slowness and weird macros, but now I can proudly state that in some cases NDArray can be faster than NumPy by a factor of two: [1]. Well, not always. It's hard to consistently beat highly optimized and vectorized native code on JVM :) But we have a secrete sauce here in Clojure: macros. You can find the code I've benchmarked here: [2]. What's going on? The thing here is that using macros we can fully eliminate the cost of intermediate matrix allocation (or function call machinery in case of map-like functions) doing element-wise operations. Thanks to macros, the code will be expanded to a highly optimized loop right inside user's code, hiding messy details of NDArray and Clojure's type hinting from user, but exposing necessary information to JVM. Moreover, this will work on a bunch of NDArrays, too: [3]. More details can be found in NDArray's documentation (by the courtesy of Marginalia): [4]. Overall, this project was very interesting experience to me. Hope others will find it useful :) Cheers! Dmitry [1]: http://i.imgur.com/6qdUF7f.png [2]: https://gist.github.com/si14/6676599 [3]: https://github.com/mikera/matrix-api/blob/develop/src/test/clojure/clojure/core/matrix/test_ndarray_implementation.clj#L16 [4]: http://mikera.github.io/matrix-api/ndarray.html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: Expresso, symbolic manipulation of Algebraic Expressions in clojure
nice work congratulations -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: NDArray for core.matrix
great congrats Op maandag 23 september 2013 23:25:25 UTC+2 schreef Dmitry Groshev: Today Google Summer of Code finally ends. NDArray is pretty stable now and will be the default implementation used by core.matrix in the upcoming release. It was an epic journey through bugs, unexpected slowness and weird macros, but now I can proudly state that in some cases NDArray can be faster than NumPy by a factor of two: [1]. Well, not always. It's hard to consistently beat highly optimized and vectorized native code on JVM :) But we have a secrete sauce here in Clojure: macros. You can find the code I've benchmarked here: [2]. What's going on? The thing here is that using macros we can fully eliminate the cost of intermediate matrix allocation (or function call machinery in case of map-like functions) doing element-wise operations. Thanks to macros, the code will be expanded to a highly optimized loop right inside user's code, hiding messy details of NDArray and Clojure's type hinting from user, but exposing necessary information to JVM. Moreover, this will work on a bunch of NDArrays, too: [3]. More details can be found in NDArray's documentation (by the courtesy of Marginalia): [4]. Overall, this project was very interesting experience to me. Hope others will find it useful :) Cheers! Dmitry [1]: http://i.imgur.com/6qdUF7f.png [2]: https://gist.github.com/si14/6676599 [3]: https://github.com/mikera/matrix-api/blob/develop/src/test/clojure/clojure/core/matrix/test_ndarray_implementation.clj#L16 [4]: http://mikera.github.io/matrix-api/ndarray.html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Efficiently typing an argument of implementation in deftype
Interesting, can you please explain somewhat more? On Saturday, September 21, 2013 3:19:16 AM UTC+4, Ambrose Bonnaire-Sergeant wrote: Just a thought, could implementing IKeywordInvoke and using keywords for field lookups speed up compilation? Thanks, Ambrose On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev lambda...@gmail.comjavascript: wrote: In this mail I'm talking about Clojure 1.4, however, I believe that the issue persists in later versions, too. I have quite a lot of code of the following form: (defprotocol sum-proto (sum [x y])) (deftype Pair [^long a ^long b] sum-proto (sum [x y] (let [^Pair y y new-a (+ (.a x) (.a y)) new-b (+ (.b x) (.b y))] (Pair. new-a new-b In real code there are *a lot* of implementations in that deftype generated by macroses. The problem is that compilation time skyrocketed. Right now I'm facing 5-10 seconds of compilation, which makes incremental development very painful. Profiler shows that the overwhelming majority of this time is spent here: [1]. It follows that the problem is in that ^Pair annotation: when symbol is tagged by a symbol, it should be resolved as a class. It should be way faster if I can cache that resolution, but I can't given that those implementation are inside of deftype, I can't resolve in advance the class that isn't defined. And I can't use extend-type either because of the cost of extra var lookup. The main question is: what can I do to make compilation faster? Pre-resolving that class won't work, it seems. [1]: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Efficiently typing an argument of implementation in deftype
I mean something like what defrecord does: (defprotocol SumProto (sum [x y])) (declare -Pair) (deftype Pair [^long a ^long b] clojure.lang.ILookup (valAt [this k] (case k :a a :b b)) SumProto (sum [x y] (let [new-a (+ (:a x) (:a y)) new-b (+ (:b x) (:b y))] (-Pair new-a new-b Thanks, Ambrose On Tue, Sep 24, 2013 at 4:54 PM, Dmitry Groshev lambdadmi...@gmail.comwrote: Interesting, can you please explain somewhat more? On Saturday, September 21, 2013 3:19:16 AM UTC+4, Ambrose Bonnaire-Sergeant wrote: Just a thought, could implementing IKeywordInvoke and using keywords for field lookups speed up compilation? Thanks, Ambrose On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev lambda...@gmail.comwrote: In this mail I'm talking about Clojure 1.4, however, I believe that the issue persists in later versions, too. I have quite a lot of code of the following form: (defprotocol sum-proto (sum [x y])) (deftype Pair [^long a ^long b] sum-proto (sum [x y] (let [^Pair y y new-a (+ (.a x) (.a y)) new-b (+ (.b x) (.b y))] (Pair. new-a new-b In real code there are *a lot* of implementations in that deftype generated by macroses. The problem is that compilation time skyrocketed. Right now I'm facing 5-10 seconds of compilation, which makes incremental development very painful. Profiler shows that the overwhelming majority of this time is spent here: [1]. It follows that the problem is in that ^Pair annotation: when symbol is tagged by a symbol, it should be resolved as a class. It should be way faster if I can cache that resolution, but I can't given that those implementation are inside of deftype, I can't resolve in advance the class that isn't defined. And I can't use extend-type either because of the cost of extra var lookup. The main question is: what can I do to make compilation faster? Pre-resolving that class won't work, it seems. [1]: https://github.com/**clojure/clojure/blob/master/** src/jvm/clojure/lang/Compiler.**java#L986https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Efficiently typing an argument of implementation in deftype
defrecord uses IKeywordLookup's getLookupThunk, but I can't figure out how to implement it. Thanks, Ambrose On Tue, Sep 24, 2013 at 5:16 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: I mean something like what defrecord does: (defprotocol SumProto (sum [x y])) (declare -Pair) (deftype Pair [^long a ^long b] clojure.lang.ILookup (valAt [this k] (case k :a a :b b)) SumProto (sum [x y] (let [new-a (+ (:a x) (:a y)) new-b (+ (:b x) (:b y))] (-Pair new-a new-b Thanks, Ambrose On Tue, Sep 24, 2013 at 4:54 PM, Dmitry Groshev lambdadmi...@gmail.comwrote: Interesting, can you please explain somewhat more? On Saturday, September 21, 2013 3:19:16 AM UTC+4, Ambrose Bonnaire-Sergeant wrote: Just a thought, could implementing IKeywordInvoke and using keywords for field lookups speed up compilation? Thanks, Ambrose On Fri, Sep 20, 2013 at 10:01 PM, Dmitry Groshev lambda...@gmail.comwrote: In this mail I'm talking about Clojure 1.4, however, I believe that the issue persists in later versions, too. I have quite a lot of code of the following form: (defprotocol sum-proto (sum [x y])) (deftype Pair [^long a ^long b] sum-proto (sum [x y] (let [^Pair y y new-a (+ (.a x) (.a y)) new-b (+ (.b x) (.b y))] (Pair. new-a new-b In real code there are *a lot* of implementations in that deftype generated by macroses. The problem is that compilation time skyrocketed. Right now I'm facing 5-10 seconds of compilation, which makes incremental development very painful. Profiler shows that the overwhelming majority of this time is spent here: [1]. It follows that the problem is in that ^Pair annotation: when symbol is tagged by a symbol, it should be resolved as a class. It should be way faster if I can cache that resolution, but I can't given that those implementation are inside of deftype, I can't resolve in advance the class that isn't defined. And I can't use extend-type either because of the cost of extra var lookup. The main question is: what can I do to make compilation faster? Pre-resolving that class won't work, it seems. [1]: https://github.com/**clojure/clojure/blob/master/** src/jvm/clojure/lang/Compiler.**java#L986https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L986 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure
I'm curious how this relates to core.logic. If I understand correctly, Clara can be compiled to core.logic and utilize it's search, doesn't it? On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote: This is the first release of Clara, forward-chaining rules in Clojure. Details on the github site: https://github.com/rbrush/clara-rules I've also posted the rationale for what I'm doing here: http://www.toomuchcode.org/2013/09/rules-as-control-structure.html The gist is that forward-chaining rules are a great tool for many problems and Clojure's strengths can address some weaknesses in existing production systems. Right now Clara supports most of the major features seen in production systems, embraces Clojure values like immutability, and is powerful enough for a number of use cases. It still needs to be profiled and subjected to more rigorous testing before I'd consider it production ready, but this release is for anyone interested in experimenting with it. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure
Clara is a forward-chaining production system -- think Jess, Drools or CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based logic programming, more along the lines of Prolog and obviously with a strong relationship to Kanren. These approaches are complementary; which one to use really depends on the problem you want to solve. If you can describe a problem as a search space over a set of constraints, core.logic is almost certainly a better fit than Clara. In contrast, Clara targets the expression of complex and arbitrary domain-specific knowledge. Even a functional approach to programming can become unwieldy if business rules are frequently changing and have arbitrary relationships to other rules. Those functions would need to be deeply chained together, with frequent changes forcing them to be re-wired. Production systems allow the logic to be expressed independently, where authors need not worry about other rules, order of execution, or wiring them together. The engine then runs the rules against a set of input and ensures the working memory reaches a consistent state. I wrote about this in more depth here: https://github.com/rbrush/clara-rules/wiki/Introduction On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote: I'm curious how this relates to core.logic. If I understand correctly, Clara can be compiled to core.logic and utilize it's search, doesn't it? On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote: This is the first release of Clara, forward-chaining rules in Clojure. Details on the github site: https://github.com/rbrush/clara-rules I've also posted the rationale for what I'm doing here: http://www.toomuchcode.org/2013/09/rules-as-control-structure.html The gist is that forward-chaining rules are a great tool for many problems and Clojure's strengths can address some weaknesses in existing production systems. Right now Clara supports most of the major features seen in production systems, embraces Clojure values like immutability, and is powerful enough for a number of use cases. It still needs to be profiled and subjected to more rigorous testing before I'd consider it production ready, but this release is for anyone interested in experimenting with it. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Library (or libraries) for translating REST queries to database queries?
I want to use clojure to build a web service with a RESTful API that exposes resources stored in a relational database (mysql in this case). I'd like to use a library that, given a specification of the db schema, would translate incoming requests to db queries, or korma constructs. Examples might be: GET /users?status=4 translates to something like: SELECT * FROM `users` WHERE `status` = 4; or: PUT /users/12 would be: UPDATE `users` SET ... WHERE `id` = 12 Is there anything out there that would facilitate this? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC Report: Expresso, symbolic manipulation of Algebraic Expressions in clojure
Impressive work congrats!
On Mon, Sep 23, 2013 at 11:38 AM, Maik Schünemann maikschuenem...@gmail.com
wrote:
GSoC ends today and I can announce the 0.2.0 version of the expresso [1]
library.
It is build on top of core.logic and core.matrix and provides symbolic
manipulation of algebraic expressions.
What's there?
1. An api/dsl for manipulation of algebraic expressions which doesn't get
in your way. Expresso's expressions are
just clojure s-expressions and can be manipulated with rich set of
clojure sequence functions
2. useful manipulations for mathematical expressions: simplify,
multiply-out, differentiate, ...
3. An equation solver which is capable of solving a single equation and
multiple equations for unknowns.
4. An optimizer which transforms a mathematical expression to a
semantically equivalent but performanter one
5. An expression compiler to compile an expression to an efficient clojure
function
6. A semantic rule based translator on top of which many of expresso's
features are implemented
The code is fully documented and I wrote a tutorial and showcase of
expresso, the expresso-tutorial [2].
GSoC has been a really fun and valuable time for me. I learned a lot. Of
course I will continue developing expresso!
Expresso and core.matrix are the first steps in the direction of a full
computer algebra system for clojure. I hope that it will help clojure to be
an attractive choice for scientific computing projects in the future.
Showcase:
Here are two examples of expresso's facility to manipulate mathematical
expressions. They can be found and are explained in the expresso-tutorial
[2].
1. solving word problems:
(solve 'blue
(ex (= pencils (+ green white blue red)))
(ex (= (/ pencils 10) green))
(ex (= (/ pencils 2) white))
(ex (= (/ pencils 4) blue))
(ex (= red 45))) ;= #{{blue 75N}}
2. Analyzing roots and extremata of functions. This code shows how easy
one can implement tasks involving symbolic manipulation with expresso:
(defn roots
returns the set of roots of the expression in regard to var
[var expr]
(solve var (ex (= ~expr 0
(defn extremata
gets the extrema of the expression in regard to var. Returns a map with the
keys :maxima and :minima
[var expr]
(let [d1 (differentiate [var] expr)
d2 (differentiate [var] d1)
candidates (roots var d1)]
(if (seq candidates)
(let [extremata
(- candidates
(map (fn [candidate] [candidate (evaluate d2 {var
candidate})]))
(remove #(== 0 (second %)))
(group-by #( 0 (second %]
{:maxima (map first (get extremata false))
:minima (map first (get extremata true))}
(defn analyse-function
returns a map with the :roots, the :maxima and the :minima of the
expression
in regard to var
[var expr]
(assoc (extremata var expr)
:roots (roots var expr)))
(analyse-function 'x (ex (- (** x 4) (** x 2
;= {:roots #{0 -1 1},
;; :maxima (0),
;; :minima (0.7071067811865476 -0.7071067811865476)}
Ideas/feedbacks etc are greatly appreciated!
Enjoy,
Maik
[1] https://github.com/clojure-numerics/expresso
[2] https://github.com/mschuene/expresso-tutorial
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Library (or libraries) for translating REST queries to database queries?
U... OData maybe a bit overwhelming, but I guess it is in your direction http://www.odata.org/ There is an implementation in Java https://code.google.com/p/odata4j/ (apparently with consumers and producers, too) There is an experimental Clojure project consuming odata4j https://github.com/danbev/odata_test Don't sure if it implements a consumer But I insist, odata is a bit overwhelming... Something more simple? Angel Java Lopez @ajlopez On Tue, Sep 24, 2013 at 10:35 AM, Bill Piel b...@billpiel.com wrote: I want to use clojure to build a web service with a RESTful API that exposes resources stored in a relational database (mysql in this case). I'd like to use a library that, given a specification of the db schema, would translate incoming requests to db queries, or korma constructs. Examples might be: GET /users?status=4 translates to something like: SELECT * FROM `users` WHERE `status` = 4; or: PUT /users/12 would be: UPDATE `users` SET ... WHERE `id` = 12 Is there anything out there that would facilitate this? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC report: Extend Neko library for Android
I am so excited about how neko and lein-droid have come along; Alex has done some amazing work. Compared to Android's standard Java/XML approach, it's really a revelation to write your UI and logic in the same simple Clojure code. For the types of apps that don't require instant boot times, I think Clojure will be a tremendous secret weapon. On Monday, September 23, 2013 8:30:16 PM UTC-4, Alexander Yakushev wrote: As you might already figured out from similar topics, GSoC 2013 is over and it is time to collect the fruit. As of my proposal, I achieved several things this year at both lein-droid[1] and Neko[2]. Here is the list of them: 1. Rewrote neko.ui from macros to functions to allow true dynamic UI generation (similar to Hiccup, for example). 2. Added utilities to create menus and manipulate application ActionBar (including action modes), implemented support for tabbed views and Fragments. 3. Added support for data readers in Clojure/Android projects, implemented a few data readers for resource identifiers. 4. Implemented auto-completion[3] that works reasonably fast on Android devices. The client currently exists for Emacs only[4], but Zach is working on integrating it into Nightcode. The auto-completion library can also be used in Clojure/JVM projects since it has a couple of nice features beyond clojure-complete. 5. Created template for a splash window to be shown while Clojure runtime is being loaded[5]. New projects are created with this splash already included. 6. Implemented some more UI widgets and traits in Neko. I thank my mentor, Zach Oakes, for his amazing support, advice and feedback throughout the whole program; and of course, Clojure community for giving me a chance to pursue this project. I am very glad that some people have already tried Clojure on Android, and sincerely hope that my work brings even more curious minds to it. Best regards, Alex Yakushev [1] https://github.com/clojure-android/lein-droid [2] https://github.com/alexander-yakushev/neko [3] https://github.com/alexander-yakushev/compliment/ [4] https://github.com/alexander-yakushev/ac-nrepl-compliment [5] http://www.youtube.com/watch?v=sqI-iUmxJS0 -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Library (or libraries) for translating REST queries to database queries?
Hi Bill, Did you look at restSQL? http://restsql.org For custom needs generating SQL from REST routes might be a way. Shantanu On Tuesday, 24 September 2013 19:05:38 UTC+5:30, Bill Piel wrote: I want to use clojure to build a web service with a RESTful API that exposes resources stored in a relational database (mysql in this case). I'd like to use a library that, given a specification of the db schema, would translate incoming requests to db queries, or korma constructs. Examples might be: GET /users?status=4 translates to something like: SELECT * FROM `users` WHERE `status` = 4; or: PUT /users/12 would be: UPDATE `users` SET ... WHERE `id` = 12 Is there anything out there that would facilitate this? thanks -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: much lower recursion depth with memoization
I posted an article detailing the approaches I outlined earlier in this thread: http://programming-puzzler.blogspot.com/2013/09/defeating-stack-overflows.html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
light-table doesn't like (set! *unchecked-math* true)
Hi all, does anyone have a clue why light-table 0.5.3 throws exception whenever it sees a (set! *unchecked-math* true)? I mean it swallows (set! *warn-on-reflection* true) just fine! Is this a bug? the actual exception is (set! *warn-on-reflection* true) (set! *unchecked-math* true) java.lang.IllegalStateException: Can't change/establish root binding of: *unchecked-math* with set Var.java:233 clojure.lang.Var.set NO_SOURCE_FILE:26 hotel-nlp.helper/eval9004 Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
room available at Clojure/conj
I have registered a suite for Thursday and Friday nights at the conference hotel (Embassy Suites Alexandria - Old Town), but I only need the main room. So, the second room (and sofa bed) is available. I'm open to sharing the suite with another (quiet, non-smoking) Clojurist. If you are interested, please get in touch *off-list*. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure
I see your point. By the way, the documentation is outstanding, especially for first release. Great work! On the other hand, I can't help but think that Rete algorithm looks like a part of logic programming system. I understand that this is a corner case (Prolog does a lot more than just scanning through facts/rules) and therefore can be solved much more efficiently, but is there a way to blend this approaches? I've also found [1] and this supports my suspicion that the distinction is more of a historic/business kind rather than fundamental one. Your argument on execution order problems is valid, especially for Prolog. But minikanren is not so brittle in this sense. Moreover, runtime assertion of facts in regard to core.logic already surfaced a few times in this list [2], so effective addition of facts and rules can be very beneficial for core.logic. On the other hand, if I understand correctly, information on constraints (both real, integer and FD) can be useful for rule-based systems to reduce search space of rules that can be affected by new fact. So combined approach seems useful to me. [1]: http://programmers.stackexchange.com/questions/114711/the-relation-between-business-rules-engines-and-constraint-programming-languages [2]: http://osdir.com/ml/clojure/2013-03/msg00778.html On Tuesday, September 24, 2013 3:42:02 PM UTC+4, Ryan Brush wrote: Clara is a forward-chaining production system -- think Jess, Drools or CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based logic programming, more along the lines of Prolog and obviously with a strong relationship to Kanren. These approaches are complementary; which one to use really depends on the problem you want to solve. If you can describe a problem as a search space over a set of constraints, core.logic is almost certainly a better fit than Clara. In contrast, Clara targets the expression of complex and arbitrary domain-specific knowledge. Even a functional approach to programming can become unwieldy if business rules are frequently changing and have arbitrary relationships to other rules. Those functions would need to be deeply chained together, with frequent changes forcing them to be re-wired. Production systems allow the logic to be expressed independently, where authors need not worry about other rules, order of execution, or wiring them together. The engine then runs the rules against a set of input and ensures the working memory reaches a consistent state. I wrote about this in more depth here: https://github.com/rbrush/clara-rules/wiki/Introduction On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote: I'm curious how this relates to core.logic. If I understand correctly, Clara can be compiled to core.logic and utilize it's search, doesn't it? On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote: This is the first release of Clara, forward-chaining rules in Clojure. Details on the github site: https://github.com/rbrush/clara-rules I've also posted the rationale for what I'm doing here: http://www.toomuchcode.org/2013/09/rules-as-control-structure.html The gist is that forward-chaining rules are a great tool for many problems and Clojure's strengths can address some weaknesses in existing production systems. Right now Clara supports most of the major features seen in production systems, embraces Clojure values like immutability, and is powerful enough for a number of use cases. It still needs to be profiled and subjected to more rigorous testing before I'd consider it production ready, but this release is for anyone interested in experimenting with it. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure
I appreciate the kind words! You're right that the lines between forward- and backward-chaining systems are blurry, with some systems incorporating ideas from both. Perhaps more important than that is how easily we can express the logic for a given problem. While it's possible to write, say, a Sudoku solver in Clara, it really isn't the right tool for that sort of constraint-based logic. Conversely, some forward-chaining rules may not be as easily expressed in a system that emphasizes constraints. Some examples I put together to demonstrate Clara are at [1]; I hope these are fairly clear. I'm not so sure this type of arbitrary, changing business logic is as easy to modularize and express in other systems. To be clear, I think core.logic is awesome, and am uncomfortable drawing any comparison between it and Clara. I also can imagine leveraging core.logic and its ideas in Clara itself as this evolves. As a starting point, however, Clara is targeting a different class of problem. If working with a problem that could benefit from rules, I'd suggest thinking of the simplest way that problem can be expressed, and choosing a technology that most closely aligns with that. I hope this makes sense! I wish I had some clear litmus test to contrast these systems, but I'm still learning myself. ;) [1] https://github.com/rbrush/clara-examples/tree/master/src/main/clojure/clara/examples On Tuesday, September 24, 2013 2:02:33 PM UTC-5, Dmitry Groshev wrote: I see your point. By the way, the documentation is outstanding, especially for first release. Great work! On the other hand, I can't help but think that Rete algorithm looks like a part of logic programming system. I understand that this is a corner case (Prolog does a lot more than just scanning through facts/rules) and therefore can be solved much more efficiently, but is there a way to blend this approaches? I've also found [1] and this supports my suspicion that the distinction is more of a historic/business kind rather than fundamental one. Your argument on execution order problems is valid, especially for Prolog. But minikanren is not so brittle in this sense. Moreover, runtime assertion of facts in regard to core.logic already surfaced a few times in this list [2], so effective addition of facts and rules can be very beneficial for core.logic. On the other hand, if I understand correctly, information on constraints (both real, integer and FD) can be useful for rule-based systems to reduce search space of rules that can be affected by new fact. So combined approach seems useful to me. [1]: http://programmers.stackexchange.com/questions/114711/the-relation-between-business-rules-engines-and-constraint-programming-languages [2]: http://osdir.com/ml/clojure/2013-03/msg00778.html On Tuesday, September 24, 2013 3:42:02 PM UTC+4, Ryan Brush wrote: Clara is a forward-chaining production system -- think Jess, Drools or CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based logic programming, more along the lines of Prolog and obviously with a strong relationship to Kanren. These approaches are complementary; which one to use really depends on the problem you want to solve. If you can describe a problem as a search space over a set of constraints, core.logic is almost certainly a better fit than Clara. In contrast, Clara targets the expression of complex and arbitrary domain-specific knowledge. Even a functional approach to programming can become unwieldy if business rules are frequently changing and have arbitrary relationships to other rules. Those functions would need to be deeply chained together, with frequent changes forcing them to be re-wired. Production systems allow the logic to be expressed independently, where authors need not worry about other rules, order of execution, or wiring them together. The engine then runs the rules against a set of input and ensures the working memory reaches a consistent state. I wrote about this in more depth here: https://github.com/rbrush/clara-rules/wiki/Introduction On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote: I'm curious how this relates to core.logic. If I understand correctly, Clara can be compiled to core.logic and utilize it's search, doesn't it? On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote: This is the first release of Clara, forward-chaining rules in Clojure. Details on the github site: https://github.com/rbrush/clara-rules I've also posted the rationale for what I'm doing here: http://www.toomuchcode.org/2013/09/rules-as-control-structure.html The gist is that forward-chaining rules are a great tool for many problems and Clojure's strengths can address some weaknesses in existing production systems. Right now Clara supports most of the major features seen in production systems, embraces Clojure values like immutability, and
Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure
I used CLIPS (another forward-chaining rule system) for several years, and the way I tend to explain it to people is that it is the best tool for the job when your code would look like an enormous cond with thousands of cases, executed over and over, because: 1. The Rete algorithm can jump to the right branch more efficiently than testing each case one by one in some linear order. 2. When you have thousands of cases, it can be difficult to ensure that they are in exactly the right order and/or don't overlap. Forward-chaining systems let you express the cases more declaratively and apply precedence rules judiciously rather than thinking about precedence all the time. I think a forward-chaining system would also make a great foundation for a project that requires some sort of dataflow architecture. I agree with Ryan that it tends to be useful in different contexts than constraint solvers. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clara-rules 0.1.0 released -- rules as a control structure
+1 On Tue, Sep 24, 2013 at 9:00 PM, Mark Engelberg mark.engelb...@gmail.comwrote: I used CLIPS (another forward-chaining rule system) for several years, and the way I tend to explain it to people is that it is the best tool for the job when your code would look like an enormous cond with thousands of cases, executed over and over, because: 1. The Rete algorithm can jump to the right branch more efficiently than testing each case one by one in some linear order. 2. When you have thousands of cases, it can be difficult to ensure that they are in exactly the right order and/or don't overlap. Forward-chaining systems let you express the cases more declaratively and apply precedence rules judiciously rather than thinking about precedence all the time. I think a forward-chaining system would also make a great foundation for a project that requires some sort of dataflow architecture. I agree with Ryan that it tends to be useful in different contexts than constraint solvers. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
