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 2

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 Nandihal

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 Gr

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: > Maybe this is a little off-

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 cloju

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 and not primitive. > C

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 to

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 > correctness, not p

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 w

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 useful in, you know, maki

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 some, i dunno, 'types'

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 wa

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 because

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 me

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 im

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 cripple

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 cloju

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 be

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

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

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

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

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

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 but feels nooby-ish, as

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