Seite 4 von 9

Verfasst: Dienstag 6. Januar 2009, 15:22
von Leonidas
SchneiderWeisse hat geschrieben:wie wäre es mit einer Assembler-Lösung?
Für welche CPU? :)

Verfasst: Dienstag 6. Januar 2009, 16:42
von Leonidas
Rebecca hat geschrieben:Oh hi!

Mai LOLPython solushn

KTHXBYE
Wow, ich habe selten bei einem Programm so sehr gelacht - danke! :D

Verfasst: Dienstag 6. Januar 2009, 19:11
von abgdf
@abgdf: `time()` wird in `time.h` deklariert. Bei dem Programm macht es nichts aus, aber `srand()` sollte man nur einmal aufrufen. So wie es jetzt aussieht, hängt jede Zufallszahl von der aktuellen Zeit ab und nicht mehr vom Zufallszahlengenerator.
Ja stimmt, danke ! Ich weiß, mein C ist nicht besonders gut, auch wenn ich mich hin- und wieder daran versuche :roll:.

@Roberta: :shock:
Wenn man allerdings eines Tages morgens aufwacht und sowas von sich gibt, sollte man wieder etwas mehr mit Menschen reden :lol: ...

Gruß

Verfasst: Dienstag 6. Januar 2009, 23:49
von Darii
Leonidas hat geschrieben:
SchneiderWeisse hat geschrieben:wie wäre es mit einer Assembler-Lösung?
Für welche CPU? :)
Am besten LLVM Assembler, dass ist es CPU unabhängig.

Verfasst: Mittwoch 7. Januar 2009, 12:56
von BlackJack
Dann ist es von der LLVM "CPU" abhängig. Das ist genau so abhängig oder unabhängig wie 6510-Assembler, den kann ich ja auch im Emulator auf anderen CPUs laufen lassen.

JavaScript

Verfasst: Mittwoch 7. Januar 2009, 15:15
von derdon
Und hier eine Lösung in JavaScript: http://paste.pocoo.org/show/98444/

Verfasst: Mittwoch 7. Januar 2009, 15:47
von HWK
@BlackJack: Hast Du bei Deiner C-Lösung einmal z.B. "a" eingegeben? Bei mir (Watcom-C unter Windows XP) hängt das Programm dann in einer Endlos-Schleife. Erst ein fflush(stdin) verhindert das. Meine Variante, die zusätzlich noch falsche Eingaben abfängt, ist hier.
MfG
HWK

Verfasst: Mittwoch 7. Januar 2009, 16:06
von Trundle
@HWK: AFAIK ist fflush auf einen Eingabestream laut Standard undefiniertes Verhalten.

Verfasst: Mittwoch 7. Januar 2009, 16:10
von HWK
@Trundle

Code: Alles auswählen

Description:
If the file fp is open for output or update,
the fflush function causes any unwritten data to be written to the file.
If the file fp is open for input or update,
the fflush function undoes the effect of any preceding  ungetc operation on the stream. 
If the value of fp is NULL, then all files that are open will be flushed.
Also offensichtlich (zumindest bei Watcom) nicht undefiniert. MSVC verhält sich übrigens genauso.
MfG
HWK

Verfasst: Mittwoch 7. Januar 2009, 16:29
von Trundle
@HWK: Aber nur bei Watcom. fflush(3) sagt: "EBADF - Stream is not an open stream, or is not open for writing" und beruft sich auf C89 und C99. Und C99 sagt in 7.19.5.2: "the behaviour is undefined", wenn der Stream kein Ausgabestream ist bzw. kein Updatestream, in den zuletzt geschrieben wurde.

Verfasst: Mittwoch 7. Januar 2009, 20:14
von HWK
Nicht nur in Watcom, sondern zumindest auch in MSVC. Läuft denn BlackJacks Code mit anderen C-Compilern bei Eingabe einer "Nichtzahl" problemlos? Vielleicht ist das ja Windows-spezifisches Verhalten.
MfG
HWK

Verfasst: Mittwoch 7. Januar 2009, 20:40
von sebastinas
HWK hat geschrieben:Nicht nur in Watcom, sondern zumindest auch in MSVC. Läuft denn BlackJacks Code mit anderen C-Compilern bei Eingabe einer "Nichtzahl" problemlos? Vielleicht ist das ja Windows-spezifisches Verhalten.
Deine und BlackJacks-Variante enden in einer Endlosschleife (gcc 4.3/Linux). http://faq.cprogramming.com/cgi-bin/sma ... 1043284392 für funktionierende Varianten.
Abgesehen davon heißt's int main *hust*

Verfasst: Mittwoch 7. Januar 2009, 21:50
von HWK
@sebastinas: Danke für die Infos!
MfG
HWK

Verfasst: Donnerstag 8. Januar 2009, 00:20
von BlackJack
@sebastinas: Rückgabe eines `int` macht auf'm C64 keinen Sinn. :-)

Verfasst: Donnerstag 8. Januar 2009, 00:47
von sebastinas
BlackJack hat geschrieben:@sebastinas: Rückgabe eines `int` macht auf'm C64 keinen Sinn. :-)
Ach, ich hab' vergessen, dass platform-unabhängigkeit von gestern ist.

Verfasst: Donnerstag 8. Januar 2009, 01:08
von BlackJack
Wenn ich `void` angebe erwarte ich, dass Compiler für Plattformen, die einen Rückgabewert auswerten, dort ein implizites EXIT_SUCCESS liefern. Sehe also kein Problem mit der plattformunabhängigkeit, aber ein paar gesparte Bytes. Bei einem PET mit 8 KiB RAM wird das schon ein wenig eng. ;-)

Verfasst: Donnerstag 8. Januar 2009, 08:29
von sebastinas
BlackJack hat geschrieben:Wenn ich `void` angebe erwarte ich, dass Compiler für Plattformen, die einen Rückgabewert auswerten, dort ein implizites EXIT_SUCCESS liefern. Sehe also kein Problem mit der plattformunabhängigkeit, aber ein paar gesparte Bytes. Bei einem PET mit 8 KiB RAM wird das schon ein wenig eng. ;-)
Und das ist einfach falsch. Wenn dort kein int steht, ist es implementation-defined. Dein Programm baut dann unter Umständen auf einer Platform gar nicht. Außerdem geht es nicht darum, was du vom Compiler erwartest, sondern er bzw. der Standard von dir. Und dann ist die einzige portable Möglichkeit eben ``int main``.

Verfasst: Donnerstag 8. Januar 2009, 10:47
von HerrHagen
Wie wärs mit ner Runde Golf? :D
Biete zum Auftakt 100 Zeichen:

Code: Alles auswählen

r=id(9)%101
while 1:
 g=input()
 if g==r:print"geschafft";break
 print["zu klein","zu gross"][g>r]
Das geht auf jeden Fall noch kleiner...

MFG HerrHagen

Regeln:
Zufallszahl 0..100
Python 2.5
Output wie beim obigen Beispiel

Verfasst: Donnerstag 8. Januar 2009, 12:04
von str1442

Code: Alles auswählen

r=id(9)%101;a=1
while a:
 g=input();a=g!=r;print["geschafft",["zu klein","zu gross"][g>r]][a]
94 oO

Verfasst: Donnerstag 8. Januar 2009, 12:17
von HerrHagen
92 :lol:

Code: Alles auswählen

r=id(9)%101;a=1
while a:g=input();a=g!=r;print["geschafft",["zu klein","zu gross"][g>r]][a]