Re: Unable to call the method when it clearly exists..

[James Reeves]

Yeah, from the docs

it
looks like parquet takes a string varargs, rather than just a string. Maybe
that's what the "<>" on the end of "java.lang.String" means?

- James

On 13 May 2016 at 05:52, Sunil S Nandihalli 
wrote:

> I was able to get over this problem by doing one of the following two ways
> of calling "parquet" function.
>
> (. inp-rdr (parquet (into-array java.lang.String [parq-path])))
> (. inp-rdr (parquet (-> [parq-path] JavaConversions/asScalaBuffer
> .toList)))
>
> On Fri, May 13, 2016 at 10:01 AM, Sunil S Nandihalli <
> sunil.nandiha...@gmail.com> wrote:
>
>> Just to add to the previous email,
>> I have also tried
>>
>> (. inp-rdr-s (parquet (to-array '(parq-path))
>>
>> but got the same error.
>> Thanks
>> Sunil.
>>
>> On Fri, May 13, 2016 at 9:55 AM, Sunil S Nandihalli <
>> sunil.nandiha...@gmail.com> wrote:
>>
>>> Hi everybody,
>>>  I am trying to call function "parquet" on the var "inp-rdr-s". From the
>>> following reflection output using clojure.reflect, it is clear that the
>>> method parquet exists. However I am unable to call the function. Can
>>> somebody help?
>>> Thanks and regards,
>>> Sunil
>>>
>>> bidland.core> (def parq-path
>>> "/home/hdfs/sunil/dl4j/bidland/tmp/sunil-bidland-data/part-r-0.parquet")
>>> #'bidland.core/parq-path
>>> bidland.core> (pp/pprint (filter  #(= 'parquet (:name %)) (:members
>>> (r/reflect (class inp-rdr-s)
>>> ({:name parquet,
>>>   :return-type org.apache.spark.sql.DataFrame,
>>>   :declaring-class org.apache.spark.sql.DataFrameReader,
>>>   :parameter-types [java.lang.String<>],
>>>   :exception-types [],
>>>   :flags #{:varargs :public}}
>>>  {:name parquet,
>>>   :return-type org.apache.spark.sql.DataFrame,
>>>   :declaring-class org.apache.spark.sql.DataFrameReader,
>>>   :parameter-types [scala.collection.Seq],
>>>   :exception-types [],
>>>   :flags #{:public}})
>>> nil
>>> bidland.core> (. inp-rdr-s (parquet parq-path))
>>> IllegalArgumentException No matching method found: parquet for class
>>> org.apache.spark.sql.DataFrameReader
>>>  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:80)
>>> bidland.core>
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Unable to call the method when it clearly exists..

[Sunil S Nandihalli]

I was able to get over this problem by doing one of the following two ways
of calling "parquet" function.

(. inp-rdr (parquet (into-array java.lang.String [parq-path])))
(. inp-rdr (parquet (-> [parq-path] JavaConversions/asScalaBuffer .toList)))

On Fri, May 13, 2016 at 10:01 AM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Just to add to the previous email,
> I have also tried
>
> (. inp-rdr-s (parquet (to-array '(parq-path))
>
> but got the same error.
> Thanks
> Sunil.
>
> On Fri, May 13, 2016 at 9:55 AM, Sunil S Nandihalli <
> sunil.nandiha...@gmail.com> wrote:
>
>> Hi everybody,
>>  I am trying to call function "parquet" on the var "inp-rdr-s". From the
>> following reflection output using clojure.reflect, it is clear that the
>> method parquet exists. However I am unable to call the function. Can
>> somebody help?
>> Thanks and regards,
>> Sunil
>>
>> bidland.core> (def parq-path
>> "/home/hdfs/sunil/dl4j/bidland/tmp/sunil-bidland-data/part-r-0.parquet")
>> #'bidland.core/parq-path
>> bidland.core> (pp/pprint (filter  #(= 'parquet (:name %)) (:members
>> (r/reflect (class inp-rdr-s)
>> ({:name parquet,
>>   :return-type org.apache.spark.sql.DataFrame,
>>   :declaring-class org.apache.spark.sql.DataFrameReader,
>>   :parameter-types [java.lang.String<>],
>>   :exception-types [],
>>   :flags #{:varargs :public}}
>>  {:name parquet,
>>   :return-type org.apache.spark.sql.DataFrame,
>>   :declaring-class org.apache.spark.sql.DataFrameReader,
>>   :parameter-types [scala.collection.Seq],
>>   :exception-types [],
>>   :flags #{:public}})
>> nil
>> bidland.core> (. inp-rdr-s (parquet parq-path))
>> IllegalArgumentException No matching method found: parquet for class
>> org.apache.spark.sql.DataFrameReader
>>  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:80)
>> bidland.core>
>>
>
>

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

Re: I knew that primitives were better, but this is ridiculous

[James Reeves]

If we want improve lookup performance in a SQL database, we place an index
on a column, or a group of columns. The same idea can be applied to a data
structure we keep in memory.

So if you know that you want to lookup entities by position and velocity,
you could have an indexing function like:

  (fn [index entity]
(when (and (:position entity) (:velocity entity))
  (assoc-in index [:mobile (:id entity)] entity)))

And then you just need a way to run that index each time an entity is added
to your in-memory database. Naturally you'd also need a "unindex" function
as well.

I've written a game library called Ittyon that works along these lines.

- James


On 13 May 2016 at 00:31, JvJ  wrote:

> I'm intrigued, but I don't know exactly what you mean.
>
> On Thursday, 12 May 2016 16:25:05 UTC-7, James Reeves wrote:
>>
>> Have you considered defining specific indexes? For instance, if you know
>> ahead of time that you want to search for entities that have both position
>> and velocity, you could define an index that keys both of those values.
>>
>> - James
>>
>>
>>
>> On 12 May 2016 at 23:50, JvJ  wrote:
>>
>>> Maybe this is a little off-topic, but on the general topic of
>>> performance, other than just numerical performance, what's the best way to
>>> get information/advice on how to improve it.
>>>
>>> I went about doing these tests (and other tests) because I'm trying to
>>> create a game scripting framework in clojure, which I want to build around
>>> an entity-component-system architecture.  Entities are maps of
>>> components, and system functions are defined to sort of "pattern match"
>>> against
>>> entities to see if they have the required components.  (i.e. an
>>> update-position function would add velocity to position, so it only applies
>>> to entities
>>> with both a position and a velocity component).
>>>
>>> The first step in this process is to find a way to store these so that
>>> it would be as fast as possible to iterate over "all entities with this set
>>> of components",
>>> while avoiding things like filter operations.
>>>
>>> I started off by making cross-map ,
>>> which cross-indexes any entries with keys of the form [r c], where r is a
>>> row and c is a column, and allows O(1) access
>>> of entire rows and columns.
>>>
>>> Still, though, the performance tests
>>> 
>>> aren't what I expected they would be, and I'm wondering how to go about
>>> dealing with that.
>>>
>>> Again, this isn't strictly about numerical performance, but it's why I'm
>>> doing these kinds of tests in the first place.
>>>
>>> Thanks.
>>>
>>> On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:

 On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto 
 wrote:
 > Fair enough, but in this case types wouldn't really have helped: the
 author did use `Double` type hints, mistakenly assuming that would make its
 code use primitive types, which it does not since `Double` is boxed and not
 primitive.
 > Clojure already has compile time warnings about boxed math that
 would've helped in this case if turned on, without any need for types: try
 compiling OP's code after running `(set! *unchecked-math* :warn-on-boxed)`

 Thanks for the details re: double. Apologies for being annoyed/ing.

 Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We
 can relive the ignominious history of "$!" in Haskell.

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: Unable to call the method when it clearly exists..

[Sunil S Nandihalli]

Just to add to the previous email,
I have also tried

(. inp-rdr-s (parquet (to-array '(parq-path))

but got the same error.
Thanks
Sunil.

On Fri, May 13, 2016 at 9:55 AM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hi everybody,
>  I am trying to call function "parquet" on the var "inp-rdr-s". From the
> following reflection output using clojure.reflect, it is clear that the
> method parquet exists. However I am unable to call the function. Can
> somebody help?
> Thanks and regards,
> Sunil
>
> bidland.core> (def parq-path
> "/home/hdfs/sunil/dl4j/bidland/tmp/sunil-bidland-data/part-r-0.parquet")
> #'bidland.core/parq-path
> bidland.core> (pp/pprint (filter  #(= 'parquet (:name %)) (:members
> (r/reflect (class inp-rdr-s)
> ({:name parquet,
>   :return-type org.apache.spark.sql.DataFrame,
>   :declaring-class org.apache.spark.sql.DataFrameReader,
>   :parameter-types [java.lang.String<>],
>   :exception-types [],
>   :flags #{:varargs :public}}
>  {:name parquet,
>   :return-type org.apache.spark.sql.DataFrame,
>   :declaring-class org.apache.spark.sql.DataFrameReader,
>   :parameter-types [scala.collection.Seq],
>   :exception-types [],
>   :flags #{:public}})
> nil
> bidland.core> (. inp-rdr-s (parquet parq-path))
> IllegalArgumentException No matching method found: parquet for class
> org.apache.spark.sql.DataFrameReader
>  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:80)
> bidland.core>
>

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

Unable to call the method when it clearly exists..

[Sunil S Nandihalli]

Hi everybody,
 I am trying to call function "parquet" on the var "inp-rdr-s". From the
following reflection output using clojure.reflect, it is clear that the
method parquet exists. However I am unable to call the function. Can
somebody help?
Thanks and regards,
Sunil

bidland.core> (def parq-path
"/home/hdfs/sunil/dl4j/bidland/tmp/sunil-bidland-data/part-r-0.parquet")
#'bidland.core/parq-path
bidland.core> (pp/pprint (filter  #(= 'parquet (:name %)) (:members
(r/reflect (class inp-rdr-s)
({:name parquet,
  :return-type org.apache.spark.sql.DataFrame,
  :declaring-class org.apache.spark.sql.DataFrameReader,
  :parameter-types [java.lang.String<>],
  :exception-types [],
  :flags #{:varargs :public}}
 {:name parquet,
  :return-type org.apache.spark.sql.DataFrame,
  :declaring-class org.apache.spark.sql.DataFrameReader,
  :parameter-types [scala.collection.Seq],
  :exception-types [],
  :flags #{:public}})
nil
bidland.core> (. inp-rdr-s (parquet parq-path))
IllegalArgumentException No matching method found: parquet for class
org.apache.spark.sql.DataFrameReader
 clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:80)
bidland.core>

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

Re: apply madness

[Mike Rodriguez]

Vectors are eager. So they'd need to be finite. Varargs/rest args can be 
infinite lazy sequences. So it is appropriate that they are just generic "seq" 
abstractions instead of something specific (and eager) like a vector. 

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

Re: I knew that primitives were better, but this is ridiculous

[JvJ]

I'm intrigued, but I don't know exactly what you mean.

On Thursday, 12 May 2016 16:25:05 UTC-7, James Reeves wrote:
>
> Have you considered defining specific indexes? For instance, if you know 
> ahead of time that you want to search for entities that have both position 
> and velocity, you could define an index that keys both of those values.
>
> - James
>
>
>
> On 12 May 2016 at 23:50, JvJ  wrote:
>
>> Maybe this is a little off-topic, but on the general topic of 
>> performance, other than just numerical performance, what's the best way to 
>> get information/advice on how to improve it.
>>
>> I went about doing these tests (and other tests) because I'm trying to 
>> create a game scripting framework in clojure, which I want to build around
>> an entity-component-system architecture.  Entities are maps of 
>> components, and system functions are defined to sort of "pattern match" 
>> against
>> entities to see if they have the required components.  (i.e. an 
>> update-position function would add velocity to position, so it only applies 
>> to entities
>> with both a position and a velocity component).
>>
>> The first step in this process is to find a way to store these so that it 
>> would be as fast as possible to iterate over "all entities with this set of 
>> components",
>> while avoiding things like filter operations.
>>
>> I started off by making cross-map , 
>> which cross-indexes any entries with keys of the form [r c], where r is a 
>> row and c is a column, and allows O(1) access
>> of entire rows and columns.
>>
>> Still, though, the performance tests 
>>  
>> aren't what I expected they would be, and I'm wondering how to go about 
>> dealing with that.
>>
>> Again, this isn't strictly about numerical performance, but it's why I'm 
>> doing these kinds of tests in the first place.
>>
>> Thanks.
>>
>> On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>>>
>>> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto  
>>> wrote: 
>>> > Fair enough, but in this case types wouldn't really have helped: the 
>>> author did use `Double` type hints, mistakenly assuming that would make its 
>>> code use primitive types, which it does not since `Double` is boxed and not 
>>> primitive. 
>>> > Clojure already has compile time warnings about boxed math that 
>>> would've helped in this case if turned on, without any need for types: try 
>>> compiling OP's code after running `(set! *unchecked-math* :warn-on-boxed)` 
>>>
>>> Thanks for the details re: double. Apologies for being annoyed/ing. 
>>>
>>> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We 
>>> can relive the ignominious history of "$!" in Haskell. 
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: I knew that primitives were better, but this is ridiculous

[James Reeves]

Have you considered defining specific indexes? For instance, if you know
ahead of time that you want to search for entities that have both position
and velocity, you could define an index that keys both of those values.

- James



On 12 May 2016 at 23:50, JvJ  wrote:

> Maybe this is a little off-topic, but on the general topic of performance,
> other than just numerical performance, what's the best way to get
> information/advice on how to improve it.
>
> I went about doing these tests (and other tests) because I'm trying to
> create a game scripting framework in clojure, which I want to build around
> an entity-component-system architecture.  Entities are maps of components,
> and system functions are defined to sort of "pattern match" against
> entities to see if they have the required components.  (i.e. an
> update-position function would add velocity to position, so it only applies
> to entities
> with both a position and a velocity component).
>
> The first step in this process is to find a way to store these so that it
> would be as fast as possible to iterate over "all entities with this set of
> components",
> while avoiding things like filter operations.
>
> I started off by making cross-map ,
> which cross-indexes any entries with keys of the form [r c], where r is a
> row and c is a column, and allows O(1) access
> of entire rows and columns.
>
> Still, though, the performance tests
> 
> aren't what I expected they would be, and I'm wondering how to go about
> dealing with that.
>
> Again, this isn't strictly about numerical performance, but it's why I'm
> doing these kinds of tests in the first place.
>
> Thanks.
>
> On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>>
>> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto 
>> wrote:
>> > Fair enough, but in this case types wouldn't really have helped: the
>> author did use `Double` type hints, mistakenly assuming that would make its
>> code use primitive types, which it does not since `Double` is boxed and not
>> primitive.
>> > Clojure already has compile time warnings about boxed math that
>> would've helped in this case if turned on, without any need for types: try
>> compiling OP's code after running `(set! *unchecked-math* :warn-on-boxed)`
>>
>> Thanks for the details re: double. Apologies for being annoyed/ing.
>>
>> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We
>> can relive the ignominious history of "$!" in Haskell.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: I knew that primitives were better, but this is ridiculous

[JvJ]

Maybe this is a little off-topic, but on the general topic of performance, 
other than just numerical performance, what's the best way to get 
information/advice on how to improve it.

I went about doing these tests (and other tests) because I'm trying to 
create a game scripting framework in clojure, which I want to build around
an entity-component-system architecture.  Entities are maps of components, 
and system functions are defined to sort of "pattern match" against
entities to see if they have the required components.  (i.e. an 
update-position function would add velocity to position, so it only applies 
to entities
with both a position and a velocity component).

The first step in this process is to find a way to store these so that it 
would be as fast as possible to iterate over "all entities with this set of 
components",
while avoiding things like filter operations.

I started off by making cross-map , which 
cross-indexes any entries with keys of the form [r c], where r is a row and 
c is a column, and allows O(1) access
of entire rows and columns.

Still, though, the performance tests 
 
aren't what I expected they would be, and I'm wondering how to go about 
dealing with that.

Again, this isn't strictly about numerical performance, but it's why I'm 
doing these kinds of tests in the first place.

Thanks.

On Thursday, 12 May 2016 15:23:07 UTC-7, raould wrote:
>
> On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto  > wrote: 
> > Fair enough, but in this case types wouldn't really have helped: the 
> author did use `Double` type hints, mistakenly assuming that would make its 
> code use primitive types, which it does not since `Double` is boxed and not 
> primitive. 
> > Clojure already has compile time warnings about boxed math that would've 
> helped in this case if turned on, without any need for types: try compiling 
> OP's code after running `(set! *unchecked-math* :warn-on-boxed)` 
>
> Thanks for the details re: double. Apologies for being annoyed/ing. 
>
> Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We 
> can relive the ignominious history of "$!" in Haskell. 
>

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

Re: I knew that primitives were better, but this is ridiculous

[Raoul Duke]

On Thu, May 12, 2016 at 3:11 PM, Nicola Mometto  wrote:
> Fair enough, but in this case types wouldn't really have helped: the author 
> did use `Double` type hints, mistakenly assuming that would make its code use 
> primitive types, which it does not since `Double` is boxed and not primitive.
> Clojure already has compile time warnings about boxed math that would've 
> helped in this case if turned on, without any need for types: try compiling 
> OP's code after running `(set! *unchecked-math* :warn-on-boxed)`

Thanks for the details re: double. Apologies for being annoyed/ing.

Next up: something like `(set! *unchecked-laziness* :warn-on-lazy)? We
can relive the ignominious history of "$!" in Haskell.

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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

I generally agree with this suggestion, I just want to point out that, if 
incorporated with your previous suggestion of using `double` primitive type 
hints, using `.-x` vs `:x` to acess the field will make a difference: the 
former will access the primitive field while the latter will cause it to get 
boxed

> On 12 May 2016, at 21:23, Alex Miller  wrote:
> 
> In general, it is considered bad form to use the java interop features to 
> construct or access fields of a record. Preferred:
> 
> (defn rv+
>   [v1 v2]
>   (->v2r (+ (:x v1) (:x v2))
>  (+ (:y v1) (:y v2
> 

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: I knew that primitives were better, but this is ridiculous

[JvJ]

I've tried core.typed a few times, but I always find it too difficult to 
work with.

On Thursday, 12 May 2016 15:05:50 UTC-7, raould wrote:
>
> On Thu, May 12, 2016 at 2:59 PM, Nicola Mometto  > wrote: 
> > Static types wouln't have helped at all in this case. Types are about 
> correctness, not performances. This comment was needless 
>
> Here I thought maybe knowing when something was or was not something 
> could have been useful in, you know, making the code (benchmarks in 
> this case) actually do what the author wanted it to be doing. Silly 
> me. 
>
> I will always have my fingers crossed for core.typed. :-) 
>

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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Fair enough, but in this case types wouldn't really have helped: the author did 
use `Double` type hints, mistakenly assuming that would make its code use 
primitive types, which it does not since `Double` is boxed and not primitive.
Clojure already has compile time warnings about boxed math that would've helped 
in this case if turned on, without any need for types: try compiling OP's code 
after running `(set! *unchecked-math* :warn-on-boxed)`


> On 12 May 2016, at 23:05, Raoul Duke  wrote:
> 
> On Thu, May 12, 2016 at 2:59 PM, Nicola Mometto  wrote:
>> Static types wouln't have helped at all in this case. Types are about 
>> correctness, not performances. This comment was needless
> 
> Here I thought maybe knowing when something was or was not something
> could have been useful in, you know, making the code (benchmarks in
> this case) actually do what the author wanted it to be doing. Silly
> me.
> 
> I will always have my fingers crossed for core.typed. :-)
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: I knew that primitives were better, but this is ridiculous

[Raoul Duke]

On Thu, May 12, 2016 at 2:59 PM, Nicola Mometto  wrote:
> Static types wouln't have helped at all in this case. Types are about 
> correctness, not performances. This comment was needless

Here I thought maybe knowing when something was or was not something
could have been useful in, you know, making the code (benchmarks in
this case) actually do what the author wanted it to be doing. Silly
me.

I will always have my fingers crossed for core.typed. :-)

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

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Static types wouln't have helped at all in this case. Types are about 
correctness, not performances. This comment was needless


> On 12 May 2016, at 22:52, Raoul Duke  wrote:
> 
> 
> y'know, if only there were something, i dunno, something static that
> could you know have some, i dunno, 'types' that would help annotate
> things such that at maybe compile time, we'd know if the things we're
> handling are lazy or boxed or whatever-else or not.
> 
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Not necessarily, when combined with functions that take a variable number of 
arguments.
Example:

user=> (do (apply concat () (range)) nil)
nil

If apply did realize the range lazy sequence, that form would never terminate 
rather than returning nil.

In your case however memory failed me and I was mistaken: it actually *does* 
realize the sequence because `list` eagerly iterates over the argument list 
rather than constructing it lazily.

Ignore my point about the overhead of creating the *-list lazy sequences, 
everything else still stands

> On 12 May 2016, at 22:40, JvJ  wrote:
> 
> I was under the impression that the call to "apply list" would realize the 
> lazy sequences beforehand.
> 

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: I knew that primitives were better, but this is ridiculous

[Raoul Duke]

y'know, if only there were something, i dunno, something static that
could you know have some, i dunno, 'types' that would help annotate
things such that at maybe compile time, we'd know if the things we're
handling are lazy or boxed or whatever-else or not.


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

changing metadata questions

[hiskennyness]

It occurred to me that the game I was playing shunting initargs off into a 
"raw" key of one name or another before converting them into a map might 
more comprehensibly be done by treating the raw values (and other 
attributes I use to manage these beasts) as metadata. But I need to update 
the metadata during the life of my creation. So...

I found alter-meta!, and it seems perfect. Working from one of the doc 
examples:
 

> (def ^{:version 1} doc2 "This is text")
> (alter-meta! #'doc2 #(assoc-in % [:version] 17)) 
> (meta #'doc2)

;; => {:version 17}
>

Great! But this more realistic example throws an  inscrutable error:

(let [x (with-meta {:a 42}
>   {:raw 17})]
>   (alter-meta! x #(update-in % [:raw] inc))
>   (meta x))


Fine. The doc clearly advertises "Atomically sets the metadata for a 
namespace/var/ref/agent/atom"

OK, I am working with refs, let's do it!:

(let [x (with-meta (ref {:a 42})
> {:raw 17})]
>(alter-meta! x #(update-in % [:raw] inc))
>(meta x))


Nope. IRef cannot be cast to IObj. ...google...google... Hunh? The :meta 
option on ref? 

[1] Why the special mechanism? 

Well, when in Rome...:

(let [x (ref {:a 42}
>  :meta {:m 17})]
>   (alter-meta! x #(assoc-in % [:m] 64))
>   (meta x))
> ;; => {:m 64}


Booyow!

The bad news is that the metadata is about the map, not the ref. The two 
are meant to be inseparable (so no worries about copying the map and losing 
the metadata) but what happens in re synchronization? 

[2] If I modify the map inside the ref and the ref's metadata at the same 
time, will the latter "stick" even if the former gets rolled back?

-hk




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

Re: I knew that primitives were better, but this is ridiculous

[JvJ]

>
>
> The first benchmark is the slowest of all because it's: 
> - realizing the nums lazy sequence 
> - realizing the vpairs lazy sequence 
> - destructuring a vector 
> - creating and realizing a lazy sequene of record types 
> - only then benchmarking the reduce operation. 


I was under the impression that the call to "apply list" would realize the 
lazy sequences beforehand.


On Thursday, 12 May 2016 13:09:57 UTC-7, Nicola Mometto wrote:
>
> Those benchmarks are flawed and you're not testing what you think you are. 
>
> The first benchmark is the slowest of all because it's: 
> - realizing the nums lazy sequence 
> - realizing the vpairs lazy sequence 
> - destructuring a vector 
> - creating and realizing a lazy sequene of record types 
> - only then benchmarking the reduce operation. 
>
> In the second benchmark you're still benchmarking the destructuring of 
> vector pairs and the creation and realization of a lazy sequence of types 
> The third benchmark is like the second in that you're creating and 
> realizing a lazy sequence but it's slightly faster than the second one 
> because you're not including destructuring in the mix 
> The last benchmark is the fastest of all because you're just iterating 
> over an already realized sequence. 
>
> In no benchmark you're actually using any primitive types, you're always 
> using boxed Doubles 
>
> > On 12 May 2016, at 20:58, JvJ  wrote: 
> > 
> > I've been doing some performance tests on various floating point 
> operations.  In particular, I wanted to check what would be the fastest way 
> to implement a 2-d floating point vector in clojure. 
> > 
> > Here's my tests: 
> > 
> > ;;; V+ Tests 
> > ;;; Implementing floating-point vectors as: 
> > ;;; structs, deftype, vector 
> > (defrecord v2r 
> > [^Double x ^Double y]) 
> > 
> > (defn rv+ 
> >   [^v2r v1 ^v2r v2] 
> >   (v2r. (+ (.x v1) (.x v2)) 
> > (+ (.y v1) (.y v2 
> > 
> > (deftype v2t 
> > [^Double x ^Double y]) 
> > 
> > (defn tv+ 
> >   [^v2t v1 ^v2t v2] 
> >   (v2t. (+ (.x v1) (.x v2)) 
> > (+ (.y v1) (.y v2 
> > 
> > (defn vv+ 
> >   [v1 v2] 
> >   (mapv + v1 v2)) 
> > 
> > 
> > (defn testvecs 
> >   "Tests the vector add operations by reducing a 
> >   random list by each of the v+ operations on 
> >   identical sets of random vectors" 
> >   [n] 
> >   (let [nums (repeatedly (* 2 n) rand) 
> > vpairs (partition 2 nums) 
> > v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs)) 
> > v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs)) 
> > v2v-list (apply list (map vec vpairs))] 
> > (println "V2 Record:") 
> > (bench (reduce rv+ v2r-list)) 
> > (println "V2 Type:") 
> > (bench (reduce tv+ v2t-list)) 
> > (println "V2 Vector:") 
> > (bench (reduce vv+ v2v-list)) 
> > (println "Just Doubles:") 
> > (bench (reduce + nums 
> > 
> > 
> >  Here's my output: 
> > 
> > V2 Record: 
> > Evaluation count : 420 in 60 samples of 7 calls. 
> >  Execution time mean : 164.379725 ms 
> > Execution time std-deviation : 4.478128 ms 
> >Execution time lower quantile : 149.546749 ms ( 2.5%) 
> >Execution time upper quantile : 172.317132 ms (97.5%) 
> >Overhead used : 1.873322 ns 
> > 
> > Found 8 outliers in 60 samples (13. %) 
> > low-severe 4 (6.6667 %) 
> > low-mild 3 (5. %) 
> > high-mild 1 (1.6667 %) 
> >  Variance from outliers : 14.2105 % Variance is moderately inflated by 
> outliers 
> > V2 Type: 
> > Evaluation count : 1860 in 60 samples of 31 calls. 
> >  Execution time mean : 32.238857 ms 
> > Execution time std-deviation : 2.331682 ms 
> >Execution time lower quantile : 26.769206 ms ( 2.5%) 
> >Execution time upper quantile : 35.318368 ms (97.5%) 
> >Overhead used : 1.873322 ns 
> > 
> > Found 8 outliers in 60 samples (13. %) 
> > low-severe 5 (8. %) 
> > low-mild 3 (5. %) 
> >  Variance from outliers : 53.4940 % Variance is severely inflated by 
> outliers 
> > V2 Vector: 
> > Evaluation count : 2040 in 60 samples of 34 calls. 
> >  Execution time mean : 30.175015 ms 
> > Execution time std-deviation : 3.870306 ms 
> >Execution time lower quantile : 21.877116 ms ( 2.5%) 
> >Execution time upper quantile : 37.668717 ms (97.5%) 
> >Overhead used : 1.873322 ns 
> > 
> > Found 10 outliers in 60 samples (16.6667 %) 
> > low-severe 5 (8. %) 
> > low-mild 2 (3. %) 
> > high-mild 3 (5. %) 
> >  Variance from outliers : 78.9869 % Variance is severely inflated by 
> outliers 
> > Just Doubles: 
> > Evaluation count : 20640 in 60 samples of 344 calls. 
> >  Execution time mean : 4.309871 ms 
> > Execution time std-deviation : 537.444033 µs 
> >Execution time lower 

Re: understanding a clojuredocs merge example

[hiskennyness]

On Thursday, May 12, 2016 at 9:33:29 AM UTC-4, Michael Willis wrote:
>
> As long as we're cutting out unnecessary code, this is also equivalent:
>
> (defn baz [options]
>(merge {:opt1 "default-1" :opt2 "default-2"} options))
>
>
Heh-heh, I was going to point that out. And now baz is a crippled form of 
merge. 

Good examples are tough!


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

Re: I knew that primitives were better, but this is ridiculous

[Alex Miller]

Bunch of comments here inline below...


On Thursday, May 12, 2016 at 2:58:29 PM UTC-5, JvJ wrote:
>
> I've been doing some performance tests on various floating point 
> operations.  In particular, I wanted to check what would be the fastest way 
> to implement a 2-d floating point vector in clojure.
>
> Here's my tests:
>
> ;;; V+ Tests
> ;;; Implementing floating-point vectors as:
> ;;; structs, deftype, vector
> (defrecord v2r
> [^Double x ^Double y])
>
>
These type hints don't actually do much for you - the record will always 
have field of type Object. The one exception to this are the two primitive 
type hints ^double and ^long - using ^double here would help you. Type 
hints on a record field type do assist with type inference for methods 
declared inside the record (but you don't have those).

(defn rv+
>   [^v2r v1 ^v2r v2]
>   (v2r. (+ (.x v1) (.x v2))
> (+ (.y v1) (.y v2
>
>
In general, it is considered bad form to use the java interop features to 
construct or access fields of a record. Preferred:

(defn rv+
  [v1 v2]
  (->v2r (+ (:x v1) (:x v2))
 (+ (:y v1) (:y v2


> (deftype v2t
> [^Double x ^Double y])
>
>
Ditto above - primitive type hints would help.
 

>
> (defn tv+
>   [^v2t v1 ^v2t v2]
>   (v2t. (+ (.x v1) (.x v2))
> (+ (.y v1) (.y v2
>
>
Ditto above although keyword accessors are not provided with deftypes. If 
you are accessing fields directly, use .- to indicate field access.

(defn tv+
  [^v2t v1 ^v2t v2]
  (->v2t. (+ (.-x v1) (.-x v2))
 (+ (.-y v1) (.-y v2

However, it's generally better to define an interface, then have the type 
v2t implement that interface. The other benefit of this is that the 
interface can specify primitive accessors and the type will implement them 
accordingly - this eliminates boxing on the accessors.

(definterface IV
  (^double getX [])
  (^double getY []))

(deftype v2t [^double x ^double y]
  IV
  (getX [] x)
  (getY [] y))
 

> (defn vv+
>   [v1 v2]
>   (mapv + v1 v2))
>
>
mapv (and any sequence or collection ops) use only boxed objects so this is 
going to foil all the carefully laid plans above. If you do the more manual 
path and type hint sufficiently (I'm not actually running any of this, so 
you may not actually need these hints here):

(defn vv+
  [^v2t v1 ^v2t v2]
  (->v2t (+ ^double (getX v1) ^double (getX v2))
(+ ^double (getY v1) ^double (getY v2



>
> (defn testvecs
>   "Tests the vector add operations by reducing a
>   random list by each of the v+ operations on
>   identical sets of random vectors"
>   [n]
>   (let [nums (repeatedly (* 2 n) rand)
> vpairs (partition 2 nums)
> v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs))
> v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs))
> v2v-list (apply list (map vec vpairs))]
> (println "V2 Record:")
> (bench (reduce rv+ v2r-list))
> (println "V2 Type:")
> (bench (reduce tv+ v2t-list))
> (println "V2 Vector:")
> (bench (reduce vv+ v2v-list))
> (println "Just Doubles:")
> (bench (reduce + nums
>
>
>
And some other options to compare beyond this are primitive vectors (see 
vector-of) which gives you the memory usage of arrays, but still boxes on 
use (for now! but maybe not forever) and of course Java arrays, which are 
how this is probably best done to prevent all boxing. 

And then there are libs like hiphip (https://github.com/plumatic/hiphip) 
for better working with arrays or core.matrix (for access to native vector 
math).

I suspect those paths will substantially improve perf, perhaps by 100x more 
than you're seeing even in your good numbers now.

 

>
>  Here's my output:
>
> *V2 Record:*
> Evaluation count : 420 in 60 samples of 7 calls.
>  Execution time mean : 164.379725 ms
> Execution time std-deviation : 4.478128 ms
>Execution time lower quantile : 149.546749 ms ( 2.5%)
>Execution time upper quantile : 172.317132 ms (97.5%)
>Overhead used : 1.873322 ns
>
> Found 8 outliers in 60 samples (13. %)
> low-severe 4 (6.6667 %)
> low-mild 3 (5. %)
> high-mild 1 (1.6667 %)
>  Variance from outliers : 14.2105 % Variance is moderately inflated by 
> outliers
> *V2 Type:*
> Evaluation count : 1860 in 60 samples of 31 calls.
>  Execution time mean : 32.238857 ms
> Execution time std-deviation : 2.331682 ms
>Execution time lower quantile : 26.769206 ms ( 2.5%)
>Execution time upper quantile : 35.318368 ms (97.5%)
>Overhead used : 1.873322 ns
>
> Found 8 outliers in 60 samples (13. %)
> low-severe 5 (8. %)
> low-mild 3 (5. %)
>  Variance from outliers : 53.4940 % Variance is severely inflated by 
> outliers
> *V2 Vector:*
> Evaluation count : 2040 in 60 samples of 34 calls.
>  Execution time mean : 30.175015 ms
> Execution time std-deviation : 3.870306 ms
>Execution time lower quantile : 21.877116 ms ( 

Re: I knew that primitives were better, but this is ridiculous

[Nicola Mometto]

Those benchmarks are flawed and you're not testing what you think you are.

The first benchmark is the slowest of all because it's:
- realizing the nums lazy sequence
- realizing the vpairs lazy sequence
- destructuring a vector
- creating and realizing a lazy sequene of record types
- only then benchmarking the reduce operation.

In the second benchmark you're still benchmarking the destructuring of vector 
pairs and the creation and realization of a lazy sequence of types
The third benchmark is like the second in that you're creating and realizing a 
lazy sequence but it's slightly faster than the second one because you're not 
including destructuring in the mix
The last benchmark is the fastest of all because you're just iterating over an 
already realized sequence.

In no benchmark you're actually using any primitive types, you're always using 
boxed Doubles

> On 12 May 2016, at 20:58, JvJ  wrote:
> 
> I've been doing some performance tests on various floating point operations.  
> In particular, I wanted to check what would be the fastest way to implement a 
> 2-d floating point vector in clojure.
> 
> Here's my tests:
> 
> ;;; V+ Tests
> ;;; Implementing floating-point vectors as:
> ;;; structs, deftype, vector
> (defrecord v2r
> [^Double x ^Double y])
> 
> (defn rv+
>   [^v2r v1 ^v2r v2]
>   (v2r. (+ (.x v1) (.x v2))
> (+ (.y v1) (.y v2
> 
> (deftype v2t
> [^Double x ^Double y])
> 
> (defn tv+
>   [^v2t v1 ^v2t v2]
>   (v2t. (+ (.x v1) (.x v2))
> (+ (.y v1) (.y v2
> 
> (defn vv+
>   [v1 v2]
>   (mapv + v1 v2))
> 
> 
> (defn testvecs
>   "Tests the vector add operations by reducing a
>   random list by each of the v+ operations on
>   identical sets of random vectors"
>   [n]
>   (let [nums (repeatedly (* 2 n) rand)
> vpairs (partition 2 nums)
> v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs))
> v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs))
> v2v-list (apply list (map vec vpairs))]
> (println "V2 Record:")
> (bench (reduce rv+ v2r-list))
> (println "V2 Type:")
> (bench (reduce tv+ v2t-list))
> (println "V2 Vector:")
> (bench (reduce vv+ v2v-list))
> (println "Just Doubles:")
> (bench (reduce + nums
> 
> 
>  Here's my output:
> 
> V2 Record:
> Evaluation count : 420 in 60 samples of 7 calls.
>  Execution time mean : 164.379725 ms
> Execution time std-deviation : 4.478128 ms
>Execution time lower quantile : 149.546749 ms ( 2.5%)
>Execution time upper quantile : 172.317132 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 8 outliers in 60 samples (13. %)
>   low-severe   4 (6.6667 %)
>   low-mild 3 (5. %)
>   high-mild1 (1.6667 %)
>  Variance from outliers : 14.2105 % Variance is moderately inflated by 
> outliers
> V2 Type:
> Evaluation count : 1860 in 60 samples of 31 calls.
>  Execution time mean : 32.238857 ms
> Execution time std-deviation : 2.331682 ms
>Execution time lower quantile : 26.769206 ms ( 2.5%)
>Execution time upper quantile : 35.318368 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 8 outliers in 60 samples (13. %)
>   low-severe   5 (8. %)
>   low-mild 3 (5. %)
>  Variance from outliers : 53.4940 % Variance is severely inflated by outliers
> V2 Vector:
> Evaluation count : 2040 in 60 samples of 34 calls.
>  Execution time mean : 30.175015 ms
> Execution time std-deviation : 3.870306 ms
>Execution time lower quantile : 21.877116 ms ( 2.5%)
>Execution time upper quantile : 37.668717 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 10 outliers in 60 samples (16.6667 %)
>   low-severe   5 (8. %)
>   low-mild 2 (3. %)
>   high-mild3 (5. %)
>  Variance from outliers : 78.9869 % Variance is severely inflated by outliers
> Just Doubles:
> Evaluation count : 20640 in 60 samples of 344 calls.
>  Execution time mean : 4.309871 ms
> Execution time std-deviation : 537.444033 µs
>Execution time lower quantile : 2.389294 ms ( 2.5%)
>Execution time upper quantile : 4.716009 ms (97.5%)
>Overhead used : 1.873322 ns
> 
> Found 8 outliers in 60 samples (13. %)
>   low-severe   5 (8. %)
>   low-mild 2 (3. %)
>   high-mild1 (1.6667 %)
>  Variance from outliers : 78.9282 % Variance is severely inflated by outliers
> 
> 
> The performance is amazingly better when using primitive doubles, even though 
> all operations are doing effectively the same thing: 2 floating point add 
> operations. I assume that the overhead of allocating a new vector2 object is 
> responsible for the decline in performance.
> 
> Did I use type hints correctly?  Is there a way to keep the "x and y" vector 
> abstraction and still get something 

I knew that primitives were better, but this is ridiculous

[JvJ]

I've been doing some performance tests on various floating point 
operations.  In particular, I wanted to check what would be the fastest way 
to implement a 2-d floating point vector in clojure.

Here's my tests:

;;; V+ Tests
;;; Implementing floating-point vectors as:
;;; structs, deftype, vector
(defrecord v2r
[^Double x ^Double y])

(defn rv+
  [^v2r v1 ^v2r v2]
  (v2r. (+ (.x v1) (.x v2))
(+ (.y v1) (.y v2

(deftype v2t
[^Double x ^Double y])

(defn tv+
  [^v2t v1 ^v2t v2]
  (v2t. (+ (.x v1) (.x v2))
(+ (.y v1) (.y v2

(defn vv+
  [v1 v2]
  (mapv + v1 v2))


(defn testvecs
  "Tests the vector add operations by reducing a
  random list by each of the v+ operations on
  identical sets of random vectors"
  [n]
  (let [nums (repeatedly (* 2 n) rand)
vpairs (partition 2 nums)
v2r-list (apply list (map (fn [[x y]] (v2r. x y)) vpairs))
v2t-list (apply list (map (fn [[x y]] (v2t. x y)) vpairs))
v2v-list (apply list (map vec vpairs))]
(println "V2 Record:")
(bench (reduce rv+ v2r-list))
(println "V2 Type:")
(bench (reduce tv+ v2t-list))
(println "V2 Vector:")
(bench (reduce vv+ v2v-list))
(println "Just Doubles:")
(bench (reduce + nums



 Here's my output:

*V2 Record:*
Evaluation count : 420 in 60 samples of 7 calls.
 Execution time mean : 164.379725 ms
Execution time std-deviation : 4.478128 ms
   Execution time lower quantile : 149.546749 ms ( 2.5%)
   Execution time upper quantile : 172.317132 ms (97.5%)
   Overhead used : 1.873322 ns

Found 8 outliers in 60 samples (13. %)
low-severe 4 (6.6667 %)
low-mild 3 (5. %)
high-mild 1 (1.6667 %)
 Variance from outliers : 14.2105 % Variance is moderately inflated by 
outliers
*V2 Type:*
Evaluation count : 1860 in 60 samples of 31 calls.
 Execution time mean : 32.238857 ms
Execution time std-deviation : 2.331682 ms
   Execution time lower quantile : 26.769206 ms ( 2.5%)
   Execution time upper quantile : 35.318368 ms (97.5%)
   Overhead used : 1.873322 ns

Found 8 outliers in 60 samples (13. %)
low-severe 5 (8. %)
low-mild 3 (5. %)
 Variance from outliers : 53.4940 % Variance is severely inflated by 
outliers
*V2 Vector:*
Evaluation count : 2040 in 60 samples of 34 calls.
 Execution time mean : 30.175015 ms
Execution time std-deviation : 3.870306 ms
   Execution time lower quantile : 21.877116 ms ( 2.5%)
   Execution time upper quantile : 37.668717 ms (97.5%)
   Overhead used : 1.873322 ns

Found 10 outliers in 60 samples (16.6667 %)
low-severe 5 (8. %)
low-mild 2 (3. %)
high-mild 3 (5. %)
 Variance from outliers : 78.9869 % Variance is severely inflated by 
outliers
*Just Doubles:*
Evaluation count : 20640 in 60 samples of 344 calls.
 Execution time mean : 4.309871 ms
Execution time std-deviation : 537.444033 µs
   Execution time lower quantile : 2.389294 ms ( 2.5%)
   Execution time upper quantile : 4.716009 ms (97.5%)
   Overhead used : 1.873322 ns

Found 8 outliers in 60 samples (13. %)
low-severe 5 (8. %)
low-mild 2 (3. %)
high-mild 1 (1.6667 %)
 Variance from outliers : 78.9282 % Variance is severely inflated by 
outliers



The performance is amazingly better when using primitive doubles, even 
though all operations are doing effectively the same thing: 2 floating 
point add operations. I assume that the overhead of allocating a new 
vector2 object is responsible for the decline in performance.

Did I use type hints correctly?  Is there a way to keep the "x and y" 
vector abstraction and still get something approaching primitive 
performance?

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

Re: understanding a clojuredocs merge example

[Michael Willis]

As long as we're cutting out unnecessary code, this is also equivalent:

(defn baz [options]
   (merge {:opt1 "default-1" :opt2 "default-2"} options))
(baz {:opt1 "custom-1" :opt3 "custom-3"});;=> {:opt3 "custom-3" :opt1 "custom-1 
:opt2 "default-2"}



On Thursday, May 12, 2016 at 4:03:04 AM UTC-5, Dan Kersten wrote:
>
> Yes, only the first map passed into baz (only one passed in anyway in the 
> example) is kept, anything else is thrown away. Seems like a strange 
> example when something like this would have sufficed to get the point of 
> merge across:
>
> (defn baz [options]
>(let [options (merge {:opt1 "default-1" :opt2 "default-2"} 
> options)]
>   options))
> (baz {:opt1 "custom-1" :opt3 "custom-3"});;=> {:opt3 "custom-3" :opt1 
> "custom-1 :opt2 "default-2"}
>
>
> On Thu, 12 May 2016 at 07:45 hiskennyness  
> wrote:
>
>> I do not understand something this example:
>>
>>   
>> https://clojuredocs.org/clojure.core/merge#example-54c7b859e4b0e2ac61831cdf
>>
>> Specifically:
>>
>> (defn baz [& options]
>>>(let [options (merge {:opt1 "default-1" :opt2 "default-2"} 
>>> (first options))]
>>>   options))
>>> (baz {:opt1 "custom-1" :opt3 "custom-3"});;=> {:opt3 "custom-3" :opt1 
>>> "custom-1 :opt2 "default-2"}
>>>
>>>
>> IIANM, that throws away all but the first map in the rest parameter 
>> options.
>>
>> Is there more going on here than I realize?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: apply madness

[hiskennyness]

On Thursday, May 12, 2016 at 4:10:39 AM UTC-4, Michael Gardner wrote:
>
> There's no need to avoid `apply` altogether, IMO. You could do something 
> like this: 
>
> (let [raw (list :a 1 :b 2 :c 3)] 
> (into {:raw raw} 
> (filter (comp even? second) 
> (apply hash-map raw 
>

Ah, that comp is nice. I'll use that.
 

>
> BTW, `list` is pretty uncommon. Usually you'd just use a vector literal. 
>

Understood, but I am actually working on a function where the values 
originate as a & rest param. 

Hmm, given the oddness of lists in Clojure, I wonder why those aren't 
vectors.

Thx! -kt

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

Re: apply madness

[hiskennyness]

On Thursday, May 12, 2016 at 3:59:10 AM UTC-4, dennis wrote:
>
> A try:
>
> (let [raw (list  :a 1 :b 2 :c 3)]
>   (->> raw
>(partition 2)
>(filter #(even? (second %)))
>(map vec)
>(into {})
>(merge {:raw raw})))
>
> => {:b 2, :raw (:a 1 :b 2 :c 3)}
>

Brilliant. Actually, I had my own spec wrong. Adjusting for that:

(let [raw (list  :a 1 :b 2 :c 3 :d 42)]
>   (merge {:cz (->> raw
>(partition 2)
>(filter #(even? (second %)))
>(map vec)
>(into {}))}
>  (->> raw
>   (partition 2)
>   (map (fn [[k v]] (vector k (when-not (even? v) v
>   (into {}
> ;; => {:cz {:b 2, :d 42}, :a 1, :b nil, :c 3, :d nil}

 
ie, I want the :cz (formerly :raw) key to hold a selective map of the 
inputs, and then all the inputs as key-values but with some values cleared.

Further repairs welcome.

Thx! -kt

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

Re: understanding a clojuredocs merge example

[Daniel Kersten]

Yes, only the first map passed into baz (only one passed in anyway in the
example) is kept, anything else is thrown away. Seems like a strange
example when something like this would have sufficed to get the point of
merge across:

(defn baz [options]
   (let [options (merge {:opt1 "default-1" :opt2 "default-2"}
options)]
  options))
(baz {:opt1 "custom-1" :opt3 "custom-3"});;=> {:opt3 "custom-3" :opt1
"custom-1 :opt2 "default-2"}


On Thu, 12 May 2016 at 07:45 hiskennyness  wrote:

> I do not understand something this example:
>
>
> https://clojuredocs.org/clojure.core/merge#example-54c7b859e4b0e2ac61831cdf
>
> Specifically:
>
> (defn baz [& options]
>>(let [options (merge {:opt1 "default-1" :opt2 "default-2"}
>> (first options))]
>>   options))
>> (baz {:opt1 "custom-1" :opt3 "custom-3"});;=> {:opt3 "custom-3" :opt1 
>> "custom-1 :opt2 "default-2"}
>>
>>
> IIANM, that throws away all but the first map in the rest parameter
> options.
>
> Is there more going on here than I realize?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: apply madness

[Michael Gardner]

There's no need to avoid `apply` altogether, IMO. You could do something like 
this:

(let [raw (list :a 1 :b 2 :c 3)]
(into {:raw raw}
(filter (comp even? second)
(apply hash-map raw

BTW, `list` is pretty uncommon. Usually you'd just use a vector literal.

And this is the right place to ask!

> On May 12, 2016, at 00:46, hiskennyness  wrote:
> 
> This does what I want but feels nooby-ish, as in "in a month I will do this 
> without APPLY":
> 
> (let [raw (list  :a 1 :b 2 :c 3)]
>   (apply assoc {}
>  :raw raw
>   (apply concat
>(filter #(even? (second %))
>(apply hash-map raw)
> ;; => {:raw (:a 1 :b 2 :c 3), :b 2}
> 
> Am I being too hard on myself?
> 
> Meta question: is there a better place to ask such questions?
> 
> -kt
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: apply madness

[dennis zhuang]

A try:

(let [raw (list  :a 1 :b 2 :c 3)]
  (->> raw
   (partition 2)
   (filter #(even? (second %)))
   (map vec)
   (into {})
   (merge {:raw raw})))

=> {:b 2, :raw (:a 1 :b 2 :c 3)}



2016-05-12 15:46 GMT+08:00 hiskennyness :

> This does what I want but feels nooby-ish, as in "in a month I will do
> this without APPLY":
>
> (let [raw (list  :a 1 :b 2 :c 3)]
>>   (apply assoc {}
>>  :raw raw
>>   (apply concat
>>(filter #(even? (second %))
>>(apply hash-map raw)
>> ;; => {:raw (:a 1 :b 2 :c 3), :b 2}
>
>
> Am I being too hard on myself?
>
> Meta question: is there a better place to ask such questions?
>
> -kt
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

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

apply madness

[hiskennyness]

This does what I want but feels nooby-ish, as in "in a month I will do this 
without APPLY":

(let [raw (list  :a 1 :b 2 :c 3)]
>   (apply assoc {}
>  :raw raw
>   (apply concat
>(filter #(even? (second %))
>(apply hash-map raw)
> ;; => {:raw (:a 1 :b 2 :c 3), :b 2}


Am I being too hard on myself?

Meta question: is there a better place to ask such questions?

-kt

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

understanding a clojuredocs merge example

[hiskennyness]

I do not understand something this example:

  
https://clojuredocs.org/clojure.core/merge#example-54c7b859e4b0e2ac61831cdf

Specifically:

(defn baz [& options]
>(let [options (merge {:opt1 "default-1" :opt2 "default-2"} 
> (first options))]
>   options))
> (baz {:opt1 "custom-1" :opt3 "custom-3"});;=> {:opt3 "custom-3" :opt1 
> "custom-1 :opt2 "default-2"}
>
>
IIANM, that throws away all but the first map in the rest parameter options.

Is there more going on here than I realize?

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