Re: *print-dup* and subvec
Thanks Stuart. Is that a bug that will be fixed in 1.3? I was under the impression that we can rely on print-dup for serialization. Am I wrong about that? Carson -- 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
*print-dup* and subvec
In Clojure 1.2, I tried this: (read-string (binding [*print-dup* true] (print-str (subvec [1 2 3] 1 But I get a java.lang.IllegalArgumentException: No matching method found: create I had something else print-dup'ed out onto disk and when I read it back in it gave me that error. I just search and replaced clojure.lang.APersistentVector$SubVector/create with vec in the file and then it was okay, I guess. What's going on? Thanks, Carson -- 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: I'm doing something wrong with gen-class
Haven't tried this, but some ideas/questions in my mind: Is it not better to use the (:gen-class :name ... :prefix ...) inside (ns) instead of having a separate (gen-class ...) outside (ns ...)? Maybe it makes no difference? (dunno, but the documentation for ns suggests otherwise) Where you have (reverse), you are calling a no-argument function named reverse, no? I don't see such a function defn'ed. Where you have :prefix rba-. Should there be quotes around *rba-*? Or does that not matter? Sorry can't be of more help. Carson -- 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: Creating standalone executable
I've given launch4j http://launch4j.sourceforge.net/ a try and it seems to work well for building Windows exe. I use lein to build an uberjar and then use launch4j to make the exe. Please let me know if you find something better though. :) Best, Carson -- 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: discussing Clojure with non-CS types
Curious if anyone has given Lush a try here? http://lush.sourceforge.net/ It's essentially a lisp-like way to write C, with lots of integration with libraries to do numerical computing, machine learning, etc. Carson On Nov 24, 5:47 pm, CuppoJava patrickli_2...@hotmail.com wrote: I must admit that even though I love Clojure and use it daily for many things, I don't like using it very much for my research (machine learning) which involves a lot of number crunching. The main reasons being: Numerical software involves a lot of array indexing, and loops, and not much else. Clojure's functional data structures are elegant, but are not quite fast enough for heavy numerical processing so I still need to use native arrays. And if all I'm using is native arrays, the java syntax for arrays is much easier on the eyes than a bunch of nested s-exps. The other reason is that Clojure emphasizes functional programming and discourages mutation. This is fine, as I believe well-written code is usually functional anyway. The problem is that bad code is usually easier to write in an imperative way than a functional way, and the ability to write bad code is important I think. It's usually a lot quicker to whip up a mutative hack than think through the problem and factor out components and be functional about the whole thing. And usually, in the very very early stages of programming something, when you don't clearly know what it is you're programming, it's nice to be able to whip out a quick and dirty mutative hack. And then make it nice and elegant and functional later on, but Clojure makes doing that difficult for me. -Patrick On Nov 24, 3:12 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: On Wed, 24 Nov 2010 09:20:49 -0800 (PST) cej38 junkerme...@gmail.com wrote: I am a physicist. I have been using Clojure full time for the last year and a half. The reasons that Rich (and most other Clojure evangelists) give for using Clojure, are all nice and good, but they point to what computer scientists think about. If you want scientists and engineers to think about switching to Clojure, you need to talk to the concerns that they have. Of course, there is some overlap. The thing is, I'm not sure it's the best choice for such people. At least, not yet. The LISP-like syntax means you have to explain the code if you publish it, a problem that some alternatives - which have most of your advantages - don't have. Look at Python, a descendant of ABC, which was designed for teaching/prototyping. It's been described as executable pseudo-code. Here are some reasons that I would give for using clojure: 1. Most data analysis gets done by writing little programs that do certain tasks. When writing in Fortran I more or less have to write a new program to do each task. In clojure, I might have to write a new function, but I keep finding that functions that I wrote before, will help with these new problems. Code re-use is much higher! Less time coding. I think this says more about your coding style than Clojure. I find that true in most of the languages I write in, but I structure programs to make it so. 2. fewer number of parameters that need to be passed into subroutines. When writing fortran/C programs, you not only need to pass in the data, but you also need to pass in parameters that describe the data. In clojure, you usually only pass in the data. The same is true of Python, and most modern languages. Clojure's data structures - which make this possible - have been around in other languages for quite a while now. 3. (related to 2) Everything is a function, thus, as long as the inputs and outputs are the same, you can change the internals at will. This makes it super easy to try rewriting code to make it run faster. The same is true of Python. 4. Using the REPL you write fewer bugs. In an imperative language you have to make a guess as to how a whole (possibly very long) subroutine should be written before writing it and then debug. Using the REPL you start with the most basic steps of the subroutine, make sure those work, and then continue to build until you have something that works. This is also true of Python's REPL. 5. ease of changing function calls to allow for extra stuff/ functionality without breaking other stuff. An example would be best here. Suppose I had defined some function that worked for a specific purpose: (defn setzero [value] If value is less than 1.0E-8 setzero returns zero.. (if (tolerance? value 1.0E-8) 0 value)) The same is true of Python: def setzero(value): If value is less than 1.0E-8 setzero returns zero return 0 if tolerance_p(value, 1.0E-8) else value and later I decided that I would really like to use that same function again, but that 1.0E-8 won't work in this new case. I can change
Re: Simple Neural Network DSL -- request for feedback
It might be interesting to add a Clojure frontend to Nengo. Having
said that, Nengo is very opinionated in the sense that you have to
buy in to the kind of neural simulation Eliasmith is doing (and the
way he's doing it), which Eric may not be interested in doing. There
are many other kinds of neural nets worthy of research besides
Eliasmith's NEF. Still, it'd be cool to have a Clojure frontend to
Nengo.
Carson
On Nov 13, 4:09 pm, Ross Gayler r.gay...@gmail.com wrote:
You might also consider using your DSL as a frontend to the Nengo
neural simulator (http://nengo.ca). Nengo (which is written in Java)
has recently added a Python
scripting interface (http://www.frontiersin.org/neuroinformatics/
10.3389/neuro.11/007.2009/abstract). Nengo has a lot to recommend it
and is pretty mature, so you may save yourself a lot of effort under
the covers - also the way Nengo conceptualises the neyworks might be
useful feedback to your DSL design.
Ross
On Nov 14, 5:18 am, Eric Schulte schulte.e...@gmail.com wrote:
Hi Ross,
#+begin_src clojure
(let [n {:phi identity
:accum (comp (partial reduce +) (partial map *))
:weights [2 2 2]}]
[(repeat 3 n) (repeat 5 n) (assoc n :weights (vec (repeat 5 1)))])
#+end_src
would result in the following connection pattern
[[file:/tmp/layers.png]]
layers.png
45KViewDownload
However, for other NNs you may care about the topological organisation
of the neurons in a 1-D, 2-D, or 3-D space in order to do things like
connecting corresponding neurons in different layers or having the
probability of a connection be a function of the separation of the
neurons. In this case, you might use a data structure representing
the coordinates of each neuron as its key.
Fully agreed, I'm partway through implementing what you've just
described (at least as I understand it), in that the library now
declares a new Graph data type which consists of a list of
keys-Neural mappings as well as a directed edge set. Using this new
data type it is possible to construct, run and train arbitrarily
connected graphs of Neural elements. See the fourth example
athttp://repo.or.cz/w/neural-net.git
Best -- Eric
Ross- Hide quoted text -
- Show quoted text -
Ross Gayler r.gay...@gmail.com writes:
On Nov 13, 9:12 am, Eric Schulte schulte.e...@gmail.com wrote:
Albert Cardona sapri...@gmail.com writes:
Your neural network DSL looks great. One minor comment: why use lists
instead of sets? ...
I used lists because I want to be able to specify a network in which (at
least initially) all neurons in a hidden layer are identical e.g. the
list example athttp://cs.unm.edu/~eschulte/src/neural-net/.
You might want to consider maps.
Currently I'm using maps to specify a single neuron, and I fear it would
add complexity to have two different meanings for maps.
For some NN models all you care about is that each neuron has a unique
identity (in which case using an index value as a key is as good a
solution as any).
I'm currently using lists only for fully connected layers in a neural
network, e.g. the following code
--
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: Simple Neural Network DSL -- request for feedback
Hi! That looks interesting. I'm curious how big a network are you intending to experiment with? (ie, # of layers, size of layers?). Carson On Nov 11, 8:17 am, Eric Schulte schulte.e...@gmail.com wrote: Hi Saul, Saul Hazledine shaz...@gmail.com writes: On Nov 10, 11:20 pm, Eric Schulte schulte.e...@gmail.com wrote: Hi, Inspired by cgrand's regexp example [1], I've implemented a simple DSL for specifying neural networks using Clojure data types. This is really clear. The web page documentation is awesome. Great, Thanks, the web page is produced using Emacs Org-mode [1], the raw text source file is in the repository at [2] Construction of this simple language involved a number of choices as to where to place complexity (into the DSL or into user land), generally I erred on the side of leaving complexity out of the DSL resulting in potentially more complex usage, but in increased generality. I'd love to hear any feedback on how this could be improved, simplified, or made more idiomatic. Its probably not a direction you want to go in, but when using a Lisp to specify the network architecture it opens up the possibility of using genetic programming to design a network to fit a particular problem. The map format doesn't fit this but, because you use protocols in the implementation, a list format for the DSL would allow genetic programming. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.4432 Thanks for the paper link, I know GA has been used to design neural networks, but have not yet seen any specific examples (much less one in lisp and by Koza himself). I have some experience using Clojure for evolutionary computation, and this is something I have been considering since the beginning of this NN implementation. Now with this paper I have no excuse not to follow through on this impulse. Obviously though, their DSL is nowhere as clear and clean as yours. :) flattery, I doubt they had access to a lisp with protocols. Thanks -- Eric Saul Footnotes: [1] http://orgmode.org/ [2] http://cs.unm.edu/~eschulte/src/neural-net/neural-net.org -- 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: Collapse some functions? (was Re: clojure.core function decision tree)
rseq O(1), reverse O(n). peek O(1), last O(n). pop O(1), butlast O(n). get O(1), nth O(n). I don't see that in the documentation... If these functions aren't collapsed, then it's better if at least (doc reverse) says something about O(n) and see rseq. Carson On Nov 10, 8:16 am, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 10 Nov., 17:09, Gary Poster gary.pos...@gmail.com wrote: I believe that the cost of having developers remember both rseq and reverse (why can't reverse just DTRT if it is given a vector?), last and peek (same), butlast and pop (same), and nth and get (same) is unnecessarily high. Ehm. No. rseq O(1), reverse O(n). peek O(1), last O(n). pop O(1), butlast O(n). get O(1), nth O(n). (Where O(1) might sometimes mean O(log32 n)) The different functions are there under different names, because they have different performance promises. Then peek is not equivalent to last. For lists it is equivalent to first. Sincerely Meikel -- 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: Collapse some functions? (was Re: clojure.core function decision tree)
But perhaps it should be more clear. What if there were some additional structured fields for each doc entry, like performance guarantees and see also? That's a good idea. I've found See Also sections useful in man pages, for example. And if performance guarantees are part of the semantics of a function, then it's better for it to be documented in the docstring to let people know without having to do complexity analysis on the source. Carson On Nov 10, 10:40 am, Michael Gardner gardne...@gmail.com wrote: On Nov 10, 2010, at 11:36 AM, Carson wrote: rseq O(1), reverse O(n). peek O(1), last O(n). pop O(1), butlast O(n). get O(1), nth O(n). I don't see that in the documentation... If these functions aren't collapsed, then it's better if at least (doc reverse) says something about O(n) and see rseq. The docstring for reverse does say not lazy, which implies at least O(n). But perhaps it should be more clear. What if there were some additional structured fields for each doc entry, like performance guarantees and see also? -- 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: Response
Hi Per, woh, take it easy. I don't claim to be an expert. Thanks for showing me that though. It certainly didn't seem right at first, but I had trouble figuring out the laziness in clojure, me being new to it. Anyway, have a good weekend! Carson On Jul 17, 10:02 pm, Per Vognsen per.vogn...@gmail.com wrote: How about some common sense? The convolution algorithm everyone is discussing runs in O(n m) time. So your measured time would imply that a single of your computer's core is capable of 10 * 3,000,000^2 = 9 * 10^14 FLOPS, or about one peta-FLOPS. That should have tipped you off you aren't actually measuring anything useful. Wrap your (convolve dxs dys) calls with (doall ...). And you will want to reduce the three million number to something much smaller, or you'll be waiting for a very long time. By the way, no-one actually uses this quadratic-time algorithm for very wide kernels. For that you use FFTs and pointwise multiplication (look up the convolution theorem), which yields an O(n log n) algorithm. -Per -- 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: A functional, efficient, convolution function. Is imperitive-style the answer?
I should add, oops, ignore what I wrote. :) see: https://groups.google.com/group/clojure/tree/browse_frm/thread/33366bccc6df7756/415072576d83b757?rnum=11_done=%2Fgroup%2Fclojure%2Fbrowse_frm%2Fthread%2F33366bccc6df7756%3F#doc_0d0a3759a0a10328 Carson On Jul 17, 3:58 pm, Carson c.sci.b...@gmail.com wrote: Hi, Try this: (defn stationary-convolve [n fs gs] (let [window-size (count fs) padding (repeat window-size 0) padded-gs (concat padding gs padding) new-center (+ n window-size) window-of-gs (subvec (vec padded-gs) (- (inc new-center) window-size) (inc new-center)) reverse-window-fn (fn [i] (nth window-of-gs (mod (- -1 i) window-size))) reverse-window (map reverse-window-fn (range 0 window-size))] (reduce + (map * fs reverse-window (defn convolve [fs gs] (map #(stationary-convolve % fs gs) (range 0 (+ (count fs) (count gs) (let [xs (for [i (range 100)] (rand 100)) ys (for [i (range 100)] (rand 100))] (time (dotimes [_ 3] (convolve xs ys Elapsed time: 2540.967482 msecs Seems to run pretty fast and seems to be the kind of convolution you want. Thanks for the interesting problem! Carson On Jul 16, 12:57 pm, Isaac Hodes iho...@mac.com wrote: I posted this on StackOverflow yesterday, but to no avail: I don't think many people looked at it, or least I didn't get much feedback. I am trying to create a lazy/functional/efficient/Clojuresque function to carry out convolution on two lists/vectors of (ideally BigDecimals but that may be inefficient) doubles. It is turning out to be very difficult. I have four or five versions in my buffer right now, and none of them are acceptable. I've even tried a number of versions using into-array etc, e.g. mutables. Instead of posting a lot of links to pastie, I'm just copying the SO link here, where my code and the algorithms can be found. Right now, it seems as though this is something Clojure cannot do. David Nolen mentioned that the appropriate Java-interop functionality may come in Clojure 1.3, but aside from eschewing the functional style by using arrays, it seems as though there should be a better answer. (As an aside, where can I find out about 1.3?) I have a Python implementation to show how nicely it can be expressed in an imperitive language (though I suppose I dabbled in the functional style initializing my return array). Is it possible to do this, and do it well? Thank you so much, in advance. -- 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: A functional, efficient, convolution function. Is imperitive-style the answer?
Hi, Try this: (defn stationary-convolve [n fs gs] (let [window-size (count fs) padding (repeat window-size 0) padded-gs (concat padding gs padding) new-center (+ n window-size) window-of-gs (subvec (vec padded-gs) (- (inc new-center) window-size) (inc new-center)) reverse-window-fn (fn [i] (nth window-of-gs (mod (- -1 i) window-size))) reverse-window (map reverse-window-fn (range 0 window-size))] (reduce + (map * fs reverse-window (defn convolve [fs gs] (map #(stationary-convolve % fs gs) (range 0 (+ (count fs) (count gs) (let [xs (for [i (range 100)] (rand 100)) ys (for [i (range 100)] (rand 100))] (time (dotimes [_ 3] (convolve xs ys Elapsed time: 2540.967482 msecs Seems to run pretty fast and seems to be the kind of convolution you want. Thanks for the interesting problem! Carson On Jul 16, 12:57 pm, Isaac Hodes iho...@mac.com wrote: I posted this on StackOverflow yesterday, but to no avail: I don't think many people looked at it, or least I didn't get much feedback. I am trying to create a lazy/functional/efficient/Clojuresque function to carry out convolution on two lists/vectors of (ideally BigDecimals but that may be inefficient) doubles. It is turning out to be very difficult. I have four or five versions in my buffer right now, and none of them are acceptable. I've even tried a number of versions using into-array etc, e.g. mutables. Instead of posting a lot of links to pastie, I'm just copying the SO link here, where my code and the algorithms can be found. Right now, it seems as though this is something Clojure cannot do. David Nolen mentioned that the appropriate Java-interop functionality may come in Clojure 1.3, but aside from eschewing the functional style by using arrays, it seems as though there should be a better answer. (As an aside, where can I find out about 1.3?) I have a Python implementation to show how nicely it can be expressed in an imperitive language (though I suppose I dabbled in the functional style initializing my return array). Is it possible to do this, and do it well? Thank you so much, in advance. -- 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: Response
Hi David,
Would appreciate if you could try out my attempt at this [1] on your
machine. My machine ain't as fast as yours apparently...
[1]
https://groups.google.com/group/clojure/tree/browse_frm/thread/ee4169bc292ab572/6d03461efde166ad?rnum=11_done=%2Fgroup%2Fclojure%2Fbrowse_frm%2Fthread%2Fee4169bc292ab572%2Ff769ca6eb6fb8622%3Ftvc%3D1%26#doc_6d03461efde166ad
Thanks,
Carson
On Jul 17, 4:04 pm, David Nolen dnolen.li...@gmail.com wrote:
(defn ^{:static true} convolve ^doubles [^doubles xs ^doubles is]
(let [xlen (count xs)
ilen (count is)
ys (double-array (dec (+ xlen ilen)))]
(dotimes [p xlen]
(dotimes [q ilen]
(let [n (+ p q), x (aget xs p), i (aget is q), y (aget ys n)]
(aset ys n (+ (* x i) y)
ys))
I don't think this is so bad and it can do a million points in ~400ms on my
machine. 100,000 points in ~25ms. I don't consider this dropping to the Java
level at all.
--
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: Response
Have you taken a look at my attempt at a solution (on the other/
original thread)?
https://groups.google.com/group/clojure/tree/browse_frm/thread/ee4169bc292ab572/6d03461efde166ad?rnum=11_done=%2Fgroup%2Fclojure%2Fbrowse_frm%2Fthread%2Fee4169bc292ab572%3F#doc_6d03461efde166ad
I don't know if it can be called idiomatic, but it looks functional to
me, doesn't use any type hints or mutable arrays, and it seems pretty
fast. Convolves two 100 size vectors in roughly ~600 ms I
think...
Carson
On Jul 17, 5:44 pm, Frederick Polgardy f...@polgardy.com wrote:
This example is beside the point of the original question. It uses mutable
arrays. It's very much dropping to the Java level. Am I missing something?
-Fred
--
Science answers questions; philosophy questions answers.
On Jul 17, 2010, at 6:04 PM, David Nolen wrote:
(defn ^{:static true} convolve ^doubles [^doubles xs ^doubles is]
(let [xlen (count xs)
ilen (count is)
ys (double-array (dec (+ xlen ilen)))]
(dotimes [p xlen]
(dotimes [q ilen]
(let [n (+ p q), x (aget xs p), i (aget is q), y (aget ys n)]
(aset ys n (+ (* x i) y)
ys))
I don't think this is so bad and it can do a million points in ~400ms on my
machine. 100,000 points in ~25ms. I don't consider this dropping to the
Java level at all.
--
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: Response
I guess different people see things differently. I actually didn't
understand the intent of the imperative version, even though it takes
less lines I guess. There's quite a few things called convolution.
My naive implementation was functional and pretty fast. Turns out it
can be even faster with just a little work (still functional):
(defn point-convolve [n ^doubles fs ^doubles gs]
(let [window-size (alength fs)
padding (repeat window-size 0.0)
padded-gs (concat padding gs padding)
window-of-gs (double-array (subvec (vec padded-gs)
(inc n)
(inc (+ n window-size
reverse-window-fn (fn [i] (aget window-of-gs
(mod (- -1 i) window-size)))
reverse-window (map reverse-window-fn (range window-size))]
(reduce + (map * fs reverse-window
(defn convolve [^doubles fs ^doubles gs]
(map #(point-convolve % fs gs)
(range (+ (alength fs) (alength gs)
(let [dxs (double-array (for [i (range 300)] (rand 100)))
dys (double-array (for [i (range 300)] (rand 100)))]
(time (dotimes [_ 10] (convolve dxs dys
Elapsed time: 0.506432 msecs
Have a good weekend,
Carson
On Jul 17, 6:13 pm, Frederick Polgardy f...@polgardy.com wrote:
I think it really doesn't get any clearer than this in terms of intent. While
I was adept at calculus-level math 20 years ago, I've forgotten the little I
knew of matrices. This is the first algorithm that has communicated by visual
inspection (to me) exactly what a convolution is.
-Fred
--
Science answers questions; philosophy questions answers.
On Jul 17, 2010, at 3:43 PM, Isaac Hodes wrote:
double convolve(double *xs, double *is, double *ys){
int i,j;
for(i=0; ilen(xs); i++){
for(j=0; jlen(is); j++){
ys[i+j] = ys[i+j] + (xs[i]*is[j]);
}
}
return ys;
}
--
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: Response
Thanks David.
On Jul 17, 4:58 pm, David Nolen dnolen.li...@gmail.com wrote:
I tried this, it runs in about the same amount of time as it did for you.
On Sat, Jul 17, 2010 at 7:17 PM, Carson c.sci.b...@gmail.com wrote:
Hi David,
Would appreciate if you could try out my attempt at this [1] on your
machine. My machine ain't as fast as yours apparently...
[1]
https://groups.google.com/group/clojure/tree/browse_frm/thread/ee4169...
Thanks,
Carson
On Jul 17, 4:04 pm, David Nolen dnolen.li...@gmail.com wrote:
(defn ^{:static true} convolve ^doubles [^doubles xs ^doubles is]
(let [xlen (count xs)
ilen (count is)
ys (double-array (dec (+ xlen ilen)))]
(dotimes [p xlen]
(dotimes [q ilen]
(let [n (+ p q), x (aget xs p), i (aget is q), y (aget ys n)]
(aset ys n (+ (* x i) y)
ys))
I don't think this is so bad and it can do a million points in ~400ms on
my
machine. 100,000 points in ~25ms. I don't consider this dropping to the
Java
level at all.
--
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.comclojure%2bunsubscr...@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: Clojure-based scientific paper!
Congrats! On Jul 13, 11:56 pm, bOR_ boris.sch...@gmail.com wrote: Hi all, My first paper with results based on a clojure-build agent-based model is in press! If you have academic access to the journal, you can peek at it here:http://dx.doi.org/10.1016/j.epidem.2010.05.003, but otherwise it is also available on mendeley: http://www.mendeley.com/profiles/boris-schmid/ A very old and experimental version of the code is still in the files directory of the newsgroup (eden.clj), but I'll make some time to clean up the current version and drop it in the files directory as well. Several other papers using clojure are in the works as well, and by now I'm making heavy use of Incanter for visualization. Thanks for making these wonderful tools! The paper quoted above still uses xmgrace and inkscape. -- 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: Enhanced Primitive Support
On Jun 19, 9:02 pm, Aaron Cohen aa...@assonance.org wrote: On Sat, Jun 19, 2010 at 11:22 PM, Mike Meyer mwm-keyword-googlegroups.620...@mired.org wrote: Rob Lachlan robertlach...@gmail.com wrote: Actually, Mike, your two functions work just fine. (Equal branch). Mind you I checked that out over two hours ago, so this information might be out of date. Rob On Jun 19, 6:59 pm, Mike Meyer mwm-keyword-googlegroups. Ok, why does this work but the fact fail? Or does the fact example still fail on that build? The fact that this requires explanation is a pretty good argument the fact behavior. (defn fact [n] (loop [n n r 1] (if (zero? n) r (recur (dec n) (* r n) (The quoting in this thread is getting out-of-hand, everyone please reply on the bottom) The difference between your examples and the fact examples is that (inc prim) - prim while (* prim boxed) - boxed In the fact example, the type of n as an initializer in the loop statement is unknown at compile time and thus must be boxed. The fact that you need to know that, is very much what some people are arguing against. The choices are to do either: (loop [n n r (num 1)] or (loop [n (long n) r 1] Or this! (on the new equal branch) user= (defn fact [n] (loop [n n r 1.0] (if (zero? n) r (recur (dec n) (* r n) #'user/fact user= (fact 5) 120.0 user= (fact 5N) 120.0 :) Not sure I understand why completely since I don't entirely understand the interaction of the Clojure code, LispReader.java, and Numbers.java, but it seems a double multiplied by anything returns a double now. A long will be returned by multiplication only if both arguments are long, unless you ask for auto-promoting multiplication, in which case it always returns a Number object. If one of the arguments to multiplication is an Object and the other a long, it returns a Number object --- I suppose because if the Object turns out to be a Double rather than a Long, then it has to return a Double rather than a Long object? So it seems like it's not enough to see a literal and think it's initializing the variable r to be a primitive, but you'd need to know what kind of primitive it is (long or double?), and what effect it has on the return value of the functions they are arguments to. Eg, by looking at Numbers.java, I figured to try making r double so to force * to return double. This is all in theory, of course. Whether you think it matters day- to-day is something else. On that note, my own code works fine on the new equal branch. It does concern me a little bit that to really understand what a function or loop/recur will do, it seems I'd have to know the kind of primitive type that the variables are initialized to, or that the functions I call might return... Carson PS: how come everyone is calling throw-on-overflow unsafe now? hmm... Either option will make (* r n) return a primitive or boxed value of the appropriate type. Both versions will overflow and throw an exception at (fact 21). To have a fact that works for large numbers you need: (defn fact [n] (loop [n n r (num 1)] (if-not (pos? n) r (recur (dec n) (*' r n) Most of the versions posted so far were broken for negative n by the way. -- 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: Enhanced Primitive Support
Just tried out num branch and I really like how easy it is to be fast! However... Consider: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) (defn twice-fact [n] (fact (fact n))) (defn bad-twice-fact [n] (fact (- n fact range last inc))) user= (fact (fact 5)) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:3) user= (fact (fact 5N)) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user= (twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:5) user= (twice-fact 5N) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user= (bad-twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:7) user= (bad-twice-fact 5N) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:8) Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. BigInt contagion doesn't help if in some convoluted manner a BigInt's value is used to construct a primitive sufficiently large that later causes an overflow. It'd sure be nice if I could just write ((safe bad-twice-fact) 5) and get back a BigInt. Maybe ((safe foo) x) can ensure all arguments and return values of function foo are boxed, and recursively, ensures boxing of arguments and return values for all functions called by foo, etc. Is that possible? Would that guarantee safety? Carson On Jun 17, 11:35 pm, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jun 18, 2010 at 2:10 AM, Mark Engelberg mark.engelb...@gmail.comwrote: Elaborating on Anthony's explanation, let's say you call (fact (foo n)). This imposes too high a burden on any programmer who cares about safety. Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) (defn foo [n] (inc n)) (fact (foo 40)) (fact (foo 40N)) Both work. -- 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: Enhanced Primitive Support
On Jun 18, 2:44 am, Christophe Grand christo...@cgrand.net wrote: With contagious bigints (let's nick name them safeints and assume they are not BigInteger but something à la kawa) a single N on literals or having all your inputs going through a safeint conversion would trigger safe computations (unless you try to call a static primitive-hinted fn but the compiler would then bark). I think the example (defn bad-twice-fact [n] (fact (- n fact range last inc))) shows it takes more than safeint conversion of arguments to the surface function to trigger safe computations. All functions called by the surface function needs to have their arguments converted to bigints too, and their return values probably, just in case. Although I'm not sure if even that's enough without auto-promotion (if I understand auto-promotion correctly...). But note the example doesn't even use any type hints or explicit conversion to primitives (the point is the conversion may occur as a legitimate side effect of doing something else). *Still*, I'm in favour of fast by default, with an *easy* way to make things safe as an option. Of course a rogue fn can still internally convert to primitives and overflow but you can't do anything to protect you from that. As for mixing several numebr representations in a single collection, I think it's a problem of normalizing data but most of the time your are either in safeland or in fastland so your representations will be homogeneous (safehints or (boxed) primitives). A middleground may be to keep the semantics proposed by Rich but: * integer literals default to safeint (unless suffixed by L for long) * scientific notation and decimal literals default to double (unless suffixed by M or N) * implement a better bigint. Christophe -- European Clojure Training Session: Brussels, 23-25/6http://conj-labs.eu/ Professional:http://cgrand.net/(fr) On Clojure:http://clj-me.cgrand.net/(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: Enhanced Primitive Support
On Jun 18, 4:22 am, Nicolas Oury nicolas.o...@gmail.com wrote: On Fri, Jun 18, 2010 at 11:47 AM, Carson c.sci.b...@gmail.com wrote: Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. BigInt contagion doesn't help if in some convoluted manner a BigInt's value is used to construct a primitive sufficiently large that later causes an overflow. I would like to see that in real examples. And not in something that tend to be mainly a program that crunch numbers. (I think a program about numbers could take a bit of complexity to handle numbers. If you write a program to that generates web page, you agree to have an html library and not have every structure in clojure is html.) I agree! Sorry I have no real examples, just my contrived example. But note the example I used isn't *that* contrived, in the sense that it doesn't use any type hints or explicit conversion to primitives to cause an overflow on purpose. The point is that the overflow may occur as a legitimate side effect of doing something else, whereas it currently will not. And *still*, I'm in favour of fast by default, with an *easy* way to make things safe as an option. The key is to make the safe option *easy*. On the other hand, programs that have few number computations - mainly to handle a few stats and indices - but that are spread in a lot of code (I think most program are like that) should benefit from good performance without annotating all the code. -- 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: Enhanced Primitive Support
On Jun 18, 5:45 am, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jun 18, 2010 at 6:47 AM, Carson c.sci.b...@gmail.com wrote: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) (defn twice-fact [n] (fact (fact n))) (defn bad-twice-fact [n] (fact (- n fact range last inc))) Not only is it contrived, under the proposal, this implementation of fact is broken. It needs to be fixed to: (defn fact [n] (if (zero? n) 1N (* n (fact (dec n) With that change bad-twice-fact is not actually bad. I appreciate what you're saying, and the example above is not broken. Recall from here: On Jun 17, 8:00 pm, Rich Hickey richhic...@gmail.com wrote: ... Certainly one could write a version of fact that hardwired bigints as you showed. But you need not - here's the original naive definition: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) Such logic that doesn't specify one of the components (in this case, n) is still polymorphic, as are operations with mixed components. So the power is in the hands of the supplier of n: user= (fact 10) 3628800 user= (fact 40) java.lang.ArithmeticException: integer overflow user= (fact 40N) 8159152832478977343456112695961158942720N I think you can always write code in this way, such that it will work with any of the numeric types, without dictating. I believe the example (which I have tried on the num branch) shows providing a BigInt argument does not always make things safe. That is all. Carson As Christophe Grand has mentioned one of the main things that is be complained about from the BigInt supporters *is already a problem* in Clojure. Nothing new to see here. Finally having actually tried out the new branches, this is a good change for me. I'd like to hear more from the BigInt crowd about whether getting their code to work with the new branches is actually causing problems. So far it just seems like talk. -- 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: Enhanced Primitive Support
On Jun 18, 6:11 am, Rich Hickey richhic...@gmail.com wrote: On Jun 18, 2010, at 6:47 AM, Carson wrote: Just tried out num branch and I really like how easy it is to be fast! However... Consider: (defn fact [n] (if (zero? n) 1 (* n (fact (dec n) (defn twice-fact [n] (fact (fact n))) (defn bad-twice-fact [n] (fact (- n fact range last inc))) user= (fact (fact 5)) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:3) user= (fact (fact 5N)) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user= (twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:5) user= (twice-fact 5N) 668950291344912705758811805409037258675274633313802981029567135230163355724496298936687416527198498130815763789321409055253440858940812185989848111438965000596496052125696N user= (bad-twice-fact 5) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:7) user= (bad-twice-fact 5N) java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:8) Don't buy it. That's the whole point of BigInt contagion. If fact and foo are correctly written this will work. BigInt contagion doesn't help if in some convoluted manner a BigInt's value is used to construct a primitive sufficiently large that later causes an overflow. It'd sure be nice if I could just write ((safe bad-twice-fact) 5) and get back a BigInt. Maybe ((safe foo) x) can ensure all arguments and return values of function foo are boxed, and recursively, ensures boxing of arguments and return values for all functions called by foo, etc. Is that possible? Would that guarantee safety? -- While range could be written differently, this is tantamount to saying - if I use a bigint to lookup another number in some mapping, it might not be a bigint. Yes, ok, but not a real issue. - Note - I don't mean to single you out, as others are using the same language, but I find this whole characterization of throw-on-overflow being somehow 'unsafe' to be a bit specious. I want it to be perfectly clear to everyone, this is not a choice between good math and bad math, i.e. C/Java style truncating/wrapping of results. That will never be the default. Such silent truncation/ wrap is truly unsafe, and often the proposed alternative. It was a surprising result that optimizations of hot spot, combined with pipelining and speculative execution on modern processors, makes the overflow checking a very minor overhead above the raw operations, and, in my mind, a third, new, viable and safe high-performance option. Is a program that might throw an exception unsafe? If so, no Java program is safe. Is a vector that throws an exception when asked to store something at an index out of range, rather than grow to accommodate it, unsafe? This is in many ways similar - you are creating a result that doesn't fit, and need to be using a bigger container. So, let's go easy on the hyperbole. The behavior might not be what you desire, but it is not unsafe. Rich hmm...didn't see this earlier. You're right, it's not unsafe, it's undesired behaviour. My mistake describing it that way. -- 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: Complex type in clojure
Thanks. It's always interesting to see different notations. On Jun 15, 4:49 pm, Travis Hoffman travis.a.hoff...@gmail.com wrote: We Electrical Engineers are quite annoying in this regard, but historically, there is much variation out there: Python uses j, MATLAB accepts i or j. Apache Commons allows the user to specify the specific character to use, but defaults to i I believe. Eventually, I would suggest this be a localizable field. Please see: http://en.wikipedia.org/wiki/Imaginary_unit#Alternative_notations -Travis On Jun 15, 4:22 pm, James Reeves jree...@weavejester.com wrote: On 15 June 2010 23:26, Carson c.sci.b...@gmail.com wrote: Sorry I may have missed the reason for this earlier: What's the reason for allowing both 'i' and 'j' to indicate the imaginary part? Is the intention to also later have 'k' to support quaternions? Just curious. Thanks. j is used by electrical engineers to represent the imaginary part of a complex number, because I has already been taken to mean electrical current. Presumably this is the reason. - 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
Re: Complex type in clojure
Sorry I may have missed the reason for this earlier: What's the reason for allowing both 'i' and 'j' to indicate the imaginary part? Is the intention to also later have 'k' to support quaternions? Just curious. Thanks. Carson On Jun 14, 10:12 am, Travis Hoffman travis.a.hoff...@gmail.com wrote: I've almost completed a Complex (and Imaginary) basic type in a fork of clojure. It turns out that it was a bit more effort that I had originally indicated. I'll save the implementation details for the clojure-dev group, but here is a quick run-down of the interface, such as it is: 1.) Added two classes: clojure.lang.Complex clojure.lang.Imaginary (These do not extend Number) 2.) Added and modified the core java code related to the basic mathematical operations to allow Complex and Imaginary to s(cr)eamlessly integrate with the existing Number types. You can +, -, *, / with the existing types. 3.) Comparison operations are not implemented for Complex Imaginary. Note: The exception reported is currently a ClassCastException, which is the default if you try to compare anything that isn't Comparable. user= ( foo bar) java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number (NO_SOURCE_FILE:0) user= ( 3i 4i) java.lang.ClassCastException: clojure.lang.Imaginary cannot be cast to java.lang.Number (NO_SOURCE_FILE:0) 4.) Added pattern matching for parsing complex numbers in a very flexible way. You can use any Number type (even ratios!) as the imaginary and real parts of the Complex and Imaginary numbers. The formatting of a complex number is natural: 3+4i, 4/5i, 2.12+2/3i, etc. and you can prepend 'i', 'I', 'j' or 'J' to indicate the imaginary part. As with properly formatted doubles and floats, there must be no whitespace between the numbers and the '+' or '-' sign. The '+' or '-' in the format of a complex is not an infixed operator! :-) 5.) Results of the real and imaginary parts follow Clojure conventions for producing Ratios: user= (/ 6+6i 5) 6/5+6/5i user= (/ 6+6i -5) -6/5-6/5i user= (/ 6+6i 5i) 6/5 user= (/ 6+6i -5i) -6/5 This is mostly working, but is beta. There are a few known bugs: 1.) Parsing of floats and doubles with sign included in the mantissa seems to be a bit off. 2.) 44 tests fail when I run 'ant test' 3.) I need to create tests for correctness of operations. Overall, I would estimate that I'm about 80% done with a error-free implementation, but the basic behavior of the Complex type works. I've put somewhere in the neighborhood of 60 hrs into it so far, so it's been a relatively small effort but I've had to touch some rather obtuse code. I'm a n00b with git (but experienced with cvs and svn); I'm still trying to figure out how to push my local git repository changes to the fork I created on github. Can anyone help me there? The fork on git-hub is: git://github.com/travis-a-hoffman/clojure.git I created a branch locally complex_type, and have done git commit -a with my changes. I can't, however, seem to push my changes back to github: ~/Projects/HackingClojure/workspace/clojure git push fatal: remote error: You can't push to git://github.com/travis-a-hoffman/clojure.git Use g...@github.com:travis-a-hoffman/clojure.git Using the recommended doesn't help: ~/Projects/HackingClojure/workspace/clojure git push g...@github.com:travis-a-hoffman/clojure.git Permission denied (publickey). fatal: The remote end hung up unexpectedly Cheers, Travis -- 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: Why I have chosen not to employ clojure
Maybe it'd be helpful to draw up several of the most common use-cases and target those with instructions. There are programmers new to some combination of Lisp/Clojure/Java either wanting to just get a taste of Clojure, or wanting to get a IDE/text editor (of their choosing) going to program in Clojure. There are sysadmins new to some combination of Lisp/Clojure/Java wanting either to deploy programs written in Clojure on a server, or to maintain a development environment on a desktop for someone else. Etc. It doesn't have to be so structured I guess, but even something like this helps (eg, see the getting started section from http://data-sorcery.org/contents/ ) # Buildng Incanter applications with Leiningen and Clojars # Building Clojure Web applications with Incanter, Compojure, and Leiningen # Setting up Clojure, Incanter, Emacs, Slime, Swank, and Paredit # Starting an Incanter Swank server with Leiningen My own experience with installing Clojure wasn't at all friendly. I was looking for an alternative to Matlab/Octave to learn (I'm a grad student doing machine learning stuff). Installing Octave is one-click easy. All I want is to write some code in emacs and run it. Why is it so hard to get Clojure, Incanter, Emacs, Slime, Swank, and Paredit to work together? And what are these class path stuff. ;) I was persistent enough to tough out the hours (!) it took to figure out which of all the various instructions didn't work, just to find instructions that worked; otherwise I would've went on to Sage/SciPy/ Python. Carson On Mar 22, 6:31 pm, Lee Spector lspec...@hampshire.edu wrote: I agree with Sean on the near-orthogonality of sysadmin skills and the skills needed to get a lot of Clojure as a language. I have precious few of the former but not of the latter. And just today I had a very capable undergrad student with programming experience in a couple of languages (but not Java), starting a project for which a lisp-like language would make the most sense, say that although he saw that Clojure would be great he might just work in DrScheme since he could easily download it and have a functional IDE. This student can definitely deal with sexpr syntax, immutable data structures, iteration through recursion, concurrency etc. I've seen him learn a new language and complete a really incredible project in it within a couple of weeks. But cageface's instructions will only get him a REPL, and not even get him contrib, the classpath details to allow him to load files, or an editor that can indent properly for the language and match parentheses. Some day he should probably learn enough about Java and sysadmin stuff to deal with this, but right now he just wants to dig into his project which doesn't have anything to do with that stuff. Someone else mentioned that maybe part of the problem is that there are several different simple ways to get started, and this may have been part of my own problem. I installed one of the emacs clojure modes from the getting started page (or maybe two?) and then later tried to install slime and I think they fought with each other, with elpa saying something was already installed and quitting. It wasn't obvious how to start over because I didn't realize that things were in my .emacs and .emacs.d (if I recall correctly). And after watching one of Lau's screencasts I realized I also had to put copies of clojure.jar and clojure-contrib.jar in my .emacs.d, but that was not obvious to me previously... -Lee On Mar 22, 2010, at 5:48 PM, Sean Devlin wrote: There are a ton of people who are ready for dabbling with Clojure but aren't ready for production systems. You'd be surprised how linearly independent system administration skills and software development skills really are. They aren't quite orthogonal, but it's amazingly close. On Mar 22, 5:36 pm, cageface milese...@gmail.com wrote: I'll certainly agree that it should be as easy as possible to get started in Clojure, but I really don't think that the kind of people that can't use anything without a windows installer are going to get very far with Clojure in any case. I mean, if it's too much to install java, unzip a file and run: java -cp clojure.jar clojure.main As the getting_started page suggests, what are you going to do with sexpr syntax, immutable data structures, iteration through recursion, concurrency etc? Clojure might at some point mature into the kind of language that has something to offer for people that need a lot more hand holding but clearly it's a bit of a wild west environment at the moment. -- 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
Re: Why I have chosen not to employ clojure
I second Lee's thought -- my work as a grad student is AI research, not application development. I'm glad I discovered Incanter's package (three lines of instructions [1]) that allows me to run a Swank server that I can easily connect to from Emacs (and Slime from the Emacs end can be easily installed thru Elpa). The part about getting Swank/ Slime easily going achieves the threshold on the editor front. [1] from http://data-sorcery.org/2009/12/20/getting-started/ $ git clone git://github.com/liebke/incanter.git $ cd incanter $ mvn install then $ bin/clj to get a repl on the terminal or $ bin/swank to start up a swank server. For me, if it takes more than three lines on the terminal, it's just too much. :) So labrepl sounds interesting from what I read here (especially as it includes Incanter?). It'd be great if it also has Swank as part of it so Emacs can connect to it (or does it already?). Thanks! Carson On Mar 23, 11:53 am, Lee Spector lspec...@hampshire.edu wrote: I like where this is going but I would suggest that there's a significant audience (including me and most of my students) in what we might call category A.01: Want to explore and even do some real work, but not necessarily work involving deploying apps, connecting to databases, working with third party code, or anything else that requires a full-featured production environment or project management system. A working REPL with access to contrib and a classpath that allows load to work (all of which I can get pretty painlessly with ClojureX) is *almost* enough, but the 0.01 extra that makes an enormous difference is an editor with the minimal functionality of clojure-aware indentation and bracket matching. I'm intrigued by what I've read here about labrepl, but can someone tell me if it's possible that the lein installation step will mess up my existing setup in any way? Not knowing anything about lein, and having had a confusing time creating my setup that now works (with ClojureX + slime), I don't want to endanger it. This is part of the reason that I (and I presume others who have expressed similar sentiments) really like the idea of a getting started package for which the installation process is literally just download and double click or maybe download, unzip, and double click. (And if you don't like it, throw away what you downloaded and the rest of your system will be unchanged.) For me the functionality threshold for such a package, which would not only get me started but allow me to do serious work (AI research, not application development) and teach using Clojure, is: a REPL, access to contrib, a classpath that lets load find my source files, and a clojure-indenting, bracket-matching editor. Anything else is gravy, but most of the existing getting started setups fall short of my threshold at least on the editor front. -Lee On Mar 23, 2010, at 11:30 AM, Stuart Halloway wrote: I think it is important to be clear about the difference between: (A) exploring Clojure (non trivially, including interesting Java libraries) (B) deploying Clojure into production. I nominate the labrepl (http://github.com/relevance/labrepl) as a solution for (A). It already includes interesting libraries (e.g. compojure, incanter), and it has instructions for working with different IDEs (which I hope the community will improve upon). I don't think there is, or needs to be, a one-size-fits-all solution for (B). That's what the Java ecosystem is for. Plus, beginners don't need (B). Stu So perhaps it would be worthwhile to create, like jruby, a single zip/ tgz file containing clojure, clojure-contrib, and a reasonable bin/clj file that will find at least the core clojure jar files on its own? I don't see how you're going to actually deploy any clojure apps, or connect to a database, or really use any third party code at all without understanding how java's classpath works but at least you can get a REPL going. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- 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
