I just hit 50 solved problems, yay me.

Quote: Original post by slayemin
Some guy used the golden ratio perfectly to find the sum of even Fibonacci numbers below 4 million. Wow!!! that would never have occurred to me!

The formula in question is pretty well known. What's impressive is not getting messed up by round-off error. :)

Quote: I'm working on problem 3 now. I discovered the __int64 data type in the process :) Did you know that can hold up to 18.4 quintillion different values? (that's 18.4 trillion times a million)

Yes.

Quote: Such a fun site :) I usually hate math, but this is awesome.

Glad you're enjoying it :D

Quote: Original post by capn_midnight
I just hit 50 solved problems, yay me.

It looks like you have to have a logged-in account to see other peoples' profiles. I just get an about page. :/

Quote: Original post by capn_midnight
I haven't encountered any problems that strictly required Big Number support. There's always been some sort of work around that kept the problem in normal data type bounds.

This statement is a lot less compelling if you've only done fifty problems.

Quote: Original post by SiCrane

Quote: Original post by capn_midnight
I haven't encountered any problems that strictly required Big Number support. There's always been some sort of work around that kept the problem in normal data type bounds.

This statement is a lot less compelling if you've only done fifty problems.

50 problems is a little more than 1/5th of all the problems, which I would say is a fairly decent sample size. The problems are designed around the "one minute rule", i.e. problem execution should take no more than one minute, and of the 50 problems I've done so far, every one of them has had a sub-second solution. I think it's reasonable to assume that this ideal is maintained through the rest of the site. I *have* completed at least 3 problems that a naive implementation would include Big Numbers, but more clever implementations dispose of them completely.

I've also been participating in programming contests since college, which are very similar sorts of problems, again never actually requiring Big Numbers for optimal solutions.

Did the first 22 to play around with Haskell. I should really reinstall GHC one of these days.

Quote: Original post by capn_midnight
50 problems is a little more than 1/5th of all the problems, which I would say is a fairly decent sample size.

Selection bias. The fact that 50 of the easiest problems don't require big num support says nothing about the 200 harder problems remain that you haven't figured out how to do. Perhaps you can't do them because you've closed your mind to the possibility of using big nums.

It's like saying that since one fifth of the problems on a regular programming site don't require floating point numbers then the rest of the problems won't require floating point numbers. Or replace with dynamic memory/pointers/user defined types/bit shift operator/etc.

And in comparison, I'm at 123 problems solved and have used big nums. Or at least I probably have. One of the nice things about using Python is that I don't have to know or care what format my integers are stored in.

Perfect example of a bad solution: the one about largest prime factor of 6x10^17.

I brute forced with trial division and took me 5 minutes. Amazed at some of the solutions from that one. There is an algorithm that can find this for 10^30 in 5 seconds???

Quote: Original post by ChurchSkiz
largest prime factor of 6x10^17.

5. I can do that in my head. :D The actual given number is harder, of course, because it isn't so round.

But if you think about how I could answer that so quickly, maybe you'll get some ideas about a better general implementation.

Quote: Original post by SiCrane
It's like saying that since one fifth of the problems on a regular programming site don't require floating point numbers then the rest of the problems won't require floating point numbers. Or replace with dynamic memory/pointers/user defined types/bit shift operator/etc.

Uhm, actually, yes, you're absolutely right. It is pretty much an equivalent statement. And those statements would also be true. Instead of using floating point numbers, you could use fixed point numbers scaled to the level of precision you need. Instead of bit shift operators, you could multiply by two (since not all language have a bit shift operator). If there are multiple solutions to a problem, and some use feature X while others do not, then the problem does not strictly *require* feature X.

Now then, unless you would care to point out a problem that strictly requires an implementation of Big Numbers, I really have to question what your point is for jumping all over my case.