MatLab, Fortran und NumPy
#1
Fortsetzung von dort:

kaimex,'index.php?page=Thread&postID=193038#post193038 schrieb:Dann fällst du aber irgendwie aus der Reihe, denn ich bin bislang kaum einem Physiker oder Elektrotechniker begegnet, der nicht MatLab benutzte wie andere einen Notizblock oder Taschenrechner.

Bei Fortran hätte es hier aber noch allerlei Zeilen mit Variablen-Deklarationen und Laufanweisungen über Array-Indizes gegeben.

Ich hab gerade nebenbei das letzte c't Sonderheft "Programmieren" duchgeblättert (eigentlich nur wegen der Beschreibung eines FPGA-Boards, mit dem man historische 8- und 16 Bit Computer nachbilden kann), dem liegt eine DVD mit mehreren Python-Systemen für Windows, Mac und linux bei. Welches benutzt du ?

MfG Kai

Hallo Kai,

ich mache mal hier weiter, um den anderen Thread nicht endgültig vom Thema abzubringen:

Auch Physiker ist nicht gleich Physiker. In der Experimentellen Teilchenphysik, in der ich tätig war, kommt MatLab quasi nicht vor. Die Werkzeuge dort waren früher FORTRAN mit PAW, dann C++ mit ROOT, und heute Python und NumPy mit einem großen Stack an nützlicher Software außenrum. Modernes Fortran (ab 90, wo die Array-Funktionen kamen) spielte dort schon keine wesentliche Rolle mehr, weil es zu spät kam und der Umzug auf C++ schon vollzogen war. So mächtig und schön C++ sein kann, so viel Ballast bringt es doch mit sich, und so viel kann man falsch machen, wenn man "einfach nur" seine Analyse machen will. The real determined Scientist can write a FORTRAN program in any language.

Inzwischen habe ich die Teilchenphysik verlassen und wende die dort gelernten Methoden an, um trotz voller Regale im Supermarkt weniger Lebensmittel zu verschwenden; auch dort basiert unser Software-Stack auf Python und etwas C++.

Modernes Fortran hat übrigens die gleichen schönen Array-Operationen - man hätte zwar die Arrays noch deklarieren müssen, aber Schleifen mit manuellen Indizes sind auch dort nicht mehr nötig.

In Sachen Python-Installation wird es mir als Linux-Nutzer leicht gemacht: Meine Distribution (Ubuntu, noch 12.04) bringt Pakete für Python, NumPy und alles andere mit, die ich einfach verwende. Natürlich sind das nicht die letzten Versionen, aber damit kommt man schon weit. Erst wenn man aktuellste Versionen braucht (es tut sich ziemlich viel in dem Ökosystem), muss man sich was nachinstallieren.

Unter Windows weiß ich nicht, was die beste Python-Distribution ist - aber ich würde vermuten, in dem c't-Sonderheft steht was dazu, oder eine sinnvolle Version liegt bei. Ich habe einmal kurz mit Anaconda gearbeitet, das hat soweit gut funktioniert.

Eine Entwicklungsumgebung verwende ich nicht - einer der Vorteile von Python ist, dass man auch nicht unbedingt eine braucht, weil die Syntax wenig überflüssigen Code erfordert, den so eine IDE dann generieren würde. Ich bin mit Lieblingseditor Vim rundum glücklich Smile

Was könntest Du noch mit "Python-System" meinen? Ich Verwende aus Gewohnheit noch Python 2 (2.7.3 bei Ubuntu 12.04), aber Python 3 bringt einige schöne Neuerungen. Ach so ja, klassisches cPython. Es gibt auch PyPy, und IronPython, und Python auf der Java VirtualMachine, aber nichts davon brauchte ich bisher Smile

Nachdem ich mich vergeblich mit dem Buch "Learning Python" herumgeschlagen habe, bin ich damals mit dem ausgezeichneten Online-Tutorial Dive Into Python

Viele Grüße
Andreas
Zitieren
#2
Ich meinte mit Python-System die Editionen, die auf der DVD des c't Sonderheftes "Programmieren", 2016, enthalten sind:
Für Windows Python 2.7.11, Python 3.5.1 und WinPython 3.4.4.1,
für Mac OS ebenso Python 2.7.11 & 3.5.1.

