From: Pal-Kristian Engstad <pal_engstad@naughtydog.com>
To: "Quôc Peyrot" <chojin@lrde.epita.fr>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Book about functional design patterns
Date: Wed, 27 Jun 2007 15:13:58 -0700 [thread overview]
Message-ID: <4682E126.1050008@naughtydog.com> (raw)
In-Reply-To: <F00765A8-6A15-415A-9E2E-D693A9558387@lrde.epita.fr>
Quôc Peyrot wrote:
> I think we agree, I'm just saying that C*N*log2(N) is a over-estimated
> upper bound for large N.
>
> C*(log2(1) + ... + log2(N)) = C * log2(1*2*....*N) = C * log2(N!)
> hence
>
> time <= C*log2(N!) <= C * N * log2(N)
>
> as an example, for N = 100
>
> sum(floor(log2(i)), i = 1..100) = 480
> log2(100!) = 524 (overestimated by 10%)
> 100 * log2(100) = 664 (overestimated by 40%)
>
> for large N, the difference is going to be significant.
Ok, I see what you mean.
> But anyway, the details doesn't matter, it just looks to me that
> inserting N elements in a functional map, is really significant.
> If my maths are correct, for only 1000 elements, we are going to have
> an extra 8500 allocations (the difference is so huge I actually can't
> believe my maths...)
But you are forgetting that you won't have to reallocate every log2(n)
elements, for every n, there is a chance that the actual number is much
less than log2(n). log2(n) really is just the worst case, where you have
to change every red-black tree (say) all the way to the top. This is
fairly unlikely, thus the number of allocations is in practice going to
be far less.
I tested OCaml's Map adding a counter for each allocation. Adding
100,000 random key, value pairs resulted in 151,587 allocations, and
1,000,000 adds resulted in 1,516,551 allocations. Adding sorted numbers
gave: 299,964 and 2,999,958 allocations. So it looks like it is near
linear (with a factor of 1.5 to 3.0) in practice.
PKE.
--
Pål-Kristian Engstad (engstad@naughtydog.com), Lead Graphics & Engine Programmer,
"Uncharted"-team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
Jonathan Blow, 2/1/2006, GD Algo Mailing List
next prev parent reply other threads:[~2007-06-27 22:20 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-27 12:14 The Implicit Accumulator: a design pattern using optional arguments Jon Harrop
2007-06-27 13:18 ` [Caml-list] " Quôc Peyrot
2007-06-27 13:53 ` Jon Harrop
2007-06-27 14:18 ` Thomas Fischbacher
2007-06-27 15:09 ` Quôc Peyrot
2007-06-27 15:28 ` Mattias Engdegård
2007-06-27 15:38 ` Robert Fischer
2007-06-27 15:48 ` Mattias Engdegård
2007-06-27 16:01 ` Robert Fischer
2007-06-27 16:01 ` Mattias Engdegård
2007-06-27 18:06 ` Jon Harrop
2007-06-27 18:31 ` Brian Hurt
2007-06-27 19:56 ` skaller
2007-06-27 20:17 ` Jonathan Bryant
2007-06-27 22:57 ` Jon Harrop
2007-06-27 16:53 ` Hash-consing (was Re: [Caml-list] The Implicit Accumulator: a design pattern using optional arguments) Daniel Bünzli
2007-06-30 8:19 ` [Caml-list] The Implicit Accumulator: a design pattern using optional arguments Pierre Etchemaïté
2007-06-27 13:55 ` Thomas Fischbacher
2007-06-27 15:06 ` Quôc Peyrot
2007-06-27 15:53 ` Jon Harrop
2007-06-28 11:01 ` Thomas Fischbacher
2007-06-28 11:32 ` Jon Harrop
2007-06-28 11:42 ` Joel Reymont
2007-06-28 12:08 ` Jon Harrop
2007-06-28 13:10 ` Quôc Peyrot
2007-06-28 13:35 ` Thomas Fischbacher
2007-06-28 12:59 ` Thomas Fischbacher
2007-06-28 13:05 ` Jon Harrop
2007-06-28 13:33 ` Thomas Fischbacher
2007-06-28 14:43 ` Jon Harrop
2007-06-28 16:01 ` Thomas Fischbacher
2007-06-28 17:53 ` Jon Harrop
2007-06-27 16:39 ` Thomas Fischbacher
2007-06-27 19:26 ` Quôc Peyrot
2007-06-28 11:39 ` Thomas Fischbacher
2007-06-28 14:44 ` Jon Harrop
2007-06-28 16:03 ` Thomas Fischbacher
2007-06-28 17:20 ` Dirk Thierbach
2007-06-28 22:12 ` Thomas Fischbacher
2007-06-29 1:10 ` Jon Harrop
2007-06-29 10:55 ` Thomas Fischbacher
2007-06-29 6:12 ` Dirk Thierbach
2007-06-27 17:16 ` Book about functional design patterns Gabriel Kerneis
2007-06-27 17:48 ` [Caml-list] " Jon Harrop
2007-06-27 19:33 ` Quôc Peyrot
2007-06-27 19:30 ` Quôc Peyrot
2007-06-27 19:48 ` Brian Hurt
2007-06-27 20:04 ` Quôc Peyrot
2007-06-27 20:35 ` Brian Hurt
2007-06-27 20:55 ` Quôc Peyrot
2007-06-27 20:58 ` Pal-Kristian Engstad
2007-06-27 21:18 ` Quôc Peyrot
2007-06-27 21:18 ` Pal-Kristian Engstad
2007-06-27 21:34 ` Quôc Peyrot
2007-06-27 22:13 ` Pal-Kristian Engstad [this message]
2007-06-27 15:18 ` [Caml-list] The Implicit Accumulator: a design pattern using optional arguments Jon Harrop
2007-06-27 16:44 ` Thomas Fischbacher
2007-06-27 18:17 ` Jon Harrop
2007-06-28 11:18 ` Thomas Fischbacher
2007-06-29 13:15 ` Bill Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4682E126.1050008@naughtydog.com \
--to=pal_engstad@naughtydog.com \
--cc=caml-list@yquem.inria.fr \
--cc=chojin@lrde.epita.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox