Can I compare references (in a sense of compareTo method)?

[Lew]

Oops, seems I'm missing some posts . I'm reading this group at
google groups and cannot see that message from Patricia . The
message counter at the top of
http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/0394b3b3e68ff139/
shows that there are 18 messages in this thread, but there are
actually only 14 shown. Does this group has an archive somewhere else?

Once again Google Groups causes trouble.

There are just /so/ many reports of people having difficulties with Google
Groups.

Does your ISP have a news server? Mine (the local cable company) does,
through Giganews, and my subscription for 'net access includes something like
2 GiB downloads from news per month. I use Mozilla Thunderbird (free) for
access to it.

From everything I've read about it, I'd neither use nor recommend Google
Groups. In fact, if I were Google I'd be embarrassed to have my name
associated with it.

As to other archives, I believe they exist but in sort of the same way I
belief there's life on other planets. It makes sense that something exists
but I've got no direct evidence. Someone else, or perhaps a quick GIYF
search, could tell you.

 

[Lew]

I didn't mean to compare hashCodes. I didn't realize that the address
can change in lifetime of an object, so now I'm discouraged enough
from wanting to obtain it.

It not so much that the address can change in the JVM, as that the concept of
"address" in Java is not numeric. The more precise statement is that there
is no consistent, unique number that can be intrinsically derived from the
address.

Objects have referential identity, so in some sense there is an unchangeable
"address" to it; it's just not a number.

 

[Joshua Cranmer]

Oops, seems I'm missing some posts . I'm reading this group at
google groups and cannot see that message from Patricia . The
message counter at the top of
http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/0394b3b3e68ff139/
shows that there are 18 messages in this thread, but there are
actually only 14 shown. Does this group has an archive somewhere else?

T.

Google for "free news servers" and hook up to one of them from a
competent news reader; seeing that you are on Linux, I would recommend
Pan as a starting point.

Also check with your ISP to see if they provide a free newsserver.

 

[Lew]

Once again Google Groups causes trouble.

There are just /so/ many reports of people having difficulties with
Google Groups.

This one might not be against GG. The message I quoted from Patricia, and a
few that were in its subthread, are gone from my server / client as well.

 

[Tomas Mikula]

This one might not be against GG. The message I quoted from Patricia, and a
few that were in its subthread, are gone from my server / client as well.

Anyway, I installed Pan as Joshua suggested and connected to the
university's news server and see more messages than I could see on GG.

Tomas

 

[Roedy Green]

The more precise statement is that there
is no consistent, unique number that can be intrinsically derived from the
address.

Presumably there is a table indexed by object number pointing to the
current address of an object, at least in a simple-minded JVM. That
index number would give you a permanent object id. The catch is, when
an object were garbage collected, a new object could recycle its slot.
So your ids would be unique in time, but not unique over the life of
the job.

If you want unique ids that will work on any platform, including
native compilation, I think you will need to get the constructor do:

this.id = TheClass.id++;

in the constructor.

 

[Roedy Green]

I don't care about the actual ordering, but I wanted to use Tree*
since I thought it would have smaller memory overhead than Hash*

I think you need to do an experiment to verify that. I
suspect the opposite since you would need a node per element in both,
with the TreeSet having in addition the tree structure, where the
HashSet has a simple array of pointers.

It seems obvious to me that a HashSet should be FASTER than a TreeSet.
You go right to the element with a single division or mask, rather
than chasing down a multi-level index structure.

 

[Lew]

I think you need to do an experiment to verify that. I
suspect the opposite since you would need a node per element in both,
with the TreeSet having in addition the tree structure, where the
HashSet has a simple array of pointers.

It seems obvious to me that a HashSet should be FASTER than a TreeSet.
You go right to the element with a single division or mask, rather
than chasing down a multi-level index structure.

People are concerned with the corner case, wherein the hash distributes the
(presumably random) input so imperfectly that linear search time at the
appropriate hash bucket exceeds the log(n) performance of the tree search.
The argument seems to be that TreeFoo's guarantee of O(log(n)) search
complexity pays off since HashFoo would degrade to O(n) in that case.

Either the input is sufficiently random that the odds of this happening are
acceptable, given a good general-purpose hash, or there are expectations that
would cause a general hash to distribute values poorly, in which case one
should override hashCode() with a better choice of algorithm for the expected
input shape.

TreeFoo suffers insertion performance degradation compared to HashFoo, too,
doesn't it? So not only would the effort of providing and maintaining a
Comparator have to exceed that of writing a good hashCode(), and the odds that
the input would have the shape to trigger the scenario exceed the
worthwhileness threshold, but the Foo would have to be frequently read, rarely
written, to make the Tree version perform better than the Hash version.

Given the fragility of semantically superfluous code introduced for putative
performance gains absent hard evidence of such gain, the simplicity of an
alternative solution that is likely to handle the issue, and the so-far high
uncertainty that the nature of the data will even remotely justify the
attention, I recommend avoiding TreeFoo for this particular matter.

 

[Lew]

If you want unique ids that will work on any platform, including
native compilation, I think you will need to get the constructor do:

this.id = TheClass.id++;

in the constructor.

That static var might need synchronization, if the class is meant to be
thread-safe. Pre-emptively, one might wrap the get-and-increment in a static
method for present or future synchronization, or conversion of id to
AtomicInteger.

 

[Piotr Kobzda]

That static var might need synchronization, if the class is meant to be
thread-safe. Pre-emptively, one might wrap the get-and-increment in a
static method for present or future synchronization, or conversion of id
to AtomicInteger.

Even synchronizing it may not prevent from non-unique ids of two (or
more) distinct objects. When not all objects becomes garbage
immediately after use, the other short-time living objects may cause
overflow of the id.

Using time as part of the id may make it better (see java.util.UUID),
but even generation of ids like that requires extreme patience on corner
cases.


piotr