Why am I multiplying when I want to divide (C)?

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
Here's the code:

Code:
p = 0;
		for ( i = 0; i < lp; i++)
			
				{
					p += fwrite(&Pt[i*pagesize], sizeof(char), pagesize, fp);
						
				}
		fclose(fpt);
		printf("%d\n", p);
		printf("%d %d \n",pagesize, p/pagesize);
Here's the output:

264600
5400 14288400

Does this make sense to anybody????
 

chown33

Moderator
Staff member
Aug 9, 2009
8,379
4,366
Pumpkindale
Does this make sense to anybody????
What are the types of p and pagesize?

Code:
#include <stdio.h>

int main (int argc, const char * argv[]) 
{
	size_t p;
	size_t pagesize;

	p = 264600;
	pagesize = 5400;

	printf("%d\n", p);
	printf("%d %d \n",pagesize, p/pagesize);

	printf("%d * %d = %d\n", p, pagesize, p*pagesize);
}
Output:
Code:
264600
5400 49 
264600 * 5400 = 1428840000
Notice that your unexpected output differs from the actual product by a factor of 100.
 

lloyddean

macrumors 65816
May 10, 2009
1,001
16
Des Moines, WA
The question seems about as malformed as the code fragment.

Looks to be writing an 'lp' count of 'pagesize' blocks of the array 'Pt' to the stream 'fp'.

The multiplication is used to calculate an 'offset' within the array 'Pt'.
 

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
Sorry, I don't understand. I've never declared a variable using size_t. Besides, I don't see any likelihood of overflow.

One of us is missing something.
I am writing lp pages sized pagesize to a file. p should be pagesize*lp but this is fact has little bearing on the two print statements that follow. If p is 264600 and pagesize in 5400, why is 264600/5400 not 49 as in chown's code.
 

lloyddean

macrumors 65816
May 10, 2009
1,001
16
Des Moines, WA
Code:
int fwrite( const void *buffer, size_t size, size_t count, FILE *stream );
What are the 'types' of 'p', 'i', 'lp', 'pagesize' and 'Pt[]'.

Further hint:

Code:
int fwrite( const void *buffer, size_t size, size_t count, FILE *stream );
The return value is the number of objects written.
 

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
You trying to out terse me.

Modifying the code doesn't change the output.
fwrite returns the number of bytes read, it was read in in chunks of pagesize.
a total of p/pagesize should print 49.
Code:
fpt = fopen(filename, "w");
		p = 0;
		for ( i = 0; i < lp; i++)
			
				{
					p += fwrite(&Ptrading[i*pagesize], sizeof(char), (size_t) pagesize, fpt);
						
				}
		fclose(fpt);
		printf("%d\n", p);
		printf("%ld %ld \n",(size_t)pagesize, (size_t)p/(size_t)pagesize);
P, i, lp are ints.
pagesize is #define to be 5400.
Pt is an array allocated to be much larger than lp*pagesize
 

chown33

Moderator
Staff member
Aug 9, 2009
8,379
4,366
Pumpkindale
Modifying the code doesn't change the output.
fwrite returns the number of bytes read, it was read in in chunks of pagesize.
a total of p/pagesize should print 49.
Instead of posting code fragments, and us trying to debug it without compilable context, please rewrite your code as a small isolated self-contained program that exhibits the problem.

You don't have to provide real data. You can use artificial data, generated in any manner (including not generated at all, in which case the output data will be all zeros).

All the data types, sizes, etc. should be identical to your real program.

You should allocate memory exactly like your real program.

You should write data (which was artificially generated) in the same manner as the real program does. Not doing so would defeat the point of the program.

You should have a main() function and whatever other functions you think make sense in a small self-contained program.

If the self-contained program doesn't exhibit the problem, then you have to figure out why that is.

If the self-contained program does exhibit the problem, then everyone else will be able to see it, and some may even be able to determine why.

As it stands now, you're the only one who has actual compilable code, hence the only one who has actual debuggable code. However, you also find yourself unable to debug that code.

The only way to solve the problem is to create the intersection of compilable code with debugging skills. If that intersection remains empty, then all you can do is solve the problem by accident.
 

lloyddean

macrumors 65816
May 10, 2009
1,001
16
Des Moines, WA
You trying to out terse me.
No not at all. I'm simply trying to give you and idea of what it's like when the other end of a conversation expects you to be a mindreader and work with assumed common information where there is none.

I was going to post something to the effect of what chown33 just posted so I'll let his stand.
 

jared_kipe

macrumors 68030
Dec 8, 2003
2,967
1
Seattle
The fact that p came out as 264600 when expressed as an integer does not necessarily mean it is an integer and will follow integer division.

Try
printf("%d %d \n",pagesize, (int)p/pagesize);
or maybe
printf("%d %d \n",pagesize, (int)p/(int)pagesize);

As an idea...

EDIT: my first inclination would be to also set a breakpoint down in there somewhere and observe the values.
 

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
guys.

On (too) many occasions, I have suffered because I have not posted the full code. You would easily see things I have missed. On the other hand, your responses, when not yelling at me, are usually helpful; I eventually get it. So let me just be a little more specific since my working skills preclude writing other test code until absolutely necessary. I'm an old dog stuck in my ways.

The file gets written to; I've looked at it and it seems ok. The division error seems to be out of left field. Do you a clue? Any suggestions where I should look.

