By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,824 Members | 1,247 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,824 IT Pros & Developers. It's quick & easy.

Memory address of an object

P: n/a
I want to get the memory address of an object. Can someone tell me how
to do that in C#. Also, I tried using the unsafe and the "&" operator
and could not acheive it. Can you tell me a good way of doing it? I am
new to this and have no clue how to get the memory address.

Nov 17 '05 #1
Share this Question
Share on Google+
37 Replies


P: n/a
I want to get the memory address of an object.


Why do you need it? In the garbage collected world of .NET it may
change from one moment to the next.
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Nov 17 '05 #2

P: n/a
Could you explain what are you trying to do. Why would you need "memory
address".

"kp******@gmail.com" wrote:
I want to get the memory address of an object. Can someone tell me how
to do that in C#. Also, I tried using the unsafe and the "&" operator
and could not acheive it. Can you tell me a good way of doing it? I am
new to this and have no clue how to get the memory address.

Nov 17 '05 #3

P: n/a
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.

Nov 17 '05 #4

P: n/a
kp******@gmail.com wrote:
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.


In .NET, you can pin an object and thus get hold of a pointer to it. I
don't know exactly what kind of objects you can pin, but I know you need
to use unsafe code to do it.

What's wrong with a Guid?

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2
Nov 17 '05 #5

P: n/a
Unfortunately, your supervisors don't know much about .NET.

If you really want something that is unique for each object, you really
have no choice but to use a GUID (it's the easiest way to create something
that is guaranteed to be unique, and doesn't require a manager of your own
to synchronize generation of the unique values).

You would have to associate that guid with the object, and expose it
somehow. This would be best done through a method on your object itself.
If you store it outside your objects, then you will be holding references to
them (in order to do a lookup for the id based on the object) and that will
extend the lifetime of them (and force you to resort to some gnarly lifetime
management code).

You could use a hash, but that isn't guaranteed to generate a unique id
for each object instance.

Besides creating a unique id, what are you trying to do? What is the id
for?

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<kp******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.

Nov 17 '05 #6

P: n/a
"Memory addresses" in .NET aren't really static. Object can be moved around
as part of memory management. You can fix objects in memory, but I don't
think this is really a good solution to your problem.

If there's no other way to uniquely identify your objects, why not have a
static int which is simply incremented each time an object is created and
assigned to the object? Not much different than assigning a Guid in terms of
there not being any particular logic associated with the objects themselves.

Pete
<kp******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.

Nov 17 '05 #7

P: n/a
Lasse,

This isn't completely correct. You don't need to use unsafe code to pin
an object reference. You can use the GCHandle structure to do it.

Also, this would be a very, very, very, VERY MONUMENTALLY BAD idea. If
you pin the object for a long period of time (and it would have to be, so
that the id remains unique), you will end up fragmenting the heap and make
the GC do WAY more work than it needs to.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:eb********************@telenor.com...
kp******@gmail.com wrote:
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.


In .NET, you can pin an object and thus get hold of a pointer to it. I
don't know exactly what kind of objects you can pin, but I know you need
to use unsafe code to do it.

What's wrong with a Guid?

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2

Nov 17 '05 #8

P: n/a


"kp******@gmail.com" wrote:
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.


Niether naturally implementable, nor a good idea. Convince your boss to use
a guid.

The address of an object in the GCed world is mutable and can change with
each successive GC pass. You can pin the address of an object in memory to
keep the GC from moving it, but this is only intended to be used briefly to
sent a pointer to un unmanaged codeblock because doing so will affect the
GCs performance.

As a sidebar question, if a GC pass opens a gap in the heap between the last
movable object and a pinned one with a higher address, does the heap fragment
like in the c/c++ world or is the free memory pointer placed after the pinned
object with the memory between the two temporarily unusable?
Nov 17 '05 #9

P: n/a


"kp******@gmail.com" wrote:
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.


Hmm... You need something like GetHashCode method:
http://msdn.microsoft.com/library/de...hcodetopic.asp

Though it does not quarantee uniqueness for all types, but you could write
your onw implementation:

"The default implementation of GetHashCode does not guarantee uniqueness or
consistency; therefore, it must not be used as a unique object identifier for
hashing purposes. Derived classes must override GetHashCode with an
implementation that returns a unique hash code. For best results, the hash
code must be based on the value of an instance field or property, instead of
a static field or property."

