Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-120121-

Pascal's triangle

Name: Anonymous 2012-01-05 17:41

Motivated by the Hacker News challenge in http://news.ycombinator.com/item?id=3429466 I just made this.


#include <stdio.h>
#include <stdlib.h>

int64_t* next_pascal_row(int64_t* previous_row, int64_t previous_size)
{
  int64_t* retval = (int64_t*)malloc(sizeof(int64_t)*(previous_size+2));
  int64_t i;
  for (i=0;i<previous_size+1;i++) {
    if (i==0 || i == previous_size) {
      retval[i] = 1;
    } else {
      retval[i] = previous_row[i-1] + previous_row[i];
    }
  }
  return retval;
}

void print_row(int64_t* row, int64_t size)
{
  int64_t i;
  for(i = 0; i < size; i++) {
    printf("%lld ",row[i]);
  }
  printf("\n");
}

int main()
{
  int64_t* first_row = (int64_t*)malloc(sizeof(int64_t));
  int64_t* previous_row;
  int64_t* next_row;
  int64_t i,size;
  first_row[0] = 1;
  size = 1;
  print_row(first_row,size);
  previous_row = first_row;
  for(i = 0; i<30;i++) {
    next_row = next_pascal_row(previous_row,size);
    size++;
    print_row(next_row,size);
    free(previous_row);
    previous_row = next_row;
  }
  free(next_row);
}

Opinions? Yeah, int64_t is probably a GNU extension, I don't care as long as it works with gcc. U mad? Also, post you're own solutions. If you can't do the Pascal, you can just go ahead and apply to your're nearest McDonald's, because you ain't worth shit.

Name: Anonymous 2012-01-05 17:41

Not PASCAL, didn't read.

Name: Anonymous 2012-01-05 17:47