Fortran hab ich lange vor 1990 gelegentlich benutzen müssen. Da gab es die Array-Funktionalitäten noch nicht.

Als ich vor einiger Zeit meine noch aktiven Kollegen fragte, ob sie noch MatLab benutzen, oder wegen der hohen Lizenzkosten zu den Clones a'la Octave, SciLab oder FreeMat schwenken, antworteten sie, daß man jetzt manches in Python programmieren würde. Das solle ich mir mal angucken. Hab ich auch kurz anhand eines der Bücher darüber in der hiesigen Zentralbibliothek gemacht, dabei aber garnicht mitbekommen, daß es diese schöne Arbeit-sparenden Array-Funktionen gibt. Deshalb konnte ich damals die Empfehlung garnicht verstehen.

Wird der Python-Code interpretiert oder beim ersten Aufruf kompiliert und ab dann (rasend) schnell abgearbeitet ?

MfG Kai
Zitieren
#3
kaimex,'index.php?page=Thread&postID=193049#post193049 schrieb:Wird der Python-Code interpretiert oder beim ersten Aufruf kompiliert und ab dann (rasend) schnell abgearbeitet ?

Hallo Kai,

letztes, allerdings nicht in nativen (direkt vom Prozessor ausführbaren) Code, sondern in Bytecode à la Java, der von einer virtuellen Maschine ausgeführt wird. Die Programme werden damit in Sachen Performance nie in die Nähe von C oder C++ kommen, normalerweise ist auch Java deutlich schneller (vor allem durch die statische Typisierung). Wenn's wirklich auf das letzte Quentchen Performance bei sehr rechenintensiven Anwendungen ankommt, ist Python wahrscheinlich nicht die richtige Wahl.

Für vieles andere ist es aber wirklich superklasse. Wenn ich für mich selbst mal irgendwas skripte, nehme ich seit Jahren immer Python, weil man darin wirklich sehr schnell und effizient entwickeln kann.

Es gibt übrigens einen alternativen Python-Interpreter namens PyPy, dem man nachsagt, gelegentlich erheblich schneller zu arbeiten als die Referenzimplementierung CPython. Erfahrungen kann ich leider noch nicht beisteuern.

Falls Du eine leistungsfähige Entwicklungsumgebung für Python suchst, sieh' Dir mal PyCharm an. Die "Community"-Version ist kostenlos und sollte für Deinen Anwendungsfall reichen.

Gruß,
Timo
Zitieren
#4
Hallo Kai, hallo Timo,

kaimex,'index.php?page=Thread&postID=193049#post193049 schrieb:Python 2.7.11, Python 3.5.1 und WinPython 3.4.4.1

ah. Mit Python3 werden inkompatible Änderungen eingeführt, die aber eigentlich alle die Sprache konsistenter machen; nur existieren noch unheimlich viele Pakete für Python2, so dass vor ein paar Jahren die Mehrheit der Nutzer noch Python2 verwendet hat. Das ist aber eigentlich gerade am Kippen, es kann also nicht schaden, gleich Python3 zu verwenden. Andererseits sind die Unterschiede so überschaubar, dass man auch recht bald beides im Blick hat.

WinPython scheint mir nicht uninteressant - was ich auf Anhieb unter https://winpython.github.io/ gefunden habe, klingt gut: Lebt in einem Verzeichnis, bringt NumPy und Co. schon mit. Wenn Du es also einfach kurz ausprobieren willst, scheint mir das ein sehr guter Startpunkt zu sein!

kaimex,'index.php?page=Thread&postID=193049#post193049 schrieb:garnicht mitbekommen, daß es diese schöne Arbeit-sparenden Array-Funktionen gibt.

Die Array-Funktionen kommen mit NumPy, das im Prinzip native C-Arrays (sowas wie float[1024]) mit Python-Wrappern versieht. Damit ist der Weg sehr kurz, native C- C++ und Fortran-Libraries aus Python heraus anzusprechen. Die Schleifen der Array-Funktionen laufen damit im nativ compilierten Code - also fast genauso schnell wie in C. Das ist unheimlich nützlich. Einen kurzen Überblick findest Du hier: https://docs.scipy.org/doc/numpy-dev/use...start.html

