Re: math expression simplifier, kibit implementation
On Sat, Dec 1, 2012 at 12:24 AM, Jonas jonas.enl...@gmail.com wrote: * Predicates on logic vars: [(foo (? x number?)) (bar ?x)] = match (foo 42) but not (foo :bar) This is now possible since we have constraints. * Segment vars: [(* ??x 1 ??y) (* ??x ??y)] = (* 4 3 2 1 2 3 4) would turn into (* 4 3 2 2 3 4) and [(* ??x 0 ??y) 0] = (* 1 2 3 0 4 5 6 7) would turn into 0 This has been possible for some time - but you need to extend unification. You need to create a wrapper around sequences and a new kind of logic var. Kevin's work on the partial map (PMap) functionality is a good starting point as well the work I've done on constrained vars (CVar). As far as doing a computer algebra system, I know things like this have been done before in Prolog so I don't see why not. David -- 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
Re: math expression simplifier, kibit implementation
On Sunday, December 2, 2012 7:33:17 PM UTC+2, David Nolen wrote: On Sat, Dec 1, 2012 at 12:24 AM, Jonas jonas@gmail.com javascript:wrote: * Predicates on logic vars: [(foo (? x number?)) (bar ?x)] = match (foo 42) but not (foo :bar) This is now possible since we have constraints. Awesome. Is this already in a released version of core.logic? Do you know of any examples I might study? * Segment vars: [(* ??x 1 ??y) (* ??x ??y)] = (* 4 3 2 1 2 3 4) would turn into (* 4 3 2 2 3 4) and [(* ??x 0 ??y) 0] = (* 1 2 3 0 4 5 6 7) would turn into 0 This has been possible for some time - but you need to extend unification. You need to create a wrapper around sequences and a new kind of logic var. Kevin's work on the partial map (PMap) functionality is a good starting point as well the work I've done on constrained vars (CVar). I'd be interested in creating an SVar (segment var) then. I'll start by trying to understand yours and Kevins work on CVar/PMap. As far as doing a computer algebra system, I know things like this have been done before in Prolog so I don't see why not. Sorry, I didn't mean to imply that it couldn't be done in core.logic, only that the kibit rule system isn't as expressive as I'd like it to be. Jonas David -- 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
Re: math expression simplifier, kibit implementation
On Sun, Dec 2, 2012 at 1:42 PM, Jonas jonas.enl...@gmail.com wrote: On Sunday, December 2, 2012 7:33:17 PM UTC+2, David Nolen wrote: On Sat, Dec 1, 2012 at 12:24 AM, Jonas jonas@gmail.com wrote: * Predicates on logic vars: [(foo (? x number?)) (bar ?x)] = match (foo 42) but not (foo :bar) This is now possible since we have constraints. Awesome. Is this already in a released version of core.logic? Do you know of any examples I might study? Not yet - but you can look at the code in master (and the tests) for some ideas. I plan on adding what Kevin needs fairly soon to the simple unifier and documenting it the high level interface - it will probably use the CVar functionality I mentioned. It's a bit hard to make any promises about the details of the constraint functionality as it's likely to change as I better understand how all of this should work. * Segment vars: [(* ??x 1 ??y) (* ??x ??y)] = (* 4 3 2 1 2 3 4) would turn into (* 4 3 2 2 3 4) and [(* ??x 0 ??y) 0] = (* 1 2 3 0 4 5 6 7) would turn into 0 This has been possible for some time - but you need to extend unification. You need to create a wrapper around sequences and a new kind of logic var. Kevin's work on the partial map (PMap) functionality is a good starting point as well the work I've done on constrained vars (CVar). I'd be interested in creating an SVar (segment var) then. I'll start by trying to understand yours and Kevins work on CVar/PMap. I'm not convinced this needs to be in core.logic proper but I'm more than happy to answer any questions once you understand how PMap CVar work. It's a goal to allow many kinds of extensions to core.logic w/o needing to directly modify the core. David -- 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
Re: math expression simplifier, kibit implementation
Hi The function `simplify-one` in kibit.core is the “brain” behind kibit: (defn simplify-one [expr rules] (let [alts (logic/run* [q] (logic/fresh [pat subst] (logic/membero [pat subst] rules) (logic/project [pat subst] (logic/all (pat expr) (subst q)] (if (empty? alts) expr (first alts The line `(logic/membero [pat subst] rules)` picks a rule (both the pattern and the substitution part). Both `pat` and `subst` are functions who have closed over the same logic vars. pat takes a form and subst takes the logic var representing the result as arguments. Since both pat and subst contain the same logic vars the final expression `(logic/all (pat expr) (subst q))` will only succeed if (pat expr) succeeds. If (pat expr) succeeds it has presumably bound its logic vars and since the same vars are closed over in subst, the final answer is unified with q, giving us a result. Rules are compiled with (defn compile-rule [rule] (let [[pat alt] (logic/prep rule)] [(fn [expr] (logic/== expr pat)) (fn [sbst] (logic/== sbst alt))])) (logic/prep rule) walks the rule (where a rule is e.g., [(+ ?x 1) (inc ?x)]) and replaces symbols starting with `?` with logic vars. The compile-rule function is defined in the kibit.rules.util namespace. This is basically how the kibit rule system works. I don’t think it’s powerful enough to create a full-blown computer algebra system and often It’s not powerful enough for the kind of rules I’d like to express in kibit. Two enhancements I’d like to add are * Predicates on logic vars: [(foo (? x number?)) (bar ?x)] = match (foo 42) but not (foo :bar) * Segment vars: [(* ??x 1 ??y) (* ??x ??y)] = (* 4 3 2 1 2 3 4) would turn into (* 4 3 2 2 3 4) and [(* ??x 0 ??y) 0] = (* 1 2 3 0 4 5 6 7) would turn into 0 David Nolen and Kevin Lynagh has discussed enhancements to the core.logic unifier on IRC lately. I haven’t been able to follow along as much as I’d like so I’m not completely sure what enhancements they are aiming for. You can see some of the results of those discussions in many of Kevins gists on github (https://gist.github.com/lynaghk) Cheers, Jonas On Saturday, December 1, 2012 12:08:16 AM UTC+2, Brent Millare wrote: Hey all, Before I diving in detail into the code, can someone provide me a high level explanation of how kibit simplifies code? I understand underneath it uses core.logic and rules but its not clear to me how it picks one form over the other. I'm trying to extend this to data that represents mathematical expressions. Ideally in the future I'd like to have many types of transformations that enable one to shape a mathematical expression in one way or another depending on the user's requirements. My current work (which requires dj atm since its under heavy development) is available here https://github.com/bmillare/dj.math -- 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
Re: math
The apache commons library - http://commons.apache.org/math/ is really rock solid. all the utilities can be found in: http://commons.apache.org/math/apidocs/org/apache/commons/math3/util/FastMath.html see http://stackoverflow.com/questions/12327120/finding-all-the-power-roots-in-clojure for a complex example On Wednesday, October 10, 2012 1:38:20 PM UTC+11, Brian Craft wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? -- 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
Re: math
Probably the best way to get basic maths functions in Clojure is to use java.lang.Math. Cheers, Tom On Wed, Oct 10, 2012 at 3:38 PM, Brian Craft craft.br...@gmail.com wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? -- 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 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
Re: math
On Tuesday, October 9, 2012 10:38:20 PM UTC-4, Brian Craft wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? To help answer questions like this one, I added the beginnings of a math cookbook page to the CDS: http://clojure-doc.org/articles/cookbooks/math.html . If interested in adding to that or any other CDS page, see https://github.com/clojuredocs/cds#how-to-contribute . ---John -- 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
Re: math
Looks neat. Can I make a suggestion? For these cookbooks, it would be very help to know exactly which version of clojure (and any libraries used) were used. You can even just put the associated project.clj content at the top. That way one will have confidence that this is up-to-date info, and know exactly what to do to reproduce. And it will be obvious what needs to be updated when future versions are released. On Wed, Oct 10, 2012 at 6:37 PM, John Gabriele jmg3...@gmail.com wrote: On Tuesday, October 9, 2012 10:38:20 PM UTC-4, Brian Craft wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? To help answer questions like this one, I added the beginnings of a math cookbook page to the CDS: http://clojure-doc.org/articles/cookbooks/math.html . If interested in adding to that or any other CDS page, see https://github.com/clojuredocs/cds#how-to-contribute . ---John -- 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 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
Re: math
2012/10/11 kovas boguta kovas.bog...@gmail.com Looks neat. Can I make a suggestion? For these cookbooks, it would be very help to know exactly which version of clojure (and any libraries used) were used. You can even just put the associated project.clj content at the top. putting project.clj in them is completely unnecessary. Add a new section: What Clojure Versions This Cookbook Covers? That way one will have confidence that this is up-to-date info, and know exactly what to do to reproduce. This is a good idea. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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
Re: math
https://github.com/clojure/math.numeric-tower [org.clojure/math.numeric-tower 0.0.1] On Tue, Oct 9, 2012 at 7:38 PM, Brian Craft craft.br...@gmail.com wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? -- 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 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
Re: math
As long as we're talking about docs lately, I would like to underscore that the transition to modular contrib is still confusing to newcomers. Sorry to hijack the OP's thread, but I think this needs to be dealt with. Suggestions on how to make this more visible or negate the need for understanding altogether? '(Devin Walters) On Oct 9, 2012, at 9:44 PM, Mark Engelberg mark.engelb...@gmail.com wrote: https://github.com/clojure/math.numeric-tower [org.clojure/math.numeric-tower 0.0.1] On Tue, Oct 9, 2012 at 7:38 PM, Brian Craft craft.br...@gmail.com wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? -- 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 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 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
Re: math
On Tue, Oct 9, 2012 at 7:38 PM, Brian Craft craft.br...@gmail.com wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? Back with Clojure 1.3, the old monolithic contrib was deprecated and broken up into separate modules, per: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go What would help us is knowing what path you took in looking for information about the math functions that led you to old contrib... so we can make adjustments to what documentation is out there to make the new structure easier to find and understand? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: math
Honestly the best bet for migrating from old contrib: Find the old contrib on github, and just copy the function or 2 that you want. Anything else is gonna be a frustrating PITA. Its highly misleading to say that the old contrib was broken up to be more modular. The reality is that the function names and signatures are often totally different. Just switching the namespaces ain't gonna work. These are basically new libraries, that are thematically similar to the old ones. Great for future work, terrible for migration. Most of the time you are using the contrib for some convenience function. Its way easier to just copy that function into your own project, than to worry about tracking down the new library, and then checking that the function in question is exactly the same as before. On Tue, Oct 9, 2012 at 11:35 PM, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Oct 9, 2012 at 7:38 PM, Brian Craft craft.br...@gmail.com wrote: I need some basic math functions, e.g. floor. I see there are some in contrib, but I'm unable to figure out the status of contrib. Seems like it's deprecated, or in transition, or something? Back with Clojure 1.3, the old monolithic contrib was deprecated and broken up into separate modules, per: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go What would help us is knowing what path you took in looking for information about the math functions that led you to old contrib... so we can make adjustments to what documentation is out there to make the new structure easier to find and understand? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 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
Re: math
On Tue, Oct 9, 2012 at 9:03 PM, kovas boguta kovas.bog...@gmail.com wrote: Most of the time you are using the contrib for some convenience function. Its way easier to just copy that function into your own project, than to worry about tracking down the new library, and then checking that the function in question is exactly the same as before. That might be true for the old pieces which were not migrated but certainly isn't true for things like c.c.sql (now c.j.jdbc) and things like core.logic etc. And of course, if they really were just a few convenience functions, that speaks to why they didn't get migrated as-is. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: math
On Tuesday, October 9, 2012 8:35:28 PM UTC-7, Sean Corfield wrote: What would help us is knowing what path you took in looking for information about the math functions that led you to old contrib... so we can make adjustments to what documentation is out there to make the new structure easier to find and understand? Top hits on google. clojure math floor, top three hits are contrib docs. -- 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
Re: math
The one that bit me specifically was clojure.contrib.string = clojure.string . Not criticising the new design, its just a fact that its not backwards compatible. Anyway the point is: we should make clear that this isn't a 1-to-1 migration. 50% (or even 90%) compatibility is not the same as 100%. People should not be lead to expect that if they just change the namespaces and import the new module, everything will work. In general, it will not. Because is it is not 100%, every library needs to be manually checked to make sure each function you were using before is the same as before, otherwise you will get surprised. On Wed, Oct 10, 2012 at 12:17 AM, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Oct 9, 2012 at 9:03 PM, kovas boguta kovas.bog...@gmail.com wrote: Most of the time you are using the contrib for some convenience function. Its way easier to just copy that function into your own project, than to worry about tracking down the new library, and then checking that the function in question is exactly the same as before. That might be true for the old pieces which were not migrated but certainly isn't true for things like c.c.sql (now c.j.jdbc) and things like core.logic etc. And of course, if they really were just a few convenience functions, that speaks to why they didn't get migrated as-is. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 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
Re: math
On Tue, Oct 9, 2012 at 9:22 PM, Brian Craft craft.br...@gmail.com wrote: Top hits on google. clojure math floor, top three hits are contrib docs. Thanx. I Googled that phrased and the first result was the old richhickey repo. We should be able to get that fixed - or at least a notice added linking to the new contrib. The second result was the new contrib so that's OK. The third and fourth results were to ClojureDocs... which needs an update :( Who owns ClojureDocs? Can we get more bodies involved to help keep that updated? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: math
On Tue, Oct 9, 2012 at 9:23 PM, kovas boguta kovas.bog...@gmail.com wrote: The one that bit me specifically was clojure.contrib.string = clojure.string . Not criticising the new design, its just a fact that its not backwards compatible. I believe that happened in Clojure 1.2, even before monolithic contrib was broken up... c.c.string is not listed here: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go so the caveat applies: If a clojure.contrib namespace is not listed here, it is most likely an old namespace that was either migrated somewhere else or deprecated as part of Clojure 1.2 (and c.c.string is explicitly called out as an earlier migration). You can't hold up c.c.string as an example of a problem with the break up of old contrib since it predates that - so you're talking about a problem going from Clojure 1.1 to 1.2? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: math
Alright, you got me on that one. Actually all the examples I had in mind where from 1.2 (I migrated from 1.1 so it all seemed part of a piece to me) So should we expect the function and their signatures to be the same then? On Wed, Oct 10, 2012 at 12:34 AM, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Oct 9, 2012 at 9:23 PM, kovas boguta kovas.bog...@gmail.com wrote: The one that bit me specifically was clojure.contrib.string = clojure.string . Not criticising the new design, its just a fact that its not backwards compatible. I believe that happened in Clojure 1.2, even before monolithic contrib was broken up... c.c.string is not listed here: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go so the caveat applies: If a clojure.contrib namespace is not listed here, it is most likely an old namespace that was either migrated somewhere else or deprecated as part of Clojure 1.2 (and c.c.string is explicitly called out as an earlier migration). You can't hold up c.c.string as an example of a problem with the break up of old contrib since it predates that - so you're talking about a problem going from Clojure 1.1 to 1.2? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 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
Re: math
On Tue, Oct 9, 2012 at 9:43 PM, kovas boguta kovas.bog...@gmail.com wrote: Actually all the examples I had in mind where from 1.2 (I migrated from 1.1 so it all seemed part of a piece to me) I think the migration from 1.2 to 1.3 is better documented than the migration from 1.1 to 1.2... So should we expect the function and their signatures to be the same then? Unfortunately that predates my involvement with Clojure so I can't comment. I'm doing what I can to document what I know around contrib migration but I started with early builds of 1.3 and helped with the migration of several old contribs to the new setup. I'd be happy to see specific suggestions - or edits - for the wiki page to make it easier to migrate from earlier versions. Although I'll also point out that the vast majority of Clojure users over the language's history will only experience 1.3 or later (probably 1.4 or later) so it can suck to be an early adopter but in the grand scale of things, early adopters are a minority :) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: math
On Tue, Oct 9, 2012 at 9:03 PM, kovas boguta kovas.bog...@gmail.com wrote: The reality is that the function names and signatures are often totally different. Just switching the namespaces ain't gonna work. These are basically new libraries, that are thematically similar to the old ones. The math library hasn't changed. I can't speak to the other libraries. -- 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
Re: math utilities question
On Mon, Dec 6, 2010 at 2:59 AM, Benny Tsai benny.t...@gmail.com wrote: Always nice to see a fellow Neal Stephenson fan! On Dec 5, 10:26 pm, Ken Wesson kwess...@gmail.com wrote: On Mon, Dec 6, 2010 at 12:14 AM, Miki miki.teb...@gmail.com wrote: Have you looked at Incanter? (http://incanter.org/) Hmm, interesting. Is there a Rhetor too? Wow, that didn't take long. Less than three hours! Obviously it's true what they say about Lisp hackers. :) -- 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
Re: math utilities question
I have looked at incanter and like it very much, but these are all things that incanter can't currently do. --Robert McIntyre On Mon, Dec 6, 2010 at 3:15 AM, Saul Hazledine shaz...@gmail.com wrote: On Dec 6, 12:27 am, Robert McIntyre r...@mit.edu wrote: I'm trying to use clojure for scientific data analysis but I keep running into lacunas of functionality. 6. symbolic manipulation as in sage This is something that would be awesome to have in Clojure because, unlike most non-lisps, you can compile the result and use it. This makes : 7. minimizing non-linear functions much easier. Saul -- 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 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
Re: math utilities question
Robert McIntyre r...@mit.edu writes: I'm wondering if people have had experience with java libraries of that sort and might have some recommendations. Anyone use clojure for scientific data analysis? What do you find helpful to use? I'm still just evaluating clojure for scientific data analysis, but I can share what I've found so far. First of all, Incanter. I like the idea of Incanter, but I don't like its decision to have matrices be the fundamental data object. Matrices are great, but they not the be-all and end-all. Multidimensional arrays are better, like in numpy or APL or J. It's a pet peeve about R that it doesn't distinguish scalars from vectors of length 1. (Konrad Hinsen had started some work on multiarrays in Clojure, but I've not been following his progress.) Also, Incanter seems very tuned to a row-wise view of data sets, while I've spent enough time with R and kdb+/q to prefer a column-wise view of data. (This is just based on reading the Incanter docs quickly; I may be misrepresenting the package.) As far as matrix libraries go, I've settled on EJML, since it seems reasonably fast, and I can understand what it's doing. Bradford Cross blogged a comparison of different libraries at: http://measuringmeasures.com/blog/2010/3/28/matrix-benchmarks-fast-linear-algebra-on-the-jvm.html I can't seem to find a good Java multiarray library, but I have some hope that I could beat EJML into shape, since its representation is just a basic array of doubles. I've built the Java interface to HDF5, and I've been using that for data storage. I would prefer to use a pure-Java solution, but I can't find anything that's nearly as good. Maybe I'm not reading the right news, but I've not seen all that much on using Java for scientific work for a while now. The NIST JavaNumerics guys seem to have given up, but if I remember correctly their conclusions were that Java really needed complex numbers as a value/stack-allocated type. This is a bit of a disjointed ramble, but I'd love to hear what you settle on. Regards, Johann -- 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
Re: math utilities question
On 06.12.2010, at 16:02, Johann Hibschman wrote: (Konrad Hinsen had started some work on multiarrays in Clojure, but I've not been following his progress.) There hasn't been much, unfortunately. I haven't found much time for serious Clojure hacking for a few months. But the project is not abandoned, just slowed down. I've built the Java interface to HDF5, and I've been using that for data storage. I would prefer to use a pure-Java solution, but I can't find anything that's nearly as good. netCDF has a Java library that also reads HDF5, but it's read-only. Maybe I'm not reading the right news, but I've not seen all that much on using Java for scientific work for a while now. The NIST JavaNumerics guys seem to have given up, but if I remember correctly their conclusions were that Java really needed complex numbers as a value/stack-allocated type. I'd say what Java needs is not complex numbers as a value type, but a way to define additional value types. Complex numbers are just one applications. Another one is points (2D or 3D) for geometry and graphics. Unfortunately the problem is not just Java, but the JVM, meaning that Clojure inherits the problem. Konrad. -- 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
Re: math utilities question
On Mon, Dec 6, 2010 at 11:45 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 06.12.2010, at 16:02, Johann Hibschman wrote: Maybe I'm not reading the right news, but I've not seen all that much on using Java for scientific work for a while now. The NIST JavaNumerics guys seem to have given up, but if I remember correctly their conclusions were that Java really needed complex numbers as a value/stack-allocated type. I'd say what Java needs is not complex numbers as a value type, but a way to define additional value types. Complex numbers are just one applications. Another one is points (2D or 3D) for geometry and graphics. Unfortunately the problem is not just Java, but the JVM, meaning that Clojure inherits the problem. Clojure does not inherit the problem, if you use macros cleverly. You can stack allocate individual primitives, separately, e.g. (let [x (int 3) y (double 4.2)] ...) And with macros you can wrap that in an abstraction that looks like a single object, such as a point or a complex number. Passing it to a function would require a bit of magic, though -- say, bundling the components into a vector and passing that as the fn arg, and unbundling again on the inside. If the call gets inlined the JIT should hopefully be able to optimize away this boxing. -- 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
Re: math utilities question
On 06.12.2010, at 22:35, Ken Wesson wrote: I'd say what Java needs is not complex numbers as a value type, but a way to define additional value types. Complex numbers are just one applications. Another one is points (2D or 3D) for geometry and graphics. Unfortunately the problem is not just Java, but the JVM, meaning that Clojure inherits the problem. Clojure does not inherit the problem, if you use macros cleverly. You can stack allocate individual primitives, separately, e.g. (let [x (int 3) y (double 4.2)] ...) And with macros you can wrap that in an abstraction that looks like a single object, such as a point or a complex number. Passing it to a function would require a bit of magic, though -- say, bundling the That's exactly the problem. An abstraction that doesn't pass a function boundary is of little use in a functional language. Decomposing complex numbers or points into primitives can be used as a local optimization technique, but not in a larger-scale design for software systems. Konrad. -- 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
Re: math utilities question
On Tue, Dec 7, 2010 at 12:58 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 06.12.2010, at 22:35, Ken Wesson wrote: I'd say what Java needs is not complex numbers as a value type, but a way to define additional value types. Complex numbers are just one applications. Another one is points (2D or 3D) for geometry and graphics. Unfortunately the problem is not just Java, but the JVM, meaning that Clojure inherits the problem. Clojure does not inherit the problem, if you use macros cleverly. You can stack allocate individual primitives, separately, e.g. (let [x (int 3) y (double 4.2)] ...) And with macros you can wrap that in an abstraction that looks like a single object, such as a point or a complex number. Passing it to a function would require a bit of magic, though -- say, bundling the That's exactly the problem. An abstraction that doesn't pass a function boundary is of little use in a functional language. Decomposing complex numbers or points into primitives can be used as a local optimization technique, but not in a larger-scale design for software systems. First of all, the abstraction does pass the function boundary if the function's a closure and you get it from the lexical scope rather than passing it as an argument. Second, macros can probably be used to make passing them as arguments and returning them transparent to the coder, in a way that boils away to nothing when the -server JIT goes to work on it. I can try to code a rough draft of such a facility and post it later. -- 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
Re: math utilities question
(defmacro defchunk [name tps] `(def ~name (quote ~tps))) (defmacro let-chunk [vname name val-vec body] (let [chunk-def @(resolve name) types (map first chunk-def) part-names (map (comp symbol (partial str vname !) second) chunk-def)] `(let [~vname ~val-vec ~@(interleave part-names (map #(list %1 (list vname %2)) types (iterate inc 0)))] ~...@body))) user= (defchunk foo [[int x][double y]]) #'user/foo user= (let-chunk afoo foo [1 1.7] afoo) [1 1.7] user= (let-chunk afoo foo [1 1.7] afoo!x) 1 user= (let-chunk afoo foo [1 1.7] afoo!y) 1.7 Simple enough, and afoo!x and afoo!y are primitive. (defchunk complex [[double real][double imag]]) (defn cx-mult [w z] (let-chunk w complex w (let-chunk z complex z [(- (* w!real z!real) (* w!imag z!imag)) (+ (* w!imag z!real) (* w!real z!imag))]))) (after a few runs to get it all JITted) user= (time (nth (iterate #(cx-mult % %) [0.0 1.0]) 1)) Elapsed time: 14.12232 msecs [1.0 -0.0] Looks like one iteration taking less than 2 microseconds to me. And that's with iterate. Loop gives this: user= (time (loop [c [0.0 1.0] n 1] (if (= n 0) c (recur (cx-mult c c) (dec n) Elapsed time: 2.54112 msecs [1.0 -0.0] Interestingly, using definline to define cx-mult slows this down instead of speeding it up. Another macro could give you a super-defn that let-chunks certain function parameters, so the (let-chunk foo bar foo ...) stuff wrapping the body of cx-mult disappears into a macro. Yet another could give you a loop-chunk. For truly high performance, though, the vector boxing is a problem. JIT doesn't seem to be eliminating it, or the speed would be up to 1000x faster still. Defstruct/defrecord is probably what's needed here; this would mean a) modifying defchunk to emit a suitable defstruct/defrecord in addition to the type-partname pairs structure and b) making the other macros destructure these instead of vectors. But the above shows a working, if crude, first pass at implementing the facility under discussion in this thread. Replacing vectors with structmaps/records in it will probably produce a large speedup when the things are passed across function boundaries. The remaining bugbear will be that the let-chunk and loop-chunk will create a heap allocated structmap/record even if it's unused. Having the macros detect if it's unused might not be easy. I'm unsure, though, that heap allocation is as horrid as everyone here seems to be assuming it to be. It may be horribly slow in FORTRAN or even in C but modern JVMs make heap allocation very cheap. I wouldn't be surprised if using heap-allocated structmaps or records directly will do fine. There are also supposed to be more optimizations for primitive use, including passing across function boundaries, in the forthcoming Clojure 1.3. -- 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
Re: math utilities question
Standard way, definitely no. As others have pointed out, Incanter is The Clojure Math Tool, but strongly biased towards statistics and linear algebra, and outside those fields you'll need other tools. Apache Commons Math (http://commons.apache.org/math/) is one of the better self-contained Java math libraries. I think it can do at least 4 (in one dimension), 5, and 7 (e.g. Levenberg-Marquardt). Another tool worth mentioning is jHepWork (http://jwork.org/ jhepwork/). It contains an impressive collection of various numerical Java libraries glued together, using Jython as its scripting language. Probably it wouldn't be too hard to glue Clojure into it, but how idiomatic it would be is another question... Best Regards, Joonas On Dec 6, 1:27 am, Robert McIntyre r...@mit.edu wrote: I'm trying to use clojure for scientific data analysis but I keep running into lacunas of functionality. I'd love to hear the community's recommendations and experiences with this: Is there a standard way to do things like: 1. take the convolution of two vectors 2. work with imaginary numbers, quaternions, octonions, etc 3. work with matrices of arbitrary dimension 4. Fourier transform ( in multiple dimensions) 5. integration / finite difference 6. symbolic manipulation as in sage 7. minimizing non-linear functions 8. finding zeros of non-linear functions thank you all in advance for any recommendations you might have. --Robert McIntyre -- 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
Re: math utilities question
On Sun, Dec 5, 2010 at 6:27 PM, Robert McIntyre r...@mit.edu wrote: I'm trying to use clojure for scientific data analysis but I keep running into lacunas of functionality. I'd love to hear the community's recommendations and experiences with this: Is there a standard way to do things like: 1. take the convolution of two vectors 2. work with imaginary numbers, quaternions, octonions, etc 3. work with matrices of arbitrary dimension 4. Fourier transform ( in multiple dimensions) 5. integration / finite difference 6. symbolic manipulation as in sage 7. minimizing non-linear functions 8. finding zeros of non-linear functions Standard, as in built into Clojure? No. Standard as in algorithmic? Of course. There are two options here. First, many of those things are fairly easily implemented in Clojure, and with a bit more work can be made very efficient (essentially, native-C efficient). For instance, for matrices you'd want a contiguous representation in memory so you'd use a vector, or even a Java array of doubles, of length m*n and functions that provided a matrix API and used this representation internally. With definline and macros this can be made efficient, and a Java array of doubles could have the speed of equivalent C code since it would be a contiguous block of doubles in RAM just as you'd get in C. Second, there are probably lots of existing scientific-computing libraries for Java out there that do the things you need done, and Clojure can load and call into Java libraries pretty easily. -- 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
Re: math utilities question
Thanks for your input --- I'm hoping that some of this stuff is already written with performance optimizations and the like. I'm wondering if people have had experience with java libraries of that sort and might have some recommendations. Anyone use clojure for scientific data analysis? What do you find helpful to use? --Robert McIntyre On Sun, Dec 5, 2010 at 9:36 PM, Ken Wesson kwess...@gmail.com wrote: On Sun, Dec 5, 2010 at 6:27 PM, Robert McIntyre r...@mit.edu wrote: I'm trying to use clojure for scientific data analysis but I keep running into lacunas of functionality. I'd love to hear the community's recommendations and experiences with this: Is there a standard way to do things like: 1. take the convolution of two vectors 2. work with imaginary numbers, quaternions, octonions, etc 3. work with matrices of arbitrary dimension 4. Fourier transform ( in multiple dimensions) 5. integration / finite difference 6. symbolic manipulation as in sage 7. minimizing non-linear functions 8. finding zeros of non-linear functions Standard, as in built into Clojure? No. Standard as in algorithmic? Of course. There are two options here. First, many of those things are fairly easily implemented in Clojure, and with a bit more work can be made very efficient (essentially, native-C efficient). For instance, for matrices you'd want a contiguous representation in memory so you'd use a vector, or even a Java array of doubles, of length m*n and functions that provided a matrix API and used this representation internally. With definline and macros this can be made efficient, and a Java array of doubles could have the speed of equivalent C code since it would be a contiguous block of doubles in RAM just as you'd get in C. Second, there are probably lots of existing scientific-computing libraries for Java out there that do the things you need done, and Clojure can load and call into Java libraries pretty easily. -- 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 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
Re: math utilities question
Have you looked at Incanter? (http://incanter.org/) On Dec 5, 3:27 pm, Robert McIntyre r...@mit.edu wrote: I'm trying to use clojure for scientific data analysis but I keep running into lacunas of functionality. I'd love to hear the community's recommendations and experiences with this: Is there a standard way to do things like: 1. take the convolution of two vectors 2. work with imaginary numbers, quaternions, octonions, etc 3. work with matrices of arbitrary dimension 4. Fourier transform ( in multiple dimensions) 5. integration / finite difference 6. symbolic manipulation as in sage 7. minimizing non-linear functions 8. finding zeros of non-linear functions thank you all in advance for any recommendations you might have. --Robert McIntyre -- 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
Re: math utilities question
On Mon, Dec 6, 2010 at 12:14 AM, Miki miki.teb...@gmail.com wrote: Have you looked at Incanter? (http://incanter.org/) Hmm, interesting. Is there a Rhetor too? -- 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
Re: math utilities question
Always nice to see a fellow Neal Stephenson fan! On Dec 5, 10:26 pm, Ken Wesson kwess...@gmail.com wrote: On Mon, Dec 6, 2010 at 12:14 AM, Miki miki.teb...@gmail.com wrote: Have you looked at Incanter? (http://incanter.org/) Hmm, interesting. Is there a Rhetor too? -- 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
Re: *math-context*
On Fri, Jul 10, 2009 at 7:14 AM, John Harropjharrop...@gmail.com wrote: It would be useful to have a *math-context* or similar that had a sensible default and could be set with binding to affect bigdec calculations within the temporal scope of said binding. user= (binding [*math-context* (java.math.MathContext. 5)] (+ 2 1.1M)) 3.M Even works in 1.0.0! Dunno if it's documented anywhere, though. :-/ In git master (a.k.a. 1.1.0-alpha-SNAPSHOT), you can now also set it at the REPL: user= (set! *math-context* (java.math.MathContext. 5)) #MathContext precision=5 roundingMode=HALF_UP http://www.assembla.com/spaces/clojure/tickets/137 --Chouser --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *math-context*
On Jul 10, 9:01 am, Chouser chou...@gmail.com wrote: On Fri, Jul 10, 2009 at 7:14 AM, John Harropjharrop...@gmail.com wrote: It would be useful to have a *math-context* or similar that had a sensible default and could be set with binding to affect bigdec calculations within the temporal scope of said binding. user= (binding [*math-context* (java.math.MathContext. 5)] (+ 2 1.1M)) 3.M Even works in 1.0.0! Dunno if it's documented anywhere, though. :-/ In git master (a.k.a. 1.1.0-alpha-SNAPSHOT), you can now also set it at the REPL: user= (set! *math-context* (java.math.MathContext. 5)) #MathContext precision=5 roundingMode=HALF_UP http://www.assembla.com/spaces/clojure/tickets/137 See also: with-precision Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *math-context*
On Fri, Jul 10, 2009 at 9:22 AM, Rich Hickey richhic...@gmail.com wrote: On Jul 10, 9:01 am, Chouser chou...@gmail.com wrote: On Fri, Jul 10, 2009 at 7:14 AM, John Harropjharrop...@gmail.com wrote: It would be useful to have a *math-context* or similar that had a sensible default and could be set with binding to affect bigdec calculations within the temporal scope of said binding. user= (binding [*math-context* (java.math.MathContext. 5)] (+ 2 1.1M)) 3.M See also: with-precision Eh. Thanks. There's no *math-context* on the api page at the web site. I just checked again. I'll keep it in mind though. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Math functions
On Jan 3, 7:46 pm, vogelrn voge...@gmail.com wrote: sqrt(a/b) should always be equal to sqrt(a)/sqrt(b) since (a/b)^m = a^m/b^m for b != 0. However, I'm unsure of whether it's the best option for ratios because unless both the numerator and the denominator are perfect squares, you're going to end up with a float anyway. This is trading an extra sqrt for precision in the relatively uncommon situation where both numbers are perfect squares. *nodsnodsnods* As for taking square roots involving complex numbers, I've been considering that as well, but I think it might be a bad idea to have it as a part of the normal sqrt function. In the majority of situations, taking the square root of a negative number is a bad thing and probably shouldn't be allowed. An alternative sqrt associated with complex numbers could be appropriate instead. I agree. Perhaps this article will be relevant for those interested in such a project: http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/6127.html mfh --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Math functions
On Jan 3, 2:48 pm, Mark Engelberg mark.engelb...@gmail.com wrote: I've noticed that Clojure is missing several math functions that come standard with most programming languages, especially other Schemes/Lisps. Many of these functions are available in java's math library, but only for doubles. Nice work, Mark. Are you on clojure-contrib? This would be a useful addition. -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Math functions
sqrt(a/b) should always be equal to sqrt(a)/sqrt(b) since (a/b)^m = a^m/b^m for b != 0. However, I'm unsure of whether it's the best option for ratios because unless both the numerator and the denominator are perfect squares, you're going to end up with a float anyway. This is trading an extra sqrt for precision in the relatively uncommon situation where both numbers are perfect squares. As for taking square roots involving complex numbers, I've been considering that as well, but I think it might be a bad idea to have it as a part of the normal sqrt function. In the majority of situations, taking the square root of a negative number is a bad thing and probably shouldn't be allowed. An alternative sqrt associated with complex numbers could be appropriate instead. On Jan 3, 10:06 pm, Mark H. mark.hoem...@gmail.com wrote: On Jan 3, 11:48 am, Mark Engelberg mark.engelb...@gmail.com wrote: If you give it an exact number (i.e., not a floating point), Floating-point numbers are exact -- it's their operations that may not be. *ducks* Seriously, handy code -- many thanks! I should check with someone whether sqrt(a/b) - sqrt(a)/sqrt(b) is a fair assumption. Would you find a sqrt that returns complex numbers for negative inputs (it would be the appropriate branch of the sqrt function in order to make it single-valued) useful? mfh --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Math functions
On Sat, Jan 3, 2009 at 7:06 PM, Mark H. mark.hoem...@gmail.com wrote: Would you find a sqrt that returns complex numbers for negative inputs (it would be the appropriate branch of the sqrt function in order to make it single-valued) useful? Ideally I'd also like that, but since complex numbers aren't part of Clojure's numeric tower, and since there isn't one official Java implementation of complex numbers (as far as I know), I just do what Java's sqrt function does (i.e., return NaN). --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Math as multimethods
Alternatively, could I provide a multi- math lib to redefine the core math functions? Type classes would be king. Do you mean this in the Haskell sense? (I'm not too familiar with those) Or something more like Java's types? I was thinking about how to solve this problem more generally and was considering an interface, but nothing obvious came to mind. Java's lack of operator overloading makes this more difficult I think. But at least you can use your definition : (ns test.test (:refer-clojure :exclude [+ -])) (defn + [a b] 33) (+ 1 2) ;= 33 Thanks for the suggestion, this will give me a chance to play around with multi-method and see what I think. Cheers, -Mark --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Math as multimethods
On 8 déc, 17:14, Mark Fredrickson [EMAIL PROTECTED] wrote: Alternatively, could I provide a multi- math lib to redefine the core math functions? Type classes would be king. Do you mean this in the Haskell sense? Yes : http://www.haskell.org/tutorial/classes.html Haskell make a dispatch on type at runtime. (ns test.test (:refer-clojure :exclude [+ -])) (defn + [a b] 33) (+ 1 2) ;= 33 Thanks for the suggestion, You can overload core function : (binding [clojure.core/compare (constantly 1)] (sort [1 5 2 6])) ;(6 2 5 1) But it wouldn't work if the function is inline. (binding [clojure.core/= (constantly false)] [(= 1) (= 1 1) (not= 1 1) ]) ; [false true false] this will give me a chance to play around with multi-method and see what I think. I'm not sure, but : defmethod macro simply call addMethod on clojure.lang.MultiFn object. So you can add method from an other namespace. Basically, you would build something like type class. But it wouldn't play nice with core operator. pierre --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Math as multimethods
I've been toying with something similar. The approach I took was to define multi-methods for the various operators: (defmulti add class) (defmulti sub class) (defmulti mul class) (defmulti div class) ... Then I of course write the implementations for various different types. Then, because the multi-method names don't look nice, I wrote a macro which transformed the regular operators into calls on the multi-methods, i.e.: (macroexpand-1 '(extended-math (* 3 A))) -- (mul 3 A) Its still not as clean as a having the operators defined as multi-methods from the get-go, but you don't have to muck with overriding the core names. One reason to leave the core operators alone is performance. Multi-method dispatch is far more expensive than a regular dispatch. I don't have this in front of me to get some real numbers, but when I tested, the same operations with the multi-methods were about 10x slower than the direct dispatch. /mike. On Mon, Dec 8, 2008 at 1:50 PM, ppierre [EMAIL PROTECTED] wrote: On 8 déc, 17:14, Mark Fredrickson [EMAIL PROTECTED] wrote: Alternatively, could I provide a multi- math lib to redefine the core math functions? Type classes would be king. Do you mean this in the Haskell sense? Yes : http://www.haskell.org/tutorial/classes.html Haskell make a dispatch on type at runtime. (ns test.test (:refer-clojure :exclude [+ -])) (defn + [a b] 33) (+ 1 2) ;= 33 Thanks for the suggestion, You can overload core function : (binding [clojure.core/compare (constantly 1)] (sort [1 5 2 6])) ;(6 2 5 1) But it wouldn't work if the function is inline. (binding [clojure.core/= (constantly false)] [(= 1) (= 1 1) (not= 1 1) ]) ; [false true false] this will give me a chance to play around with multi-method and see what I think. I'm not sure, but : defmethod macro simply call addMethod on clojure.lang.MultiFn object. So you can add method from an other namespace. Basically, you would build something like type class. But it wouldn't play nice with core operator. pierre --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Math as multimethods
On 8 déc, 23:13, Michael Reid [EMAIL PROTECTED] wrote:
Then I of course write the implementations for various different
types. Then, because the multi-method names don't look nice, I wrote a
macro which transformed the regular operators into calls on the
multi-methods, i.e.:
(macroexpand-1 '(extended-math (* 3 A))) -- (mul 3 A)
Its still not as clean as a having the operators defined as
multi-methods from the get-go, but you don't have to muck with
overriding the core names.
I was trying to do it with namespace but :
ns scratch
(:refer-clojure :exclude [+ - * /])
(:use clojure.contrib.def))
(defalias * clojure.core/*)
(* 2 5) ; 10
(defalias / clojure.core//)
;; #Exception java.lang.Exception: Invalid token: scratch//
Didn't find why it work in core.clj ???
One reason to leave the core operators alone is performance.
Multi-method dispatch is far more expensive than a regular dispatch. I
don't have this in front of me to get some real numbers, but when I
tested, the same operations with the multi-methods were about 10x
slower than the direct dispatch.
Yes, but it give you some nice abstractions :
sort fallback to Comparable interface.
If not you would use sort-by and provide a function.
An other example :
public interface IPersistentVector extends Associative, Sequential,
IPersistentStack, Reversible
seq co make Clojure nice and efficient.
But I didn't see a simple way to do it in Clojure (it self).
May be :
(gen-type
:name AType
:extends [Types...]
:methods [aMethode names...])
(gen-instance
:name AnInstance
:extends [AType Types...])
(defmethod aMethode [#^AnInstance param]
(print (param any:)))
(def aVar (AnInstance. {any: Data}))
(aMethode (aVar))
Some day, I would try to do it.
pierre
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Math as multimethods
On 6 déc, 05:09, Mark Fredrickson [EMAIL PROTECTED] wrote: Alternatively, could I provide a multi- math lib to redefine the core math functions? Type classes would be king. But at least you can use your definition : (ns test.test (:refer-clojure :exclude [+ -])) (defn + [a b] 33) (+ 1 2) ;= 33 pierre --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
