Increasing time limits

Hy,

I'm trying to use only LISP for the problems here but TLE is making it really hard.

For example, SUMITR has both a low char and time limit. Making the small chars solution was ok but I have no way to make it fit into that time limit. (Needless to say that due to size restrictions I can't even declare some optimizations ).

I also have troubles with PLONK, FCTRL and INTEST.

Some of them could be my fault (INTEST should be optimized somehow with (declare)'s but this is some kind of black art) but overall I think the time limit isn't realistic for some LISP problems.

My SPOJ user is the same (emilian).

I'm afraid I won't help you much, but I noticed SUMITR and PLONK have "large Input/Output data, be careful with certain languages" warning (at the bottom of problem description.
In theory it means your I/O have to be fast enough to pass INTEST. If it doesn't pass INTEST, it probably is too slow even to read the input data and/or output the answers alone - no point in optimizing the algorithm itself.

As for strict source size limit.. one solution would be to give less/no size restrictions and make it an optimization problem, where the shortest code wins.. but it's a matter of taste and it's up to problemsetters.

P.S. You can always browse through the list of accepted solutions (like spoj.sphere.pl/ranks/PLONK/4). If there are accepted solutions in languages you think are slower than Lisp, it should be possible

Indeed this didn't help alot

Could you at least provide something like this for LISP/other?: TLE but program finished (correctly/not) in 1 minute with an extended time limit for some languages/problems.

I really want to see how slow it is.

In my opinion that's what tutorial problems are for. AFAIK there are some problems from the main problemset cloned with extended time limit in "tutorial" category.

As far as I see the Sums in Triangle problem is with the same time limit and an extended char-size limit. Not quite the case.

But, there are only a handfull of problems in tutorial.

I have to say that this is getting quite frustrating for me. I think I have about 5 problems with TLE and quite fast algoritms (meaning stuff that shouldn't take long) but just because lisp seems to be slower I just keep them arround in my TODO list. It's getting quite tiresome.

I have tried to solve FCTRL using gcl and clisp.
Unfortunately, I get time limit exceeded for gcl, which is strange, because GCL is natively compiled and is typically faster than clisp.

I have tried this locally with a relatively large input set (100000 times the number 8735373)

Results are as follows:
gcl 2.6.7 takes 6.8 seconds
clisp 2.38 takes 29.7 seconds

I am aware that I am using different versions locally, but still it feels strange.
Any idea how this can be?

(problem submitted has ID 491973)

This is really frustrating ... I'm really not interested in the time issue but am constrained by time limits that apply to assembler like languages. You get a really nice and elegant solution that, ok may not be optimal, but who cares, my laptop is like 4 times as fast as the server that's imposing time limits ... sheesh!

The core of my Factorial (11) solution ID 496507 is just 21 lines, and I know it's correct, and I could probably get it to accept by caching previously calculated values, but that doesn't have anything to do with the solution to the problem, apart from the time limit problem, so what's the point??

Sorry for the rant, but it really burns my wick.

How about an option for no points and no arbitrary time limit for people who just want to enjoy themselves applying their minds to tricky programming problems, and leave the time limits for those who want to get to the top of some list.

Jonathan.

Hmm ... ok then maybe I have missed the boat ... cacheing didn't help at all ... how do they do that in tiny fractions of a second without precalculating?? OCaml isn't that inefficient ...

Oh. There's a formula to calculate the zeros in n! ... like I bet all those people with accepted answers derived it from first principles too! ... and what's that got to do with a time limit?

If the time limit were valid, why isn't it 1 sec because the solution would only have like 13 iterations for the maximum value ...

I am a recent arrival to spoj, and am enjoying it very much. However, I'm a little disappointed that the run time limits for some problems prevent one producing a solution in python, simply because python has such slow IO and scanning.

For example, I have a solution to HMRO which takes about 1.5 seconds to run on my laptop (1.6GHz P4M). This is with a dataset that I generate with size as specified on the problem description.

I get TLE on spoj.

I can strip it down so it just scans the input and produces canned output. Then it runs in 1.26 s and gets Wrong Answer (of course) after 4.38s.

So IO takes 4.38s out of the 5s available, and my algorithm, which is O(n) and runs in less than 1s cannot even be tested. I mean, it could be that it produces wrong answers, but I can't even test it.

It is a similar story for CISTFILL.

Yes, C has fast IO, and I would like to have fast IO in python too. But maybe just a little longer time limit would add to the fun while still preventing dumb and lazy O(n!) solutions from passing?

I'm using SPOJ for gaining experience with Haskell. PRIME1 shut me down though. On my box I can generate primes for 10 non-overlapping, non-contiguous 10k ranges in about 2.3 seconds. Kept getting TLE on submission so rewrote in Perl. Haha! Even slower so rewrote in C. I'm using the exact same algorithms (and checked the C output against the Haskell output) and the C code was accepted with a runtime of 1.2 seconds. (On my box it took 0.15!) Using a factor of 8 for this problem my Haskell code should finish in 18.7 seconds. Obviously that's not going to make the problem's 6 second time limit.

I've read through this thread and agree that time limits are a good thing in a point system to favor well written and efficient code. However big a disparity between languages folks are still trying to complete the contests (if for nothing more than for the challenge and entertainment value). My suggestion would be to use a system of natural selection. At the start of a problem, set some high time limit tracked per language. As you get submissions keep a log of the time successful programs took. Take the median of those values and call it the expected runtime for a solution in the given language. It seems a program isn't halted until about 2*T so if someone finishes within that time but not below T then offer the knowledge that their solution was correct but don't offer points.

$0.02,
-ljr

(edit) PS - Rewrote the Haskell version to use the first 6542 pre-calced primes (from all my other programs finding primes) covering the solution space. When tested on the same 10 non-overlapping, non-contiguous 10k ranges as above runtime on my box was 0.33 secs. Result on SPOJ... TLE!

I got a solution accepted for PRIMES1 in Scheme, with Guile. While fast Scheme interpreters and compilers do exist, the only (usable) Scheme interpreter at SPOJ is Guile, which is pretty slow (its intented use is as an embedded interpreter in other programs, which forced the authors to make compromises).

My C solution for that problem runs in 0.03s at SPOJ. If your C code is 40 times slower, then sorry to say this, but you're probably using the wrong algorithm.

I'm using a straight-forward implementation of miller-rabin with preset values that guarantee primality discovery for the range of values allowed in the problem. (I wrote my own pow_mod() which is probably where I'm missing out on time. Don't care enough to figure out the library call's name.) Alternately in Haskell I pre-calced the primes needed to cover the solution space. Perhaps I'm behind the state of the art in primality testing but I'd be really surprised if either of those could be labeled the 'wrong algorithm'.

-ljr

Please edit the very first post of this forum then. I wrote a Haskell program which received TLE. I am convinced I wrote the equivalent program in C which was accepted.

-ljr

A primality test such as Miller-Rabin (or Solovay-Strassen, or Fermat, or AKS, or whatever) is the wrong approach for this problem. You want a variation of the Sieve of Eratosthenes. Search the forum for suggestions, some of the posts practically spell out the answer.

The sieve is nice and fast in a... was going to say non-FP but I haven't tested them all so I'll say not-Haskell. If you look at my previous posts I pointed out that I built a source file that hard-coded all primes needed to cover the problem space. It still hit TLE. That's SoE with all the legwork pre-calculated so I'll admit the solution needed is beyond me.

Now I don't really care. I tried SoE. I tried Miller-Rabin. I tried pre-calc and all hit TLE. I won't argue that the problem isn't with me because obviously other folks have used haskell and are well below the limit. My original post was following up on the first post in this thread. I had an algorithm which hit TLE in a functional language. Same alg in C was accepted. I posted. Got told, 'What I really meant is "just make your program faster"'.

Nice system. Not useful as a learning tool for trying a new language. My bad.

-ljr