On Sunday 14 December 2008 09:00, harrison clarke wrote:
> yep. a function f(n) is O(n) if there are constants c and n0 such
> that f(n) <= c * n for all n >= n0.
>
> sometimes you do care about the c and the n0, though.
To be sure.
And there can be times that, for the problem size you know you
yep. a function f(n) is O(n) if there are constants c and n0 such that f(n)
<= c * n for all n >= n0.
sometimes you do care about the c and the n0, though.
On Sun, Dec 14, 2008 at 12:41 PM, levand wrote:
>
> Ah, ok... I would have assumed that would be labeled as O(2n). Didn't
> realize that was
Ah, ok... I would have assumed that would be labeled as O(2n). Didn't
realize that was rolled into the constant factor. So, when graphed,
ANY linear function is O(n), no matter how "steep" the line is?
Obviously I have some reading to do.
Thanks for the clarification,
-Luke
On Dec 13, 6:35 pm,
On Saturday 13 December 2008 15:35, Randall R Schulz wrote:
> ...
>
> Any algorithm that requires to O(n) steps is itself O(n).
And by that I meant "...two O(n) steps...", of course.
> The big-O concept is roughly "equality up to a constant factor."
Randall Schulz
--~--~-~--~~---
On Saturday 13 December 2008 14:29, levand wrote:
> > ...
>
> > Calling reverse when done is still O(N)
>
> Really? Maybe my grasp of big-O notation is faulty, but isn't the
> recursive function itself O(n), and then a reversal another O(n)
> operation on top of that, leading to two complete trave
> Really? I get:
>
> (last (copy-seq (range 10)))
> -> 9
I'm running inside of VirtualBox assigned very little memory. Maybe
that's why? I'll run some more tests. I know I have been able to get
up to 3000 levels of recursion without a stack overflow, once, at
another time.
In any case, i
On Dec 13, 4:11 pm, levand wrote:
> Right... I realize there is absolutely no need to actually do this, it
> was more of an exercise in understanding ways to iterate over seqs.
> For example, I might want to do something else than a straight copy.
map is a good way to iterate over seq. E.g.
(m
On Dec 12, 9:51 pm, levand wrote:
> So, I'm trying to understand functional programming, particularly as
> it relates to the seq abstraction, and I'm hitting a slight difficulty
> as I'm playing around - something that seems as if it ought to be
> simple, is not.
>
> I'm playing with copying on
Right... I realize there is absolutely no need to actually do this, it
was more of an exercise in understanding ways to iterate over seqs.
For example, I might want to do something else than a straight copy.
Thanks for the replies...
On Dec 13, 8:12 am, lpetit wrote:
> Yes, the semantics of a s
Yes, the semantics of a sequence force it to be immutable :
"Seqs differ from iterators in that they are persistent and
immutable" ( http://clojure.org/sequences )
So there's simply no need to have a copy function for sequences (or
for any other clojure data structure).
HTH,
--
Laurent
On 13
On Dec 13, 4:51 am, levand wrote:
> So, I'm trying to understand functional programming, particularly as
> it relates to the seq abstraction, and I'm hitting a slight difficulty
> as I'm playing around - something that seems as if it ought to be
> simple, is not.
>
> I'm playing with copying one
On Fri, Dec 12, 2008 at 6:51 PM, levand wrote:
> The next implementation is simpler, and uses recursion quite
> elegantly:
> (defn copy-seq [source]
>(if (nil? source)
> '()
> (cons (first source) (copy-seq (rest source)
> What would one do in a language like Scheme, without l
I guess one answer to your question would be: If the seq is persistent
(immutable) why would you need to make a copy of it?
On Dec 12, 8:51 pm, levand wrote:
> So, I'm trying to understand functional programming, particularly as
> it relates to the seq abstraction, and I'm hitting a slight diffi
13 matches
Mail list logo