Weitere nützliche Pakete über die Standard-Libary hinaus sind z.B. iPython (eine interaktive Shell mit Highlighting, Syntax-Ergänzung etc. die meinen Taschenrechner und Notizblock ersetzt) und das iPython-Notebook (inzwischen Jupyter), mit dem Du im Browser Code, Ergebnisse, Plots, Kommentare etc. als ausführbare Zellen anzeigen und bedienen kannst.

Für Plots gibt es leider vor allem die etwas vergurkte Matplotlib, mit deren Interface ich nie warmgeworden bin. Allerdings sagt die Webseite: "For simple plotting the pyplot interface provides a MATLAB-like interface, particularly when combined with IPython." - vielleicht liegt es daran...

Nicht zu vergessen ist auch Pandas, was ein statistisches Datenanalyseframework ist. Es hat so manche Eigenheiten, die mich in der Praxis oft gestört haben, wird aber wohl mit der Zeit auch besser. Ich habe es länger nicht verwendet.

timo,'index.php?page=Thread&postID=193052#post193052 schrieb:Wenn's wirklich auf das letzte Quentchen Performance bei sehr rechenintensiven Anwendungen ankommt, ist Python wahrscheinlich nicht die richtige Wahl.

Performance lässt sich meistens durch Optimierung von wenigen entscheidenden Code-Stellen erreichen.

Wenn reines Python nicht reicht, gibt es den niederschwelligen Weg nach Cython: Das ist eine um statische Typdefinitionen erweiterte Python-Variante, die über C fast unveränderten Python-Code compilieren kann. Wenn man z.B. eine lange Datenschleife hat, bringt es schon enorm viel, den Schleifenzähler als int zu deklarieren und das ganze als Cython-Modul zu übersetzen.

Wenn das noch nicht reicht, kann man auch echten C, C++- oder Fortran-Code ohne viel Interfacing-Arbeit einbauen. Die ideale Arbeitsteilung ist dann, die harten Berechnungen in einer nativen Hochsprache und die Ablaufsteuerung und Ergebnisaufbereitung in Python zu machen.

timo,'index.php?page=Thread&postID=193052#post193052 schrieb:Es gibt übrigens einen alternativen Python-Interpreter namens PyPy, dem man nachsagt, gelegentlich erheblich schneller zu arbeiten als die Referenzimplementierung CPython.

PyPy verwendet einen Just-In-Time-Compiler, der sich den Code im Betrieb ein paarmal ansieht und dann weiß, welche Variante der Routine wie aufgerufen wird. Damit kann er quasi nach einigen Durchläufen die Typen erraten und optimierten Code erzeugen. Für numerische Berechnugen weiß ich diese Typen aber normalerweise schon vorher, so dass man schon mit NumPy alleine oft schnell genug ist.

Zur Performance noch ein kleines Code-Beispiel: Die im vorigen Thread diskutierte Generierung von 10 Sekunden Sinus, und anschließend die Effektivwertberechnung, in klassischem Python und mit NumPy:

Code:
from math import sin, pi
import numpy as np

def gen_classic(fs=96000, T=10):
    out = []
    for i in range(fs * T):
        out.append(sin(2*pi * 1000 * i / fs))
    return out
        
def gen_lc(fs=96000, T=10):
    return [sin(2*pi * 1000 * i / fs) for i in range(fs * T)]

def gen_np(fs=96000, T=10):
    return np.sin(2*np.pi * 1000 * np.arange(fs*T) / fs)

def eff_classic(a):
    sqsum = 0
    for i in a:
        sqsum += i*i
    return (sqsum / len(a))**.5

def eff_np(a):
    return np.sqrt(1. / len(a) * np.sum(a**2))

Nun hat IPython ein schönes Feature, um einfach die Performance eines Statements zu messen. Die Session sieht so aus:

Code:
Python 2.7.3 (default, Jun 22 2015, 19:33:41)
Type "copyright", "credits" or "license" for more information.

IPython 0.12.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from perf import *

In [2]: %timeit gen_classic()
1 loops, best of 3: 507 ms per loop

In [3]: %timeit gen_lc()
1 loops, best of 3: 420 ms per loop

In [4]: %timeit gen_np()
10 loops, best of 3: 82.2 ms per loop

In [5]: a1 = gen_classic()

