Carl,
There is nothing wrong with the code. It is good C code from the good ole days.
Size of pointers has no effect, other than in the total sizes of the arrays
being allocated. Similar for the size of ints themselves.
However, you stop short in your example, and you don’t show either how you 1)
put values into the arrays, or 2) use those values. I would guess the problem
is in one of those two places, and not in the allocation of the arrays nor in
the nature of 64-bit arithmetic.
I would recommend you insert some code directly after you create the arrays,
that first loads them with a simple pattern of values, and you then immediately
print them out or look at them with a debugger. You need to first assure
yourself that the arrays are holding exactly what you think they should be
holding before you start looking at the overall results of arithmetic
operations.
Good luck,
Tom Wetmore
> On Jul 6, 2015, at 3:38 PM, Carl Hoefs <newsli...@autonomy.caltech.edu> wrote:
>
> We have a legacy Cocoa library of mathematical algorithms that has worked
> fine since OS X 10.6, but running this same code on 10.10 results in odd
> numerical errors (that is, incorrect results). I'm thinking this could be
> the result of differences in ILP32 vs LP64?
>
> The code variables are ints and pointers, and there's a bunch of memory
> allocation for arrays that looks fragile. I know that the size of ints has
> not changed, but pointers have gone from 4 bytes to 8 bytes in LP64. Could
> this be the problem?
>
> Here's a sample of affected code:
>
> int ***hov;
>
> /* memory allocation for data arrays */
> if((hov=(int ***)malloc(LNUM*sizeof(int **)))==NULL)
> {
> fprintf(stderr,"Error in memory allocation for hov!\n");
> return(-1);
> }
> for(k=0;k<LNUM;k++)
> {
> if((hov[k]=(int **)malloc(XDIM*sizeof(int *)))==NULL)
> {
> fprintf(stderr,"Error in memory allocation for hov[%d]!\n",k);
> return(-1);
> }
> for(i=0;i<XDIM;i++)
> {
> if((hov[k][i]=(int *)malloc(YDIM*sizeof(int)))==NULL)
> {
> fprintf(stderr," in memory allocation for hov[%d][%d]!\n",k,i);
> return(-1);
> }
> }
> }
>
> /* calculate total field in deg^2 tested per level */
> TOTAL_VF=XDIM*YDIM*(GRES/60.0)*(GRES/60.0);
>
> . . . etc.
>
> I've tried promoting the ints to longs, but the errors in the mathematical
> computations became much worse.
> -Carl
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ttw4%40verizon.net
>
> This email sent to t...@verizon.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