Other words calculate your own HashCode based on some properties.

Nov 17 '05 #10

P: n/a
How much do your supervisors know about .Net? Did they give you a reason not
to use a Guid?

To use a memory address would be problematic and require unsafe coding. A
Guid is 128 bits in size. Now, the trade-off here is the expense of
resources to get (and use) the memory address, combined with the use of
unsafe code, balanced against using 128 bits of memory. Sounds like a
no-brainer to me. Therefore, I am led to strongly suspect that your
supervisors have no brains.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Big things are made up of
lots of little things.

<kp******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
We are in someway trying to create a unique id. Though I know we could
use Guid, my supervisors are advising me to use a logic to do it,
whereby the memory address of that instance of a class (object) is used
in this logic. Please help.

Nov 17 '05 #11

P: n/a
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
Unfortunately, your supervisors don't know much about .NET.

If you really want something that is unique for each object, you really
have no choice but to use a GUID (it's the easiest way to create something
that is guaranteed to be unique, and doesn't require a manager of your own
to synchronize generation of the unique values).


Very slight correction - GUIDs aren't guaranteed to be unique (they
can't be - you could create more than 2^128 of them, even though the
time taken to do so would be pretty huge). There's just a very, very,
very low probability of duplicates.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #12

P: n/a
Lenn <Le**@discussions.microsoft.com> wrote:

<snip>
Other words calculate your own HashCode based on some properties.


And how would that give uniqueness? GUID is the best option here. Even
though that's not *technically* guaranteed to be unique, it's as close
as you're likely to get (and the chance of getting duplicates is
astronomically small).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #13

P: n/a
Jon,

Very, very very low doesn't even begin to describe how low the
probability of generating a duplicate is.

You would have to create something like one a second for the next
10790283070806014188970529154990 years to duplicate it. If you generated
5000 a second, you would still need 2158056614161202837794105831 years to go
through the complete range.

I think that for a program with a VERY finite lifetime (in comparison to
these numbers), it will work just fine. =)

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
Unfortunately, your supervisors don't know much about .NET.

If you really want something that is unique for each object, you
really
have no choice but to use a GUID (it's the easiest way to create
something
that is guaranteed to be unique, and doesn't require a manager of your
own
to synchronize generation of the unique values).


Very slight correction - GUIDs aren't guaranteed to be unique (they
can't be - you could create more than 2^128 of them, even though the
time taken to do so would be pretty huge). There's just a very, very,
very low probability of duplicates.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #14

P: n/a
The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system. But since we need a unique
id across multiple machines(which run different parts of our system),
they wanted us to generate our own key.

Also, they logic they asked me to use is combine Datetime(to
milliseconds)+ticks+the object's memory address.

Youhave to note that this ID is just used once to put this object into
database and then to be be used as a primary key as well for that
record.

Nov 17 '05 #15

P: n/a
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
Very, very very low doesn't even begin to describe how low the
probability of generating a duplicate is.
It's actually more than the MSDN docs give - they just say "very low".
You would have to create something like one a second for the next
10790283070806014188970529154990 years to duplicate it. If you generated
5000 a second, you would still need 2158056614161202837794105831 years to go
through the complete range.
Yes - although of course you don't need to go through the complete
range in order to get a duplicate. By the time I'd seen 2^128-1 GUIDs,
I'd be really, really impressed if the 2^128th happened to be the
missing one :)
I think that for a program with a VERY finite lifetime (in comparison to
these numbers), it will work just fine. =)


Almost certainly, yes.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #16

P: n/a
<kp******@gmail.com> wrote:
The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system. But since we need a unique
id across multiple machines(which run different parts of our system),
they wanted us to generate our own key.
GUIDs are astronomically unlikely to be repeated on *any* system, even
though it's possible.
Also, they logic they asked me to use is combine Datetime(to
milliseconds)+ticks+the object's memory address.

Youhave to note that this ID is just used once to put this object into
database and then to be be used as a primary key as well for that
record.


That's a really bad idea - what happens if the address is reused by
another object within the same tick? Or the same address is used on a
different box? Unlikely as it is, it's certainly feasible - more likely
than a GUID being duplicated.

Frankly though, if it's to go in the database, I'd have an identity
column in the database and find out what it is when it's autogenerated.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #17

P: n/a
"The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system"

