4096 Array Reader

>>58790117
I left in the commented out if-else block, so he can see how efficient it actually is.

I know efficiency was a concern in the original project, and he made note of a lot of comparisons, but it's actually only running 3 comparisons:
if (i + j) < 0, if (i + j) > 4096, and if (i + j) == 4096

It might be possible to crank down some other operations. I'm not sure. Possibly a few Arithmetic ones?

But, this should be pretty efficient.
And it DOES do what the guy needed.

function post(){
   if (guyIsOn = true){
      post.this = visible;
   } else {
      if (someoneIsLurk = true){
         sleep 3600;
         post();
      }
   }
}

>>58790117
>gets
Are you serious?
Didn't your compiler/linker give you the "YOU ARE A FUCKING IDIOT, WHAT ARE YOU DOING???" warning?

>>58790141
>doing bounds checking with if's rather than just using arithmetics
Full pleb mode, learn how to do long division and modulo operator.

>>58790206
That's just code I was using to hold the thing up while testing.

OFC, you'd use scanf() in normal code. I just needed the thing to pause while I was looking at it, and stay open at the end.

The only relevant code is the nested for-loop

>>58790230
I'm curious now. How could I actually use modulo in this?
It needs to check, specifically that the index being requested is a non-negative number less than the max size.

Modulo doesn't return negative numbers, and it can return 0 on many numbers that are not what I'm looking for.

If you can show me how this would also do this with Modulo, that'd be pretty cool, and I'd appreciate it

>>58790267
>That's just code I was using to hold the thing up while testing.
Such a statement is pointless.
>OFC, you'd use scanf() in normal code
No, in normal code, there would be nothing.

But basically what you have is a "crash my program because I'm stupid" statement. It reads potentially unbounded characters and can easily overflow any function, and you gave the damn thing an uninitialised pointer.
gets is a horrible, horrible function. It's so horrible they even removed it from C11.
It's the only function to have ever been removed from C.

What you're probably thinking of is getchar(), but again, you don't need to fucking pause your program.

>>58790290
>overflow any function
overflow any buffer*

>>58790267
Well, first of all, your test is nonsensical.

The first iteration, i = -1024 and j goes from 0 to 1023

So your test is always false, because -1024 + j for all values of j is < 0

Second iteration, only the last iteration is 0

Third iteration, second last and last iteration is 0 and 1 respectively.

Fourth iteration, i + j = {0, 1, 2} and so on

I'm will help you in a bit, but I have to run out for a while. But just think about that issue. It's the same for when i grows close to 4096.

The last iteration, i = 4096. j goes from 0 to 1024, but i + j will always be > 4096.

The second last iteration, i = 4095. Only the first round for j will have a valid value.

>>58790290
I needed to make sure that the output was correct and I could scroll through it in the Terminal.

Yeah, fine, though, getchar() would be better, but it was just debug code I left in.

It has not value for the program here. I can strip that gets() out AND the variable it assigns to, and it would make no difference for what the program needs to do, just that it might accidentally close on me when I was trying to look at the output.

The variable doesn't even need to exist.
If you prefer:

#include <stdio.h>

#define MAIN_SZ 4096
#define WINDOW_SZ 1024
#define INCREMENT 128

int main()
{
    int nums[MAIN_SZ];
    int window[WINDOW_SZ];

    for(int i = 0; i < MAIN_SZ; i++){
        nums[i] = i + 1;
    }
    for(int i = 0; i < WINDOW_SZ; i++){
        window[i] = i;
    }

    for(int i = -WINDOW_SZ; i <= MAIN_SZ; i += INCREMENT){
        printf("\n---------------------------\nNext Row: ");
        for(int j = 0; j < WINDOW_SZ; j++){
            /* * /
            if((i + j) < 0){
                window[j] = 0;
            }else if((i + j >= MAIN_SZ)){
                window[j] = 0;
            }else{
                window[j] = nums[i + j];
            }
            /* */
            window[j] = (((i + j) < 0) || ((i + j) >= MAIN_SZ)) ? 0 : nums[i + j];
        }
        for(int k = 0; k < WINDOW_SZ; k++){
            printf("%d ", window[k]);
        }
    }
    return 0;
}

