I NEED TO CODE???

                    /* Put all coefficients to zero */
                    for (A = 0; A < 4; A++)
                    {
                        for (B = 0; B < 4; B++)
                        {
                            for (qq = 0; qq < 7; qq++)
                            {
                                for (ii = 0; ii < 3; ii++)
                                {
                                    for (ji = 0; ji < 3; ji++)
                                    {
                                        for (ki = 0; ki < 3; ki++)
                                        {
                                            coefg[A][B][ii][ji][ki][qq] = 0.0;
                                        }
                                    }
                                }
                            }
                        }
                    }

//This thread is now about why your coding conventions suck.
//I can abuse you and still use less space than your code.
//Abuse of /* is a particularly grievous sin; it's ridiculous
// that so many people still misuse it, resulting in it being
// impossible to comment out a block of code because of comments.
//Put all coefficients to zero
for (A = 0; A < 4; A++)
   for (B = 0; B < 4; B++)
       for (qq = 0; qq < 7; qq++)
           for (ii = 0; ii < 3; ii++)
               for (ji = 0; ji < 3; ji++)
                   for (ki = 0; ki < 3; ki++)
                      coefg[A][B][ii][ji][ki][qq] = 0.0;

>>2
Abuse of /* is a particularly grievous sin; it's ridiculous that so many people still misuse it, resulting in it being impossible to comment out a block of code because of comments.
Get a real editor.

memset(coefg, 0, sizeof(coefg));

>>2
It's a good practice to always use braces. Not because noobs fail ifs, but because whenever you want to nigger-debug any of these loops with printfs, you need to add braces, try it, then remove them, which is cumbersome and error-prone. This is why you want the forced indentation of code: it combines the no-braces with the multi-statement benefits.

>>4 wins

>>5
memset sets the bytes to zero, the original code sets the fields to zero >>4 does not win.

>>6
Which in this case does the same, unless the for limits are not the matrix sizes.

>>7
no.. learn C fag

>>8
you fail, gb2 visual basic

Since arrays with more than one dimension of do not get stored in one contigous region of memory, memset wouldn't work because it only works on contigous regions of memory. No doubt it would segfault as memset ran off the space allocated to the pointer coefg.

tl;dr:
>>4 fails.

Could someone explain?
if type of coefg[4][8][16][32][64][128] is float, then type of coefg[A][B][ii][ji][ki] is float *(technically it's "``array''", but in reality it's just pointer to array of 128 floats), and coefg[A][B][ii][ji] is float ** a pointer to array of 64 pointers, and coefg is float ******, pointer to array of 4 pointers; setting them to zero should fuck thing up, but it works perfectly.

OP you fail
tell us what coefg is.

sizeof coefg is 536870912, too;

reread the code: the only things that are getting set to zero are the elments of coefg[A][B][ii][ji][ki][qq]

>>14
I'm talking about memset(coefg, 0, sizeof(coefg));
It isn't supposed to work, and it works for me


#include <stdio.h>
#include <string.h>

int main()
{
    int array[10][10][10][10];

    int a, b, c, d;
    for (a = 0; a < 10; a++) {
        for (b = 0; b < 10; b++) {
            for (c = 0; c < 10; c++) {
                for (d = 0; d < 10; d++) {
                    array[a][b][c][d] = a + b + c + d;
                }
            }
        }
    }

    for (a = 0; a < 10; a++) {
        for (b = 0; b < 10; b++) {
            for (c = 0; c < 10; c++) {
                for (d = 0; d < 10; d++) {
                    printf("%d", array[a][b][c][d]);
                }
            }
        }
    }

    memset(array, 0, sizeof(array));

    for (a = 0; a < 10; a++) {
        for (b = 0; b < 10; b++) {
            for (c = 0; c < 10; c++) {
                for (d = 0; d < 10; d++) {
                    printf("%d", array[a][b][c][d]);
                }
            }
        }
    }

    return 0;
}

I just ran that and yeh, inexplicably, it works perfectly.
someone please explain this.

>>2
You should NEVER use /* ... */ to comment out code. This is the correct way to comment out code:
#if 0
code to be commented out here /* comments are handled fine too */
#endif

Now there are no issues with /* though of course allowing nested /* comments would be better..

Question: why some people use multiple comment characters, like
())(())()
;;;;;;;;;;;hurr durr
(()()(())

instead of

()()()()))()
;hurr durr
(()()))

>>18
for the same reason they do

/*
 ******************************
 ******HELLO WORLD EXAMPLE*****
 ******************************
*/

in case you still don't understand: because they're retarded.

>>19
agreed

From the Standard:

6.5.2.1 Array subscripting
Constraints
1 One of the expressions shall have type ‘‘pointer to object type’’, the other expression shall
have integer type, and the result has type ‘‘type’’.
Semantics
2 A postfix expression followed by an expression in square brackets [] is a subscripted
designation of an element of an array object. The definition of the subscript operator []
is that E1[E2] is identical to (*((E1)+(E2))). Because of the conversion rules that
apply to the binary + operator, if E1 is an array object (equivalently, a pointer to the
initial element of an array object) and E2 is an integer, E1[E2] designates the E2-th
element of E1 (counting from zero).
3 Successive subscript operators designate an element of a multidimensional array object.
If E is an n-dimensional array (n ≥ 2) with dimensions i × j × . . . × k, then E (used as
other than an lvalue) is converted to a pointer to an (n − 1)-dimensional array with
dimensions j × . . . × k. If the unary * operator is applied to this pointer explicitly, or
implicitly as a result of subscripting, the result is the pointed-to (n − 1)-dimensional array,
which itself is converted into a pointer if used as other than an lvalue. It follows from this
that arrays are stored in row-major order (last subscript varies fastest).

i'm not really sure if this means that the  the data in coefg is contigous in memory or not. I'd lean to "yes" given the evidence from the behaviour of the code.

>>21
Probably depends on the low level OS.

>>3
Agreed.

>>5
LEARN2DEBUG -- printf for that? What the fuck.

>>18
Coding style. Some people use more semicolons for "larger scope" comments (e.g. four = comment relates to entire file as a whole, e.g. boilerplate crap at the top, three = precedes a group of related functions, two = one function, one-semicolon comment on a separate line to document blocks of code within the function, and inline comments to document individual lines of code within those logical blocks.

also i fail at sage

>>18
Yeah. There was even some quasi-formal recommendation about Common Lisp commenting style.

I'm amazed at how hardly can you faggots fail. Being C fags and Gentoo ricers all day for this? You don't even know C! You fucking faggots!

In C, i[j][k] can be two different things, depending on how it's defined:

1. If you define i like int **i = malloc(X * sizeof(int *)), or int *i[X], you get a vector of pointers to i, which you're supposed to fill with dynamically-allocated memory. The type of i is int **, and it's not an "array" as far as C's concerned, just a double pointer. When you do i[j][k], C does *(*(i + j) + k). (This is the way Java does "arrays", BTW, which aren't true matrices because rows can have different lengths.)

2. If you define i like int i[X][Y] (where x and y are constants), you get an int array [Y]. This is the true C array. The compiler actually remembers Y, and allocates contiguous memory. Then when you do i[j][k], it actually does *(i + j * Y + k).

So in the case OP's array is an array, malloc will naturally work perfectly, and it's the recommended way to clear it.

>>4
>>26

and sizeof(coefg) is FAIL if it was dynamically allocated or a sparse array.

>>26
>>27
then what, oh oracle(s) is a sparse array?

>>23
You forgot the closing paren, which hurts my Lisp eyes.

int foo[5][5][5][5] = {{0},{0},{0},{0}};

WIN ? Y/N

>>30
c99, gtfo.

That extra line ended   up in there   because of a   multidimensional array object   If E is   in an illicit   affair with a   crash when the   stack overflows live   fast die young   public void Live?

36 Name: Anonymous 2012-01-12 3:38

OP's setting of all bits zero will work, in itself, depending on the way the memory is allocated. However, C does not guarantee or mandate IEEE 754 as the internal representation, so an all-bits-zero float is not necessarily 0.0.