date:20120804

I won't object, and the alter-meta! approach allows you to do that.  Of 

 course, it cannot provide documentation for the implementations, but the 
 interface docs may be extended with impl docs incrementally at the 
 location where the implementation is defined.  That's at least better 
 than nothing... 

 Bye, 
 Tassilo 


Thanks for pointing out the alternative. As you said, this is better than 
nothing. I filed a Jira ticket for this and hope some day it will get some 
consideration. 

-- 
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

record constructor

My vague impression is this has been discussed somewhere, but I did not 
find a ticket in Jira when searching on record, constructor, so I want to 
have some discussion here before considering entering a ticket myself. 

Often, when I create a record, I need to do some set-up more than just pass 
the values to the fields (like to set the field values derived from some 
arguments, or add extra map keys when needed. Regular common OO constructor 
thing). Or course, I can do this:

(defn make-myrecord []   ... )

But I don't like the ad-hoc nature of that. Besides personal taste, 
whenever a common use case pattern is not captured and defined in the 
language, it just makes further abstraction and writing generic code more 
difficult.

So what I have now is this:

(defmulti make-record
  Create a new record. The first argument should be the record type (like
  MyRecord). Kind of like a constructor for record.

  Example method definition:
  (defmethod make-record MyRecord
  [rectype arg1 arg2 ...] ...)
  (fn [ args] (first args)))

This works but has one downside: it involves unnecessary run-time dispatch 
on the type. Although there are cases we may need dynamic creation of a 
record with run-time record type, most of time the record type is just 
static that can be decided at compile time (again, just like new 
MyClass(a, b, c) as in common OO languages). 

So, as you may have guessed out from the title and the above, I think if we 
can have a mechanism to define constructors in defrecord, that seems a 
nice feature to me. What's on my mind is something like this:

(defrecord MyRecord
[x y z]
  (make-record My constructor 1 [arg1 arg2] ...)
  (make-record My constructor 2 [arg1 arg2 arg3 ...] ...))

(make-record MyRecord arg1 arg2 arg3 ...)   ;; this creates a new record. 
no need of run-time dispatching

Just like the constructors in common OO languages, constructors will:

1. Clearly communicates the designer's intention how the record should be 
created and avoid insistent internal field values. By the way, the doc 
strings in all constructors will also help, as everything in in one place.
2. Provides more regularity in the language, which can smooth/help further 
abstractions (for example, certain macros).

I know mentioning OO may be a big turn-off for certain people, but I don't 
see a clash here. Immutable objects are still objects and certain boring 
but widely accepted practice from OO may still apply here.

I had a brief look at defrecord2 
(https://github.com/david-mcneil/defrecord2), which certainly enhanced 
things. But because it is not part of the language itself, it feels patchy 
(I think even the author is not happy about that). Also, in general I would 
avoid creating functions behind the scene based on naming manipulations, 
especially for low level constructs.

Any comments? 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
http://groups.google.com/group/clojure?hl=en

Re: record constructor

for setting up  objects as you say, I'm fine using (doto Object ... ... 
...).  Records, as everything else in Clojure promote immutability and 
so setting fields doesn't really make sense unless you're consuming 
external java classes in which case 'doto' suffices...at least that is 
the way I see it...I originally thought you were  asking about how to 
create a record at runtime via a macro or a function, which is actually 
quite tricky (and I can certainly help), but what you're asking sort of 
exists doesn't it?


Jim


On 04/08/12 17:44, Warren Lynn wrote:
My vague impression is this has been discussed somewhere, but I did 
not find a ticket in Jira when searching on record, constructor, so 
I want to have some discussion here before considering entering a 
ticket myself.


Often, when I create a record, I need to do some set-up more than just 
pass the values to the fields (like to set the field values derived 
from some arguments, or add extra map keys when needed. Regular common 
OO constructor thing). Or course, I can do this:


(defn make-myrecord []   ... )

But I don't like the ad-hoc nature of that. Besides personal taste, 
whenever a common use case pattern is not captured and defined in the 
language, it just makes further abstraction and writing generic code 
more difficult.


So what I have now is this:

(defmulti make-record
  Create a new record. The first argument should be the record type (like
  MyRecord). Kind of like a constructor for record.

  Example method definition:
  (defmethod make-record MyRecord
  [rectype arg1 arg2 ...] ...)
  (fn [ args] (first args)))

This works but has one downside: it involves unnecessary run-time 
dispatch on the type. Although there are cases we may need dynamic 
creation of a record with run-time record type, most of time the 
record type is just static that can be decided at compile time (again, 
just like new MyClass(a, b, c) as in common OO languages).


So, as you may have guessed out from the title and the above, I think 
if we can have a mechanism to define constructors in defrecord, that 
seems a nice feature to me. What's on my mind is something like this:


(defrecord MyRecord
[x y z]
  (make-record My constructor 1 [arg1 arg2] ...)
  (make-record My constructor 2 [arg1 arg2 arg3 ...] ...))

(make-record MyRecord arg1 arg2 arg3 ...)   ;; this creates a new 
record. no need of run-time dispatching


Just like the constructors in common OO languages, constructors will:

1. Clearly communicates the designer's intention how the record should 
be created and avoid insistent internal field values. By the way, the 
doc strings in all constructors will also help, as everything in in 
one place.
2. Provides more regularity in the language, which can smooth/help 
further abstractions (for example, certain macros).


I know mentioning OO may be a big turn-off for certain people, but I 
don't see a clash here. Immutable objects are still objects and 
certain boring but widely accepted practice from OO may still apply here.


I had a brief look at defrecord2 
(https://github.com/david-mcneil/defrecord2), which certainly enhanced 
things. But because it is not part of the language itself, it feels 
patchy (I think even the author is not happy about that). Also, in 
general I would avoid creating functions behind the scene based on 
naming manipulations, especially for low level constructs.


Any comments? 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
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: community interest in machine learning (?)

2012-08-04 Thread Timothy Washington

Hey Jim,

So I started playing around with
clojure-encoghttps://github.com/jimpil/clojure-encog,
and I'm pretty excited about it so far. Again, I'm trying to make a
financial series predictor. And I'm trying to go through the steps of 1)
nomalizing / preparing the data 2) creating a feed-forward neural network
with back-prop (I'll try sigmoid  gaussian activations). Then I'll 3)
train and 4) run the network.


*A)* The first problem I'm having is a library one. I'm trying to normalize
the data with the (*prepare* ...) function, but the
*normalization*namespace isn't in
*[clojure-encog 0.4.0-SNAPSHOT]*. Here, we see that the *nnets* and *
training* namespaces are in the snapshot jar, but not the
*normalization*namespace. So I don't know how easy it is to update the
snapshot jar. But
in the meantime, I'll see if I can use the github version.

webkell@ubuntu:~/Projects/nn$ jar tvf
lib/clojure-encog-0.4.0-20120518.170223-1.jar
72 Fri May 18 17:58:04 PDT 2012 META-INF/MANIFEST.MF
  1961 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.xml
   111 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.properties
   584 Fri May 18 17:00:30 PDT 2012 project.clj
*  9839 Fri May 18 17:01:38 PDT 2012 clojure_encog/nnets.clj*
 11532 Fri May 18 17:57:20 PDT 2012 clojure_encog/examples.clj
