Kodierer

[Leonidas]

Da sich Leonidas nicht rührt und mich das Problem irgend wie motiviert hat, hier mein Vorschlag in Scheme.

Leonidas rührt sich und gibt dir erstmal den Link zu den Folien die du vermutlich gemeint hast. Da sind aber auch noch andere Dinge die Dekoratoren, ``with``-Statement und sowas drin.

Naja, ``convert`` ist ja nur ein anderer Name für... ``map``. ``_crypt`` hingegen sieht mir ein wenig nach einem Fall für ``reduce`` aus (oder ``foldl`` oder wie man das nun nennen will, total egal). Die Einrückung ist auch etwas komisch. Ansonsten ganz ok denk ich. Aber an den Clojure-Lösungen siehst du auch, warum Clojure inzwischen ein "akzeptables, funktionales Lisp" ist. Wenns das jetzt nur ohne die JVM gäbe...

[Hyperion]

Leonidas rührt sich und gibt dir erstmal den Link zu den Folien die du vermutlich gemeint hast. Da sind aber auch noch andere Dinge die Dekoratoren, ``with``-Statement und sowas drin.

Ja, aber genau die meinte ich, danke

Naja, ``convert`` ist ja nur ein anderer Name für... ``map``.

Stimmt. Hab ich lokal mal umgebaut.

``_crypt`` hingegen sieht mir ein wenig nach einem Fall für ``reduce`` aus (oder ``foldl`` oder wie man das nun nennen will, total egal).

Hm... wenn ich von Pythons reduce() ausgehe, dann sehe ich da noch nicht eine exakte Übereinstimmung. Die einzelnen Elemente der Byte-Liste werden ja nicht direkt miteinander verknüpft, sondern mit dem Zähler. Könntest Du das ggf. umformulieren? (oder ging es Dir nur um den Namen?)

Die Einrückung ist auch etwas komisch.

Gibts da evtl. ne Art Styleguide für Scheme?

Ansonsten ganz ok denk ich.

Aber an den Clojure-Lösungen siehst du auch, warum Clojure inzwischen ein "akzeptables, funktionales Lisp" ist. Wenns das jetzt nur ohne die JVM gäbe...

Ja, die sieht wirklich hübsch aus Scheint auch sinnvoll zu sein, sich das anzugucken... wenn man doch mehr Zeit hätte

Was hast Du gegen die JVM? (In diesem Kontext)

[cofi]

Wenns das jetzt nur ohne die JVM gäbe...

Gibts doch: https://github.com/richhickey/clojure-clr
Ich glaube aber, dass das die Probleme auch nich weniger macht

[Leonidas]

``_crypt`` hingegen sieht mir ein wenig nach einem Fall für ``reduce`` aus (oder ``foldl`` oder wie man das nun nennen will, total egal).

Hm... wenn ich von Pythons reduce() ausgehe, dann sehe ich da noch nicht eine exakte Übereinstimmung. Die einzelnen Elemente der Byte-Liste werden ja nicht direkt miteinander verknüpft, sondern mit dem Zähler. Könntest Du das ggf. umformulieren? (oder ging es Dir nur um den Namen?)

Ja, du musst bei der von ``reduce`` aufgerufenen Funktion aber natürlich nicht nur den String zurückgeben, du kannst auch den String plus den aktuellen Zählerstand als Akkumulator nutzen. Und dann in eine Funktion verpacken, die den Zähler wegwirft und nur den fertigen String zurückgibt. Analoges geht natürlich auch mit Pythons ``reduce`` indem man Tupel nutzt. In Schem kann man sich ggf. zu nutzen machen dass Funktionen mehrere Werte gleichzeitig zurückgeben dürfen.

Die Einrückung ist auch etwas komisch.

Gibts da evtl. ne Art Styleguide für Scheme?

Am ehesten noch das was hier beschrieben wird. idR sagen Lisper ja "so wie Emacs es macht", aber als Vim-User falle ich auch nicht drauf rein

Aber an den Clojure-Lösungen siehst du auch, warum Clojure inzwischen ein "akzeptables, funktionales Lisp" ist. Wenns das jetzt nur ohne die JVM gäbe...

Ja, die sieht wirklich hübsch aus Scheint auch sinnvoll zu sein, sich das anzugucken... wenn man doch mehr Zeit hätte

Was hast Du gegen die JVM? (In diesem Kontext)

In diesem Kontext speziell nichts.

[BlackJack]

Die CoffeScript-"Idee" in C umgesetzt: http://paste.pocoo.org/show/326649/

[Hyperion]

Die CoffeScript-"Idee" in C umgesetzt: http://paste.pocoo.org/show/326649/

Hübsch

Kurze Frage zum Funktionskopf von "code":

Code: Alles auswählen

static void code(char (*op)(char a, char b), char *data)

Ist die Angabe der Parameter der Funktion hinter dem Funktionszeiger wirklich notwendig (für den Compiler)? Oder ist es eher "Dokumentation" für Entwickler, welche Operationen übergeben werden können?

[BlackJack]

@Hyperion: Ich sehe nicht wie man das weglassen könnte ohne den Compiler mit falschen Informationen zu füttern. Nach dem ``(*op)`` müssen Klammer kommen, denn sonst wäre ``char (*op)`` kein Funktionszeiger sondern ein Zeiger auf ``char``. Und wenn Klammern folgen um syntaktisch einen Funktionszeiger daraus zu machen, müssen da auch die Parameter drin stehen, sonst würde der Compiler eine andere Signatur annehmen als die tatsächliche. Das kann gut gehen. Muss es aber nicht.

[BlackJack]

Und nun 6510-Assembler. Je nachdem ob En- oder dekodiert werden soll, wird der entsprechende Teil zum addieren/subtrahieren im Code durch überschreiben der Opcodes geändert. Und als wenn das noch nicht undurchsichtig genug wäre, werden die Opcodes auch noch über Bitverknüpfungen angepasst, statt sie einfach für beide Fälle direkt in den Quelltext zu schreiben. Das ist 3 Bytes kürzer.

Code: Alles auswählen

    .importzp   tmp1, ptr1
    .export     _encode, _decode

; En- and decode both expect the address of a null terminated string in A/X.

.code

_decode:
    ldy #%00100000
    .byte $2c   ; BIT $xxxx opcode.  "Masks" the following opcode + operand.
_encode:
    ldy #0
    
    sta ptr1            ; Store start address of data.
    stx ptr1+1
    
    tya                 ; Based on Y content write opcodes CLC/ADC or SEC/SBC
    ora #$18            ; into the code below.  ($18/$65 or $38/$e5)
    sta selfmod
    tya
    asl
    asl
    ora #$65
    sta selfmod+1

    ldy #0
loop:
    lda (ptr1),y
    beq return
    sty tmp1
selfmod:
    clc
    adc tmp1
    sta (ptr1),y
    iny
    bne loop
return:
    rts

[Hyperion]

Na wenn schon 6510 Assembler darf auch das COMMODORE BASIC V2.0 nicht fehlen

Code: Alles auswählen

10 INPUT"WORT"; DA$: EN$="":CC%=0:GOSUB 100
20 PRINT EN$: END
95 REM ENCODE
100 FOR X=1 TO LEN(DA$):C$=MID$(DA$,X,1):EN$=EN$+CHR$(ASC(C$)+CC%):CC%=CC%+1
110 NEXT X:RETURN
195 REM DECODE
200 FOR X=1 TO LEN(DA$):C$=MID$(DA$,X,1):EN$=EN$+CHR$(ASC(C$)-CC%): CC%=CC%+1
210 NEXT X:RETURN

Puh... mein erstes C64 Programm seit olims Zeiten Vertsößt zwar gegen DRY, aber mit den Mitteln damals ist da nicht viel mehr drin fürchte ich. Man könnte wohl allenfalls den berechenden Teil in ein Unterprogramm auslagern und die Schleife für das decoding entsprechend anpassen, dass negative Zahlen erzeugt werden. Aus Geschwindigkeitsgründen muss man da aber auch vorsichtig sein; Sprünge kosten iirc einiges an Zeit, GOSUB im speziellen noch mehr, da die Rücksprungadresse auf den Stack gelegt wird.

[/me]

Und nun 6510-Assembler.

Rein interessehalber: Gibt es einen speziellen Grund, dass du noch 6502/10-Assembler sprechen kannst? Ich habe bestimmt seit über 20 Jahren nichts mehr damit gemacht.

[BlackJack]