Haha, gotta love management....use a GUID.

Nov 17 '05 #18

P: n/a
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??

Nov 17 '05 #19

P: n/a
Hahah, God, you are so screwed and your manager doesn't even know it.

Your manager is a jack-ass, and you need to quit your job. That's not
theory, that's the truth.

As for finding the address of the object in memory, you can't, it's
going to shift and you will find that it changes throughout the lifetime of
your program.

So use the guid. If you want, I'd be more than willing to speak to your
manager on the phone and let him know why a guid is better than a home grown
solution at this point.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<kp******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??

Nov 17 '05 #20

P: n/a
Ask your manager if he knows what the type used in SQL Server for
replication IDs is (which would mean the id would have to be unique
across multiple systems).

Nov 17 '05 #21

P: n/a

Other words calculate your own HashCode based on some properties.
And how would that give uniqueness?


It would not, unless values of some properties are unique.

GUID is the best option here. Even
though that's not *technically* guaranteed to be unique, it's as close
as you're likely to get (and the chance of getting duplicates is
astronomically small).


Yes, GUID is the best option.

Nov 17 '05 #22

P: n/a
Lenn <Le**@discussions.microsoft.com> wrote:
Other words calculate your own HashCode based on some properties.


And how would that give uniqueness?


It would not, unless values of some properties are unique.


In which case you could just use that single property, or those
combinations of properties. I think it's reasonable to assume that
there is no such combination in this case, given the question.
GUID is the best option here. Even
though that's not *technically* guaranteed to be unique, it's as close
as you're likely to get (and the chance of getting duplicates is
astronomically small).


Yes, GUID is the best option.


Indeed.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #23

P: n/a
Kplkumar,
The reason they say not to use GUID is because the GUID is restricted
to the machine that is running our system. But since we need a unique
id across multiple machines(which run different parts of our system),
they wanted us to generate our own key.


Why do you make it yourself so difficult to generate those keys?
The way you tell it does me think, just use the unique Id number of your
multiple machines and add to that a datetimetick that starts all on the same
date-time.

The misfailure from this approach is that it can only be used to be unique
in your own organisation and should never be used to mix up or create
uniqueness with data from other organisations and has the change on
programming errors because of the way programmers implement it in the
different programs or just make errors reading the documentation how it
should be done or just forget a part of the code.

Therefore the Guid is so nice, it is completely created for you and
therefore has a low change on errors or other misfailures.

Just my thought

Cor
Nov 17 '05 #24

P: n/a
<kp******@gmail.com> wrote:
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??


The following shows how to get the address of the object - and why your
manager shouldn't be allowed to make any decisions about how to find a
unique identifier:

using System;

class Test
{
static void Main()
{
for (int i=0; i < 10; i++)
{
string x = i.ToString();
unsafe
{
fixed (void* y = x)
{
Console.WriteLine (new IntPtr(y));
}
GC.Collect();
}
}
}
}

Use GUIDs - or get the database itself to generate the ID.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #25

P: n/a
No, it's not just a "theory". It's widely accepted and used in the idustry.
COM Program IDs in system registry are GUIDs, SQL server uniqueidentifier
data type is GUID. It works for many, but somehow it's not enough for your
managmnet?

"kp******@gmail.com" wrote:
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??

Nov 17 '05 #26

P: n/a
Nicholas Paldino [.NET/C# MVP] wrote:
Very, very very low doesn't even begin to describe how low the probability of generating a duplicate is.

You would have to create something like one a second for the next
10790283070806014188970529154990 years to duplicate it. If you generated
5000 a second, you would still need 2158056614161202837794105831 years to
go through the complete range.


I did some funny calculations with the numbers of possible GUIDs to
explain the point of the low probability to somebody. I found that for
every square millimeter of earth surface (including the water) there are
665672539443490875 GUIDs available. For the space occupied by a single
human being (estimated to be 100000 square millimeters, you'll have to
stand rather straight to make that true), that'll be
66567253944349087500000 GUIDs. Now, if I was using 10 Million of my GUIDs
every day - an arbitrary number that should suffice to account for all the
new data than's generated for me personally each day - I'll do fine for
18237603820369 years, which is about 6000 times the duration for which the
sun is likely to keep shining. And then I've been forgetting all the
places on the surface of the earth where nobody's currently standing...

I still find these numbers quite astonishing - don't ask me about details
of my calculations, it's been a while :-)
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)
Nov 17 '05 #27