In [6]: a2 = gen_np()

In [7]: %timeit eff_classic(a1)
10 loops, best of 3: 111 ms per loop

In [8]: %timeit eff_np(a2)
100 loops, best of 3: 4.59 ms per loop

Die Variante gen_lc ist immernoch klassisches Python, verwendet aber eine list comprehension, bei der die Schleifen auch wesentlich schneller ausgeführt werden. Die Version gen_classic würde man eigentlich in Python selten so schreiben - das ist quasi aus anderen Sprachen bekannte Elemente in Python übersetzt. Bei der Sample-Erzeugung ist der Unterschied noch moderat - NumPy ist nur etwa 6mal schneller. Bei der Effektivwertberechnung ist schon ein Faktor 24 drin. Je nach Anwendungsfall kann da auch mal 2000 stehen...

Viele Grüße
Andreas
Zitieren
#5
Danke für die Erläuterungen, Timo & Andreas,

zwar interessant, aber die Begeisterung nimmt angesichts der Details dann doch nicht zu, denn wenn man Software-Evolution schon einige Jahrzehnte miterlebt hat, hat man doch einen dejavue-Effekt insofern: wieder ne neue Sprache, wieder viele Details per Lernkurve aufnehmen, bis man ein Gespür dafür hat, was flott geht und was man vermeiden sollte. Und wenn man es dann endlich flüssig benutzen kann, stellt man fest, daß es auch wieder nicht der große Schritt nach vorn war.
Ich hab viele Jahre lang Dinge, die gelegentlich schnell gelöst/berechnet/grafisch dsrgestellt werden sollten, mit MatLab gemacht. Man verliert sich nicht in Programmiersprachendetails und schreibt komplexe Matrizenrechnungen hin wie Dreisatzaufgaben. Sehr bequem für numerisches Prototyping oder Test von Algorithmen, bevor man sich dran setzt, es in einer Sprache zu formulieren, die zu schnellstmöglicher Rechnung führt.
Ich hab sogar eine "perpetual license", also eine ewige Lizenz, das Dumme ist nur, daß ich mein MatLab-Paket seit Windows 7 nicht mehr auf einem aktuellen Rechner installieren kann. Das liegt an einem grotesken Detail: Die Installationsroutine besteht darauf, an einer Stelle eine alte Microsoft Java Implementation zu benutzen, die Microsoft vor einiger Zeit aufgegeben hat und darüber hinaus verweigert, es unter den neueren Windows nachzuinstallieren. Inzwischen habe ich zwar von einem trickreichen Workaround gehört, traue mich aber noch nicht, das mal auszuprobieren, aus Angst, damit die vorhandene aktuelle Java 7 Installation zu beschädigen.
Octave und SciLab hab ich auch schon probiert, sind in manchen Details anders, man kommt dann schnell mit den spezifischen Unterschieden durcheinander. Außerdem sind sie langsamer als MatLab. Bei SciLab hängt die Geschwindigkeit von der Code-Formulierung ab. Wenn ich es recht entsinne, werden nur Funktionen vorkompiliert. Es macht also im Gegensatz zu MatLab einen großen Unterschied, ob ich etwas als in-Line Code hinschreibe oder als einen Haufen von Funktionen formuliere. Bei Octave beginnt man anscheinend erst jetzt, Kompilierung einzubauen.
Unerfreulich ist zudem, daß man als Privatmensch für den MatLab-Vertrieb offenbar völlig uninteressant ist: man kann entweder online eine aktuelle Lizenz kaufen oder es sein lassen. Man bekommt keine Chance, mit Vertriebsmitarbeitern direkten Kontakt aufzunehmen.
Als ich vor einiger Zeit in einem MatLab User-Forum versuchte, den Autor des Workarounds nach Details wegen meiner Bedenken zu fragen, meldete sich stattdessen jemand, der fragte, wieso ich eine so alte Version überhaupt noch benutzen wolle, es gäbe doch aktuelle erweiterte und es sei unbilig zu fordern, daß meine immer noch zu installieren sei.

MfG Kai
Zitieren
#6
kaimex,'index.php?page=Thread&postID=193059#post193059 schrieb:wieder ne neue Sprache, wieder viele Details per Lernkurve aufnehmen, bis man ein Gespür dafür hat, was flott geht und was man vermeiden sollte.

