Kurzer Prozess: Size Contest bei SPOJ

[name]

Weil es keine { und } hat sind so wenig Zeilen wie moeglich noch bloedsinniger...

Das verstehe ich nicht.
Edit: Außerdem gibt es doch { und } in Python ...

da is mit ein paar ifs, fors, oder was weiss ich die eine zeile schon weg.

[numerix]

Moin,

nimmt man Python 3, dann sind es 71 Zeichen:

Code: Alles auswählen

n=p=0
for c in input()[1:-1]:
 if"Z"<c:p+=1
 else:n+=3-p%4;p=0
print(n)

Gruß,
Manuel

Ja, das stimmt. Aber bei SPOJ wird Python 2.5 eingesetzt ...
(Meine kürzeste Fassung käme mit Python 3.0 auf 69 Bytes.)

[numerix]

Weil es keine { und } hat sind so wenig Zeilen wie moeglich noch bloedsinniger...

Das verstehe ich nicht.
Edit: Außerdem gibt es doch { und } in Python ...

da is mit ein paar ifs, fors, oder was weiss ich die eine zeile schon weg.

Tut mir leid, vielleicht bin ich gerade etwas begriffsstutzig, aber ich verstehe immer noch nicht, ob du meinst, dass Python im Falle des Zeilenzählens nicht gut weggekäme (so meine Vermutung) oder etwas anderes.

Falls du das meinst: Es gibt doch elegante Konstrukte wie z.B. LCs oder mächtige Funktionen, mit denen man auf einen Rutsch in einer Zeile ohne Semikolon eine Menge machen kann.

[snafu]

Es gibt doch elegante Konstrukte wie z.B. LCs oder mächtige Funktionen, mit denen man auf einen Rutsch in einer Zeile ohne Semikolon eine Menge machen kann.

Genau das meinte zumindest ich. Vielleicht kann Python seine Stärken nicht in der konkreten Aufgabe ausspielen aber doch wohl in so einigen anderen Fällen.

Die Kritik, dass möglichst kurzer Code != optimaler Code ist, ist natürlich berechtigt, hier aber - so finde ich - irrelevant. Man kann den Leuten doch auch mal ihren Spass mit solchen Wettbewerben lassen.

[b.esser-wisser]

Die berücksichtigt noch nicht die garstigen Zeilenenden, die weg müssen.

Wo wird sowas bei der Aufgabenstellung erwähnt?
(Und welchen Einfluß hat es überhaupt? Hinten muss doch nicht aufgefüllt werden und Ausgegeben werden sollen die doch auch nicht).
Außerdem teste ich gerade nur unter Windows "\r\n"-Zeilenenden sind da die Regel.

[name]

Weil es keine { und } hat sind so wenig Zeilen wie moeglich noch bloedsinniger...

Das verstehe ich nicht.

Code: Alles auswählen

if [foo]:
    do something
    do something else

geht schwer mit einer zeile.

[Leonidas]

Dann löst man das Problem eben anders.

[BlackVivi]

Faszinierend auch, meine echte Einzeiler Lösung ist auch die langsamste auf der ersten Seite =D

Sind diese ganzen funktionalen Sachen so langsam? ._. Ich find die total toll.

[snafu]

Code: Alles auswählen

if [foo]:
    do something
    do something else

geht schwer mit einer zeile.

Code: Alles auswählen

if foo: do_something()

Mal im Ernst: Worauf willst du mit solchen Argumenten hinaus? Es bestreitet niemand, dass gewisse Konstrukte sich auch bei Python über mehrere Zeilen erstrecken, trotzdem kann man IMHO zurecht behaupten, dass in sehr vielen Fällen weniger Zeilen in Python nötig sind als in anderen Sprachen, um bestimmte Probleme zu lösen.

[DasIch]

Sind diese ganzen funktionalen Sachen so langsam? ._. Ich find die total toll.

In Python schon. Du könntest ja Haskell nehmen

[numerix]

Die berücksichtigt noch nicht die garstigen Zeilenenden, die weg müssen.

