> I'm not sure why you think a plain list would be O(N). It seems to me
> that it would be O(1).
I agree, my idea in the beginning was to split the largest range
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Algori
On Feb 23, 2:05 am, Ridvan <[EMAIL PROTECTED]> wrote:
> > I see no reason to use a sorted heap, a plain list
> > of ranges would do as well.
>
> This will lead to O(N) algo, i prefer O(lgN).
I'm not sure why you think a plain list would be O(N). It seems to me
that it would be O(1).
> > Once a
> I see no reason to use a sorted heap, a plain list
> of ranges would do as well.
This will lead to O(N) algo, i prefer O(lgN).
> Once again, why? Even if you a heap sorted by range size,
> just take the smallest one, and pick the min value. After
> reducing the range by one, if it's zero - get
On Feb 22, 9:01 am, Ridvan <[EMAIL PROTECTED]> wrote:
> Well if some preprocessing may be done just store the largest number
> and increase it.
>
> If the number has to be somewhere in between the 100 numbers I
> would do it in this way:
> Define a Range class: Range{int min, int max}
>
> In t
It seems that the intent of the problem was to work with the file to
find one unused number. If preprocessing can be done, just list the
numbers that are available (e.g., mark their availability in a bit
table) and use them one by one. If the member numbers are unbounded,
just list enough numbers
Well if some preprocessing may be done just store the largest number
and increase it.
If the number has to be somewhere in between the 100 numbers I
would do it in this way:
Define a Range class: Range{int min, int max}
In the preprocessing split the numbers to free Ranges.
Define Heap Whe
