| Newsgroups |
gmane.comp.gnu.gift.general |
| Message-ID |
<[email protected]> |
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]>