New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Clojure Engineers Needed at Factual http://functionaljobs.com/jobs/8646-clojure-engineers-needed-at-factual Cheers, Sean Murphy FunctionalJobs.com -- -- 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: Clojure, floats, ints and OpenGL
Hi Alex, Just one more thing to think about: Dmitry Groshev has been doing some good early work on Clojure float support in the core.matrix NDArray implementation (basically a NumPy-style multidimensional array implementation backed by a single large float[] array). The per-object overhead is probably too high for it to be useful as a Vertex3f replacement, but it might fit some of your use cases, particularly when you have a large number of float values to manipulate at the same time (physics, wave simulation, mesh deformation etc). It avoids the current Clojure limitations on float function arguments by using custom macros to compile all the inner loops. Quite clever stuff. Mike. On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote: Hello! With this letter I would like to receive an answer from somebody from the development team (if anyone else has something to say, you're surely welcome :) ). I am working for a big multimedia company and recently I have been considering moving to Clojure as the main language of development. We have been doing Java and Scala before, but now when I tried Clojure and see the possibilities it provides, I would definitely stand for it to be our ground. However, while I am so satisfied with everything - the language, the community, the Java interop, there is still something that hinders and makes me linger. Namely, the lack of good support of floats and ints in the language. While many people would not consider it to be a huge disadvantage or even notice it, things are not so bright when it comes to OpenGL. The case is that OpenGL and 3D graphics hardware in general has no support for doubles or longs. Therefore, all libraries, all data and all computations are meant to be performed with floats and ints (shaders too). Due to the lack of good support of these data types in Clojure (for example, there are no ^float and ^int typehints, float and int values can only be typecasted to, all calculations always retain doubles and longs), results in too many extra typecasts, which are absolutely unnecessary and take too much time. So, calculations become very cumbersome, even if we do not take mandatory boxing into account. Considering that such kinds of calculations are usually abuntant in the aforementioned types of applications, the penalty grows really huge. I have endeavoured several discussions on the IRC to find out possible workarounds. Although many good proposals by many good people were made, aimed at improving the situation, none of them could solve the fundamental lack of the ability to manipulate 32bit primitive (or even boxed) data types. That lack renders Clojure not really suitable for heavy-load OpenGL applications that require somewhat extensive calculations: some kinds of games, simulations, generative graphics and so on. Considering how superior Clojure is to any other language available for JVM, that black spot looks especially embarrasing. And I could imagine falling back to Java for fast computations, just like we fall back to ASM in, say C, that is very undesirable and discouraging, since we want to pick Clojure for Clojure and it will be too cumbersome to make 50/50% Java/Clojure apps just to work around that design decision. Therefore, while deciding if to pick Clojure as the base for our development, I would like to know answers to the following questions: 1) What is the current reason for the support for these types to be missing? 2) Are there any plans for improvement of support for floats, ints and maybe, localized unboxed calculations? Or is there some advice on how to enable their support? 3) What is you vision for Clojure + OpenGL applications? 4) Is it possible to request support for floats, ints and maybe shorts for the language? 5) Is it possible to request support for localized unboxed calculations, like (with-unboxed ... ) and localized float-only and int-only calculations, like, say in special macros (with-floats--ints ... here go (+) (-) and stuff ONLY with floats/ints ... ) ? Preferably, I would like to hear the answers from somebody from the development team, because I have already received enough support from the community, on the IRC, I appreciate it, but now I have to make a serious choice for our company and I feel quite responsible for that. I also feel that these questions are very important for any specialist that works with OpenGL and influence Clojure acceptance for OpenGL-enabled applications world-wide. Thank you. -- -- 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
Re: Clojure, floats, ints and OpenGL
On Saturday, 14 September 2013 00:36:05 UTC+8, James Reeves wrote:
On 13 September 2013 08:54, Mikera mike.r.an...@gmail.com
javascript:wrote:
Either way, if Clojure's semantics prove to be a fundamental issue for
performance, then I think it is better to start work to improve Clojure's
semantics (perhaps targeting 2.0 if we think it's a really big breaking
change). This would be better, IMHO, than forever accepting semantics that
prevent idiomatic code from ever being truly fast. I'd rather see a bit of
breakage and fix my code when upgrading to Clojure 2.0 than be stuck with
poor performance forever.
Out of curiosity, what is the performance hit in these cases?
Here's a quick highly artificial benchmark I did with Caliper in Java
(Obviously can't benchmark in Clojure since we don't have proper float
support)
0% Scenario{vm=java, trial=0, benchmark=Float} 267222.79 ns; σ=1629.43 ns
@ 3 trials
50% Scenario{vm=java, trial=0, benchmark=Double} 416110.28 ns; σ=2087.75 ns
@ 3 trials
benchmark us linear runtime
Float 267 ===
Double 416 ==
vm: java
trial: 0
Obviously this is just a microbenchmark, but it fits my general experience
that floats are a reasonable bit faster than doubles, typically 20-100%
(doubles are closer when it is pure number crunching since 64-bit CPUs are
actually pretty good at doubles, floats have a bigger advantage when you
are manipulating a lot of data points and hence memory bandwidth matters
more)
Code here for those interested:
src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java
Floats obviously save memory, and I believe they're also between 15% to
40% more efficient for division, at least on Intel CPUs. Is there also a
cost to be paid passing doubles to OpenGL? Do you know what that cost is?
I'm not exactly an expert in OpenGL, but I would make the following points:
- Many GPU applications are actually memory-bandwidth bound (the compute
power is insane). So using floats means you can pump through 2x as much
data to keep your GPUs busy
- Hardware and driver support is usually not on a par with floats, even if
it is technically supported by the OpenGL API
This is an interesting article to back up the latter point: For example on
NVidia GeForce hardware doubles are 1/8 the speed of floats
http://blog.hvidtfeldts.net/index.php/2012/07/double-precision-in-opengl-and-webgl/
--
--
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: The Eclipse Public License is not a good license
Seriously? Your problem is that a contributor has to state that they have added something? Why are you worried about this? Musical Notation musicdenotat...@gmail.com writes: Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. That's my problem. On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote: This is an interesting thread. I think, though, it repeats what is a misconception about GPL -- that you cannot produce GPL code using Clojure. This isn't true, as far as I can see -- you can write GPL code using any language, because it doesn't usage restrictions in GPL do not percolate through a standard interface. So, for instance, my own library is covered by LGPL; it is possible to link this to GPL code without problems. Historically, the first GPL products (Emacs for example) were built using on non GPL platforms; it is the same issue. Sean Corfield seancorfi...@gmail.com writes: Searching the archives would have turned up some _long_ threads about this where it would have been clear that the license is not going to change - as well as explaining why it is the way it is. For example: https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from 2008) Sean On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis musicdenotat...@gmail.com wrote: I think that Clojure should switch to a better license with similar spirit like Apache 2.0, BSD, or MIT. While the EPL doesn't have the evil copyleft requirement of GPL, and therefore allows and encourages commercial uses of the code, it has a requirement that makes it incompatible with the GPL: If you create modified versions of EPL-covered software, you must slap your name (or any other identity) on it. In my humble opinion, this restriction isn't justified. (All, or most, creators of modified versions will do that anyway). It may have been chosen uncarefully. Other permissive licenses better fulfill Rich Hickey's spirit. -- -- 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. -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- 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: ClojureScript 0.0-1885 (Source maps!)
Nicola Mometto also deserves quite a bit of credit, the fact that tools.reader emits line and column information on all symbols is essential for the accuracy of ClojureScript source maps. On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga drchoc...@gmail.com wrote: I'm so happy for this, I've been subscribed to that issue on Jira for a while now, and here it is, alive and working! Just ran some demo code and it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you know about any bugs I find. On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. The biggest change in this release thanks to Sean Grove - much improved source maps. You can provide a :source-map option to the compiler to name the source map file. Feedback on this significant enhancement welcome. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-1885 Leiningen dependency information: [org.clojure/clojurescript 0.0-1885] Enhancements: * Accurate source maps! Changes: * cljs.core/format based on goog.string/format backed out * set-print-fn! no longer exported Fixes: * CLJS-588: allow upstream :foreign-libs to be used -- -- 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: The Eclipse Public License is not a good license
Being filed by the NSA ? Oups, too late :) Luc P. Seriously? Your problem is that a contributor has to state that they have added something? Why are you worried about this? Musical Notation musicdenotat...@gmail.com writes: Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. That's my problem. On Sep 12, 2013, at 19:18, phillip.l...@newcastle.ac.uk (Phillip Lord) wrote: This is an interesting thread. I think, though, it repeats what is a misconception about GPL -- that you cannot produce GPL code using Clojure. This isn't true, as far as I can see -- you can write GPL code using any language, because it doesn't usage restrictions in GPL do not percolate through a standard interface. So, for instance, my own library is covered by LGPL; it is possible to link this to GPL code without problems. Historically, the first GPL products (Emacs for example) were built using on non GPL platforms; it is the same issue. Sean Corfield seancorfi...@gmail.com writes: Searching the archives would have turned up some _long_ threads about this where it would have been clear that the license is not going to change - as well as explaining why it is the way it is. For example: https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8 (from 2008) Sean On Wed, Sep 11, 2013 at 6:41 AM, Kalinni Gorzkis musicdenotat...@gmail.com wrote: I think that Clojure should switch to a better license with similar spirit like Apache 2.0, BSD, or MIT. While the EPL doesn't have the evil copyleft requirement of GPL, and therefore allows and encourages commercial uses of the code, it has a requirement that makes it incompatible with the GPL: If you create modified versions of EPL-covered software, you must slap your name (or any other identity) on it. In my humble opinion, this restriction isn't justified. (All, or most, creators of modified versions will do that anyway). It may have been chosen uncarefully. Other permissive licenses better fulfill Rich Hickey's spirit. -- -- 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. -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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: [ClojureScript] Re: ANN: ClojureScript 0.0-1885 (Source maps!)
Yeah, tools.reader is amazing. Honestly the source map patch was just a bit of glue between David's existing work and integrating tools.reader, the bulk of the results are due to them. On Mon, Sep 16, 2013 at 2:31 PM, David Nolen dnolen.li...@gmail.com wrote: Nicola Mometto also deserves quite a bit of credit, the fact that tools.reader emits line and column information on all symbols is essential for the accuracy of ClojureScript source maps. On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga drchoc...@gmail.comwrote: I'm so happy for this, I've been subscribed to that issue on Jira for a while now, and here it is, alive and working! Just ran some demo code and it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you know about any bugs I find. On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. The biggest change in this release thanks to Sean Grove - much improved source maps. You can provide a :source-map option to the compiler to name the source map file. Feedback on this significant enhancement welcome. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-1885 Leiningen dependency information: [org.clojure/clojurescript 0.0-1885] Enhancements: * Accurate source maps! Changes: * cljs.core/format based on goog.string/format backed out * set-print-fn! no longer exported Fixes: * CLJS-588: allow upstream :foreign-libs to be used -- -- 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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- -- 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: Clojure, floats, ints and OpenGL
Hi Mikera, I don't have a whole lot of skin in this game as, unfortunately, I haven't run into any performance bottlenecks that I couldn't fix in a satisfying way whilst writing Clojure. My impression, however, is that there are some people in the community who feel the performance limitations of some of Clojure's core design decisions. I've been following this discussion as it's going on and it seems like it's winding down in the same way I've watched many such discussions wind down in the past: Can we please get an official word from Rich whether this would be worth someone's time? That's usually where these things die. So have you considered writing up a more formal proposal, maybe with some very rough sketches of how you might envision implementing things, and actually sending it to Rich (or maybe at this point Alex Miller)? Ideally this wouldn't be something as time consuming as a full prototype but would be more than just some thoughts scratched out on mail. I think he basically doesn't read this list or visit IRC anymore and getting heard here on something like design directions for Clojure seems like a fool's errand. Anyway, I like being able to follow these discussions on the mailing list and I think the mailing list is still a good place to gauge interest and get some thoughts on design direction (Timothy's been doing a great job lately of bringing up edge cases that may not have been considered), but I think you'll probably never see an official word on Clojure here. Keep up the good work! -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ -- Spend less time on mail -- -- 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.
[ANN] Cognitect
I just wanted to let everyone know that Metadata Partners (the company behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This merger is great for Clojure, adding considerable resources and stability to its development and support, including new enterprise support offerings and reinvigorated community support. (You should read the hiring of Alex Miller as the first example of the latter). I hope the availability of enterprise support for the entire platform makes it easier for people to introduce Clojure into their organizations. This is a very exciting time for Clojure and the platform and ecosystem surrounding it. You can find out more at: http://cognitect.com Thanks, 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 --- 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] Cognitect
Rich and Relevance, This is very exciting news for the Clojure community (and yourselves I'm sure). I for one look forward to seeing how you rock our worlds. On Mon, Sep 16, 2013 at 9:50 AM, Rich Hickey richhic...@gmail.com wrote: I just wanted to let everyone know that Metadata Partners (the company behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This merger is great for Clojure, adding considerable resources and stability to its development and support, including new enterprise support offerings and reinvigorated community support. (You should read the hiring of Alex Miller as the first example of the latter). I hope the availability of enterprise support for the entire platform makes it easier for people to introduce Clojure into their organizations. This is a very exciting time for Clojure and the platform and ecosystem surrounding it. You can find out more at: http://cognitect.com Thanks, 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 --- 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. -- -- http://blog.fogus.me -- http://github.com/fogus -- -- -- 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] Cognitect
Congrats! This is great news all around! Paul On Monday, September 16, 2013 6:50:46 AM UTC-7, Rich Hickey wrote: I just wanted to let everyone know that Metadata Partners (the company behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This merger is great for Clojure, adding considerable resources and stability to its development and support, including new enterprise support offerings and reinvigorated community support. (You should read the hiring of Alex Miller as the first example of the latter). I hope the availability of enterprise support for the entire platform makes it easier for people to introduce Clojure into their organizations. This is a very exciting time for Clojure and the platform and ecosystem surrounding it. You can find out more at: http://cognitect.com Thanks, 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 --- 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] Cognitect
Exciting! --- Joseph Smith j...@uwcreations.com @solussd On Sep 16, 2013, at 8:50 AM, Rich Hickey richhic...@gmail.com wrote: I just wanted to let everyone know that Metadata Partners (the company behind Datomic) and I have merged with Relevance, Inc., to form Cognitect, Inc. This merger is great for Clojure, adding considerable resources and stability to its development and support, including new enterprise support offerings and reinvigorated community support. (You should read the hiring of Alex Miller as the first example of the latter). I hope the availability of enterprise support for the entire platform makes it easier for people to introduce Clojure into their organizations. This is a very exciting time for Clojure and the platform and ecosystem surrounding it. You can find out more at: http://cognitect.com Thanks, 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 --- 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.
Memory leak problem
Dear List,
I'm experiencing a memory leak and I don't understand why.
I have a bunch of 50 files on disk called data-1.edn through
data-50.edn. I perform the following code:
(def all-processed-data (reduce (fn [ret f] (merge ret (process-data
(clojure.tools.reader.edn/read-string (slurp f) {} file-list))
file-list is a sequence of java.io.File objects pointing towards the 50
data files.
process-data is a function that produces a map from the data read.
Although each individual datafile is about 100 Megabytes, the result of
processing a datafile is a map of about 200k only, so that the map returned
by the entire above expression is only about 10 Megabytes. Nevertheless,
executing the above code fills up memory and eventually stops clojure from
functioning. Why?
Thanks a lot for any suggestions!
Joachim.
--
--
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: Building Trees
That is along the lines of my thinking. I am starting to look at zippers again. However much of what I need it to do either isn't documented at all or it was never intended to construct trees over time. The purpose of this is to look at sequenced events and detect frequent patterns. These patterns can have variations. It is built from the top down with the most frequent events added first, the 2nd most added second, etc. What ends up happening is that I see A-B-C-D a lot, for example, but I also see A-B-D-F sometimes. I see B-D-E-F-G rarely. So what I want to do is keep track of each of these. The first two are variations of each other stemming after A-B. What I want to do is to be able to look at D and see what events often precede it. I see that in all of my data A, B and C precede it. However just by examining the counts I can determine that C does not occur more than random chance so I can drop that and return B, A as my set, in that order because I see B preceeding more than A. Big Whoop you say. But now lets apply this to some interesting situations. Let's say that instead of letters we have topics. D is part of some greater topic concept. I want to know what other topics predict the existence of D such that if I see them I think that its possible they imply D. B and A do this, according to this analysis. So when I tell my search engine I'm interested in D it will also search for B and A knowing that while D isn't mentioned by name, there is a possibility it is implied when B or A are present. Concrete example. I want documents that talk about automobiles. Automobile associates with things like drivers seat steering wheel rear view mirror but also with car car wash Prius Ford and other terms. Why is this important? Let's say I don't want a general return of information but I am looking for a very specific document. If I don't have the right keyword I have to guess. A lot. I may never guess right. So I need to be sure my search is augmented properly. That is what this will do. However the number of events I will be looking at will be in the hundreds of millions and for some data sets will be in the billions or greater. The problem will be distributed. However, for today, I just need to get this to work on my laptop, with an eye to the future as to how I will get this to work on a large network of machines. So far I have loved Functional Programming... right up to this problem. This one is killing me. I am going to examine the other suggestions here for how to do it. I am certain that Clojure is extremely excellent at solving this kind of problem and I am becoming more certain I am missing some FP concept that is preventing me from tapping into that power! Solve this problem and Clojure becomes the best platform for large scale machine learning out there. My company has 3 complex applications up already making money and the bugs are 99% design issues instead of something not working in an expected manner. This is really fantastic and has me sold that Clojure was a good choice. --Pete On Monday, September 9, 2013 4:06:41 PM UTC-5, Laurent PETIT wrote: This is quite an interesting post, with the underlying question in my mind : where to put the line between pure datastructure manipulation with clojure.core only, and a datalog (datomic)/sql engine ? -- -- 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: Memory leak problem
Are you using a version of Java earlier than 7u6? If so, this *might* be
related to the conversation from a few days ago about functions like subs,
re-find, etc. returning short strings that keep references to the longer
strings they were created from:
https://groups.google.com/forum/#!topic/clojure/PeHTCWNgrL0
Even if you are using such a Java version, I have not confirmed whether the
function clojure.tools.reader.edn/read-string returns substrings of the
input string.
One quick thing to try that might help is to call
clojure.tools.reader.edn/read on the File object f directly, without
calling slurp. That will at least avoid the behavior of creating big
strings with the entire contents of each file. It should also avoid the
small substrings holding references to large original strings, if that is
indeed what you are experiencing.
Andy
On Mon, Sep 16, 2013 at 8:17 AM, Joachim De Beule
joachim.de.be...@gmail.com wrote:
Dear List,
I'm experiencing a memory leak and I don't understand why.
I have a bunch of 50 files on disk called data-1.edn through
data-50.edn. I perform the following code:
(def all-processed-data (reduce (fn [ret f] (merge ret (process-data
(clojure.tools.reader.edn/read-string (slurp f) {} file-list))
file-list is a sequence of java.io.File objects pointing towards the 50
data files.
process-data is a function that produces a map from the data read.
Although each individual datafile is about 100 Megabytes, the result of
processing a datafile is a map of about 200k only, so that the map returned
by the entire above expression is only about 10 Megabytes. Nevertheless,
executing the above code fills up memory and eventually stops clojure from
functioning. Why?
Thanks a lot for any suggestions!
Joachim.
--
--
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: [ClojureScript] ANN: ClojureScript 0.0-1885 (Source maps!)
I see that clojure.core/format is gone. Is there a replacement/alternative? --- Joseph Smith j...@uwcreations.com @solussd On Sep 16, 2013, at 7:31 AM, David Nolen dnolen.li...@gmail.com wrote: Nicola Mometto also deserves quite a bit of credit, the fact that tools.reader emits line and column information on all symbols is essential for the accuracy of ClojureScript source maps. On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga drchoc...@gmail.com wrote: I'm so happy for this, I've been subscribed to that issue on Jira for a while now, and here it is, alive and working! Just ran some demo code and it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you know about any bugs I find. On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. The biggest change in this release thanks to Sean Grove - much improved source maps. You can provide a :source-map option to the compiler to name the source map file. Feedback on this significant enhancement welcome. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-1885 Leiningen dependency information: [org.clojure/clojurescript 0.0-1885] Enhancements: * Accurate source maps! Changes: * cljs.core/format based on goog.string/format backed out * set-print-fn! no longer exported Fixes: * CLJS-588: allow upstream :foreign-libs to be used -- -- 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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- -- 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: [ClojureScript] ANN: ClojureScript 0.0-1885 (Source maps!)
Use goog.string.format. David On Mon, Sep 16, 2013 at 11:35 AM, Joe Smith j...@uwcreations.com wrote: I see that clojure.core/format is gone. Is there a replacement/alternative? --- Joseph Smith j...@uwcreations.com @solussd On Sep 16, 2013, at 7:31 AM, David Nolen dnolen.li...@gmail.com wrote: Nicola Mometto also deserves quite a bit of credit, the fact that tools.reader emits line and column information on all symbols is essential for the accuracy of ClojureScript source maps. On Mon, Sep 16, 2013 at 1:58 AM, Marco Munizaga drchoc...@gmail.comwrote: I'm so happy for this, I've been subscribed to that issue on Jira for a while now, and here it is, alive and working! Just ran some demo code and it looks amazing! Thanks Sean Grove and thanks David Nolen. I'll let you know about any bugs I find. On Sunday, September 15, 2013 2:48:46 PM UTC-4, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. The biggest change in this release thanks to Sean Grove - much improved source maps. You can provide a :source-map option to the compiler to name the source map file. Feedback on this significant enhancement welcome. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-1885 Leiningen dependency information: [org.clojure/clojurescript 0.0-1885] Enhancements: * Accurate source maps! Changes: * cljs.core/format based on goog.string/format backed out * set-print-fn! no longer exported Fixes: * CLJS-588: allow upstream :foreign-libs to be used -- -- 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. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- -- 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] Cognitect
Fantastic news. Congrats to all involved! -- -- 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: Clojure, floats, ints and OpenGL
On 16 September 2013 09:03, Mikera mike.r.anderson...@gmail.com wrote: Obviously this is just a microbenchmark, but it fits my general experience that floats are a reasonable bit faster than doubles, typically 20-100% (doubles are closer when it is pure number crunching since 64-bit CPUs are actually pretty good at doubles, floats have a bigger advantage when you are manipulating a lot of data points and hence memory bandwidth matters more) Code here for those interested: src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java That's a pretty interesting result. I ran some tests of my own, based on your code, as I wondered whether or not the time to instantiate the array of doubles was biasing the test. My goal was to see whether or not I'd get a similar result running an array of floats through a method that processed doubles. (See: https://gist.github.com/weavejester/6583367) It turns out that I get a similar result. Passing floats to a method that takes doubles slows things down by a similar amount, unless I've somehow botched up the test. Considering that converting between single and double precision should be pretty cheap on the CPU, I'm surprised at the difference. This somewhat changes my view on things. It doesn't affect me in practice, but I can see how someone might be frustrated by having to drop down to Java to achieve performance for floating point calculations. - James -- -- 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: Memory leak problem
A symptom of this would be jmap or visualvm reporting [C or char[] as the
largest allocation, by class.
On Monday, September 16, 2013 8:40:27 AM UTC-7, Andy Fingerhut wrote:
Are you using a version of Java earlier than 7u6? If so, this *might* be
related to the conversation from a few days ago about functions like subs,
re-find, etc. returning short strings that keep references to the longer
strings they were created from:
https://groups.google.com/forum/#!topic/clojure/PeHTCWNgrL0
Even if you are using such a Java version, I have not confirmed whether
the function clojure.tools.reader.edn/read-string returns substrings of the
input string.
One quick thing to try that might help is to call
clojure.tools.reader.edn/read on the File object f directly, without
calling slurp. That will at least avoid the behavior of creating big
strings with the entire contents of each file. It should also avoid the
small substrings holding references to large original strings, if that is
indeed what you are experiencing.
Andy
On Mon, Sep 16, 2013 at 8:17 AM, Joachim De Beule
joachim@gmail.comjavascript:
wrote:
Dear List,
I'm experiencing a memory leak and I don't understand why.
I have a bunch of 50 files on disk called data-1.edn through
data-50.edn. I perform the following code:
(def all-processed-data (reduce (fn [ret f] (merge ret (process-data
(clojure.tools.reader.edn/read-string (slurp f) {} file-list))
file-list is a sequence of java.io.File objects pointing towards the 50
data files.
process-data is a function that produces a map from the data read.
Although each individual datafile is about 100 Megabytes, the result of
processing a datafile is a map of about 200k only, so that the map returned
by the entire above expression is only about 10 Megabytes. Nevertheless,
executing the above code fills up memory and eventually stops clojure from
functioning. Why?
Thanks a lot for any suggestions!
Joachim.
--
--
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: Building Trees
Offhand, I'd say this sounds like you need to build a Bayesian network. I'd recommend taking this course: https://www.coursera.org/course/pgm which uses this book: http://www.amazon.com/Probabilistic-Graphical-Models-Principles-Computation/dp/0262013193 -- -- 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: Building Trees
Thanks. I authored a paper on building a gaussian-bayes classifier and implemented it in clojure. I looked at Titan. That has a lot of things I like but it requires named nodes to only exist once. So, that is close but not quite what I want. I'm looking at Zippers again. On Monday, September 16, 2013 1:42:24 PM UTC-5, puzzler wrote: Offhand, I'd say this sounds like you need to build a Bayesian network. I'd recommend taking this course: https://www.coursera.org/course/pgm which uses this book: http://www.amazon.com/Probabilistic-Graphical-Models-Principles-Computation/dp/0262013193 -- -- 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.
Weird core.async/ClojureScript issues
Howdy, I'm using core.async and ClojureScript and I'm running into a weird problem... basically if/when/loop constructs don't work anymore in go blocks in ClojureScript. For example: -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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.
Weird core.async/ClojureScript not workings...
Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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: Clojure, floats, ints and OpenGL
Timothy, thank you very much for such a good explanation! I fully agree with you. Actually, except for a few details, that is really how I thought the things are. It is good that you describe the technical base for problems with the issue. As well as clearified the human factor. What you're saying is very much like what I would say if I were in your shoes. Currently, what you're saying, is the present. In the present we make our choices for currents. And I also agree with Mikera, that an attempt should be taken. I would participate in it myself if I was into JVM and Clojure internals. I plan to learn it, but it will take time. Mikera, thanks for the reference for the library, I will have a look. Also I strongly encourage you in the attempt and I will be happy if I can be of any help, although, you seem to know much more than me. I agree with Tim that some more decisive steps have to be taken into this direction. James, ah.. yes, we did benchmarks. We use highly optimized mathematical calculations, derived from numerical analysis. Every single instruction matters there. Due to the nature of the calculations, the amout of casts, however, varies from 3 to N in one computation. There can be 1 to M such computation for a data unit. And thre can be 1 to P data units. At the end, what worked on plain Java or Java-stylized Scala, worked that times faster, NxMxP more instructions to be computed. Where there were 500 fps, sometimes happen to be 480 fps and sometimes 0.01 fps. And I am not even talking about operations on vast arrays or NIO buffers. But imagine for example, you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and will go back to it. Operation on each float takes, say 5 casts double-float in Clojure. Also, as Mikera points out, bus speeds come into play too. Of course, as Timothy said, why don't we go back to C for that kind of stuff? This is a popular question in such cases. I am not going to go into details on that, except for saying that we have mostly migrated from C to JVM and it satisfies our requirements, while giving huge benifits. However, we still do some things in C. To prevent arguments, here is an articlehttp://beautynbits.blogspot.ru/2013/01/performance-java-vs-c.html that somewhat describes what one can lose in computation, but does not describe what one gains in other aspects. The loss is what can be tolerated. But that loss for JVM is understandable. The one more loss for Clojure is understandable too, but it can be changed. I think that the discussion branch of Java vs C may be laid to rest. On Mon, Sep 16, 2013 at 9:03 PM, James Reeves ja...@booleanknot.com wrote: On 16 September 2013 09:03, Mikera mike.r.anderson...@gmail.com wrote: Obviously this is just a microbenchmark, but it fits my general experience that floats are a reasonable bit faster than doubles, typically 20-100% (doubles are closer when it is pure number crunching since 64-bit CPUs are actually pretty good at doubles, floats have a bigger advantage when you are manipulating a lot of data points and hence memory bandwidth matters more) Code here for those interested: src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java That's a pretty interesting result. I ran some tests of my own, based on your code, as I wondered whether or not the time to instantiate the array of doubles was biasing the test. My goal was to see whether or not I'd get a similar result running an array of floats through a method that processed doubles. (See: https://gist.github.com/weavejester/6583367) It turns out that I get a similar result. Passing floats to a method that takes doubles slows things down by a similar amount, unless I've somehow botched up the test. Considering that converting between single and double precision should be pretty cheap on the CPU, I'm surprised at the difference. This somewhat changes my view on things. It doesn't affect me in practice, but I can see how someone might be frustrated by having to drop down to Java to achieve performance for floating point calculations. - James -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/H5P25eYKBj4/unsubscribe. To unsubscribe from this group and all its topics, 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
Re: Weird core.async/ClojureScript not workings...
Which versions of ClojureScript and core.async are you using? David On Mon, Sep 16, 2013 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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: Building Trees
I find your description interesting but I'm confused about what the actual underlying problem is- is indexing and searching for data in documents involved, or is that just an example? If the real problem is about augmenting large document data set searches with potentially relevant taxonomic or semantic terms...ok, but I'm not sure what that necessarily has to do with frequent patterns in sequences/event streams? e.g. because taxonomic or semantic associations have richer relationships than just their location in a sequence... On the other hand, if this is just about extracting sequences from event streams- if it has to be done live, where you want to incrementally record distinct sequences of events for a series of window lengths- that sounds like you're about talking maintaining what are essentially lots of tries, one for each distinct root? But if you can do it statically, then you're basically just generating n-grams from the event sequence data and indexing those? On Mon, Sep 16, 2013 at 12:08 PM, Peter Mancini peter.manc...@gmail.comwrote: That is along the lines of my thinking. I am starting to look at zippers again. However much of what I need it to do either isn't documented at all or it was never intended to construct trees over time. The purpose of this is to look at sequenced events and detect frequent patterns. These patterns can have variations. It is built from the top down with the most frequent events added first, the 2nd most added second, etc. What ends up happening is that I see A-B-C-D a lot, for example, but I also see A-B-D-F sometimes. I see B-D-E-F-G rarely. So what I want to do is keep track of each of these. The first two are variations of each other stemming after A-B. What I want to do is to be able to look at D and see what events often precede it. I see that in all of my data A, B and C precede it. However just by examining the counts I can determine that C does not occur more than random chance so I can drop that and return B, A as my set, in that order because I see B preceeding more than A. Big Whoop you say. But now lets apply this to some interesting situations. Let's say that instead of letters we have topics. D is part of some greater topic concept. I want to know what other topics predict the existence of D such that if I see them I think that its possible they imply D. B and A do this, according to this analysis. So when I tell my search engine I'm interested in D it will also search for B and A knowing that while D isn't mentioned by name, there is a possibility it is implied when B or A are present. Concrete example. I want documents that talk about automobiles. Automobile associates with things like drivers seat steering wheel rear view mirror but also with car car wash Prius Ford and other terms. Why is this important? Let's say I don't want a general return of information but I am looking for a very specific document. If I don't have the right keyword I have to guess. A lot. I may never guess right. So I need to be sure my search is augmented properly. That is what this will do. However the number of events I will be looking at will be in the hundreds of millions and for some data sets will be in the billions or greater. The problem will be distributed. However, for today, I just need to get this to work on my laptop, with an eye to the future as to how I will get this to work on a large network of machines. So far I have loved Functional Programming... right up to this problem. This one is killing me. I am going to examine the other suggestions here for how to do it. I am certain that Clojure is extremely excellent at solving this kind of problem and I am becoming more certain I am missing some FP concept that is preventing me from tapping into that power! Solve this problem and Clojure becomes the best platform for large scale machine learning out there. My company has 3 complex applications up already making money and the bugs are 99% design issues instead of something not working in an expected manner. This is really fantastic and has me sold that Clojure was a good choice. --Pete On Monday, September 9, 2013 4:06:41 PM UTC-5, Laurent PETIT wrote: This is quite an interesting post, with the underlying question in my mind : where to put the line between pure datastructure manipulation with clojure.core only, and a datalog (datomic)/sql engine ? -- -- 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
Re: New Functional Programming Job Opportunities
If anyone has questions about working at Factual, I'm happy to answer them, and can be reached at zach at factual.com. The short version, though, is that it's great and you should come work with us. For some examples of Clojure we're writing and using at Factual, check out: https://github.com/factual/skuld https://github.com/factual/clj-leveldb https://github.com/aphyr/merkle https://github.com/ztellman/clj-tuple https://github.com/ztellman/narrator among many others. Anyone at Strange Loop who's curious should feel free to track me down. Kyle Kingsbury (better known to some as aphyr) will be giving a talk, and will also happily answer any questions about Factual. Zach On Sunday, September 15, 2013 11:00:02 PM UTC-7, Sean Murphy wrote: Here are some functional programming job opportunities that were posted recently: Clojure Engineers Needed at Factual http://functionaljobs.com/jobs/8646-clojure-engineers-needed-at-factual Cheers, Sean Murphy FunctionalJobs.com -- -- 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: Weird core.async/ClojureScript not workings...
[org.clojure/clojurescript 0.0-1878] [org.clojure/core.async 0.1.222.0-83d0c2-alpha] [[lein-cljsbuild 0.3.2]] On Mon, Sep 16, 2013 at 3:32 PM, David Nolen dnolen.li...@gmail.com wrote: Which versions of ClojureScript and core.async are you using? David On Mon, Sep 16, 2013 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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. -- Brick Alloy http://brickalloy.com https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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: Weird core.async/ClojureScript not workings...
Won't work you need core.async master. The next core.async release will fix the issue. David On Tue, Sep 17, 2013 at 1:17 AM, David Pollak feeder.of.the.be...@gmail.com wrote: [org.clojure/clojurescript 0.0-1878] [org.clojure/core.async 0.1.222.0-83d0c2-alpha] [[lein-cljsbuild 0.3.2]] On Mon, Sep 16, 2013 at 3:32 PM, David Nolen dnolen.li...@gmail.comwrote: Which versions of ClojureScript and core.async are you using? David On Mon, Sep 16, 2013 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm using core.async and ClojureScript and it seems that inside a go block, if/when/loop/while code is never executed. For example: (def dog33 (go (if true (.log js/console it's true) (.log js/console it's false prints neither it's true nor it's false, but (def dog33 (go (do (.log js/console it's true) (.log js/console it's false prints both. I'm doing lein cljsbuild auto to generate the JavaScript. Any pointers would be appreciated. Thanks, David -- Brick Alloy http://brickalloy. https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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. -- Brick Alloy http://brickalloy.com https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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.