* 10144 Fri May 18 17:43:58 PDT 2012 clojure_encog/training.clj*
  2177 Mon May 14 21:57:20 PDT 2012 java/NeuralPilot.java
  7574 Wed May 16 20:34:30 PDT 2012 java/PredictSunspotSVM.java
  2338 Mon May 14 21:56:42 PDT 2012 java/LanderSimulator.java
  1794 Fri May 18 16:02:22 PDT 2012 java/XORNEAT.java
  1672 Fri May 18 16:04:14 PDT 2012 java/XORNEAT.class
  1872 Mon May 14 14:53:26 PDT 2012 java/LanderSimulator.class
  1943 Mon May 14 14:53:26 PDT 2012 java/NeuralPilot.class
  7357 Wed May 16 20:37:20 PDT 2012 java/PredictSunspotSVM.class




*B)* The second problem I see is when trying to deal with the input data.
The example in 
clojure-encoghttps://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj#L107,
has just an array of doubles. But my input data is slightly different in
that I'm dealing with a LazySeq of arrays. Each of those arrays contain
tick data, Time, Ask, Bid, AskVolume and BidVolume:

([01.05.2012 20:00:00.676 1.32390 1.32379 300.00 225.00]
 [01.05.2012 20:00:00.888 1.32390 1.33238 300.10 220.00]
 ...)



So of course a call to ((*make-data* ...) , fails with the error
*clojure.lang.LazySeq
cannot be cast to [Double..*. So I need to figure out 1) a way to get each
one of those input data points , into an input-layer neuron. I've started
to think about that when I was dabbling with
codehttps://github.com/twashing/nn/blob/master/src/nn/neuralnet.clj.
If you like, I can look into trying to jerry-rig these kinds of tick data
mappings into (
training/make-datahttps://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/training.clj#L43
).
But I need a better understanding of the concept of a Temporalwindow. The
other thing is 2) to figure out how to transform the time field into data
the nn can use. I've been spitting the Datetime object out to longs.


Thanks

Tim Washington
Interruptsoftware.ca
416.843.9060



On Sun, Jul 29, 2012 at 11:35 AM, Dimitrios Jim Piliouras 
jimpil1...@gmail.com wrote:

 Hi Tim,

 According to :

 http://www.heatonresearch.com/content/encog-30-article-2-design-goals-overview


 encog 3 should have descent support for any temporal (time-series) based
 prediction support in particular for financial predictions...I'm afraid
 however that the only example that I've ported to clojure-encog which uses
 temporal data is the sunspot example (SVM not NN).

 Also, you shouldn't have any problems with the data (most likely you need
 to normalize them - I usually find  (-1 1) or (0 1) to work best.
 for an example of how exactly you would do it  look for
 PREDICT-SUNSPOT-SVM  here:

 https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj


 these 2 lines do all the job with regards to your input data:

 normalizedSunspots (prepare :array-range nil nil :raw-seq spots :ceiling 0.9 
 :floor 0.1)

 train-set  ((make-data :temporal-window normalizedSunspots)  window-size 1
 )


 As far as algorimthmic problems go encog has been around for quite a
 while...even though I don't necessarily agree with all the design decisions
 made along the way I find it is a  rather mature lib...of course it is
 written in Java so being large means it is a bit of a mess! also there is a
 lot of duplication in random places...anyways, what I'm trying to say is:

 if you've got a specific example in mind, (like the financial prediction)
 maybe it's worth trying it out using clojure-encog or the encog-workbench
 (the gui) or any other already-made lib and see how it goes...writing your
 own will certainly teach you loads but it might take a while until you
 actually test what you want to test...

Re: record constructor



On Saturday, August 4, 2012 1:15:13 PM UTC-4, Jim foo.bar wrote:

 for setting up  objects as you say, I'm fine using (doto Object ... ... 
 ...).  Records, as everything else in Clojure promote immutability and 
 so setting fields doesn't really make sense unless you're consuming 
 external java classes in which case 'doto' suffices...at least that is 
 the way I see it...I originally thought you were  asking about how to 
 create a record at runtime via a macro or a function, which is actually 
 quite tricky (and I can certainly help), but what you're asking sort of 
 exists doesn't it? 

 Jim 



Here I am still creating immutable objects. You may say I am setting 
things, but that is for creating a new object. The new object itself is 
still immutable. It makes sense because when you create an object, the 
values of the fields may need to meet certain integrity requirements, or 
some transformation from the caller's arguments.

Functionally, of course we can do it, as you can create a record with any 
values for the fields. But in my view it is not the main objective to say 
it works , it is powerful, it give user freedom when designing a 
language. My classic answer to those arguments is: how about assembly 
language? It definitely works, definitely powerful, and put no restrictions 
on the user. I know nobody who is a fan of such language.




 

-- 
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: community interest in machine learning (?)

p this is very strange...i'll update clojars within the next 
hour...sorry about this!


Jim

On 04/08/12 18:52, Timothy Washington wrote:

Hey Jim,

So I started playing around with clojure-encog 
https://github.com/jimpil/clojure-encog, and I'm pretty excited 
about it so far. Again, I'm trying to make a financial series 
predictor. And I'm trying to go through the steps of 1) nomalizing / 
preparing the data 2) creating a feed-forward neural network 
with back-prop (I'll try sigmoid  gaussian activations). Then I'll 3) 
train and 4) run the network.



*A)* The first problem I'm having is a library one. I'm trying to 
normalize the data with the (*prepare* ...) function, but the 
*/normalization/* namespace isn't in */[clojure-encog 
0.4.0-SNAPSHOT]/*. Here, we see that the */nnets/* and */training/* 
namespaces are in the snapshot jar, but not the /*normalization*/ 
namespace. So I don't know how easy it is to update the snapshot jar. 
But in the meantime, I'll see if I can use the github version.


webkell@ubuntu:~/Projects/nn$ jar tvf
lib/clojure-encog-0.4.0-20120518.170223-1.jar
72 Fri May 18 17:58:04 PDT 2012 META-INF/MANIFEST.MF
  1961 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.xml
   111 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.properties
   584 Fri May 18 17:00:30 PDT 2012 project.clj
*  9839 Fri May 18 17:01:38 PDT 2012 clojure_encog/nnets.clj*
 11532 Fri May 18 17:57:20 PDT 2012 clojure_encog/examples.clj
* 10144 Fri May 18 17:43:58 PDT 2012 clojure_encog/training.clj*
  2177 Mon May 14 21:57:20 PDT 2012 java/NeuralPilot.java
  7574 Wed May 16 20:34:30 PDT 2012 java/PredictSunspotSVM.java
  2338 Mon May 14 21:56:42 PDT 2012 java/LanderSimulator.java
  1794 Fri May 18 16:02:22 PDT 2012 java/XORNEAT.java
  1672 Fri May 18 16:04:14 PDT 2012 java/XORNEAT.class
  1872 Mon May 14 14:53:26 PDT 2012 java/LanderSimulator.class
  1943 Mon May 14 14:53:26 PDT 2012 java/NeuralPilot.class
  7357 Wed May 16 20:37:20 PDT 2012 java/PredictSunspotSVM.class




*B)* The second problem I see is when trying to deal with the input 
data. The example in clojure-encog 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj#L107, 
has just an array of doubles. But my input data is slightly different 
in that I'm dealing with a LazySeq of arrays. Each of those arrays 
contain tick data, Time, Ask, Bid, AskVolume and BidVolume:


([01.05.2012 20:00:00.676 1.32390 1.32379 300.00
225.00]
 [01.05.2012 20:00:00.888 1.32390 1.33238 300.10
220.00]
 ...)