Looks like crap. I did this, in C, in my college entrance exam (not in the US, I have no idea if there's such a thing there) and it didn't look like crap. I don't remember much else. Please, don't turn this into another fizzbuzz.

Name: Anonymous 2012-01-05 18:01

>>3
Listen, jerkface.

If you wish to assume the role of a post-USSR mathematical genius you better start posting some evidence that you're just a good-for-nothing blabbermouth.

Name: Anonymous 2012-01-05 18:33

>>1
And what do you do for a living? BTW, there are two three memory leaks in your program.

Name: Anonymous 2012-01-05 18:34

>>5
No there isn't. Every int64_t array that's malloced gets freed.

Name: Anonymous 2012-01-05 18:38

>>4
Fortunately, I missed USSR by one step to the west. I'm just about the furthest imaginable thing from a mathematical genius but I know how to write simple solutions to simple problems.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 18:42

>>6
You still haven't told us what you do for a living. But yes, there is at least one memory leak. Pstt.. it's in main() you stupid fucker.

Name: Anonymous 2012-01-05 18:50

>>8
There is just one malloc()'d pointer in main() and it is free()'d because the for-loop is entered at least once. See, first_row is assigned to previous_row just before the loop and previous_row is free()'d after that. Pointers malloc()'d by next_pascal_row are free()'d by the same row, with the exception of the last one which is free()'d just after the loop.

But I provide expensive senior software engineering services to our client company as my nine to five job, if that was what you were asking.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 18:54

>>9
Take a closer look at main(). 

int64_t* first_row = (int64_t*)malloc(sizeof(int64_t));

This line will cause a memory leak if the sign changes. Now there is another leak in main(). And for anyone that has a clue about C, please don't help this mental midget.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 18:56

>>10
Also, I'm following ANSI/ISO C89 standards.

Name: Anonymous 2012-01-05 19:00

>>10
The sign of what? That does make zero sense. Sign of sizeof(int64_t)?

int64_t* represents a pointer to a memory area full of int64_ts.  A sign change here is an impossibility and makes no semantical sense.

WTF?

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 19:02

>>12
Listen you stupid fucker. What happens if the bit pattern is becomes unsigned? There will be a memory leak.

  A sign change here is an impossibility and makes no semantical sense.

A sign change is a possbility. The fact that you think it's impossible leads me to believe that you've never written a single line of real C code in your entire life. Also, a compiler can't detect a sementic error.

Name: Anonymous 2012-01-05 19:04

>>12
Now what's the range of int64_t you stupid shit jew? Now, compare this range to an unsigned int you stupid fucker. Now shut up and learn something.

Name: Anonymous 2012-01-05 19:05

>>13
sementic
Wanker.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 19:07

>>15
Admit it. This guy is a bigger retard than FrozenRetard, I mean FrozenVoid.

Name: Anonymous 2012-01-05 19:09

>>13
uh what. int64_t* is a pointer type sharing the same value range as int*, void* or char*. The fact that it points to signed values is just a coincidence. Pointer is a pointer, and it's safe to cast the return value of malloc() to any kind of pointer.

I am not casting a pointer to a signed integer. Pay attention to the asterisks.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 19:12

>>17
But what it points at will cause a memory leak. An yes, the bit pattern is signed. Maybe you should just shut the fuck up and take read the ANSI/ISO C89 standard. Also, you still haven't told me where the other memory leak in main() is?

Geeze, I'm I gonna have to run a memory profiler against your shit code and post the results for you?

Name: Anonymous 2012-01-05 19:12

Hacker News
I'm sorry, I can't hear you over the sound of a million dead Steve Jobs cocks in your mouth.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 19:15

>>17
There is also a semenatic error in the for loop in print_row(). In other words, depending on the system, the results might not actually display to the screen.

void print_row(int64_t* row, int64_t size)
{
  int64_t i;
  for(i = 0; i < size; i++) {
    printf("%lld ",row[i]);
  }
  printf("\n");
}

Name: Anonymous 2012-01-05 19:15

>>18
As far as I know, I can malloc whatever I want and free cleans it up as far as I use the same pointer and don't do any dirty tricks. I also ran the code with instrumentation and checked that amounts of malloc and free match up.

GCC guarantees it.

Name: Anonymous 2012-01-05 19:17

>>20
But it works on my systems and adheres to the definition of printf(). If you're comjpiler doesn't support %lld, well, fuck you then.

Name: Anonymous 2012-01-05 19:19

>>21
Yes, that's true for a signed int. But again, what happens if the int becomes unsigned? Again, there will be a memory leak. And yes, there are trivial situations where something like this could happen.

Name: kodak_gallery_programmere !!kCq+A64Losi56ze 2012-01-05 19:20

>>22
I said it was a semantic error. In other words, the code will pass the compilation phase. However, the error will occur during run time. Holy shit you're one stupid fucker. Please tell me your trolling.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 19:22

>>24
Now please refer to ANSI/ISO C89/99 for a more detailed explanation on what a semantic error is.

Name: Anonymous 2012-01-05 19:22

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-05 19:27

>>24
*you're*

Name: Anonymous 2012-01-05 20:23

My try. Please don't laugh too much. ANSI C.


/*public domain*/
#include <stdio.h>
#define MAX 512

int main() {
    int i, j, row_to_print, pascal[MAX][MAX];
    scanf("%d", &row_to_print);
    if (row_to_print == 1) {
        printf("1");
        return 0;
    }

    pascal[0][0]=1;
    for (i=1; i<row_to_print; i++) {
        pascal[i][0]=1;
        pascal[i][i]=1;
    }
    for (i=2; i<row_to_print; i++)
        for (j=1; j<i; j++)
            pascal[i][j]=pascal[i-1][j]+pascal[i-1][j-1];
    for (j=0; j<row_to_print; j++)
        printf("%d ", pascal[row_to_print-1][j]);
    return 0;
}

Name: Anonymous 2012-01-05 20:34

(define (p n)
  (define (q l)
    (if (null? (cdr l))
      '()
      (cons (+ (car l) (cadr l))
            (q (cdr l)))))
  (if (= n 0)
    '(1)
    (append '(1)
            (q (p (- n 1)))
            '(1))))

Name: Anonymous 2012-01-05 20:44

Apart from the memory leaks, malloc is still slow as fuck and should be avoided if possible.

Name: Anonymous 2012-01-05 20:54

'
>thread about Pascal's triangle
>not written in Pascal

Name: Anonymous 2012-01-05 20:56

>>28
This is actually a simple solution to a simple problem. Won't bother if it's O(fast) but it's way better than that faggot's convoluted answer to a simple problem.

Hey, kodak. Fuck off, ``faggot".

Name: Anonymous 2012-01-05 21:00

>>32
>implying it wasn't long established that kodak is a shitty troll

Name: Anonymous 2012-01-05 21:26



program Pascal;

var counter as integer;
var ptLine as integer[20];

procedure Step(istep as integer);
var couter as integer;
begin
ptLine[istep] := 1;
if (istep<>1) then write( " " + ptLine[1]);
if (istep>=3) then begin
for couter := 2 to istep-1 do begin
    ptLine[couter] = ptLine[couter] + ptLine[couter-1];
    write(" " + ptLine[couter]);
    end;
end;
writeln(" " + ptLine[istep]);
end;

begin
for counter:=1 to 20 do begin
    Step(counter);
    end;
end.

Name: Anonymous 2012-01-05 21:59



for couter := istep-1 downto 2 do begin
    ptLine[couter] = ptLine[couter] + ptLine[couter-1];
    write(" " + ptLine[couter]);
    end;
end;


^^ Fixed (? hopefully)

Name: Anonymous 2012-01-05 22:14

#include <cstdint>
#include <cstdlib>
#include <iostream>

uint64_t fact(uint64_t n) {
    if (n == 0 || n == 1) {
        return 1;
    }
    uint64_t r = 1;
    while (n != 1) {
        r *= n--;
    }
    return r;
}

uint64_t pascal(uint64_t row, uint64_t col) {
    if (col > row) {
        return UINT64_MAX;
    }
    return fact(row)/(fact(col)*fact(row-col));
}

int main(int argc, char** argv) {
    if (argc < 3) {
        std::cout << "Usage: " << argv[0] << " row1 row2" << std::endl;
        return 0;
    }
    unsigned int row1 = std::abs(std::atoi(argv[1]));
    unsigned int row2 = std::abs(std::atoi(argv[2]));
    for (int r = row1; r <= row2; ++r) {
        for (int i = 0; i <= r; ++i) {
            std::cout << pascal(r, i) << " ";
        }
        std::cout << std::endl;
    }
    return 0;
}

Name: Anonymous 2012-01-05 22:15

Truly embarassing! Apologies to all.

#include <cstdint>
#include <cstdlib>
#include <iostream>

uint64_t fact(uint64_t n) {
    if (n == 0 || n == 1) {
        return 1;
    }
    uint64_t r = 1;
    while (n != 1) {
        r *= n--;
    }
    return r;
}

uint64_t pascal(uint64_t row, uint64_t col) {
    if (col > row) {
        return UINT64_MAX;
    }
    return fact(row)/(fact(col)*fact(row-col));
}

int main(int argc, char** argv) {
    if (argc < 3) {
        std::cout << "Usage: " << argv[0] << " row1 row2" << std::endl;
        return 0;
    }
    unsigned int row1 = std::abs(std::atoi(argv[1]));
    unsigned int row2 = std::abs(std::atoi(argv[2]));
    for (int r = row1; r <= row2; ++r) {
        for (int i = 0; i <= r; ++i) {
            std::cout << pascal(r, i) << " ";
        }
        std::cout << std::endl;
    }
    return 0;
}

Name: Anonymous 2012-01-05 22:44

>>28
Square array = wasted memory. Also, using stack space is bad.
>>37
Using stack space is bad.
>>1
Multiple mallocs = slow.

And I present to you... the best pascal.c in this thread. Only uses enough memory to hold all the numbers. It's also the fastest-running program.

#include <stdio.h>
#include <stdlib.h>
#define NTH_IN_ROW(r, n) (((r) * (r) + (r)) / 2 + (n))
int main() {
        long *a, i, j, r;
        scanf("%ld", &r);
        a = malloc(sizeof(long) * ((r + 1) * (r + 1) + r + 1) / 2);
        for (i = 0; i <= r; i++) {
                a[NTH_IN_ROW(i, 0)] = 1;
                a[NTH_IN_ROW(i, i)] = 1;
                if (i > 1)
                        for (j = 1; j < i; j++)
                                a[NTH_IN_ROW(i, j)] =
                                        a[NTH_IN_ROW(i - 1, j)] +
                                        a[NTH_IN_ROW(i - 1, j - 1)];
        }
        for (j = 0; j <= r; j++)
                printf("%ld ", a[NTH_IN_ROW(r, j)]);
        putchar('\n');
        return 0;
}

Name: Anonymous 2012-01-05 22:56

>>38
not bothering to verify if correct, but, that is some nice looking code

Name: Anonymous 2012-01-05 22:57

./pascal = >>38
./a.out = >>1
delan@pluto ~ $ time echo 10000 | ./pascal > /dev/null

real    0m4.244s
user    0m3.690s
sys     0m0.530s
delan@pluto ~ $ time echo 10000 | ./a.out > /dev/null

real    0m47.387s
user    0m47.210s
sys     0m0.170s


OP is an idiot.

Name: Anonymous 2012-01-05 22:58

>>39
Thank you.

Name: Anonymous 2012-01-05 23:00

>>37
Only appears to make correct answers for first 20 rows; 21 and later are completely wrong, and the 66th row causes a SIGFPE.

Name: Anonymous 2012-01-05 23:03

>>1
I've also discovered that going up into high row numbers, there are lots of huge negative values in the triangle, immediately signalling that your program gives the wrong result.

Name: Anonymous 2012-01-05 23:07

>>43
ould be integer overflow

Name: Anonymous 2012-01-05 23:08

>>44
That is true. Still, >>1 takes over ten times as long for row 10000 as >>38, according to >>40.

Name: Anonymous 2012-01-05 23:46

>>38
Amazing. The NTH_IN_ROW macro is specially clever. Hats off to you.

Name: Anonymous 2012-01-05 23:57

>>46
2/10

Name: Anonymous 2012-01-06 0:09

>>46
Thank you. I wanted my implementation to be as memory-efficient as possible.

Name: Anonymous 2012-01-06 0:12

>>42
Yes, that is because I use factorials. When fact(n) starts returning UINT64_MAX (18446744073709551615) or overflowing, the division in pascal() stops working properly. The SIGFPE happens when pascal() tries to divide by zero because of an overflow in either fact(col) or fact(row-col) which perchance happens to make either of them 0.
It shows up as early as row 20 because factorials grow faster than the binomial coefficients.

If one tried hard enough they could exploit the fact that n!/k! for k < n is the same as n*(n-1)*...*(k+1), to make it not overflow as quickly.

Name: Anonymous 2012-01-06 0:14

>>49
Isn't the use of factorials extremely slow, especially as your factorial results aren't cached? Wouldn't it be faster to iteratively add?

Name: Anonymous 2012-01-06 0:30

>>50
I don't particularly care about the speed, though. It would certainly be faster to add, as well as less error prone, because you can't trivially eliminate the factorial divisions and so things overflow rapidly.

The below works properly with row 20, but still gives incorrect results quickly:

uint64_t mul(uint64_t n, uint64_t k) {
    if (k >= n || n == 0) { return 1; }
    if (k == n-1) { return n; }
    uint64_t r = 1;
    while (n > k) {
        r *= n--;
    }
    return r;
}

uint64_t pascal(uint64_t row, uint64_t col) {
    if (col > row) {
        return UINT64_MAX;
    }
    if (col > row-col) {
        return mul(row, col)/fact(row-col);
    } else {
        return mul(row, row-col)/fact(col);
    }
}


Not to mention that going as far as implementing caching for something like this would be going way too far. I'm sure the cleanest, simplest and probably most efficient version will end up being >>38's.

Name: Anonymous 2012-01-06 0:32

sub pascal { [1], -> @p { [0, @p Z+ @p, 0] } ... * };

http://rosettacode.org/wiki/Pascal's_triangle

Name: Anonymous 2012-01-06 0:33

>>38
You could save a lot more memory by storing only the last and current rows, but I believe the malloc time overhead would be large.

Name: Anonymous 2012-01-06 0:35

>>53
How about allocating two arrays of n_rows length? That'd make the memory complexity O(2r) => O(r) (as opposed to O((r*r+r)/2) => O(r^2)) and still only require one or two (constant) malloc calls.

Name: Anonymous 2012-01-06 0:36

>>54
Hmm, didn't think of that. I could modify my pascal.c to implement that, thanks.

Name: Anonymous 2012-01-06 1:52

>>11
C89 doesn't have int64_t so of course that code doesn't conform.

Name: Anonymous 2012-01-06 5:31

Just to let you know, I've just finished scrubbing another toilet. What have you done in the meantime?

Name: Anonymous 2012-01-06 6:48

>>57
I added a bunch of mutexes to my functions.

Name: Anonymous 2012-01-06 7:45

>>57
I've begun a C and FastCGI-based imageboard.

Name: Anonymous 2012-01-06 7:59

From article:
>That gives a row from a Pascal triangle



#!/bin/python
def main():
    print("Gief number plox")
    row = input()
    print "row", row, "is"
    for i in xrange(row+1):
        print(fac(row)/(fac(i) * fac(row-i)))

def fac(x):
    if x<=1:
        return 1
    else:
        return x * fac(x-1)

main()

herpderp

Name: Anonymous 2012-01-06 8:08

>>60
>using the slower factorial method over the faster iterative addition method (time complexity: O(fuckingretarded))
>using input() instead of int(raw_input()) (allowing user code injection)
>using python
>using /bin/python which no known distribution uses instead of /usr/bin/python or better /usr/bin/env python

Name: Anonymous 2012-01-06 8:14

>>61
I haven't used python in a year. Cut me some slack.
Also, if I do raw_input() it'd be a string and I'd have to recast it.

Name: Anonymous 2012-01-06 8:17

>>62
There is no excuse for using Python at all. Also, using input(), like I said but you couldn't read, allows users to break your program with errors, and/or run code in the program with their input. This is fucking retarded.

Name: Anonymous 2012-01-06 8:24

>>63
This isn't meant to be enterprise code that millions of dollars depend on. It's a small sample to demonstrate a way of generating a row of Pascal's triangle.
If you can write better code than this, that's great for you. But don't get so worked up over every irrelevant detail, being butthurt doesn't help anyone.
You don't want to get a heart attack before you're 50.

Name: Anonymous 2012-01-06 8:40

>>64
Having a shitty time complexity is a BIG FUCKING DEAL.

Name: Anonymous 2012-01-06 8:50

>>65
It's a real deal in other situations and not relevant in this one.

Name: Anonymous 2012-01-06 8:50

>>66
Not relevant? How's blowing out reasonable runtime for any non-trivial triangle size?

Name: Anonymous 2012-01-06 8:53

>>67
I  don't do much mathematical processing (like in graphics or physics or other calculations), and I've never needed to deal with triangles like this in any of my work.

Name: Anonymous 2012-01-06 8:57

>>68

I
And therein lies the fallacy in your argument.

Name: Joseph D. Darcy 2012-01-06 12:56

Here is the ROBUST SCALABLE ENTERPRISE SOLUTION, it came out a lot faster than the program in >>38 I'm guessing this is more cache efficient. It's also more robust when it comes to bad input. I decided not to comment this time since some of you showed some ill-will the last time I did that.

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>

int main (int argc, char **argv) {
  unsigned long int * over = NULL, * under = NULL;
  unsigned long int n = 0, i = 0;

  if (argc < 2) {
    fprintf(stderr,
        "usage: %s n\n",
        argv[0]);
    exit(EXIT_FAILURE);
  }

  errno = 0;
  n = strtoul(argv[1], NULL, 0);

  if (errno) {
    fprintf(stderr,
        "invalid literal for an unsigned integer: %s\n",
        argv[1]);
    exit(EXIT_FAILURE);
  }

  if (!n) {
    fprintf(stderr,
        "invalid value for n: %lu\n"
        "must be greater than zero\n",
        n);
    exit(EXIT_FAILURE);
  }

  over = malloc(n * sizeof(unsigned long int));

  if (over == NULL) {
    fprintf(stderr,
        "failed to allocate array\n");
    exit(EXIT_FAILURE);
  }

  under = malloc(n * sizeof(unsigned long int));

  if (under == NULL) {
    fprintf(stderr,
        "failed to allocate array\n");
    exit(EXIT_FAILURE);
  }

  over[0] = 1;

  for (i = 1; i < n; i++) {
    unsigned long int * temp = NULL;
    unsigned long int j = 0;

    under[0] = under[i] = 1;

    for (j = 1; j < i; j++)
      under[j] = over[j-1] + over[j];

    temp = over;
    over = under;
    under = temp;
  }

  for (i = 0; i < n; i++) {
    printf("%lu", over[i]);
    if (i != n-1)
      putchar(' ');
  }
  putchar('\n');

  free(over);
  free(under);

  exit(EXIT_SUCCESS);
}

Name: Anonymous 2012-01-06 12:56

>>68
Enjoy your O(22n) ``intuitive'', ``gets the shit done'' algorithms.

Name: Anonymous 2012-01-06 13:47

ENTERPRISE JAVA SOLUTION


[ @ ~/fhost/prog/pascal ] $ cat p.java
import java.util.ArrayList;
import java.util.List;

public class p
{
    private static final String SPACE = " ";
    public static void main(String args[])
    {
        print(pascal(Integer.parseInt(args[0])));
    }

    private static void print(final List<StringBuilder> a)
    {
        StringBuilder cur;
        int len = a.get(a.size()-1).length();
        int len2 = len/2;
        for(int i=0;i<a.size();++i){
            cur = mkspc(len2-a.get(i).length()/2,len);
            cur.append(a.get(i));
            System.out.println(cur);
        }
    }

    private static StringBuilder mkspc(int len,int max)
    {
        StringBuilder sb = new StringBuilder(max);
        for(int i = 0;i<len;++i)
            sb.append(SPACE);
        return sb;
    }

    private static List<StringBuilder> pascal(int n)
    {
        List<StringBuilder> r = new ArrayList<StringBuilder>();
        StringBuilder sb;
        long coe;
        int i,j;
        for(i=0;i<n;++i){
            sb = new StringBuilder(i*2);
            for(j=0;j<=i;++j){
                coe = fact(i)/(fact(j)*fact(i-j));
                sb.append(Long.toString(coe));
                sb.append(SPACE);
            }
            r.add(sb);
        }
        return r;
    }

    private static long fact(int n)
    {
        return(n<=1 ? 1 : n * fact(n-1));
    }
}
[ Fri Jan 06 01:43:30 ]
[ @ ~/fhost/prog/pascal ] $ java p 10
             1
            1 1
           1 2 1
          1 3 3 1
         1 4 6 4 1
       1 5 10 10 5 1
      1 6 15 20 15 6 1
    1 7 21 35 35 21 7 1
   1 8 28 56 70 56 28 8 1
1 9 36 84 126 126 84 36 9 1
[ Fri Jan 06 01:46:44 ]
[ @ ~/fhost/prog/pascal ] $ java p 20
                                               1
                                              1 1
                                             1 2 1
                                            1 3 3 1
                                           1 4 6 4 1
                                         1 5 10 10 5 1
                                        1 6 15 20 15 6 1
                                      1 7 21 35 35 21 7 1
                                     1 8 28 56 70 56 28 8 1
                                  1 9 36 84 126 126 84 36 9 1
                              1 10 45 120 210 252 210 120 45 10 1
                            1 11 55 165 330 462 462 330 165 55 11 1
                          1 12 66 220 495 792 924 792 495 220 66 12 1
                      1 13 78 286 715 1287 1716 1716 1287 715 286 78 13 1
                   1 14 91 364 1001 2002 3003 3432 3003 2002 1001 364 91 14 1
               1 15 105 455 1365 3003 5005 6435 6435 5005 3003 1365 455 105 15 1
           1 16 120 560 1820 4368 8008 11440 12870 11440 8008 4368 1820 560 120 16 1
       1 17 136 680 2380 6188 12376 19448 24310 24310 19448 12376 6188 2380 680 136 17 1
    1 18 153 816 3060 8568 18564 31824 43758 48620 43758 31824 18564 8568 3060 816 153 18 1
1 19 171 969 3876 11628 27132 50388 75582 92378 92378 75582 50388 27132 11628 3876 969 171 19 1



u jelly?

Name: Anonymous 2012-01-06 16:08

int main()
{
   int col;
   printf("Which column to print? ");
   scanf("%d",&col);
   printPascal(col);
   return 0;
}

Implementation of printPascal function is left as an exercise for the reader.

Name: Anonymous 2012-01-06 18:39

This one should use up the least memory. Works until integer overflow happens.
#include <stdio.h>
#include <stdlib.h>

int main (int argc, char **argv) {
    unsigned long int inputrow, i, j;
    unsigned long int *row;
    scanf("%ld", &inputrow);
    row = malloc(inputrow*sizeof(unsigned long int));
    row[0] = 1;
    for(i=1; i<inputrow; i++) {
        row[i]=1;
        for(j=i-1; j>0; j--)
            row[j]+=row[j-1];
    }
    for(i=0; i<inputrow; i++)
        printf("%ld ", row[i]);
    free(row);
    return 0;
}

Name: Anonymous 2012-01-06 21:06

>>73
int main(/* ... */)
{
   /* ... */
}

Implementation of main() function is left as an exercise for the reader.

Name: Anonymous 2012-01-06 21:56

>>71

O(22n)
mother of god
what kind of silly algorithm would do this

Name: Anonymous 2012-01-06 22:11

>>76
According to Wikipedia ( https://en.wikipedia.org/wiki/Time_complexity#Table_of_common_time_complexities ):
22n: Deciding the truth of a given statement in Presburger arithmetic

Name: Anonymous 2012-01-06 23:56

>>77
But it is capable of doing Strong AI after all!

Name: Anonymous 2012-01-07 4:06

>>78
Is it? You can't even multiply (by any variable) in Presburger arithmetic. It's much weaker than Peano Arithmetic, which allows multiplication, but then if you add multiplication, you can encode entire programs within arithmetic, making the deciding the truth value of some sentences undecidable (this result is known in some forms as Godel's incompleteness theorems). No Strong AI will be able to solve the general halting problem, but any strong AI (or even human "AI"), should be able to decide on various specific cases, and they can self-improve to decide on more and more of them, just never 'all'.

Name: Anonymous 2012-01-07 5:22

#/usr/bin/env python

def get_row (previous_row):
    new_row = []
    new_row.append (1)

    for i in range (len(previous_row) - 1):
        new_row.append (previous_row[i] + previous_row[i + 1])

    new_row.append (1)
    return new_row

def get_nth_row (n):
    i = 0
    row = [1]
    while i < n - 1:
        row = get_row (row)
        i += 1
    return row

def main ():
    # Print first 15 rows, rows start at 1
    for i in range (1, 15):
        print get_nth_row (i)

if __name__ == "__main__":
    main ()


Not the best implementation, but what do you think?

Name: Anonymous 2012-01-07 7:12

Name: Anonymous 2012-01-07 9:40

New fizzbuzz over here

Name: Anonymous 2012-01-07 17:35

>>80 not too bad, but you can use pure Maths for that, which results in simpler code.

Name: Anonymous 2012-01-07 18:20

>>80 #!/usr/bin/env python
fixed that for you

Name: Anonymous 2012-01-07 21:00

>>81
Presburger Arithmetic? I don't know what thiat is, but it sounds like ASS BURGERS ASS SHIT.

Name: Anonymous 2012-01-07 22:53

>>79
more of them, just never 'all'.
You're too greedy.

Name: Anonymous 2012-01-07 23:43

ASPERGER ARITHMETIC

Name: Anonymous 2012-01-08 17:58

What's wrong with my code? I feel like the values are r are changing when they shouldn't...


#include <stdio.h>
#include <stdlib.h>

typedef long long size;

void main(void) {
  int i, j, n;
  size *r, *r0;
 
  printf("Row: "); scanf("%d", &n);
 
  r = (size *)malloc(sizeof(size) * (n + 1));
  r0 = (size *)malloc(sizeof(size) * (n + 1));
 
  r[0] = 1; r[1] = 1;
  puts("1 1");
  for(i = 2; i <= n; ++i) {
    r0 = r;
    r[0] = 1; r[i] = 1;
   
    for(j = 1; j < i; ++j)
      r[j] = r0[j-1] + r0[j];

    for(j = 0; j <= i; ++j)
      printf("%lld ", r[j]);
     
    putchar('\n');
  }
  free(r);
}

Name: Anonymous 2012-01-08 18:02

>>88
Should have mentioned, the output of that code is
1 1
1 2 1
1 3 4 1
1 4 8 9 1
1 5 13 22 23 1
...

Name: Anonymous 2012-01-08 18:06

>>88
void main
the space allocated in r0 = (size *)malloc(sizeof(size) * (n + 1)); is dereferenced but not freed before it's even used
[m]r0[/code] is there for no reason
Why do you do that?

Name: Anonymous 2012-01-08 18:10

lol

U MENA PASKALL

Name: Anonymous 2012-01-08 18:12

>>90
What do you mean r0 is not used? I use it in every iteration. Also, why would you free r0 before it's used? I don't get it....

I also never understood the point of declaring main as int then not returning anything.

I'm not very good at this, someone help

Name: Anonymous 2012-01-08 18:34

>>88
Read on pointers. r0 is pointing to the same address as r, so the space allocated by it is never used.

Name: Anonymous 2012-01-08 18:36

>>92
First, the first thing you do in the loop is assign r to r0, effectively discarding r0's malloced space.
Second, you can easily remove r0 altogether and your shitty code will still do the same thing it does now, just a bit better.
Third, the return value from main is returned to the OS (usually the shell or other program executing it) and is required by the C standard.

Go read your K&R already.

Name: Anonymous 2012-01-08 18:39

No one has said anything about my code. Can someone tell me if it sucks? Pretty please? I'm not very good at this C thing.
>>74

Name: Anonymous 2012-01-08 18:57

>>94
I think I understand now. I did think that the r0 = r part of my code was odd. It seems work work now. Thanks.


#include <stdio.h>
#include <stdlib.h>

typedef long long size;
void copy(size*, size*, int);

int main(void) {
  int i, j, n;
  size *r, *r0;
 
  printf("Row: "); scanf("%d", &n);
 
  r = (size *)malloc(sizeof(size) * (n + 1));
  r0 = (size *)malloc(sizeof(size) * (n + 1));
 
  r[0] = 1; r[1] = 1;
  puts("1 1");
  for(i = 2; i <= n; ++i) {
    copy(r0, r, i);
    r[0] = 1; r[i] = 1;
   
    for(j = 1; j < i; ++j)
      r[j] = r0[j-1] + r0[j];

    for(j = 0; j <= i; ++j)
      printf("%lld ", r[j]);
     
    putchar('\n');
  }
  free(r);
  free(r0);
}

void copy(size *r0, size *r, int n) {
  int i = 0;
  for(; i <= n; ++i)
    r0[i] = r[i];
}


Is there a better way to copy the contents by the way?

Name: Anonymous 2012-01-08 18:59

Third, the return value from main is returned to the OS
It still returns a value, even if main is void

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:03

>>94

First, the first thing you do in the loop is assign r to r0, effectively discarding r0's malloced space

That's incorect. r0's malloced space doesn't get discarded at this point in the loop. This space actually gets used. Cripes, relearn pointers you fucking stupid shit.

Third, the return value from main is returned to the OS (usually the shell or other program executing it) and is required by the C standard.

The return value is undefine according to both ANSI/ISO C89 and C99.

Go read your K&R already.

I think you need to go practice what you preach you mental midget.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:05

>>98

*The return value is undefined*

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:07

>>97

No, assuming this could compile on a standard ANSI/ISO C compiler, the function would return. It just wouldn't return a value.

Name: Anonymous 2012-01-08 19:09

>>98
>>99
>>100
I think you need to find a new job jobless_programmer!!kCq+A64Losi56ze-san that will teach you how to code properly

Name: Anonymous 2012-01-08 19:10

>>100
But the OS still gets a return value, right?

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:11

>>101

I think you need to find a programming job you dumb toilet scrubber.

Name: Anonymous 2012-01-08 19:14

>>103
i'm sorry did i hurt your feelings? It's okay, I'm sure it was 100% your fault the company failed and went under. Maybe next time you'll learn better.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:14

>>102
Depending on the OS, the return value could possibly be the exit status of the process. But I don't know because what you have is non standard C code. In other words, I can't get this thing to compile on either my Linux or Windows XP box.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:15

>>104
Nah. I think you just need to shut the fuck up and learn C before you criticize others.

Name: Anonymous 2012-01-08 19:16

So much FIOC and C ITT, and only one Scheme solution at >>29, and it just so happens to be the best.

I am disappoint, /frog/.

Name: Anonymous 2012-01-08 19:17

>>98-100

kodak-san! you are being helpful!

Name: Anonymous 2012-01-08 19:21

>>1
the Hacker News challenge
It's not a fucking challenge. It was mentioned as an example of a simple programming problem to weed out weak job candidates. Only you talentless autistic hacks would ever consider something like this a challenge, and then actually do it to ``prove yourself''.

If you want a challenge, build a facial recognition system from scratch using only training data that you've gathered yourself. That's a fucking challenge. Not this two-lines-of-C Pascal triangle shit, Jesus Christ.

Name: Anonymous 2012-01-08 19:24

>>102
return 0;

stop listening to kodak_jobless_moron, he's just like all the other tripfags who have no clue what they are talking about and act like elitists because they can.

Name: Anonymous 2012-01-08 19:26

>>109
Here's one that we use to weed out some of the week candidates.

We show the person a balanced binary tree. Then we ask them to write a function in either C or C++ that would convert this tree to a doubly linked list. The restrictions being that you can't use an external stack and you can't use any kind of global variables.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:27

>>110
Cite the exact passage in C89 or C99 you stupid shit. Oh wait, you can't! Now I see why you don't work as a computer programmer.

Name: Anonymous 2012-01-08 19:28

>>111
er *weak candidates*

Name: <- checkem trips 2012-01-08 19:29

Name: oh no, failure 2012-01-08 19:30

Name: your mom 2012-01-08 19:31

Name: that whore 2012-01-08 19:45

Name: Anonymous 2012-01-08 19:49

>>111
Huh, Brian Harvey at Berkeley has an anecdote involving almost the exact same problem.

http://www.youtube.com/watch?v=lMJNQIrWDJk#t=225

Name: Anonymous 2012-01-08 19:50

>>112
Now I see why you're unemployed

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 19:51

>>119
Huh? You still can't find the passage to support your incorrect assertions can you? Also, I still have a job. Now shut up and go scrub another toilet.

Name: Anonymous 2012-01-08 19:53

>>118
I find it kind of funny how >>109 hasn't posted a solution yet.

Name: Anonymous 2012-01-08 19:54

>>120
sure you do, keep telling that to yourself and one day it may come true.

Name: Anonymous 2012-01-08 19:55

ITT kodak-san can't do pascal's triangle

Name: Anonymous 2012-01-08 19:55

>>121
Yeah, the binary tree we use is

      1
     / \
    2   3

Name: Anonymous 2012-01-08 19:57

>>122
Again, you still haven't cited the passage in C89 or C99 that supports your assertion.

Name: Anonymous 2012-01-08 19:57

>>122
Now, for the 4th time you fucking retard, tell us what you do for a living.

Name: Anonymous 2012-01-08 19:58

>>125
You forgot your tripcode jobless_programmer.

thanks for making it clear you take it off to try to get your points across in a lame attempt to make it seem like other people agree with you.

Name: Anonymous 2012-01-08 19:59

>>127
Well, again, for like the 5th time you ADD fucker, you still haven't cited the C89 or C99 passage that supports your asssertion. And you still haven't told us what you do for a living.

Are these questions too difficult for you to answer you fucking retarded stupid shit?

Name: Anonymous 2012-01-08 19:59

>>126
What do you do for a living? I scrub women's toilets.

Name: Anonymous 2012-01-08 20:00

>>128
I made 0 claims that need me to cite C89 or C99

All i said was return 0 and be done with it.

Learn to read faggots.

Name: Anonymous 2012-01-08 20:01

>>130
And I said that isn't standard C you fucking nigger.

Name: Anonymous 2012-01-08 20:01

>>121
>>118 and >>109 are both me and I wasn't aware that >>111 was asking me to solve the problem.

Name: Anonymous 2012-01-08 20:03

>>129
You're more than welcome to come up to Kodak Gallery here on 63rd and Hollis in Emeryville, CA to see what I do on a regular basis you idiot.

Name: Anonymous 2012-01-08 20:03

tripfags and their haters ruin yet another thread.

Back to /g/ with both of you, please.

Name: Anonymous 2012-01-08 20:04

>>133
Give me your room number kodak-san and your name.
I'll gladly take a drive up to Emeryville CA just to see no kodak-san.

I do like how you keep forgetting to put on your trip.

Name: Anonymous 2012-01-08 20:04

>>132
Well you made light of the Pascal's Triangle problem. So I decided to post a problem that you might kind non trivial. I was really expecting a person of your caliber to have posted a solution by now.

Name: Anonymous 2012-01-08 20:06

>>135

I do like how you keep forgetting to put on your trip.

I do it to pass the filters.

Name: Anonymous 2012-01-08 20:06

>>133
You're more than welcomed to post your badge + timestamp to prove you even work anywhere in the corporate world

Name: Anonymous 2012-01-08 20:07

>>136
Like I said, I missed the part where you said, "solve this problem", or "can you solve this?", because you never did, and if you did I would probably reply "are you offering me a job?"

Name: Anonymous 2012-01-08 20:08

>>137
So you purposely try to ruin /prog/ by annoying everyone that you can?

Name: Anonymous 2012-01-08 20:10

>>140
Nah. I'm just annoyed with this uneducated burger flipper. Seriously. This guy needs to learn something otherwise he will be working some shit hourly job for the rest of his life.

Name: Anonymous 2012-01-08 20:13

>>137
Only a mental midget would think of that. Start scrubbing another toilet!

Name: Anonymous 2012-01-08 20:15

>>142
Stop stealing my one liners and come up with your own you dumb jew.

Name: Anonymous 2012-01-08 20:18

>>140
Kodak-san is mai waifu, I will not have you speak ill of him.

Name: Anonymous 2012-01-08 20:21

kodak-san how does it feel to:

--> Have no job
--> Live in your parents basement
--> Spend your entire day on /prog/ and probably an imageboard
--> Be less intelligent than the great FrozenShit
--> Have to make fun of people just to sleep at night without crying about your shitty life

Name: Anonymous 2012-01-08 20:25

>>145
How dare you attack mai waifu like that?

Dear Anonymous (>>145), how does it feel to:

--> have no life
--> be fat
--> be ugly
--> never kissed a girl
--> never hugged a girl
--> never had a girlfriend
--> spend your entire day on /prog/ and probably an imageboard
--> scrub toilets all day erry day
--> be a mental midget
--> attack your betters

I wouldn't know because I'm a superior specimen of the human species and so is mai waifu.

Name: Anonymous 2012-01-08 20:27

>>146
mai waifu

It's okay that you're all of those points, not everyone is a sad lonely faggot such as yourself. Please finish scrubbing my toilet and suck on my big meaty balls.

Name: Anonymous 2012-01-08 20:29

>>147
Prepare to defend yourself, I will not have you tarnish the reputation of mai waifu in this manner.

FOR KODAK-SAAAAAAAAAAAAAAAAAAAAAAAAAAN

Name: Anonymous 2012-01-08 20:36

I think Kodak-san is kind of cute, he's just tsundere.

Name: Anonymous 2012-01-08 20:43

>>141

alas, kodak-san's motivations are revealed. I always knew you were trying to help us, berating us while nudging us towards enlightenment.

Name: Anonymous 2012-01-08 20:47

>>150
Wow he actually is tsundere.

Name: Anonymous 2012-01-08 20:47

>>147
Go run off and make some more uneducated statements about C you homo.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-08 20:49

>>147

See, the people in
>>148
>>150

actually do like me!

Name: Anonymous 2012-01-08 20:50

>>150
Maybe he is a really intelligent burger flipper who never got an education because he had to help his single mother pay for the bills while she worked as a stripper at a local bar who now knows the true value of education and work experience but doesn't have the opportunity to get it himself so he helps us with our C programs since he's read the standards and understand them.

That's so cute, thank you Kodak-san ^_^

Name: Anonymous 2012-01-08 21:18

Name: Anonymous 2012-01-08 21:32

>>153
I-it's not like I like you or anything, you m-mental midget.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-09 15:42

>>147

See, the people in
>>148
>>150

actually do like me!

Name: VIPPER 2012-01-09 15:47

>>154
Or maybe his father killed himself, while his mom just watched TV, drank booze and smoked shit all day long just like the rest of /prog/ and he picked up some C on the side.

Don't change these.
Name: Email:
Entire Thread Thread List