Anspruchsvoller als neue Sprachen sind m.E. neue Sprachparadigmen. Die von Andreas genutzte List Comprehension setzt den Ansatz der funktionalen Programmierung voraus. Das sieht für jemanden, der von der imperativen oder objektorientierten Programmierung kommt, ein bisschen so aus, als würde man das Pferd von hinten aufzäumen (statt "Ich übergebe einer Funktion ein Array als Parameter" heißt es da "Ich rufe eine Methode des Arrays auf und übergebe dieser die Funktion als Parameter"). Meiner Erfahrung nach gewöhnt man sich da aber schnell dran. Mir kam die Hürde beim Wechsel von der imperativen auf die objektorientierte Programmierung deutlich größer vor, weil der Lösungsansatz teilweise von Grund auf unterschiedlich ist.

Mir juckte es übrigens gerade in den Fingern, Andreas' Test mit List Comprehension mal spaßeshalber gegen eine entsprechende Lösung in C++ antreten zu lassen, aber irgendwie bin ich heute zu müde dafür. Vielleicht morgen. Smile
Zitieren
#7
Gerne, mach mal, wenn es übersichtlich bleibt, und man ohne jedes Wissen darüber den Unterschied begreifen kann.
Ich hab so ca. 1968 angefangen zu programmieren als Student. Damals war ALGOL üblich, irgendwann begegnete man dann dem alten F ORTRAN IV , spâter Fortran 66 und so weiter. Als es Anfang der 80er Jahre mit den 8Bit PCs losging, natürlich BASIC und Assembler. Später dann Turbo-Pascal, etc.. Insofern war man "prozedural" geprägt und dachte, als die objekt-orientierten Sprachen rauskamen, " was soll das denn, ging doch bisher wunderbar völlig ohne" und "wieso sind Programme, die genau das gleiche tun, auf einmal so viel größer und wieso ist der Compiler so groß". Tut sich in dieser Hinsicht bei " List Comprehension" wieder ein Sprung nach "vorn" ?
Mir kommt immer das große Grausen, wenn ich den Speicherplatzbedarf aktueller Compiler oder Entwicklungssysteme sehe. Um mit dem erwähnten FPGA eigene Ideen realisieren zu können, muß man sich anscheinend 4,5 GByte auf die Festplatte schaufeln.
Ich glaube, der erste Turbo-Pascal Compiler war keine 100k groß. Wenn man heute "Hello World" mit "Visual Dingsbums" compiliert, ist der EXE-File schon einige x00 kByte groß. Man hat dann , wenn man einen Haufen kleiner Programme geschrieben hat, genauso hâufig immer wieder ein beträchtlichen Anteil der Runtime-Library auf der Platte. Das zu vermeiden, wird offenbar als unwichtig betrachtet, weil ja genügend Festplattenplatz da sei.
Kannst du einen Literaturverweis geben, wo man sich mal erste Informationen über diesen neuesten Ansatz verschaffen kann ?
Es ist ja immer noch besser, etwas bewußt zu ignorieren, wenn es sich nach näherer Betrachtung nicht als das neue Glück herausstellt, als garnichts davon zu wissen.

MfG Kai
Nachtrag:
Inzwischen habe ich den Artikel über NumPy in der Wikipedia gelesen. Da steht nicht ganz richtig,
"Using NumPy in Python gives functionality comparable to MATLAB since they are both interpreted" .
Meines Wissens wird Matlab-Code beim Ausführen nach Syntax-Check "On-the-fly" kompiliert. Deshalb ist es auch bei nahezu gleichem Code immer noch schneller als Octave oder SciLab, die das gleiche leisten wollen.
Zusatzfrage: Läßt sich NumPy zur Zeit nur in CPython nutzen ?
Zitieren
#8
kaimex,'index.php?page=Thread&postID=193062#post193062 schrieb:Insofern war man "prozedural" geprägt und dachte, als die objekt-orientierten Sprachen rauskamen, " was soll das denn, ging doch bisher wunderbar völlig ohne"

