Oct 2014
1 / 11
Oct 2014
Jan 2015
francky
Oct '14

You probably noticed that Pyramid cluster was overloaded those last months.
As a result, it seems some problems were switched to cube cluster by admins.

It isn't without sad consequences ; just an example1 pointed by numerix.

With an answer from Mitch in comment in TWOSQRS problem:

I fully agree with those words.

The situation is probably unchangeable ; we'll have to compose with that.

====

Here is a place for spoj users to give their propositions.

My wish is to see those problem rising again.
Sadly some old destroyed ones could land in tutorial, and set again by original psetter, a new valuable psetter, psolver, or neutral admin.
Some problems could be destroyed without any solutions. (??? those rare ones will be able to go back to Pyramid ???)

As a first proposition, I vote for an adaptation the nearest possible to the original problem by one of the best psolver (or an association).
The test cases could be made by several such psetters, with a several heads engine.
When test cases checked, the problem could be set by a neutral admin, in order to let the new psetter play "the game",
and to not allow him to read others codes.
The "new-psetters" would be only credited in the end of description.

==

Hope you'll find some great ideas and promote your favorites ones.
Please be constructive. We all want the best for spoj.

  • created

    Oct '14

  • last reply

    Jan '15
  • 10

    replies

  • 1.2k

    views

  • 5

    users

  • 11

    links

sigsegv11
Oct '14

Migration from Pyramid to Cubic also impacts a lot with Haskell. Cubic Haskell installation isn't essential, lack of most basic package like Conrol.Monad.State/System.Random (mtl/random). For haskell, Haskell-Platform should be installed instead of GHC. I like the change move problems to Cubic, but please make a full haskell-platform installation, better move to Haskell-platform 2014.2.0.

1 month later
francky
Nov '14

For archive purpose, some problems switched from Pyramid cluster to Cube cluster, with a change in time limit.

MINIMAX1, DISUBSTR, TCNUMFL, DIV, DIV2, FRACTION.

For some of these problems, numerix, THE master of Python can't get AC no more with Python with the new time limit.
That let no chance to other regular python users...

francky
Nov '14

There are new problems that have switched to cube, make the full list is useless...
It seems all problems will be switched to cube, according to admins...
If we want a "grand father clause" wink , an idea could be : old solutions are rejudged in background, and time limit is set to allow AC to all previous AC, and no more time, we could have with that only few new AC with old code. Then the new submissions are rejudged.
What about this idea ?

What about other ideas ?

francky
Nov '14

For archive purpose, it could be fine to freeze the rank list with pyramid, before the switch to cube, as the rank list can be mostly changed if there are many AC at 0.00s.
Some of us worked hard to get epsilon.s with pyramid, and this rank list disappeared... (I think at DIV and DIV2, where I had a good rank with pyramid).
This frozen ranklist could be accessible with a label "old Pyramid ranklist" or something like that...

min_25
Nov '14

I agree with that idea.

In my opinion, unreasonable switchings should be avoided at least. For example, there were 4 solvers in http://www.spoj.com/problems/WM06, but now there are no solvers after switched to cube. Since this problem had not been solved for many years, I'm very sad.

(This switching (-> 0.00 sec) might be caused by the Compile Error of the custom judge source code as with the WINDMILL)

Some other problems (whose TL = 0.00 sec) are http://www.spoj.com/problems/TCNUMFL2 (mentioned by numerix) and http://www.spoj.com/problems/HIR1. I don't think those new time limits are reasonable. So, I would like to know how the admins determine the new time limits.

numerix
Nov '14

Maybe I'm the one having the most AC Python solutions at SPOJ, but either way I am NOT a or the Python master, but in fact far away from being one.

According to the switching from Pyramid to Cube cluster, the problems connected with that "switch" and possible solutions:
Hardware doesn't live forever, the days of Pyramid cluster are counted, that's the course of events. So, switching to Cube is unvoidable and probably there will be some side effects that are not solvable to everyone's satisfaction. One of the problems belonging to that category are all the AC Python submissions using the no longer supported psyco module.
In some cases it will be possible just to run the same code without the use of psyco and get AC. That has to be done manually by the problem solver, but can be done and causes no real trouble. In other cases the Python code will be optimized for psyco and also needs psyco to get AC within the time limit at all. Several (maybe less than 20 or maybe more than 100, I don't know) of my own AC Python submissions are of that kind, and some of them needed much time to get them fast enough to pass the (former Pyramid) time limit. To get them AC without psyco will in some cases need a time limit that is too weak and will lead to naive solutions in faster languages.

BUT what could be done to minimize the number of former AC solutions that cannot pass the new time limit any more is a considered decision according to the new (Cube) time limit. If there are already AC submissions it should be set in a way that all or (in case of the mentioned psyco usage) at least most of the former AC submissions can pass. I don't know if EB members are able to adjust the time limit of problems, but if they are, they should do that for those automized(?) switches to Cube, if the problemsetter him-/herself is no longer active.

francky
Nov '14

EB members can't change time limit for a problem (unless his ones).

==

@numerix:
If the word "Master" doesn't suit to you, you're clearly the best Python user at spoj (for the number of AC, and the number of #1 in Python submissions). You earn that title without any doubt, by your great work.
wink

==

Another idea could be to set different times limit for some group of languages. But it makes psetter work more important.
If a new version of spoj is coming, maybe a group of psetter could have in charge to reload old problems, make strong cases IO files, and choose best times limit for some group of languages. Lot of work...
Keep a track of old ranking table with times for several languages with Pyramid could be helpful when choosing new times limit for cube. (but not an exclusive tool at all!)
Complex and important todo list !!!
EB members don't have yet any ideas from admins on how future spoj will looks like.
Here is a place to give ideas that may or not be used.

2 months later
kokosek
Jan '15

MINIMAX - changed the TL and numerix has AC now in Pyth.
DISUBSTR - solvable in Pyth.
TCNUMFL - that one is worse - in order for numerix to have AC I'd have to change the TL to 1.5s and that seems to much. So it probably won't be solvable in Pyth anymore unless you have a solution.
DIV, DIV2 - solvable in Pyth.
FRACTION - numerix's time is 0.25s in Pypy and TL is 2.5s. Shouldn't I decrease it?

francky
Jan '15

Based on my experiments, (real) Pypy is very different to use, and I'm totally unable (for now) to get AC using Pypy, I only get TLE.
As it is a very different use of Python, it's not to be considered as 'regular' Python.
So we should adjust time limit case by case, will we allow 'regular' Python code or not ? (depending on 'bad' fast language code)

I don't think the Pypy time should be used as limit. It would destroy any chance for 99.9% of Python users.