Die meisten Treffer zu dieser Suche sind Werkzeuge, die aus SAS-Quelltext Python erzeugen, und einige davon machen das gut. Diese Seite setzt einen Schritt früher an: ob der Wechsel für Ihre Codebasis überhaupt richtig ist, was die Prüfung des Ergebnisses kostet und was zu tun ist, wenn die Antwort Nein lautet.
Es gibt vier Wege aus einer SAS-Codebasis heraus, nicht zwei: einem automatischen Werkzeug übergeben, von Hand neu schreiben, die SAS-Programme unverändert auf etwas anderem als SAS ausführen, oder alles so lassen. Welcher richtig ist, hängt fast nur an zwei Fragen — wie viel Code es gibt und ob jemand die früher erzeugten Ergebnisse reproduzieren muss. Alles Weitere ist, was jeder Weg kostet.
Python ist häufiger das bessere Ziel, als eine Seite wie diese normalerweise zugibt. Vier Bedingungen machen es eindeutig: die Codebasis ist klein genug, dass eine Person sie in einer Woche liest, das Team schreibt ohnehin täglich Python, die Analyse wird sowieso neu aufgebaut, und nichts weiter unten verlangt, dass die neuen Zahlen exakt den alten entsprechen. Wenn alle vier zutreffen, ist ein Neuschreiben billiger als jede Kompatibilitätsschicht, und am Ende steht Code, den Ihr Team ohne eine zweite Sprache pflegen kann.
Jede Option hier ist für jemanden die richtige Antwort. Keine davon ist ohne Kosten, und der teure Teil ist nie die Syntax.
Web-Werkzeuge, Anbieterdienste und große Sprachmodelle nehmen .sas-Quelltext und geben Python zurück, wobei DATA-Steps üblicherweise auf pandas und die gängigen Prozeduren auf statsmodels oder scikit-learn abgebildet werden. Für ein paar hundert Zeilen geradliniger Datenaufbereitung ist das eine echte Abkürzung und liefert in Minuten einen lesbaren Ausgangspunkt. Die Rechnung kommt später: jede Zeile der Ausgabe muss jemand lesen, der beide Sprachen kennt.
Jemand liest das SAS-Programm, versteht, was es tun sollte, und schreibt das in Python. Das ist am Anfang langsamer und ist der einzige Weg, an dessen Ende Code steht, der wie Python aussieht und nicht wie SAS im Python-Mantel. Teams, die zwei Jahre später mit Python zufrieden sind, sind meist so dorthin gekommen und haben das alte Programm daneben weiterlaufen lassen, bis die Zahlen übereinstimmten.
Der Weg, den die Vergleichsseiten auslassen. Jenner ist eine Clean-Room-Implementierung der SAS-9.4-Sprache in Rust: sie liest SAS7BDAT-Dateien direkt und führt .sas-Quelltext so aus, wie er dasteht, es gibt also keinen erzeugten Code zum Nachlesen und keine zweite Sprache für das Team. Was sie nicht leistet, ist die vollständige Abdeckung der SAS-Sprache, und die Abdeckung ist Prozedur für Prozedur veröffentlicht, damit Sie Ihre prüfen können, bevor Sie sich darauf verlassen.
Nichts zu tun ist eine echte Entscheidung und oft die richtige. Wenn der Code stabil ist, die Umgebung, in der er läuft, dieses Jahr nicht verschwindet und niemand eine Änderung verlangt, hat die Migration, die Sie nicht machen, die beste Rendite auf dieser Seite. Greifen Sie die Frage wieder auf, wenn ein Plattformwechsel, eine Prüfung oder ein Personalproblem sie erzwingt.
Der Fehlermodus einer automatischen Konvertierung ist kein Syntaxfehler; der zeigt sich beim ersten Lauf. Es ist der stille numerische Unterschied. SAS füllt Zeichenwerte rechts mit Leerzeichen auf und Python nicht, SAS zählt Datumswerte ab dem 1. Januar 1960 und pandas ab dem 1. Januar 1970, und ein MERGE im DATA-Step verhält sich nicht wie ein pandas-merge, wenn der Schlüssel auf beiden Seiten mehrfach vorkommt. Nichts davon löst irgendetwas aus. Es entsteht eine Zahl, die fast stimmt, und das ist die schlimmste Art falsch. Der wahre Preis einer Konvertierung ist deshalb ein zeilenweises Lesen durch jemanden, der beide Sprachen beherrscht, plus eine Phase, in der Alt und Neu auf denselben Daten nebeneinander laufen, bis die Ausgaben übereinstimmen — und dieser Preis wächst mit der Menge an Code, nicht mit seiner Raffinesse.
Ihr Code, Ihre Daten und die Logs nebeneinander. Das ist der Vergleich, der die Sache entscheidet, und niemand kann ihn für Sie laufen lassen.
Kostenlos testen