Hat sich mir auch erst nur langsam erschlossen, aber mit steigender Größe seiner Projekte lernt man den objektorientierten Ansatz dann doch zu schätzen. Ist vielleicht auch eine Frage des Anwendungsbereichs. Beruflich entwickele ich im Bereichs eines Werkzeugs für die Abbildung von Geschäftsprozessen, und da hat man mit vielen Elementen (Diagrammen, Diagrammgruppen, Diagrammbausteinen) zu tun, die in gleicher oder ähnlicher Form immer wiederkehren. Da ist es einfach naheliegend, mit Objekten zu arbeiten.

Zitat:und "wieso sind Programme, die genau das gleiche tun, auf einmal so viel größer und wieso ist der Compiler so groß"

Na gut, das egalisiert sich ja weitgehend durch immer schnellere Hardware. Ich habe meine ersten Programme (wenn man davon sprechen kann) auf dem C64 geschrieben. Da gab es, wenn man wirklich effizienten Code wollte, keine wirkliche Alternative zu Assembler. Bei einem Prozessortakt von knapp 1 MHz und 56 (?) Kilobytes nutzbarem RAM musste man sparen, wo man konnte. Im Vergleich dazu schleppte ein "Hello World" in Turbo Pascal unter MS DOS schon einiges an Ballast mit sich herum, aber man konnte schneller und angenehmer größere Projekte entwickeln.

Genau nach dem Motto ging die Entwicklung eigentlich bis heute weiter. Und gerade, wenn man damit seine Brötchen verdient, muss man ja auch aus anderer Perspektive dankbar dafür sein, denn wenn es nicht die Tendenz gäbe, dem Entwickler seine Arbeit zu erleichtern und Entwicklungsaufwand einzusparen, würden Programme heute vermutlich vermehrt irgendwo in Niedriglohnländern entwickelt.

Zitat:Kannst du einen Literaturverweis geben, wo man sich mal erste Informationen über diesen neuesten Ansatz verschaffen kann ?

Leider fällt mir auf Anhieb nur der Wikipedia-Artikel ein:

https://de.wikipedia.org/wiki/Funktional...rammierung

Schneller Erklärungsversuch an zwei simplen Beispielen: Zwei typische Array-Methoden der funktionalen Programmierung sind map und filter.

Die Map-Methode konvertiert jedes einzelne Element des Arrays. Wenn man ein Array mit Fließkomma-Werten hat und nur den ganzzahligen Wert braucht, könnte man das funktional in Python so lösen:

Code:
def konvertiereInGanzzahl(fWert):
    return int(fWert)

aFloat = [1.5, 2.7, 6.4, 3.3]

aInt = map(konvertiereInGanzzahl, aFloat)

print (aFloat)
print (aInt)

Ergebnis:

[1.5, 2.7, 6.4, 3.3]
[1, 2, 6, 3]

In Javascript kann man es noch anschaulicher darstellen:

Code:
aFloat = [1.5, 2.7, 6.4, 3.3]
aInt = aFloat.map(
    function(iValue)
    {
        return Math.trunc(iValue);
    }
);

Filter lässt nur die Elemente des Arrays durch, die eine bestimmte boolsche Bedingung erfüllen. Braucht man aus dem Array nur die Werte, die kleiner oder gleich 5 sind, kann man es so machen:

Code:
def istKleinerGleichFuenf(fWert):
    return fWert<=5

aFloat = [1.5, 2.7, 6.4, 3.3]

aFloat2 = filter(istKleinerGleichFuenf, aFloat)

print (aFloat)
print (aFloat2)

Ergebnis:

[1.5, 2.7, 6.4, 3.3]
[1.5, 2.7, 3.3]

Sinnvolle Anwendungsfälle erschließen sich vielleicht nicht auf den ersten Blick. In Verbindung mit Objekten können einem die Methoden das Leben aber oft erheblich erleichern. Wenn man z.B. eine Liste von Objekten hat, die jeweils über eine "Name"-Eigenschaft verfügen, und man nur ein Array mit den Namen braucht, die sich schnell und einfach lösen lässt, ist das mit Map einfacher und eleganter zu lösen, als wenn man sich mit einer Schleife ein zweites Array aufbauen muss.

Was die List Comprehension angeht, korrigiere ich meine Aussage von gestern übrigens: Ein klassischer Fall der funktionalen Programmierung ist das nicht. Der Ansatz ist lediglich ähnlich.
Zitieren
#9
Moin moin Timo,

