On Fri, Nov 17, 2006 at 10:36:38PM +0100, David Squire wrote: > [EMAIL PROTECTED] wrote: > >wolfgang, david: > > > >the following is a difference in behavior in 32bit VS 64bit, in all > >versions of the feature extractor. > > > >specifically: > >the line reading: fprintf(out_file, "%d %d GABOR_HST SCALE, ORIENTATION, > >ENERGY UPPER BOUND = %d, %d, %f\n", feature_index, GABOR_HST, scale, > >orientation, j); > >is printing the result of a failed cast. j is type int, being printed as a > >float. this results in 0 on 32bit machines, and 10000 on 64bit machines. > >i'm assuming the 64bit behavior is correct, and correcting the 32bit > >version accordingly in my patch sets. > > > > This line does not actually affect anything at present. It is > documentation meant for humans. > > I am away travelling at present and don't have access to the code. > Still, from memory, the energy upper bound *should* be a float (or > double). What is j? > > Regards, > > David > > > -- > Dr David McG. Squire, Senior Lecturer. On sabbatical in 2006. > Caulfield School of Information Technology, Monash University, Australia > CRICOS Provider No. 00008C http://www.csse.monash.edu.au/~davids/ > It sounds to me like j was just the wrong variable. j is the integer that is being iterated against.
It HAPPENS that the 64bit code outputs 100000, which happens to coincide with the largest entry in "array" gabor_ranges. So, i'm betting you MEANT gabor_ranges[num_gabor_ranges-1]. I'm putting a patch that has that effect in my next patch set. Julia Longtin <[EMAIL PROTECTED]> _______________________________________________ help-GIFT mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gift