P: n/a
> Sometimes when you are down the chain of command as a developer and the supervisor is a jack-ass, this is what you have to put up with.

Does the jackass know how to read newsgroups? :-o

Nov 17 '05 #28

P: n/a
Jon Skeet [C# MVP] wrote:
Yes - although of course you don't need to go through the complete
range in order to get a duplicate. By the time I'd seen 2^128-1 GUIDs,
I'd be really, really impressed if the 2^128th happened to be the
missing one :)


If you use the same .NET program for generating them that would actually
be easy, you could use a generator for the field N_{2^218} to make them.
A *very* simple (and in other ways unusable) implementation would simply
return i on the i'th invocation ;)

Due to the "brithday paradox", if GUID's are generated uniform-randomly
the chance of having seen a collision passes 50% at roughly 2^(128/2) =
2^109 samples. This is still a huge number, atleast a few orders of
magnitude larger than the number of atoms in a human body.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
Nov 17 '05 #29

P: n/a
Helge Jensen <he**********@slog.dk> wrote:
Yes - although of course you don't need to go through the complete
range in order to get a duplicate. By the time I'd seen 2^128-1 GUIDs,
I'd be really, really impressed if the 2^128th happened to be the
missing one :)
If you use the same .NET program for generating them that would actually
be easy, you could use a generator for the field N_{2^218} to make them.
A *very* simple (and in other ways unusable) implementation would simply
return i on the i'th invocation ;)


I was assuming a *real* GUID implementation :)
Due to the "brithday paradox", if GUID's are generated uniform-randomly
the chance of having seen a collision passes 50% at roughly 2^(128/2) =
2^109 samples. This is still a huge number, atleast a few orders of
magnitude larger than the number of atoms in a human body.


