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

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

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

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

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

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:

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

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

Unable to call the method when it clearly exists..

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

Re: apply madness

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

changing metadata questions

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

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

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

Re: understanding a clojuredocs merge example

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

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

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

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

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

I knew that primitives were better, but this is ridiculous

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,

Re: understanding a clojuredocs merge example

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

Re: apply madness

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

Re: apply madness

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

Re: understanding a clojuredocs merge example

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"

Re: apply madness

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

Re: apply madness

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

apply madness

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

understanding a clojuredocs merge example

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