So of course a call to ((*make-data* ...) , fails with the error 
/clojure.lang.LazySeq cannot be cast to [Double../. So I need to 
figure out 1) a way to get each one of those input data points , into 
an input-layer neuron. I've started to think about that when I was 
dabbling with code 
https://github.com/twashing/nn/blob/master/src/nn/neuralnet.clj. If 
you like, I can look into trying to jerry-rig these kinds of tick data 
mappings into ( training/make-data 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/training.clj#L43 ). 
But I need a better understanding of the concept of a Temporalwindow. 
The other thing is 2) to figure out how to transform the time field 
into data the nn can use. I've been spitting the Datetime object out 
to longs.



Thanks

Tim Washington
Interruptsoftware.ca http://Interruptsoftware.ca
416.843.9060



On Sun, Jul 29, 2012 at 11:35 AM, Dimitrios Jim Piliouras 
jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote:


Hi Tim,

According to :

http://www.heatonresearch.com/content/encog-30-article-2-design-goals-overview


encog 3 should have descent support for any temporal (time-series)
based prediction support in particular for financial
predictions...I'm afraid however that the only example that I've
ported to clojure-encog which uses temporal data is the sunspot
example (SVM not NN).

Also, you shouldn't have any problems with the data (most likely
you need to normalize them - I usually find  (-1 1) or (0 1) to
work best.
for an example of how exactly you would do it  look for
PREDICT-SUNSPOT-SVM  here:

https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj


these 2 lines do all the job with regards to your input data:

normalizedSunspots  (prepare  :array-range  nil  nil  :raw-seq  spots  
:ceiling  0.9  :floor  0.1)



train-set ((make-data :temporal-window normalizedSunspots)
window-size 1)


As far as algorimthmic problems go encog has been around for quite
a while...even though I don't necessarily agree with all the
design decisions made along the way I find it is a  rather mature
lib...of course it is written in Java so being large means it is a
bit of a mess! also there is a

Re: record constructor


On 04/08/12 19:14, Warren Lynn wrote:
Here I am still creating immutable objects. You may say I am setting 
things, but that is for creating a new object.


I am not sure I follow...If you're just creating a new record yourself, 
you can pass whatever you want to the constructor...no need for 
'setting' whatsoever...On the other hand if you're consuming an object 
then you might need to 'set' some fields before it is useful (where doto 
comes into play).


It makes sense because when you create an object, the values of the 
fields may need to meet certain integrity requirements, or some 
transformation from the caller's arguments.


I won't object to this for a simple reason... in OO languages it is good 
and idiomatic to have a single road to mutation (the set method) and 
always use that (even from the constructor when initialising) so you can 
easily, as you say, check for certain criteria or do some transformation 
in one place. However this is a result of uncontrolled mutation! People 
realised it is better to avoid using the = (assignment operator) in 
favour of setters and encapsulated all the null/type-checking, shoot me 
now code inside them. However, if you're in control of your objects and 
your field are always immutable then what is the point of a setter 
method? What does it protect you from? Do you really need so many 
integrity checks or transformations when you can only really set the 
value once?



Functionally, of course we can do it, as you can create a record with 
any values for the fields. But in my view it is not the main objective 
to say it works , it is powerful, it give user freedom when 
designing a language. My classic answer to those arguments is: how 
about assembly language? It definitely works, definitely powerful, and 
put no restrictions on the user. I know nobody who is a fan of such 
language.


Deep inside, we are all fans of assembly or at least we should be... :)

Jim


--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: community interest in machine learning (?)

Clojars has been updated with a clojure-encog jar containing all the 
namespaces...I'm really sorry I can't believe I hadn't noticed that! The 
code is in complete sync with github at the moment so instead of typing 
'doc' all the time feel free to have a browser open...I've not changed 
much - I just removed some redundant let bindings and added ability to 
create an empty dataset... I also added a simple k-means clustering 
example. If i understood correctly what you're doing the closest example 
regarding preparing/normalising your data is the predict-sunspots example...


Hope that helps... :)

Jim

ps: empirically,  tanh and sigmoid work almost always best...I can say 
the same for the nuygen-widrow randomiser...Also, just so you know I'll 
be renaming clojure-encog to enclog for the 0.5 release...



On 04/08/12 19:18, Jim - FooBar(); wrote:
p this is very strange...i'll update clojars within the next 
hour...sorry about this!


Jim

On 04/08/12 18:52, Timothy Washington wrote:

Hey Jim,

So I started playing around with clojure-encog 
https://github.com/jimpil/clojure-encog, and I'm pretty excited 
about it so far. Again, I'm trying to make a financial series 
predictor. And I'm trying to go through the steps of 1) nomalizing / 
preparing the data 2) creating a feed-forward neural network 
with back-prop (I'll try sigmoid  gaussian activations). Then I'll 
3) train and 4) run the network.



*A)* The first problem I'm having is a library one. I'm trying to 
normalize the data with the (*prepare* ...) function, but the 
*/normalization/* namespace isn't in */[clojure-encog 
0.4.0-SNAPSHOT]/*. Here, we see that the */nnets/* and */training/* 
namespaces are in the snapshot jar, but not the /*normalization*/ 
namespace. So I don't know how easy it is to update the snapshot jar. 
But in the meantime, I'll see if I can use the github version.


webkell@ubuntu:~/Projects/nn$ jar tvf
lib/clojure-encog-0.4.0-20120518.170223-1.jar
72 Fri May 18 17:58:04 PDT 2012 META-INF/MANIFEST.MF
  1961 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.xml
   111 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.properties
   584 Fri May 18 17:00:30 PDT 2012 project.clj
*  9839 Fri May 18 17:01:38 PDT 2012 clojure_encog/nnets.clj*
 11532 Fri May 18 17:57:20 PDT 2012 clojure_encog/examples.clj
* 10144 Fri May 18 17:43:58 PDT 2012 clojure_encog/training.clj*
  2177 Mon May 14 21:57:20 PDT 2012 java/NeuralPilot.java
  7574 Wed May 16 20:34:30 PDT 2012 java/PredictSunspotSVM.java
  2338 Mon May 14 21:56:42 PDT 2012 java/LanderSimulator.java
  1794 Fri May 18 16:02:22 PDT 2012 java/XORNEAT.java
  1672 Fri May 18 16:04:14 PDT 2012 java/XORNEAT.class
  1872 Mon May 14 14:53:26 PDT 2012 java/LanderSimulator.class
  1943 Mon May 14 14:53:26 PDT 2012 java/NeuralPilot.class
  7357 Wed May 16 20:37:20 PDT 2012 java/PredictSunspotSVM.class




*B)* The second problem I see is when trying to deal with the input 
data. The example in clojure-encog 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj#L107, 
has just an array of doubles. But my input data is slightly different 
in that I'm dealing with a LazySeq of arrays. Each of those arrays 
contain tick data, Time, Ask, Bid, AskVolume and BidVolume:


([01.05.2012 20:00:00.676 1.32390 1.32379 300.00
225.00]
 [01.05.2012 20:00:00.888 1.32390 1.33238 300.10
220.00]
 ...)



