Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: Did the sort do anything? Date: Wed, 11 May 2011 23:27:38 +0200 Organization: A noiseless patient Spider Lines: 38 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 11 May 2011 21:27:37 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="Ifi0zMlPPHi1edxcIMhOmQ"; logging-data="14806"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19fKklcPsrAMPIu4G8umEwl" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:jkN5QQkUDEKfmc4kj6eQk/7vMjQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3991 On 11/05/2011 22:38, Tom Anderson allegedly wrote: > On Tue, 10 May 2011, Daniele Futtorovic wrote: > >> On 10/05/2011 17:06, Roedy Green allegedly wrote: >> >>> 4. do some sort of checksum before and after. >> >> I find the checksum idea quite intriguing, actually. It would have to >> do more operations than some kind of perhaps binary seep through, > > A binary seep? What's that, then? Uuhh... well... kinda like a binary sort, except you'd return (const bool NOT_ORDERED) instead of swapping. >> (although just as many if the list actually /is/ sorted). But the >> average greater efficiency of e.g. #hashCode() vs. #compare() might >> well offset that, meponders. > > Do you think hashCode is generally more efficient than compare? I would > have thought the opposite, because for hashCode, you have to examine all > an object's fields, whereas for a compareTo, you only have to examine as > many as it takes to find some which are different. Unless the hash is > cached, as in String. Yes, I thought so because of the caching. Any instance could cache the hashCode() at least between mutation of its data (theoretically, assuming it can track mutation), whereas a comparison cannot, because it compares against something different every time. In other words, between mutations, each invocation of hashCode() yields the same result, but each invocation of compare() potentially a different one (depending on what's compared against). -- DF. An escaped convict once said to me: "Alcatraz is the place to be"