danke für den Hinweis auf Wiki über Funktionale_Programmierung.

Dadurch erfuhr ich endlich mal kurz gefaßt, was das Lambda-Kalkül ist und,
was ich garnicht wußte, daß ich im vorigen Jahrhundert schon mal funktional programmiert habe:
Da wo ich arbeitete, gab es auch einige Mathematiker und Informatiker.
Einer davon ließ sich immer gern über "Programmiersprachen der 4.ten" oder "5.ten Generation" aus, weiß ich nicht mehr so genau. Von dem bekam ich dann mal µLisp für CP/M zum kennenlernen und hab ein bischen damit rumgespielt. Interessierte mich hauptsächlich, weil es darin auch eine kleine Version des Macsyma Paketes für symbolische Algebra gab. Lisp war nach Wiki schon funktionale Programmierung.
Ein anderer Kollege, ich glaube Mathematiker, war geistig etwas abgehoben vom Rest und schwierig dazu zu kriegen, das zu tun, was die Firma von ihm erwartete. Wenn es in fachlichen Diskussionen hin und herging, wurde irgendwann der Zustand erreicht, in dem er anfing, sich auf das Lambda-Kalkül zu beziehen, da sei dies und das längst geklärt worden, was gleichbedeutend damit war, daß er der einzige Durchblicker unter lauter unverständigen Dummies war. Dann war es immer das Vernünftigste, erstmal für einige Zeit auseinander zu gehen.

MfG Kai
Zitieren
#10
kaimex,'index.php?page=Thread&postID=193069#post193069 schrieb:danke für den Hinweis auf Wiki über Funktionale_Programmierung.

Da ich gerade über die Meldung auf pro-linux.de gestolpert bin: Der O'Reilly-Verlag hat u.A. ein eBook "Functional Programming in Python" als quasi-kostenlosen Download freigegeben:

http://www.oreilly.com/programming/free/

("Quasi-kostenlos", weil man sich registrieren muss. E-Mail-Adressen sind ja auch eine Art Zahlungsmittel. Smile )
Zitieren
#11
Wie ist da eigentlich die Rechtslage ?
Darf man einen "Detlef Mustermann" vorschicken, der sich registrieren läßt, und danach den Download an all seine Freunde hier im Forum kostenlos weitergibt ?

MfG Kai
Zitieren
#12
timo,'index.php?page=Thread&postID=194937#post194937 schrieb:("Quasi-kostenlos", weil man sich registrieren muss. E-Mail-Adressen sind ja auch eine Art Zahlungsmittel. Smile )
Ich nehm dann immer abc.def@xyz.com als Email Adresse, das klappt meistens. Big Grin
Strom kann erst dann fliessen, wenn Spannung anliegt.
Zitieren
#13
bitbrain2101,'index.php?page=Thread&postID=194973#post194973 schrieb:Ich nehm dann immer abc.def@xyz.com als Email Adresse, das klappt meistens. Big Grin

Ernsthaft? Kriegt man da nicht meist eine Mail, wo man die Registrierung bestätigen muss? Smile

http://www.wegwerfemail.de geht manchmal, meist wird's aber geblockt.
Zitieren
#14
Ich nehme auch an, daß mindestens die Existenz der Emailadresse erstmal verifiziert wird.
Deshalb fürchte ich, daß Ratten-mäßiges Verhalten angesagt ist: Einer wird losgeschickt und muß "sich opfern".
Da ich aber für mein nächstes Leben keine weiteren Minuspunkte ansammeln möchte, interessiert mich schon, ob unkommerzielle Weitergabe erlaubt ist.

MfG Kai
Zitieren
#15
timo,'index.php?page=Thread&postID=194974#post194974 schrieb:Ernsthaft? Kriegt man da nicht meist eine Mail, wo man die Registrierung bestätigen muss?
Wenn da eine Bestätigung erforderlich ist, geht das nicht. Bei GMX wird nur überprüft ob Strasse und Postleitzahl passen, wenn man ein kostenloses Email Konto erstellt. Das ist für solche Zwecke ganz praktisch.

MfG, bitbrain2101
Strom kann erst dann fliessen, wenn Spannung anliegt.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste