Thanks for that. The answer to the neighbour lookup is the idx1d can be decomposed
down to individual x, y, z components, and you can then calculate the idx1d for (x+1,y,z) say.
However you aren't sure if this idx1d is in the set of voxels you are looking at. Hence the
Judy array to invert the idx1d map. The alternative to this sort of thing is to use an Octree
to index the relevant voxels, which has some other drawbacks.
I'll let you know if I find anything out about getting it working.
Richard:I am curious as how this is done with a "hash table" method?
> The index above is primarily used to do neighbour lookup.Happy you like it.
> This is great stuff, and thanks for a fantastic bit of software.JudyLTables.c should be the same regardless of what compiler was used to
> My question is: do you think the fact that I am using the
JudyLTables.c generated from cygwin will matter?
compile JudyLTablesGen, with the caveat that 32 vs 64 bit compiles will
be different. So you should be OK with the way you are using it.I too am not familiar the MS compiler too, but I will pass on your problem
> (I'm not familiar with the MS compiler),
to someone that is. It would help if we knew more about the problem with
compiling JudyTables.c into JudyLTablesGen. (I do not have a MS
Good luck and thanks for your interest.
DougDoug Baskins <firstname.lastname@example.org>
From: Richard Boyes <email@example.com>
To: judy-devel <firstname.lastname@example.org>
Sent: Tuesday, March 17, 2009 9:19:18 PM
Subject: Judy & sparse volumetric indexing
Further to an email I sent a while ago, I recently used Judy to index a sparse volumetric array, and
compared it with an open addressed hash table that I coded myself.
The code I'm running performs operations over a region of interest within a volume (a medical image),
effectively turning arrays I'm using into a sparse data structure. The index above is primarily used to
do neighbour lookup.
The reason for this sparse data structure is to reduce processing time and memory usage.
The headline results were that the Judy array used ~1/4 - 1/3rd of the memory of my hash table (which had
a load of about 50%), while there was a slight improvement in the speed (average hash run time = x, average
judy run time = y), which was statistically significant in a t-test. This is great stuff, and thanks for a fantastic
bit of software.
However I'm working on windows with the MS compiler, and have not had much luck in getting the program
JudyLTablesGen to compile (I'm not familiar with the MS compiler), which, after reading the code, is used
to write out a program which sets up the JudyLTables.c file for compilation into the library.
Thus I am currently using the JudyLTables.c file that was generated by cygwin, and using the MS compiler to compile
all the subsequent *.c files (using the included build.bat script).
My question is: do you think the fact that I am using the JudyLTables.c generated from cygwin will matter? If
so I will try my best to get the MS compiler working on JudyLGenTables.c and hopefully get it even better.