0

I need your suggestions on how I should go about implementing an ever-increasing numbering system for my application. My application builds a graph in which its vertices are uniquely enumerated with integer. The problem I'm currently facing is the largest number representable by int or long, which poses an upper limit for the number of vertices a graph can accommodate.

All opinions are welcome here.

Thanks

cpp_noname
  • 2,031
  • 3
  • 17
  • 30
  • 2
    Many languages support a BigInteger type or class representing an arbitrary-precision integer. Which language are you using? What are the ranges of the values you're dealing with? – templatetypedef Jan 17 '12 at 11:13
  • @templatetypedef, My application is written in C++. Such a numbering system is required to have no upper bound so that my application can ideally generate new vertices forever as long as memory suffices. – cpp_noname Jan 17 '12 at 11:20
  • How many vertices does your graph have? Unless your graphs never have edges, in practice you're likely to run out of memory before you run out of integers. – DSM Jan 17 '12 at 11:22
  • @DSM, I would aim for millions of vertices. Most of vertices are short-lived. For this reason, they get destroyed almost immidiately after they get instantiated so running out of memory would be very unlikely. – cpp_noname Jan 17 '12 at 11:28
  • But millions is much, much less than the largest number representable even by a 32-bit unsigned int. – DSM Jan 17 '12 at 11:33
  • @DSM, you are right. That is the size of the current test cases I have, but in the near future the size of test cases I will have to run may exponentially grow, and I am required to get my application ready for such a change. – cpp_noname Jan 17 '12 at 11:42

1 Answers1

1

Use 64 Bit Integers (java: long, c/c++: long long).

You probably have not enough memory to store 2^63 graph nodes anyway, so you won't need more.

Remember: if every node stores its own index, using a 32 Bit index variable will require 16 gigabyte memory before you get your first collision.

jakob
  • 237
  • 1
  • 2
  • 16 GB is not so big for a high-end cluster, and most of the vertices will be destroyed as the program execution is in progress. – cpp_noname Jan 17 '12 at 11:35
  • That changes the situation a bit. However; you will still have to _write_ to at least 16 Gb of memory until your counter wraps around (even though you do not need them all at the same time). – jakob Jan 17 '12 at 16:00
  • Do you know any upper bounds on how many times you change the graph and how many nodes you create on every change? – jakob Jan 17 '12 at 16:06
  • some vertices of the graph will be eliminated over time, but the number of edges will tend to increase, making the graph denser. – cpp_noname Jan 18 '12 at 09:47
  • The elimination process will take place every time a memory upper bound has been reached, which is set to, say , 10 MB. – cpp_noname Jan 18 '12 at 09:48