Wo wird sowas bei der Aufgabenstellung erwähnt?
(Und welchen Einfluß hat es überhaupt?

Es wird nicht erwähnt - das ist ja das Problem. Deshalb habe ich in meinem eröffnenden Posting extra darauf hingewiesen.
Es hat mich bei meinen ersten Versuchen bei SPOJ fast an den Rand der Verzweiflung gebracht, weil alle mir vorstellbaren testcases bei mir einwandfrei gelaufen sind, aber mir SPOJ jedesmal eine "wrong answer" lieferte. Dann habe ich aus schierer Verzweiflung die Eingabe mal mit einem strip() behandelt - und siehe da, jetzt lief es ...

Mittlerweile gibt es auch andere, die es gemerkt haben, es gibt z.B. inzwischen einen entsprechenden Kommentar unter der Aufgabenstellung.

Der Einfluss ist, dass die Ergebnisse dann falsch sind ...

[BlackVivi]

Sind diese ganzen funktionalen Sachen so langsam? ._. Ich find die total toll.

In Python schon. Du könntest ja Haskell nehmen

Für Haskell bin ich ja sogar für'ne Ausgabe zu plöd, also... >_<

[Leonidas]

Sind diese ganzen funktionalen Sachen so langsam? ._. Ich find die total toll.

Generell nein, in Python sind aber Funktionsaufrufe recht teuer und Endrekursion wird nicht optimiert, daher sind funktionale Lösungen oft nicht die schnellsten. Ich nutze sie aber trotzdem gerne wo man die Laufzeit verkraften kann.

Ansonsten kannst du dir ja auch funktionale Sprachen ansehen (wie Scheme oder OCaml). Die haben dann entsprechende Optimierungen (und echte lambdas!).

[numerix]

Faszinierend auch, meine echte Einzeiler Lösung ist auch die langsamste auf der ersten Seite =D

Mich begeistert ja immernoch die 356 Bytes Lösung, die ungefähr 5x so langsam ist wie die anderen und auch noch mehr Speicher braucht (weil irgendwelche Module eingebunden wurden).

[BlackVivi]

Faszinierend auch, meine echte Einzeiler Lösung ist auch die langsamste auf der ersten Seite =D

Mich begeistert ja immernoch die 356 Bytes Lösung, die ungefähr 5x so langsam ist wie die anderen und auch noch mehr Speicher braucht (weil irgendwelche Module eingebunden wurden).

Code: Alles auswählen

class Function(object):
    def __init__(self, function, *args):
        self.function = function
        self.args = list(args)
        
    def get_number_of_args(self):
        return len(self.args)
        
    def add_arg(self, arg):
        self.args.append(arg)
        
class Argument(object):
    def __init__(self, arg):
        self.arg = arg
        
class Parser(object):
    def __init__(self, src):
        t = Tokenizer(src)
        self.lister = t.yield_token()
        
    def get_next_function(self):
        func = Function(self.lister.next())
        
        
class Tokenizer(object):
    def __init__(self, text):
        self.text = text
        
    def yield_token(self):
        for i in text:
            yield i
    

Ungefähr so, vielleicht Das macht ja noch nichmal, was's soll ._.

[numerix]

Seit eben gibt es bei SPOJ eine 66 Bytes Python Lösung ...

Edit: Ich vermute es war jemand hier aus dem Forum. Wäre nett, wenn er seine Lösung zur gegebenen Zeit mal zeigen würde ...

[bords0]

Hallo kbr

Da wir PEP-8 vernachlässigen könnten wir doch auch noch beim einrücken einige Zeichen einsparen:

Code: Alles auswählen

N=p=0
for c in raw_input():
 if c<'a' and p:N+=4-p;p=0
 p=(p+1)%4
print N

Sind total 69 Zeichen

Gruss wuf

Es sind 73 Bytes und mit der SPOJ-Original-Eingabe läuft es immer noch nicht ..

Ja. Aber man kann was draus machen (Score 66 bei SPOJ).

[numerix]

Hallo kbr

Da wir PEP-8 vernachlässigen könnten wir doch auch noch beim einrücken einige Zeichen einsparen:

Code: Alles auswählen

N=p=0
for c in raw_input():
 if c<'a' and p:N+=4-p;p=0
 p=(p+1)%4
print N

Sind total 69 Zeichen

Gruss wuf

Es sind 73 Bytes und mit der SPOJ-Original-Eingabe läuft es immer noch nicht ..

Ja. Aber man kann was draus machen (Score 66 bei SPOJ).

Gratuliere!

[bords0]

Seit eben gibt es bei SPOJ eine 66 Bytes Python Lösung ...

Edit: Ich vermute es war jemand hier aus dem Forum. Wäre nett, wenn er seine Lösung zur gegebenen Zeit mal zeigen würde ...

Ein nicht ganz offensichtlicher Trick ist vielleicht:
Ersetze p=0, p+=1 und (4-p)%4 durch p=8, p-=1 und p%4 (zum Glück haben die keinen Opcode mit mehr als 7 Operanden, sonst müsste man p=96 oder gar p=200 nehmen).

[snafu]

@snafu: So lange ich mit meinem Code in der SPOJ-Rangliste für Python auf Platz 1 stehe, werde ich ihn noch nicht rausrücken ...

Tust du's jetzt?