Hi Paul
Thanks very much again for your help.
Yes, indeed ! I was interested in verifying about the even distribution of
hashcode values - perhaps prompted by the Integer hashcode implementation
(as you rightly pointed out) and also because of Robert Uzgalis's article
(which you would be most certainly aware of ). Looks very good.
Just a thought. There are some implementations which use different primes
for x, y, and z. Not aware of anything conclusive about their effectiveness.
My normal generator - based on recursively identifying smoothing groups
surrounding a vertex and generating new indices everytime a hard-edge
is detected - seems to be working well. I match exactly the coordinate
and index values from the GeometryInfo. Thanks for your example
on the simple cube to start with.
I deduce that there must have been some smart coding in GeomInfo in
creating the coordinate array to fit in with the IndexedGeometryArray.
For example, to ensure that the coordinate and normal counts
are the same, the coordinate array is exapnded and filled with zeros
(actually they could be any dummy values since the coordinate indices do
not refer to them anyways).
Again, just a thought. If the additional coordinate values filled in,
instead of being zeros, are the actual coordinate themselves ( which
would be of course duplicates of the ones that were input), then the
coordinateIndices and normalIndices can be made exactly identical.
One would then have to carry along only one of these arrays for
further processing. On the flip side though, the current design
is probably aimed at simply returning to the user the coordinateIndices
array that he sent in as input to GeometryInfo.
Thanks for all your tips
Raj Vaidya
> You shouldn't write any code that relies on a particular implementation
> of hashCode because it could change. But having used hashCode a lot
> I'm suspecting that you want to verify that the code produces an even
> distribution. Some classes in java do not - for example, the last time
> I looked at Integer.hashCode it just returns the integer. Here's the
> implementation of Tuple3f.hashCode:
> long bits = 1L;
> bits = 31L * bits + (long)Float.floatToIntBits(x);
> bits = 31L * bits + (long)Float.floatToIntBits(y);
> bits = 31L * bits + (long)Float.floatToIntBits(z);
> return (int) (bits ^ (bits >> 32));
> So it's using a very well distributed algorithm, combining the
> idea of multiplying by a prime number and also XOR'ing.
> -Paul
***************************************************************
"Copyright (c) 2001 Sun Microsystems, Inc. All Rights Reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
-Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
-Redistribution in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
Neither the name of Sun Microsystems, Inc. or the names of contributors may be
used to endorse or promote products derived from this software without
specific prior written permission.
This software is provided "AS IS," without a warranty of any kind. ALL
EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND ITS LICENSORS SHALL NOT BE
LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING
OR DISTRIBUTING THE SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS
LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT,
INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER
CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF
OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
You acknowledge that Software is not designed,licensed or intended for use in
the design, construction, operation or maintenance of any nuclear facility."
****************************************************************************
> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Date: Thu, 23 Aug 2001 11:16:17 -0700
> From: R Vegan <[EMAIL PROTECTED]>
> Subject: [JAVA3D] HashCode for Tuples
> To: [EMAIL PROTECTED]
>
> Hi Sun Team:
>
> I am interested in finding out explicit info. on how the
> hashcode for a Tuple object is generated - the API says
> it is derived from the elements of the object. Are the hashcodes
> XOR-ed together ? with prime coefficients or none ? Would you
> please give the details, in particular, for Point3f, Point3D,
> Tuple2i (?) and Tuple3i (?).
>
> Thanks in advance
>
> Raj Vaidya
>
> ============================================================================
> Raj Vaidya, PhD
> R&D
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
