JOIN
Get Time
forums   
Search | Watch Thread  |  My Post History  |  My Watches  |  User Settings
View: Flat (newest first)  | Threaded  | Tree
Previous Thread  |  Next Thread
[ 1 2 ]    NEXT >
Python Language Support | Reply
Starting with Marathon Match 4 we will be adding Python 2.4.3 as a supported language.

Python will only be allowed in TC Marathon events and not Intel events.

Practice rooms will be up Monday evening for people to experiment with before MM4 starts.
Re: Python Language Support (response to post by TheFaxman) | Reply
That's pretty big news. Good job!

Doing it for algorithm competitions as well, or no?
Re: Python Language Support (response to post by jmzero) | Reply
We will not be adding Python to SRMs.

We considered it a number of times before deciding that we didn't want to add a language to SRMs that may not be usable for some problems due to speed.

The marathon format is a bit more forgiving (timeouts aren't used to force complexity of solutions, but just provide a general limit), so it's a good fit for them.
Re: Python Language Support (response to post by TheFaxman) | Reply
Good job!

Python isn't very suitable for SRM's, but it is a good language for Marathon matches (events). That is my =newbie= opinion ;)

Python rulez
Re: Python Language Support (response to post by TheFaxman) | Reply
I'm not familiar with Python, but if it's so much slower that it couldn't be used in SRMs, then why would people want to use it in marathons where speed of execution is very important (either directly through scoring, or indirectly by limiting the number of calculations that can be performed before timeout), and ease of coding (which I understand is Python's main advantage), isn't, since coders have many hours to code their ideas? Already some Java coders have switched to C++ for MMs.

Wouldn't the Python fans rather use it in SRMs, even if occasionally they need to use a faster language for these few problems where millions of calculations are needed?
Re: Python Language Support (response to post by battyone) | Reply
Only Intel events have used runtime as a factor of score.

That's not to say we won't have a marathon problem in the future that has a runtime component, but in general we focus our problems more on the algorithm than the runtime.

If we added Python to SRMs it would be all but unusable in division 1 (except for the easy problem). The runtime different is just too significant. On average it is at least 10x slower than Java. We decided that by adding a language we need to be able to say it's a viable choice.

Obviously you'll have less pure calculations than any other language, but the marathon format gives people more time to optimize if needed.

Speed is a major reason why we're not adding it to Intel events. The language has full threading support, but it's simply too slow to be competitive in that environment.
Re: Python Language Support (response to post by TheFaxman) | Reply
About the speed issue, it would help a lot if you could install some modules, for example numpy? When not available, python programmers have to make list of lists which is very, very slow and ugly for implementation. One big minus for python ;)

Hopefully the multidimensional arrays will be builtin in some of the future python releases.

By the way, if it is allowed to change languages during the competition, then both C++ and Java programmers could write their first solution in python, submit it (see if the algorithm works well) and then recode it in C++/Java for better speed ... Just an opinion, as I said, I'm not familiar with MM. But I'm sure coding in python is 2x faster and easier than in any other language. Also it helps you think about the problem, not about the language, as in other languages, which can be very distracting ...
Re: Python Language Support (response to post by srele) | Reply
Generally we don't install non-official libraries, mostly because there's no good way to decide what should be allowed and what shouldn't.

I did play around with a few JIT libraries for Python when I was implementing things and the difference in speed was maybe 50%, nowhere near enough to put it in the same league as the other languages.
Re: Python Language Support (response to post by srele) | Reply
Also it helps you think about the problem, not about the language, as in other languages, which can be very distracting ...

That only happens if you're newly learning the language. After you're comfortable with the language, you can, in most cases, use it without much "distracting" thinking.
(Everything here is true (IMHO) for natural languages as well as programming languages.)
Re: Python Language Support (response to post by TheFaxman) | Reply
Can you consider installing psyco package?

I received 2-5x spedup on tasks from Google Code Jam,
and even much bigger speedup with one (partial) task:

without psyco:
runtime 3.4 sec,
after I added

import psyco
psyco.full()

it becomes 0.08 sec.

This is not the common result (more than 40x speedup), but this can make python to be more vital choise.

I think it would be great just to install psyco,
and warm all python users they can try to use it.
Re: Python Language Support (response to post by pdima) | Reply
There are a number of bugs / non standard behaviors in psyco that I think prevent us from even considering it, not to mention the memory requirements might make some problems unusable with it.
Re: Python Language Support (response to post by battyone) | Reply
You could use it for prototyping an algorithm? I don't know, I can't see it being much use really unless there are people who only know Python well.
Re: Python Language Support (response to post by d000hg) | Reply
I agree with srele, python is much easier for write and to read than
most of other languages, and can be used for prototyping.
In most cases the prototypes are quite good to be used without rewritting in faster languages.
I found python works very good when you have big data sets with little
number of operations performed on data, the containers are quite fast,
sometime python version works faster than C++ one, becouse of better containers implementation. ( it's very rarely case, but it happens )
Re: Python Language Support (response to post by TheFaxman) | Reply
Can you point to the bugs / non standard behaviors?

With selective binding/proxying one can have a good deal of control in terms of memory usage.
Re: Python Language Support (response to post by fujole) | Reply
I am not sure exactly what he was referring to, but I think it may be related to this
[ 1 2 ]    NEXT >

RSS