thanks
 

lloyddean

macrumors 65816
May 10, 2009
1,001
16
Des Moines, WA
You get enough 'novice' mind readers together and eventually someone is going to have enough information to combine with their interpretation of your question in order to give you a 'useful' answer.

The fact is things could go quicker and you'd get more relevant response if you provided more complete questions and useful information with which to work.

I'm trying to be helpful but nothings happening ...
 

jared_kipe

macrumors 68030
Dec 8, 2003
2,967
1
Seattle
What platform are you compiling for?

Its like its putting 5400 into an odd size or something at compile time. Thus its not obeying normal arithmetic. or 264600 is getting converted to whatever type the compiler chose for 5400 and it gives weird results....
 

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
Jared

Yes, very odd. Haven't got a clue. pagesize is defined as

#define rows 10
#define cols 45
#define element 12
#define pagesize rows*cols*element
 

chown33

Moderator
Staff member
Aug 9, 2009
8,379
4,366
Pumpkindale
Yes, very odd. Haven't got a clue. pagesize is defined as

#define rows 10
#define cols 45
#define element 12
#define pagesize rows*cols*element
Bad define. Very bad.

Do a textual replacement on your original expression:
Code:
p/pagesize
The result will be:
Code:
p/rows*cols*element
The precedence of multiply and divide is the same, so figure out what the above evaluates to. (An exercise left for the reader.)

Redo your define as:
Code:
#define pagesize (rows*cols*element)
In general, always put parens around any macro body that contains an expression.
 

jared_kipe

macrumors 68030
Dec 8, 2003
2,967
1
Seattle
Yes, very odd. Haven't got a clue. pagesize is defined as

#define rows 10
#define cols 45
#define element 12
#define pagesize rows*cols*element
LOOOOOOOOOOOOLLLLLLL not odd anymore!

p/pagesize = p/10*45*12= 14288400

Its funny because I kept trying to figure out what was changing p or pagesize by a factor of 100. Well you took a factor of 10 out of pagesize and devided p by that factor of 10.
 

lloyddean

macrumors 65816
May 10, 2009
1,001
16
Des Moines, WA
farmerdoug,

Remember this, or did you ignore it, from the last thread.

Code:
#define kPAGES                  (2000)
#define kROWS                   (10)
#define kCOLUMNS                (45)
#define kBYTE_COUNT_PER_COLUMN  (12 * sizeof(char))
#define kBYTE_COUNT_PER_ROW     (kCOLUMNS * kBYTE_COUNT_PER_COLUMN)
#define kBYTE_COUNT_PER_PAGE    (kROWS * kBYTE_COUNT_PER_ROW)

char* allocate_memory(void)
{
    void*   ptr = calloc((kPAGES * (kROWS * kCOLUMNS)), kBYTE_COUNT_PER_COLUMN);
    if ( NULL == ptr )
    {
        printf("no memory");
    }

    return (char*)ptr;
}

//n = number of items to sort
void sort(char* array, int n, int row, int column)
{
    char    tmp[kBYTE_COUNT_PER_PAGE];

    #define INDEX(PP,RR,CC) ((PP * kBYTE_COUNT_PER_PAGE) + ((RR * kBYTE_COUNT_PER_ROW) + (CC * kBYTE_COUNT_PER_COLUMN)))
    #define DUMP(NN) for(int i=0; i<NN; i++) {printf("%s  \n ",&array[INDEX(i,0,3)]);}

    DUMP(n);

    printf("\n");

    for ( int j = (n - 1); j >= 0; j-- )
    {
        for ( int k = 1; k <= j; k++ )
        {
            if ( atoi(array + (k - 1)*kPAGES + row*kROWS + column*kCOLUMNS) > atoi(array + (k)*kPAGES + row*kROWS + column*kCOLUMNS) )
            {
                printf("\n");

                memcpy(tmp, &array[INDEX(k - 1, 0, 0)], kBYTE_COUNT_PER_PAGE);
                memcpy(&array[INDEX(k - 1, 0, 0)], &array[INDEX(k,0,0)], kBYTE_COUNT_PER_PAGE);
                memcpy(&array[INDEX(k,0,0)], tmp, kBYTE_COUNT_PER_PAGE);

                DUMP(n);
            }
        }
    }

   #undef INDEX 
   #undef DUMP
}
Note the use of parentheses to FORCE proper expansion and association of math operators during expansion.

Again, please, please, PLEASE given complete definitions of ALL variables and macros in ANY and ALL code posts for the quickest most useful responses.

Anyway have and nice weekend.

EDIT: This hasn't been compiled and was done off the top me me head and may contain syntax errors
 

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
Lloyd

No, I didn't remember it. Thanks for the help. Can't have a good weekend until this code is done LOL. Best.
 

Sydde

macrumors 68020
Aug 17, 2009
2,105
2,164
IOKWARDI
Always use parens, even when you think they might not be needed. Consider this little error I made not too long ago:

Code:
  int   eventKeys[[NSApp currentEvent] modifierFlags];
   if ( eventKeys&NSShiftKeyMask != 0 ) {
      // extend the selection
   }
The if statement did not execute correctly because "&" has a lower priority than "!=" - the fix was "( (eventKey&NSShiftKeyMask) != 0 )", though admittedly the "!= 0" part is kind of redundant.