So of course a call to ((*make-data* ...) , fails with the error 
/clojure.lang.LazySeq cannot be cast to [Double../. So I need to 
figure out 1) a way to get each one of those input data points , into 
an input-layer neuron. I've started to think about that when I was 
dabbling with code 
https://github.com/twashing/nn/blob/master/src/nn/neuralnet.clj. If 
you like, I can look into trying to jerry-rig these kinds of tick 
data mappings into ( training/make-data 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/training.clj#L43 ). 
But I need a better understanding of the concept of a Temporalwindow. 
The other thing is 2) to figure out how to transform the time field 
into data the nn can use. I've been spitting the Datetime object out 
to longs.



Thanks

Tim Washington
Interruptsoftware.ca http://Interruptsoftware.ca
416.843.9060



On Sun, Jul 29, 2012 at 11:35 AM, Dimitrios Jim Piliouras 
jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote:


Hi Tim,

According to :

http://www.heatonresearch.com/content/encog-30-article-2-design-goals-overview


encog 3 should have descent support for any temporal
(time-series) based prediction support in particular for
financial predictions...I'm afraid however that the only example
that I've ported to clojure-encog which uses temporal data is the
sunspot example (SVM not NN).

Also, you shouldn't have any problems

Re: community interest in machine learning (?)

I will address your second issue shortly...You say you have a lazy-seq 
of arrays that have 5 strings? why strings?


Jim

On 04/08/12 20:02, Jim - FooBar(); wrote:
Clojars has been updated with a clojure-encog jar containing all the 
namespaces...I'm really sorry I can't believe I hadn't noticed that! 
The code is in complete sync with github at the moment so instead of 
typing 'doc' all the time feel free to have a browser open...I've not 
changed much - I just removed some redundant let bindings and added 
ability to create an empty dataset... I also added a simple k-means 
clustering example. If i understood correctly what you're doing the 
closest example regarding preparing/normalising your data is the 
predict-sunspots example...


Hope that helps... :)

Jim

ps: empirically,  tanh and sigmoid work almost always best...I can say 
the same for the nuygen-widrow randomiser...Also, just so you know 
I'll be renaming clojure-encog to enclog for the 0.5 release...



On 04/08/12 19:18, Jim - FooBar(); wrote:
p this is very strange...i'll update clojars within the next 
hour...sorry about this!


Jim

On 04/08/12 18:52, Timothy Washington wrote:

Hey Jim,

So I started playing around with clojure-encog 
https://github.com/jimpil/clojure-encog, and I'm pretty excited 
about it so far. Again, I'm trying to make a financial series 
predictor. And I'm trying to go through the steps of 1) nomalizing / 
preparing the data 2) creating a feed-forward neural network 
with back-prop (I'll try sigmoid  gaussian activations). Then I'll 
3) train and 4) run the network.



*A)* The first problem I'm having is a library one. I'm trying to 
normalize the data with the (*prepare* ...) function, but the 
*/normalization/* namespace isn't in */[clojure-encog 
0.4.0-SNAPSHOT]/*. Here, we see that the */nnets/* and 
*/training/* namespaces are in the snapshot jar, but not the 
/*normalization*/ namespace. So I don't know how easy it is to 
update the snapshot jar. But in the meantime, I'll see if I can use 
the github version.


webkell@ubuntu:~/Projects/nn$ jar tvf
lib/clojure-encog-0.4.0-20120518.170223-1.jar
72 Fri May 18 17:58:04 PDT 2012 META-INF/MANIFEST.MF
  1961 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.xml
   111 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.properties
   584 Fri May 18 17:00:30 PDT 2012 project.clj
*  9839 Fri May 18 17:01:38 PDT 2012 clojure_encog/nnets.clj*
 11532 Fri May 18 17:57:20 PDT 2012 clojure_encog/examples.clj
* 10144 Fri May 18 17:43:58 PDT 2012 clojure_encog/training.clj*
  2177 Mon May 14 21:57:20 PDT 2012 java/NeuralPilot.java
  7574 Wed May 16 20:34:30 PDT 2012 java/PredictSunspotSVM.java
  2338 Mon May 14 21:56:42 PDT 2012 java/LanderSimulator.java
  1794 Fri May 18 16:02:22 PDT 2012 java/XORNEAT.java
  1672 Fri May 18 16:04:14 PDT 2012 java/XORNEAT.class
  1872 Mon May 14 14:53:26 PDT 2012 java/LanderSimulator.class
  1943 Mon May 14 14:53:26 PDT 2012 java/NeuralPilot.class
  7357 Wed May 16 20:37:20 PDT 2012 java/PredictSunspotSVM.class




*B)* The second problem I see is when trying to deal with the input 
data. The example in clojure-encog 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj#L107, 
has just an array of doubles. But my input data is slightly 
different in that I'm dealing with a LazySeq of arrays. Each of 
those arrays contain tick data, Time, Ask, Bid, AskVolume and 
BidVolume:


([01.05.2012 20:00:00.676 1.32390 1.32379 300.00
225.00]
 [01.05.2012 20:00:00.888 1.32390 1.33238 300.10
220.00]
 ...)



So of course a call to ((*make-data* ...) , fails with the error 
/clojure.lang.LazySeq cannot be cast to [Double../. So I need to 
figure out 1) a way to get each one of those input data points , 
into an input-layer neuron. I've started to think about that when I 
was dabbling with code 
https://github.com/twashing/nn/blob/master/src/nn/neuralnet.clj. 
If you like, I can look into trying to jerry-rig these kinds of tick 
data mappings into ( training/make-data 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/training.clj#L43 ). 
But I need a better understanding of the concept of a 
Temporalwindow. The other thing is 2) to figure out how to transform 
the time field into data the nn can use. I've been spitting the 
Datetime object out to longs.



Thanks

Tim Washington
Interruptsoftware.ca http://Interruptsoftware.ca
416.843.9060



On Sun, Jul 29, 2012 at 11:35 AM, Dimitrios Jim Piliouras 
jimpil1...@gmail.com mailto:jimpil1...@gmail.com wrote:


Hi Tim,

According to :

http://www.heatonresearch.com/content/encog-30-article-2-design-goals-overview


encog 3 should have descent support for any temporal
(time-series) based prediction support in particular for
financial predictions...I'm afraid however

Re: community interest in machine learning (?)

Hmmm, I think it is worth downloading the source for encog 3.1 for java 
and look into: org.encog.ml.data.temporal.TemporalMLDataSet


I think this is what you need to add several columns...unfortunately 
I've not wrapped this yet so you will have to do some interop to get it 
going...I promise you it will be the first thing I look at as soon as I 
find some time...


hope that helps...

Jim


On 04/08/12 20:08, Jim - FooBar(); wrote:
I will address your second issue shortly...You say you have a lazy-seq 
of arrays that have 5 strings? why strings?


Jim

On 04/08/12 20:02, Jim - FooBar(); wrote:
Clojars has been updated with a clojure-encog jar containing all the 
namespaces...I'm really sorry I can't believe I hadn't noticed that! 
The code is in complete sync with github at the moment so instead of 
typing 'doc' all the time feel free to have a browser open...I've not 
changed much - I just removed some redundant let bindings and added 
ability to create an empty dataset... I also added a simple k-means 
clustering example. If i understood correctly what you're doing the 
closest example regarding preparing/normalising your data is the 
predict-sunspots example...


Hope that helps... :)

Jim

ps: empirically,  tanh and sigmoid work almost always best...I can 
say the same for the nuygen-widrow randomiser...Also, just so you 
know I'll be renaming clojure-encog to enclog for the 0.5 release...



On 04/08/12 19:18, Jim - FooBar(); wrote:
p this is very strange...i'll update clojars within the next 
hour...sorry about this!


Jim

On 04/08/12 18:52, Timothy Washington wrote:

Hey Jim,

So I started playing around with clojure-encog 
https://github.com/jimpil/clojure-encog, and I'm pretty excited 
about it so far. Again, I'm trying to make a financial series 
predictor. And I'm trying to go through the steps of 1) nomalizing 
/ preparing the data 2) creating a feed-forward neural network 
with back-prop (I'll try sigmoid  gaussian activations). Then I'll 
3) train and 4) run the network.



*A)* The first problem I'm having is a library one. I'm trying to 
normalize the data with the (*prepare* ...) function, but the 
*/normalization/* namespace isn't in */[clojure-encog 
0.4.0-SNAPSHOT]/*. Here, we see that the */nnets/* and 
*/training/* namespaces are in the snapshot jar, but not the 
/*normalization*/ namespace. So I don't know how easy it is to 
update the snapshot jar. But in the meantime, I'll see if I can use 
the github version.


webkell@ubuntu:~/Projects/nn$ jar tvf
lib/clojure-encog-0.4.0-20120518.170223-1.jar
72 Fri May 18 17:58:04 PDT 2012 META-INF/MANIFEST.MF
  1961 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.xml
   111 Fri May 18 17:58:04 PDT 2012
META-INF/maven/clojure-encog/clojure-encog/pom.properties
   584 Fri May 18 17:00:30 PDT 2012 project.clj
*  9839 Fri May 18 17:01:38 PDT 2012 clojure_encog/nnets.clj*
 11532 Fri May 18 17:57:20 PDT 2012 clojure_encog/examples.clj
* 10144 Fri May 18 17:43:58 PDT 2012 clojure_encog/training.clj*
  2177 Mon May 14 21:57:20 PDT 2012 java/NeuralPilot.java
  7574 Wed May 16 20:34:30 PDT 2012 java/PredictSunspotSVM.java
  2338 Mon May 14 21:56:42 PDT 2012 java/LanderSimulator.java
  1794 Fri May 18 16:02:22 PDT 2012 java/XORNEAT.java
  1672 Fri May 18 16:04:14 PDT 2012 java/XORNEAT.class
  1872 Mon May 14 14:53:26 PDT 2012 java/LanderSimulator.class
  1943 Mon May 14 14:53:26 PDT 2012 java/NeuralPilot.class
  7357 Wed May 16 20:37:20 PDT 2012 java/PredictSunspotSVM.class




*B)* The second problem I see is when trying to deal with the input 
data. The example in clojure-encog 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/examples.clj#L107, 
has just an array of doubles. But my input data is slightly 
different in that I'm dealing with a LazySeq of arrays. Each of 
those arrays contain tick data, Time, Ask, Bid, AskVolume and 
BidVolume:


([01.05.2012 20:00:00.676 1.32390 1.32379 300.00
225.00]
 [01.05.2012 20:00:00.888 1.32390 1.33238 300.10
220.00]
 ...)



So of course a call to ((*make-data* ...) , fails with the error 
/clojure.lang.LazySeq cannot be cast to [Double../. So I need to 
figure out 1) a way to get each one of those input data points , 
into an input-layer neuron. I've started to think about that when I 
was dabbling with code 
https://github.com/twashing/nn/blob/master/src/nn/neuralnet.clj. 
If you like, I can look into trying to jerry-rig these kinds of 
tick data mappings into ( training/make-data 
https://github.com/jimpil/clojure-encog/blob/master/src/clojure_encog/training.clj#L43 ). 
But I need a better understanding of the concept of a 
Temporalwindow. The other thing is 2) to figure out how to 
transform the time field into data the nn can use. I've been 
spitting the Datetime object out to longs.



Thanks

Tim Washington
Interruptsoftware.ca

assoc! order problem

2012-08-04 Thread llj098

Hi list,

I'm learning Clojure now and  I was confused by assoc!.

Here is my code , I want to use the code to distinct items (I cannot use 
'distinct' function here for some reasons.)

(defn fn2[x] 
  (vals (persistent!
(reduce (fn [ret l] (assoc! ret l l ))
  (transient {}) x


user= (fn2 (range 32))
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 
28 29 30 31)
user= (fn2 (range 33))
(0 32 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 
27 28 29 30 31)
user= (fn2 (range 50))
(0 32 1 33 2 34 3 35 4 36 5 37 6 38 7 39 8 40 9 41 10 42 11 43 12 44 13 45 
14 46 15 47 16 48 17 49 18 19 20 21 22 23 24 25 26 27 28 29 30 31)


*So my question is : ** why the result is not ordered when the size of 
input is larger than 32?*



Thanks


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

assoc! order problem

2012-08-04 Thread Jeff Heon

You are using the map literal, which corresponds to the hash map.

Use this if you want a sorted map: 
http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/sorted-map

-- 
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: assoc! order problem

2012-08-04 Thread Bronsa

Note that you can't use a sorted-map in a transient

2012/8/4 Jeff Heon jfh...@gmail.com

 You are using the map literal, which corresponds to the hash map.

 Use this if you want a sorted map:
 http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/sorted-map

 --
 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: record constructor

 


 I am not sure I follow...If you're just creating a new record yourself, 
 you can pass whatever you want to the constructor...no need for 
 'setting' whatsoever...On the other hand if you're consuming an object 
 then you might need to 'set' some fields before it is useful (where doto 
 comes into play). 



I have a feeling we may not be talking about the same thing here. What I 
want is constructors, not a setter. My understanding is, in Clojure there 
is no constructors for record other than simply passing in the field values 
(directly or in a map). And hence I am proposing to have some constructors 
similar to other OO languages. Having constructors have nothing to do with 
immutability.

Here is a maybe silly example, but hope it communicates what I want. I want 
something like this:

(defrecord Book
[age-min age-max]
  (make-record Make a book for an age group [age-min age-max]
(when ( age-min age-max)
  (throw (IllegalArgumentException. Minimum age is greater than 
maximum age.)))
(Book. age-min age-max)))

(make-record Book 6 5) = IllegalArgumentException
(make-record Book 3 5) = Book#{:age-min 3 :age-max 5}

BTW, this not to argue with you. But I sometimes I feel some people have 
some kind of extreme opposition against anything associated with OO. I just 
think people designing and using OO languages are no all that stupid.


-- 
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

ANN a CjOne TodoMVC implementation

Hello,

I have published a local! -able - just dblClik ont index.html to load app, 
here [1]

based on CjOne 

Running app here [0]

[0] http://todomvc.herokuapp.com
[1] https://github.com/phperret/peer-one.git

-- 
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: assoc! order problem

I have not used transient yet so I don't understand your code. But for 
ordered maps, I use ArrayMap. 


-- 
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: community interest in machine learning (?)

2012-08-04 Thread Timothy Washington

Hey Jim,

Thanks for looking into these things. I tried removing clojure-encog from
lib/ and .m2/ . But '*lein deps*' still pulls in a jar without the
normalization.clj file. Do I need an updated [clojure-encog 0.4.x-SNAPSHOT
]?

Also, I'll take a peek at the source for 'org.encog.ml.data.temporal.
TemporalMLDataSet'. As for the structure of the tick data, I used
clojure-csv to to pull that data from this CSV
filehttps://github.com/twashing/nn/blob/master/etc/data/EURUSD_Ticks_Apr2012.csv
(you'll
have to download as it's large). So it's easy for me to convert those
strings to doubles, datetimes, etc.


This helps a great deal

Cheers

Tim Washington
Interruptsoftware.ca
416.843.9060



On Sat, Aug 4, 2012 at 3:19 PM, Jim - FooBar(); jimpil1...@gmail.comwrote:

  Hmmm, I think it is worth downloading the source for encog 3.1 for java
 and look into: org.encog.ml.data.temporal.TemporalMLDataSet

 I think this is what you need to add several columns...unfortunately I've
 not wrapped this yet so you will have to do some interop to get it
 going...I promise you it will be the first thing I look at as soon as I
 find some time...

 hope that helps...

 Jim



-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: record constructor

 ok this is clearer now! I actually like what you're proposing just 
not in the form you're proposing it...since the record will already 
create 2 constructors in the underlying class, having essentially a 3rd  
sounds a bit crowded...minimally, you want (and I agree) the ability to 
optionally attach validator functions to some record fields. I have to 
admit that sounds nice...we can already do that with atoms why can't we 
do that with regular vars?


Jim



On 04/08/12 22:06, Warren Lynn wrote:



I am not sure I follow...If you're just creating a new record
yourself,
you can pass whatever you want to the constructor...no need for
'setting' whatsoever...On the other hand if you're consuming an
object
then you might need to 'set' some fields before it is useful
(where doto
comes into play).



I have a feeling we may not be talking about the same thing here. What 
I want is constructors, not a setter. My understanding is, in 
Clojure there is no constructors for record other than simply passing 
in the field values (directly or in a map). And hence I am proposing 
to have some constructors similar to other OO languages. Having 
constructors have nothing to do with immutability.


Here is a maybe silly example, but hope it communicates what I want. I 
want something like this:


(defrecord Book
[age-min age-max]
  (make-record Make a book for an age group [age-min age-max]
(when ( age-min age-max)
  (throw (IllegalArgumentException. Minimum age is greater than 
maximum age.)))

(Book. age-min age-max)))

(make-record Book 6 5) = IllegalArgumentException
(make-record Book 3 5) = Book#{:age-min 3 :age-max 5}

BTW, this not to argue with you. But I sometimes I feel some people 
have some kind of extreme opposition against anything associated with 
OO. I just think people designing and using OO languages are no all 
that stupid.



--
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: community interest in machine learning (?)


On 04/08/12 23:08, Timothy Washington wrote:
And one more thing. I'm looking at the TemporalMLDataSet.java 
https://github.com/encog/encog-java-core/blob/master/src/main/java/org/encog/ml/data/temporal/TemporalMLDataSet.java 
source, and I keep on seeing references to a 'windowSize'. What is a 
*/inputWindowSize/* and a */predictWindowSize/* ? 



I suppose your window-size is how far back from the present you want to 
look each time...it needs to be compatible with your input layer...a 
window-size of 30 with 5 indicators would give you 150 (3*50=150) input 
neurons as confirmed in this post:


http://www.heatonresearch.com/node/2124


Jim




--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: community interest in machine learning (?)

2012-08-04 Thread Timothy Washington

Ok, this makes sense.

Thanks very much for your insights.


Tim Washington
Interruptsoftware.ca
416.843.9060



On Sat, Aug 4, 2012 at 6:21 PM, Jim - FooBar(); jimpil1...@gmail.comwrote:

  On 04/08/12 23:08, Timothy Washington wrote:

 And one more thing. I'm looking at the 
 TemporalMLDataSet.javahttps://github.com/encog/encog-java-core/blob/master/src/main/java/org/encog/ml/data/temporal/TemporalMLDataSet.javasource,
  and I keep on seeing references to a 'windowSize'. What is a
 *inputWindowSize* and a *predictWindowSize* ?



 I suppose your window-size is how far back from the present you want to
 look each time...it needs to be compatible with your input layer...a
 window-size of 30 with 5 indicators would give you 150 (3*50=150) input
 neurons as confirmed in this post:

 http://www.heatonresearch.com/node/2124


 Jim





 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To 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: ANN a CjOne TodoMVC implementation

 Using it in Chrome and then typing F12 allows to see all the clojure 
structures travelling along ..

Le samedi 4 août 2012 23:20:50 UTC+2, Pierre-Henry Perret a écrit :

 Hello,

 I have published a local! -able - just dblClik ont index.html to load app, 
 here [1]

 based on CjOne 

 Running app here [0]

 [0] http://todomvc.herokuapp.com
 [1] https://github.com/phperret/peer-one.git



-- 
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: community interest in machine learning (?)

No worries...

looking at the examples.clj in 0.4.1-SNAPSHOT, it is likely it won't
even compile which is good evidence of how much your first email made me
jump!!! If you want to run the examples just copy-paste the entire code
in a namespace of your own while commenting out the
travelling-salesman-problem example. that should sort any compilation
issues...

Jim

On 04/08/12 23:35, Timothy Washington wrote:

Ok, this makes sense.

Thanks very much for your insights.

Tim Washington
Interruptsoftware.ca http://Interruptsoftware.ca
416.843.9060

On Sat, Aug 4, 2012 at 6:21 PM, Jim - FooBar(); jimpil1...@gmail.com
mailto:jimpil1...@gmail.com wrote:

On 04/08/12 23:08, Timothy Washington wrote:

And one more thing. I'm looking at the TemporalMLDataSet.java

https://github.com/encog/encog-java-core/blob/master/src/main/java/org/encog/ml/data/temporal/TemporalMLDataSet.java
source, and I keep on seeing references to a 'windowSize'. What
is a */inputWindowSize/* and a */predictWindowSize/* ?

I suppose your window-size is how far back from the present you
want to look each time...it needs to be compatible with your input
layer...a window-size of 30 with 5 indicators would give you 150
(3*50=150) input neurons as confirmed in this post:

http://www.heatonresearch.com/node/2124

Jim

--
You received this message because you are subscribed to the Google

Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
mailto: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
mailto:clojure%2bunsubscr...@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+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: record constructor



On Saturday, August 4, 2012 6:07:20 PM UTC-4, Jim foo.bar wrote:

   ok this is clearer now! I actually like what you're proposing just 
 not in the form you're proposing it...since the record will already create 
 2 constructors in the underlying class, having essentially a 3rd  sounds a 
 bit crowded...minimally, you want (and I agree) the ability to optionally 
 attach validator functions to some record fields. I have to admit that 
 sounds nice...we can already do that with atoms why can't we do that with 
 regular vars?

 Jim


Validator can be a good feature, but I don't think that can substitute 
constructors, because constructors can do more than just validating, as we 
all know from other OO languages.

-- 
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: record constructor

2012-08-04 Thread Softaddicts

Count me as a fan I designed and wrote complex systems in assembly language
many of them above 10k lines.

Contrary to many commonly used languages, most assemblers have powerful macros,
that feature alone allows you to implement sophisticated designs.

As far as your OO related comments, may I point to you that in Java you will
find a common pattern (I hate this pattern concept) called a factory.

In Java you will find factories everywhere to create and wire objects based on
external conditions. There are no complex setters or constructors
defined whatsoever in the manufactured object class itself,
the factory is responsible for wiring the instance using it's own logic.

Adding constructors to meet your need is against what OO does these days.
On what basis other than OO then should Clojure support constructors as
you suggest to allow some complex tweaking when creating a record ?

Just use a high order fn as a factory to create your records and place it
along you record definition in the same name space with proper documentation.

High order fns can be passed around and this can be quite valuable to be able
to specify a factory fn as a parameter.

In my opinion, your suggestion is a feature in search of a problem to solve :)

Luc P.



 
 
 On Saturday, August 4, 2012 1:15:13 PM UTC-4, Jim foo.bar wrote:
 
  for setting up  objects as you say, I'm fine using (doto Object ... ... 
  ...).  Records, as everything else in Clojure promote immutability and 
  so setting fields doesn't really make sense unless you're consuming 
  external java classes in which case 'doto' suffices...at least that is 
  the way I see it...I originally thought you were  asking about how to 
  create a record at runtime via a macro or a function, which is actually 
  quite tricky (and I can certainly help), but what you're asking sort of 
  exists doesn't it? 
 
  Jim 
 
 
 
 Here I am still creating immutable objects. You may say I am setting 
 things, but that is for creating a new object. The new object itself is 
 still immutable. It makes sense because when you create an object, the 
 values of the fields may need to meet certain integrity requirements, or 
 some transformation from the caller's arguments.
 
 Functionally, of course we can do it, as you can create a record with any 
 values for the fields. But in my view it is not the main objective to say 
 it works , it is powerful, it give user freedom when designing a 
 language. My classic answer to those arguments is: how about assembly 
 language? It definitely works, definitely powerful, and put no restrictions 
 on the user. I know nobody who is a fan of such language.
 
 
 
 
  
 
 -- 
 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
--
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

Re: record constructor

On Sat, Aug 4, 2012 at 5:30 PM, Softaddicts lprefonta...@softaddicts.ca wrote:
 Just use a high order fn as a factory to create your records and place it
 along you record definition in the same name space with proper documentation.

 High order fns can be passed around and this can be quite valuable to be able
 to specify a factory fn as a parameter.

 In my opinion, your suggestion is a feature in search of a problem to solve 
 :)

I agree. Since you have to write a function anyway if you want a
record that does more than just construct a map, why not adopt the
idiom of a make-myrecord factory function?

If I was using plain maps instead of records and wanted some sort of
constructor function, I'd just write a make-whatever factory
function anyway so I don't see why this is not appropriate with
records too.

(and to be honest, Warren, I think you're beating yourself up somewhat
by trying to shoehorn OO practices into Clojure in the first place but
maybe that's something everyone goes thru if they are heavily steeped
in OO thinking, when they first try to adopt an FP language?)

p.s. to be honest, I still don't see enough benefits in records that
outweigh their limitations to use them in the first place - unless I
needed a type that would interop with Java or I was using protocols...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: record constructor



On Saturday, August 4, 2012 8:30:50 PM UTC-4, Luc wrote:

 Count me as a fan I designed and wrote complex systems in assembly 
 language 
 many of them above 10k lines. 

  
I can only admire you for that. Assemly language certain has its uses, but 
it is not really for average folks like me (I use assemly too for 
performance critical part, but not anything like 10k lines of code)
 

 Contrary to many commonly used languages, most assemblers have powerful 
 macros, 
 that feature alone allows you to implement sophisticated designs. 

 As far as your OO related comments, may I point to you that in Java you 
 will 
 find a common pattern (I hate this pattern concept) called a factory. 

 When I worked on Java (10 years ago, so I can be outdated), factory 
function was usually used to create different concrete objects confoming to 
common interfaces. Maybe now it is used a lot more, but still, I assume 
even nowadays you also find constructors everywhere.
 


 Adding constructors to meet your need is against what OO does these days. 
 On what basis other than OO then should Clojure support constructors as 
 you suggest to allow some complex tweaking when creating a record ? 


The argument here is not on the basis of OO, it is on the basis of 
reasons that lead people to do some of the OO practices. I am not saying 
we do everything as current common OO does, but we also don't need to 
reject things too quickly on the basis of OO.
 

 Just use a high order fn as a factory to create your records and place it 
 along you record definition in the same name space with proper 
 documentation. 

 High order fns can be passed around and this can be quite valuable to be 
 able 
 to specify a factory fn as a parameter. 

  
That will work. And it is valuable to have factory functions to create 
objects more dynamically. But OO like constructors is also valuable because 
it frames a pattern that is clear and intuitive for vast majority of use 
cases. And it does not do any harm to whatever people is using now (if you 
want to continue to use factory function, there is no impact of that) 
 
If it does not do any harm to anybody but have benefits for some people (of 
course not just me), I reason it is a good feature. 


-- 
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: record constructor



 (and to be honest, Warren, I think you're beating yourself up somewhat 
 by trying to shoehorn OO practices into Clojure in the first place but 
 maybe that's something everyone goes thru if they are heavily steeped 
 in OO thinking, when they first try to adopt an FP language?) 


As difficult as you can see why I keep coming up crazy OO-like proposals, I 
am also puzzled by the seemingly OO-phobia in the community. If the reason 
for a OO practice is good, we can considere using it. If not, we don't. 
Also, the proposal here is not FP vs imperative. The created object is 
still immutable, and does not violate any FP principles. 

As of going through FP, after some time, I started see certain benefits of 
FP, but I see nothing saying FP cannot use some ideas in OO.
 

 p.s. to be honest, I still don't see enough benefits in records that 
 outweigh their limitations to use them in the first place - unless I 
 needed a type that would interop with Java or I was using protocols... 


Well, my impression is quite some people (including me) in the community 
find records and protocols very useful and use them quite a bit. So, as 
long as records do not do any harm for folks who are happy with regular 
maps, records and protocols are a sure-win, right?

I think one of LISP principle is being versatile and adaptable (many right 
ways vs only one right way in Python). So I am kind of puzzled by the 
inertia here unless some harm can be demonstrated on the proposal.
 

-- 
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

Strange coercions...


Running a codelein2 check/code gives -
___
Exception in thread main java.lang.IllegalArgumentException: No 
implementation of method: :as-file of protocol: #'clojure.java.io/Coercions 
found for class: c
lojure.lang.PersistentVector
_

I would my precate my lein1 project becoming a lein2 one ..

Someone has an idea ?
Thanks

--
Pierre

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
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

Question about sets

2012-08-04 Thread Mark Engelberg

What is the reasoning behind the design decision that this generates an
error:
(let [a :x b :x] #{a b})
rather than just returning #{:x} ?

I'm finding that in practice, it limits the utility of #{} notation if you
have to somehow know in advance that all the things in the set are
different.

-- 
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

Strange coercions

Running a codelein2 check/code gives -
___
Exception in thread main java.lang.IllegalArgumentException: No 
implementation of method: :as-file of protocol: #'clojure.java.io/Coercions 
found 
for class: c
lojure.lang.PersistentVector
_

I would my precate my lein1 project becoming a lein2 one ..

Someone has an idea ?
Thanks

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Strange coercions

Running a codelein2 check/code gives -
___
Exception in thread main java.lang.IllegalArgumentException: No 
implementation of method: :as-file of protocol: #'clojure.java.io/Coercions 
found 
for class: c
lojure.lang.PersistentVector
_

I would precate my lein1 project becoming a lein2 one ..

Someone has an idea ?
Thanks

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: record constructor

2012-08-04 Thread Timothy Baldridge

Warren, I can't speak for others, but I can say that personally one of the
reasons I love Clojure so much is that it doesn't try to be a OOP language,
instead it cleanly separates data from logic. Clojure is not a OOP language
and (hopefully) will never attempt to be so. But this separation of logic
and data should be very, very carefully examined. Here's an example:

(defprotocol IFoo
  (foo-func [this]))

(defrecord Foo [num]
  IFoo
  (foo-func [this] num))

(defn foo [num]
  (Foo. num))

This is the idiomatic way to write Clojure code, and if you read the .java
files in Clojure you'll see that they are laid out the same way. Many
classes have a static create function that does the actual data
processing, while the constructors do simple assignment. So what's so great
about all this? To the OOP programmer you would see this as an interface,
a object with a overriding member, and a factory function. But this is
simply not the case. What we are defining, is a collection of polymorphic
functions (IFoo), a data-structure that installs a function into this
polymorphic function, and a constructor function.

So even here, where there appears to be OOP style abstractions and
conventions, it's really just syntactic sugar over FP code. Clojure is less
of a OOP language than most people realize.

Timothy

-- 
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: record constructor

On Sat, Aug 4, 2012 at 6:33 PM, Warren Lynn wrn.l...@gmail.com wrote:
 As difficult as you can see why I keep coming up crazy OO-like proposals, I
 am also puzzled by the seemingly OO-phobia in the community.

I don't think it is OO-phobia. I think a lot of people here have
used (several) OO languages and just find the FP way better - or at
least better for the problems they are solving.

 Also, the proposal here is not FP vs imperative. The created object is
 still immutable, and does not violate any FP principles.

 As of going through FP, after some time, I started see certain benefits of
 FP, but I see nothing saying FP cannot use some ideas in OO.

The question here seems to be whether integrating the factory function
into the record itself brings sufficient benefits to change the
language - or whether the record concept and the factory concept
should remain separate. It seems to me that the latter approach is
simpler: two distinct concepts that can be combined if needed or used
separately if desired.

One of Clojure's design goals is simplicity. Keeping functions and
data separate seems in keeping with that.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Strange coercions...

Post your project.clj. I suspect you have a symbol name where you
should have a string...

On Sat, Aug 4, 2012 at 6:42 PM, Pierre-Henry Perret phper...@gmail.com wrote:

 Running a codelein2 check/code gives -
 ___
 Exception in thread main java.lang.IllegalArgumentException: No
 implementation of method: :as-file of protocol: #'clojure.java.io/Coercions
 found for class: c
 lojure.lang.PersistentVector
 _

 I would my precate my lein1 project becoming a lein2 one ..

 Someone has an idea ?

-- 
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: Question about sets

On Sat, Aug 4, 2012 at 6:43 PM, Mark Engelberg mark.engelb...@gmail.com wrote:
 What is the reasoning behind the design decision that this generates an
 error:
 (let [a :x b :x] #{a b})
 rather than just returning #{:x} ?

My first reaction was that literals have to obey the rules of the
underlying type or else they are not valid literals:

#{1 2 1} ;; error
{:x 1 :y 2 :x 3} ;; error

I hadn't even thought of using the set literal syntax with variables
that might not have unique value. I guess I'd ask: why not use the set
function?

(let [a :x b :x] (set [a b])) ;; #{:x}
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Strange coercions

More precisely:
___
 Unsupported character: \\-



Le dimanche 5 août 2012 03:45:59 UTC+2, Pierre-Henry Perret a écrit :

 Running a codelein2 check/code gives -
 ___
 Exception in thread main java.lang.IllegalArgumentException: No 
 implementation of method: :as-file of protocol: #'
 clojure.java.io/Coercions found for class: c
 lojure.lang.PersistentVector
 _

 I would precate my lein1 project becoming a lein2 one ..

 Someone has an idea ?
 Thanks


-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: record constructor



On Saturday, August 4, 2012 9:57:55 PM UTC-4, tbc++ wrote:

 Warren, I can't speak for others, but I can say that personally one of the 
 reasons I love Clojure so much is that it doesn't try to be a OOP language, 
 instead it cleanly separates data from logic. Clojure is not a OOP language 
 and (hopefully) will never attempt to be so. 


I don't think OOP and non-OOP is so clear cut. I am just saying, OOP in the 
field consists various ideas and patterns, and we can borrow the good part. 
This also comes from my bielief that languages is for providing 
abstractions and patterns (hence the all-mighty all-freedom assembly is not 
a good language because it provides no abstraction and patterns), and it is 
hard for me to believe OOP is just a bag of all bad patterns collected by 
stupid people. It can not be all good (or suitable in our case) either of 
course.

But this separation of logic and data should be very, very carefully 
 examined. Here's an example:

 (defprotocol IFoo
   (foo-func [this]))

 (defrecord Foo [num]
   IFoo
   (foo-func [this] num))

 (defn foo [num]
   (Foo. num))

 This is the idiomatic way to write Clojure code, and if you read the .java 
 files in Clojure you'll see that they are laid out the same way. Many 
 classes have a static create function that does the actual data 
 processing, while the constructors do simple assignment. So what's so great 
 about all this? To the OOP programmer you would see this as an interface, 
 a object with a overriding member, and a factory function. But this is 
 simply not the case. What we are defining, is a collection of polymorphic 
 functions (IFoo), a data-structure that installs a function into this 
 polymorphic function, and a constructor function. 

 So even here, where there appears to be OOP style abstractions and 
 conventions, it's really just syntactic sugar over FP code. Clojure is less 
 of a OOP language than most people realize. 

  
Well, I like sugars! You can call my proposal as syntatic sugars too if it 
is included in the language. I don't really care how it is implemented 
under the hood. I care about the abstraction and patterns.
 

 Timothy




 

-- 
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: record constructor



I don't think it is OO-phobia. I think a lot of people here have 
 used (several) OO languages and just find the FP way better - or at 
 least better for the problems they are solving. 


If I am proposing something like state-mutation based OOP, that clearly 
conflicts with FP and I will just find another lanugage to work with. FP 
itself, which although I am still ajusting to, does not seem like a problem 
to me so I sitll have interest to work with it. Again I don't think the 
proposal here conflict with FP. It is still FP even with the constructors, 
isn't it?
 

  Also, the proposal here is not FP vs imperative. The created object is 
  still immutable, and does not violate any FP principles. 
  
  As of going through FP, after some time, I started see certain benefits 
 of 
  FP, but I see nothing saying FP cannot use some ideas in OO. 

 The question here seems to be whether integrating the factory function 
 into the record itself brings sufficient benefits to change the 
 language - or whether the record concept and the factory concept 
 should remain separate. It seems to me that the latter approach is 
 simpler: two distinct concepts that can be combined if needed or used 
 separately if desired. 

 One of Clojure's design goals is simplicity. Keeping functions and 
 data separate seems in keeping with that. 


Simplicity is good, only when it is not too simple. Factory functions 
denitely have its value, but for more dynamic cases (so you may even create 
different record types based on the arguments). For static cases, why 
scatter the factory functions here and there with certain name conventions 
people may or may not follow? If they both achieve the same functionality, 
don't you think grouping them in one place, with fixed naming pattern is 
better? I thought OOP people long figured that 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

Re: record constructor

On Sat, Aug 4, 2012 at 8:33 PM, Warren Lynn wrn.l...@gmail.com wrote:
 Simplicity is good, only when it is not too simple. Factory functions
 denitely have its value, but for more dynamic cases (so you may even create
 different record types based on the arguments). For static cases, why
 scatter the factory functions here and there with certain name conventions
 people may or may not follow? If they both achieve the same functionality,
 don't you think grouping them in one place, with fixed naming pattern is
 better? I thought OOP people long figured that out.

My point was that you don't need a factory function if there's no
construction logic so the record alone - the data structure - is
sufficient for a lot of cases. Similarly you can choose to use a
factory function even if the underlying data structure is not a
record. They are separate concepts and can be used in isolation.
Simple, composable, you write just the code you need, no more.

As Timothy pointed out, it's just functions and data, not objects. I
think the fact that you can use defrecord to implement a Java
interface is a bit misleading because it looks like a class
implementation (and of course because it targets the JVM, the actual
implementation _is_ a class) - when it's really just a data structure
with some associated functions that operate on it.

I hope that at least makes my position a bit clearer?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Strange coercions