Do you mean 2^64? Not sure where the 109 comes from... (I'm not
familiar with the birthday paradox, and slightly too tired to bother
with the maths on the wikipedia entry :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #30

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<kp******@gmail.com> wrote:
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??


The following shows how to get the address of the object - and why your
manager shouldn't be allowed to make any decisions about how to find a
unique identifier:

using System;

class Test
{
static void Main()
{
for (int i=0; i < 10; i++)
{
string x = i.ToString();
unsafe
{
fixed (void* y = x)
{
Console.WriteLine (new IntPtr(y));
}
GC.Collect();
}
}
}
}

Use GUIDs - or get the database itself to generate the ID.

Note that this doesn't give you the object address, it's the address of the
first char in the string object.
Yoy can only use this for array types (and strings, as they are treated as
char[]), however, you can 't use this for other ref types.

Consider this:
object o = new object();
fixed (void* y = o
{

the compiler won't allow to convert other types to void*
or simply put you can't take the address of a reference type (other than
array's)

Willy.

Nov 17 '05 #31

P: n/a
kp******@gmail.com wrote:
I know it sounds ridiculous. Sometimes when you are down the chain of
command as a developer and the supervisor is a jack-ass, this is what
you have to put up with.

I just pointed out this discussion to my supervisor and he says, "those
who says things on the forums may probably have no experience in
practically using guid. They talk from theory. Let's proceed our way."

Anyway, is there a real way of getting the address of the object in
memory??


It never ceases to amaze me just how many incompetent managers are out
there.

Nov 17 '05 #32

P: n/a


Jon Skeet [C# MVP] wrote:
Due to the "brithday paradox", if GUID's are generated uniform-randomly
the chance of having seen a collision passes 50% at roughly 2^(128/2) =
2^109 samples. This is still a huge number, atleast a few orders of
magnitude larger than the number of atoms in a human body.

Do you mean 2^64? Not sure where the 109 comes from... (I'm not
familiar with the birthday paradox, and slightly too tired to bother
with the maths on the wikipedia entry :)


Actually, i mean 2^(218/2) = 2^109, got the char's 1,2 mixed up in
grandparent-post.

I can see in the wikipedia entry that it's this specific use of the
brithday paradox is mentioned:
http://en.wikipedia.org/wiki/Birthda...x#Applications

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
Nov 17 '05 #33

P: n/a
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
Note that this doesn't give you the object address, it's the address of the
first char in the string object.
Yoy can only use this for array types (and strings, as they are treated as
char[]), however, you can 't use this for other ref types.

Consider this:
object o = new object();
fixed (void* y = o
{

the compiler won't allow to convert other types to void*
or simply put you can't take the address of a reference type (other than
array's)


Ah, true. Oops. I've only ever used unsafe code in one situation in
production code - I'm somewhat rusty on it :(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #34

P: n/a
Helge Jensen <he**********@slog.dk> wrote:
Do you mean 2^64? Not sure where the 109 comes from... (I'm not
familiar with the birthday paradox, and slightly too tired to bother
with the maths on the wikipedia entry :)
Actually, i mean 2^(218/2) = 2^109, got the char's 1,2 mixed up in
grandparent-post.


Why 218/2 though? A GUID is a 128-bit data type.
I can see in the wikipedia entry that it's this specific use of the
brithday paradox is mentioned:
http://en.wikipedia.org/wiki/Birthda...x#Applications


Ah, right. Yes, even I can follow that bit :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #35

P: n/a
Hmm, I'm pretty sure you'll find few humans standing on water :)
Considering that only 30% of the earth's surface is land, you actually have
3.33 times more GUIDs available than you thought. Of course, that changes
again as soon as you sit down...
--
Kai Brinkmann [MSFT]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Oliver Sturm" <ol****@sturmnet.org> wrote in message
news:xn****************@msnews.microsoft.com...
Nicholas Paldino [.NET/C# MVP] wrote:
Very, very very low doesn't even begin to describe how low the
probability of generating a duplicate is.

You would have to create something like one a second for the next
10790283070806014188970529154990 years to duplicate it. If you generated
5000 a second, you would still need 2158056614161202837794105831 years to
go through the complete range.


I did some funny calculations with the numbers of possible GUIDs to
explain the point of the low probability to somebody. I found that for
every square millimeter of earth surface (including the water) there are
665672539443490875 GUIDs available. For the space occupied by a single
human being (estimated to be 100000 square millimeters, you'll have to
stand rather straight to make that true), that'll be
66567253944349087500000 GUIDs. Now, if I was using 10 Million of my GUIDs
every day - an arbitrary number that should suffice to account for all the
new data than's generated for me personally each day - I'll do fine for
18237603820369 years, which is about 6000 times the duration for which the
sun is likely to keep shining. And then I've been forgetting all the
places on the surface of the earth where nobody's currently standing...

I still find these numbers quite astonishing - don't ask me about details
of my calculations, it's been a while :-)
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

Nov 17 '05 #36

P: n/a


Jon Skeet [C# MVP] wrote:
Helge Jensen <he**********@slog.dk> wrote:
Do you mean 2^64? Not sure where the 109 comes from... (I'm not
familiar with the birthday paradox, and slightly too tired to bother
with the maths on the wikipedia entry :)
Actually, i mean 2^(218/2) = 2^109, got the char's 1,2 mixed up in
grandparent-post.


I thought that 218 was from your original post.... must have misread
you.... I need to go to bed :(
Why 218/2 though? A GUID is a 128-bit data type.
So, the "back-of-envelope" calculation, without typos is: 2^(128/2) =
2^64 < 10^20, which is still pretty large -- according to
http://en.wikipedia.org/wiki/Orders_...umbers%29#1018,
it's roughly the number of insects on earth, so they could get one each.
Ah, right. Yes, even I can follow that bit :)


I can see there is even a specific page on the birthday-attack:
http://en.wikipedia.org/wiki/Birthday_attack, doesn't say much though
and it doesn't explain the maths.

For a more specific solution, using n(n-1)~=n^2, a quick calculation
rewrites p(n;d)~= 1-e^(-n(n-1)/2d) = 0.5 to: n = sqrt(-ln 0,5 * 2d) ~=
2.17e+19 or 2^64.24. Which gives the 50% chance of collision after
slightly more than 2^64 samples.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
Nov 17 '05 #37

P: n/a
I would theorize that he doesn't know how to read considering what we've
heard to this point. I would also agree with your theory that he's a
jackarse.

The question has been correctly answered.

Nothing to see here people... Move along...

Bruce Wood wrote:
Sometimes when you are down the chain of command as a developer and the supervisor is a jack-ass, this is what you have to put up with.

Does the jackass know how to read newsgroups? :-o

Nov 17 '05 #38

This discussion thread is closed

Replies have been disabled for this discussion.