However, that is interesting. I did not know that gets() was removed in C11
My compiler still has it in.

>>58790306
A, sorry, i increments by 128. But still, you should really look into the edge cases and remove those.

>>58790318
>>58790117
Your test is i + j >= MAIN_SZ, but nums is only MAIN_SZ big. nums[i + j] where i + j = MAIN_SZ is undefined (out of bounds).

its nice to see /g/ents working together for once :)

>>58790117
What is this supposed to do?

File: 4096Array-Explained-LessGoodThanOriginal.png (14KB, 1082x572px) Image search: [Google]

14KB, 1082x572px

>>58790306
>The first iteration, i = -1024 and j goes from 0 to 1023
The guy, for some reason, was starting at -896. IDK why, but he said the first run would read the first 128 values in in the last 128 cells.

>The last iteration, i = 4096. j goes from 0 to 1024, but i + j will always be > 4096.
His thing was supposed to have 1 round where it reads the last 128 cells into the first 128 cells of the window.

IDK WHY, but this is what he wanted.

I include the first and last round, specifically for testing, purposes.

>Fourth iteration, i + j = {0, 1, 2} and so on
No, it increments by 128 each time, again IDK why, but that's what the guy wanted.

I wish I saved the picture.

Lemme draw it quick

>>58790323
Well, I'll be back later, so if someone still comments, I'll be able to respond to it, but I'm not sure how to remove those edge cases, since they HAVE to be in it, according to the guy.

>>58790340
So, in that last test case, it should all be padded with 0s (for some reason)

>>58790383
see >>58790221

>>58790387
Improved it for you.

#include <stdio.h>

#define WINDOW_SZ 1028
#define ARRAY_SZ 4096
#define STEP 128


void fill_window(int* win, int win_sz, const int* arr, int arr_begin, int arr_end)
{
    int pos = 0;

    // edge case for when window range is before array position
    while (arr_begin < 0 && pos < win_sz)
    {
        win[pos++] = 0;
        ++arr_begin;
    }

    while (pos < win_sz && arr_begin < arr_end)
    {
        win[pos++] = arr[arr_begin++];
    }

    // edge case for when window range is after array position
    // arr_begin >= arr_end is implicit here if pos < win_sz is true
    while (pos < win_sz)
    {
        win[pos++] = 0;
    }
}


int main()
{
    int i, j;
    int array[ARRAY_SZ];
    int window[WINDOW_SZ];

    for (i = 0; i < ARRAY_SZ; ++i)
    {
        array[i] = i + 1;
    }

    for (i = -WINDOW_SZ; i <= ARRAY_SZ; i += STEP)
    {
        fill_window(window, WINDOW_SZ, array, i, ARRAY_SZ);

        for (j = 0; j < WINDOW_SZ; ++j)
        {
            printf(" %d", window[j]);
        }
        printf("\n\n");
    }

    return 0;
}

>>58790527
How is that an improvement, it's a lot more code to accomplish the same thing??

>>58790527
Hmmm, interesting.

But I don't really see how this would be more efficient?

In mine, every item had at most 3 comparisons.

In this, however, there is a minimum of 2 comparisons for each.
Although, it does cut down on a lot of my Arithmetic, so that's where it probably makes up.
This DOES, put a lot of calls on the stack, though, but it's hella easier to read.
IDK if it's definitively better, but it looks a lot more understandable.
(I still like my Ternaries, though...)

I do know the guy seemed to have a problem with using extra variables, though. I kinda understand him, but I think he was being a bit picky, there.

I actually found the thread I was helping with yesterday:
>>58777040

>Also, why did you change 1024 to 1028?
Typo?