Thanks Stu ..
But I think it may be reasonable to say that the rest of the arguments can
be any collection and not just Set .. But I guess you have your reasons .. I
will assume that every argument is just a set and not anything else.
Sunil.
On Wed, Dec 1, 2010 at 8:54 PM, Stuart Halloway
wrote:
On Wed, Dec 1, 2010 at 10:25 PM, Chris Maier
wrote:
> That sounds like 'reductions':
>
> (reductions + [1 2 4 8])
> ==> (1 3 7 15)
On top of that, both the OP's algorithms are quadratic.
(defn scanl2 [f seed coll]
(loop [ttl seed [fst & rst] coll acc []]
(let [ttl (f ttl fst)
acc
Actually, it was one of the features I liked about Arc, which is built
on scheme.
That being said Arc doesn't have as many data type's or structures,
quite likely making it better suited for building generic functions,
most of which can be applied
across the majority of data types/structure's.
Cl
That sounds like 'reductions':
(reductions + [1 2 4 8])
==> (1 3 7 15)
Chris
On Wed, Dec 1, 2010 at 10:20 PM, Alex Baranosky
wrote:
> My friend's playing with Haskell, and asked me how I'd write a function to
> take a list and return a list of the sums like so:
> (f [1 2 4 8])
> => [1 3 7 15]
My friend's playing with Haskell, and asked me how I'd write a function to
take a list and return a list of the sums like so:
(f [1 2 4 8])
=> [1 3 7 15]
So I told him about Haskell's scanl function.
Is scanl available in Haskell?
These were my two versions of it and some simple benchmarks:
(
I'd be highly dubious of this even if it was free, performance-wise. >
and < are not clearly defined on strings and in general this kind of
thing seems like an inroad for the kind of baffling implicit
conversion-type behaviours you can see in PHP or JavaScript. Functions
that do something like thos
On Dec 1, 3:33 pm, Ken Wesson wrote:
> On Wed, Dec 1, 2010 at 9:38 AM, Laurent PETIT wrote:
> > 2010/12/1 Ken Wesson
>
> >> On Wed, Dec 1, 2010 at 8:29 AM, Laurent PETIT
> >> wrote:
> >> > If so, then it may be sufficient to leverage the possibility, in your
> >> > testing "framework" (clojure.
2010/12/1 Ken Wesson
> On Wed, Dec 1, 2010 at 9:38 AM, Laurent PETIT
> wrote:
> > 2010/12/1 Ken Wesson
> >>
> >> On Wed, Dec 1, 2010 at 8:29 AM, Laurent PETIT
> >> wrote:
> >> > If so, then it may be sufficient to leverage the possibility, in your
> >> > testing "framework" (clojure.test ? any
On Wed, Dec 1, 2010 at 9:38 AM, Laurent PETIT wrote:
> 2010/12/1 Ken Wesson
>>
>> On Wed, Dec 1, 2010 at 8:29 AM, Laurent PETIT
>> wrote:
>> > If so, then it may be sufficient to leverage the possibility, in your
>> > testing "framework" (clojure.test ? anything else ...) to redefine the
>> > fu
On Tue, Nov 30, 2010 at 8:09 PM, David Nolen wrote:
> I've come to dislike the bandying about of "premature optimization".
> Premature optimization is wasting time optimizing when you don't understand
> the problem space. That is not the case here. It's just about convenience.
I suppose you're ri
On 1 December 2010 02:01, Chris Riddoch wrote:
> Which reminds me, I'd really love to see a good comparison of freely
> available benchmarking tools for Clojure. From past discussions on
> the list, I gather that benchmarking in the JVM is a rather tricky
> thing in general, but much more so for
Note, though, that he did not use the words "unit testing", you did :)
And mocking and stubbing are techniques that can be done at different scales
...
2010/12/1 Alyssa Kwan
> Hi Mike,
>
> "TDD as if you meant it" -
>
> http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software
Sean,
I entirely agree that the use of keywords as map keys is a feature of
clojure (and a great one, at that), and that converting result set
column names to keywords is a feature of resultset-seq. A greater
feature of clojure is its extensibility. What I am after is a
generalization of the func
Hi Mike,
"TDD as if you meant it" -
http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/
What you want is mocking and stubbing (these are different things!).
http://s-expressions.com/2010/01/24/conjure-simple-mocking-and-stubbing-for-clojure-unit-te
Yup. Count me in as another Clojurian thirsty for videos from the
conference.
I'm definitely willing to fork over a couple of bucks for the pleasure
as well.
- Farley
On Nov 30, 10:22 pm, Brent Millare wrote:
> +1, I surprised a video from the conference hasn't been posted yet.
> Are there lega
+1
On Dec 1, 8:01 pm, Ryan Twitchell wrote:
> Hi all,
>
> I'm not too happy with how resultset-seq down-cases column names and
> turns them into keywords, as I would prefer to work with string keys
> in some cases. I came up with the following change to give the caller
> a choice to remap column
Using keywords in the resultset map is a feature. It is very common
to write something like this;
(map :your-column results)
This takes advantage of the fact that keywords implement IFn. To the
best of my knowledge SQL isn't case sensitive, downcasing the column
names makes sense too, since it
The documentation is correct. It tells what the function promises to callers,
not how it does it.
Rely on implementation details at you peril. :-)
Stu
> Hello everybody,
> I think the documentation of the clojure.set/difference should change to
> reflect the fact that only the first argument
He may have some interesting points but...
Anyone who makes grandiose claims and can't bother to give credit to
the people who have helped them along the way deserves to be ignored.
On Nov 27, 11:36 pm, Duane Searsmith wrote:
> I thought his blog had some interesting points. I enjoyed reading i
> I thought his blog had some interesting points. I enjoyed reading it. Do I
> wish Mathematica was more affordable and/or open source? Yes. So what.
> That doesn't make Wolfram a lunatic or a fraud.
Do you recall me saying that?
--
You received this message because you are subscribed to the
Hi all,
I'm not too happy with how resultset-seq down-cases column names and
turns them into keywords, as I would prefer to work with string keys
in some cases. I came up with the following change to give the caller
a choice to remap column keys in any way. This leaves resultset-seq's
behavior f
2010/12/1 Ken Wesson
> On Wed, Dec 1, 2010 at 8:29 AM, Laurent PETIT
> wrote:
> > If so, then it may be sufficient to leverage the possibility, in your
> > testing "framework" (clojure.test ? anything else ...) to redefine the
> > functions of the backend before the tests run. I'm pretty sure th
On Wed, Dec 1, 2010 at 8:29 AM, Laurent PETIT wrote:
> If so, then it may be sufficient to leverage the possibility, in your
> testing "framework" (clojure.test ? anything else ...) to redefine the
> functions of the backend before the tests run. I'm pretty sure there are
> already such features a
Hi,
2010/12/1 Michael Ossareh
> Hi All,
>
> In the course of putting together my latest piece of work I decided to
> really embrace TDD. This is run of the mill for me in Java:
>
> - create some object that models your flow
> - create some object which contains your storage logic
> - create test
On Wed, Dec 1, 2010 at 8:38 AM, Alex Osborne wrote:
>> I expect the compare it does uses .equals rather than ==?
>
> Not even that, it's a CPU instruction so it'll be identical?.
The identical? predicate and the Java == operator do the same thing.
Also, what's a CPU instruction? Everything we've
Ken Wesson writes:
> It looks an awful lot like swap! itself is implemented with a polling
> sleeplock instead of using the language's own lock. :)
I suppose it's similar to a spinlock simply because it keeps retrying,
like a spinlock keeps retrying to acquire. Very different semantics
though:
Hi All,
In the course of putting together my latest piece of work I decided to
really embrace TDD. This is run of the mill for me in Java:
- create some object that models your flow
- create some object which contains your storage logic
- create tests
- dependency inject the correct storage logic
On Wed, Dec 1, 2010 at 4:50 AM, Alex Osborne wrote:
> Ken Wesson writes:
>
>> Retries? We were discussing an atom here, not a ref. A dosync
>> transaction may be retried. The obvious implementation for swap! would
>> be (locking inner_value (set! inner_value.contents (apply fun
>> inner_value.con
yea true ... :)
On Wed, Dec 1, 2010 at 3:48 PM, Laurent PETIT wrote:
>
>
> 2010/12/1 Sunil S Nandihalli
>
>
>> Andy,
>> It was just for education like you said .. It was more of waw .. it is not
>> creating another map if the value has not changed.. thing..
>>
>>
> After all, it's just a special
2010/12/1 Sunil S Nandihalli
>
> Andy,
> It was just for education like you said .. It was more of waw .. it is not
> creating another map if the value has not changed.. thing..
>
>
After all, it's just a special case of structural sharing ... when you share
exactly the same structure ! :-D
--
Ken Wesson writes:
> Retries? We were discussing an atom here, not a ref. A dosync
> transaction may be retried. The obvious implementation for swap! would
> be (locking inner_value (set! inner_value.contents (apply fun
> inner_value.contents))) (warning: pseudocode, I assume this stuff
> would a
Andy,
It was just for education like you said .. It was more of waw .. it is not
creating another map if the value has not changed.. thing..
Sunil
On Wed, Dec 1, 2010 at 1:32 PM, Andy Fingerhut wrote:
> Sunil, is there any particular reason why you are looking for when results
> of operations ha
Hello everybody,
I think the documentation of the clojure.set/difference should change to
reflect the fact that only the first argument needs to be a set and the rest
of the arguments can be any collection.
I am reporting this from Clojure 1.2
Sunil.
--
You received this message because you ar
Sunil, is there any particular reason why you are looking for when
results of operations have identical? return true, rather than merely
= return true?
If it is for some reduction in allocating new memory when it is not
necessary, then I can understand your motivation, although it really
34 matches
Mail list logo