@Hyperion: Wenn Geschwindigkeit eine Rolle spielte, hätte man nicht BASIC auf dem Gerät benutzt. Oder es durch einen Compiler gejagt.

Was ich bei Deiner Lösung nicht ganz verstehe ist das zusätzliche ``CC%``, wo es mit ``X`` doch schon jeweils den Wert frei Haus gibt!?

So würde ich das angehen:

Code: Alles auswählen

10 A$="HALLO":GOSUB 1010:PRINT R$
20 A$=R$:GOSUB 1110:PRINT R$
999 END
1000 REM ENCODE
1010 M=1:GOTO 1210
1100 REM DECODE
1110 M=-1
1200 REM COMMON EN/DECODE
1210 R$="":FOR I=1 TO LEN(A$):R$=R$+CHR$(ASC(MID$(A$,I,1))+(I-1)*M):NEXT:RETURN

(Das nette Syntaxhighlighting bekommt man mit "locobasic" als Sprache. Das ist eigentlich für Locomotive BASIC für den Amstrad CPC, aber eben auch so ein altes Heimcomputer-Dingens mit Zeilennummern wie das Commodore BASIC V2.)

@/me: Ist wie Fahrrad fahren -- das verlernt man nicht. Habe da früher viel mit geschrieben und habe auch heute noch einen C64 und mittlerweile auch einen Atari 130XE, der mir mal zufällig in die Hände gefallen ist und auch einen 6510 enthält. Den C64 beschäftige ich ab und zu mit Projekt-Euler-Problemen. Habe ich schon viel zu lange nicht mehr gemacht, fällt mir dabei auf.

Die "Szene" ist auch noch ziemlich aktiv. Hätte zum Beispiel selbst nicht gedacht, das man noch sinnvolle, neue Software-Grafikmodi erfinden/entdecken kann. Was mit NUFLI aber lange nach der "Hauptzeit" des Systems passiert ist.

[Hyperion]

Was ich bei Deiner Lösung nicht ganz verstehe ist das zusätzliche ``CC%``, wo es mit ``X`` doch schon jeweils den Wert frei Haus gibt!?

Ich auch nicht (mehr)
Ich hatte es in einer ersten Fassung mal ohne for-Schleife angedacht und das dann zurückbehalten.

Deine Idee mit dem Faktor ist natürlich genial

Naja, ich war froh das nach so langer Zeit überhaupt zum Laufen gebracht zu haben - ich wusste ja da gibts mindestens noch einen, der es optimieren kann

[Xynon1]

Vorsicht rhetorische Frage: Gehen euch nicht langsam die Sprachen aus?

Ist aber interessant den selben, doch recht simplen, Code in vielen verschiedenen Sprachen zu sehen. Sollte man hier mal öfters machen.

[Leonidas]

Vorsicht rhetorische Frage: Gehen euch nicht langsam die Sprachen aus?

Nein, üblicherweise kommen in so Threads noch mindestens eine Lösung mit Factor und Io dazu, aber ich habe leider keine Zeit das mit Factor zu implementieren. Und ja, sowas ist fast schon Tradition im Forum

[BlackJack]

Ich weiss Java hatten wir schon mal, aber bei dem hier könnte man die Operationen für die einzelnen Bytes anpassen, wenn man wollte: http://paste.pocoo.org/show/327463/

Zeigt IMHO schön wie praktisch Funktionen/Methoden als "first class citizens" in einer Sprache sind, denn da sieht (ebenfalls IMHO) selbst die C Lösung schöner aus.

[Rebecca]

Vorsicht rhetorische Frage: Gehen euch nicht langsam die Sprachen aus?

Na gut, dann mal eine Ruby-Loesung:

Code: Alles auswählen

data = "Hallo"
result = data.each_byte.with_index.map { |char, i| (char+i).chr }.join("")
puts result

[Penguin6]

Ihr seit ja wahnsinnig
Freue mich schon, wenn ich besser Programmieren kann
Momentan habe ich leider nicht so viel Zeit zum üben

Danke noch einmal an alle!

[Xynon1]

Wahnsinnig ist das

Code: Alles auswählen

,.,[>+[>+>+<<-]>>[<<+>>-]<[<<+>>-]<<.,]

, das Programm in Brainfuck

Edit: Kann auch online getestet werden: http://koti.mbnet.fi/villes/php/bf.php