[linux-l] [OT] Gewichtete Wahrscheinlichkeit, Random

Di Mär 20 12:43:02 CET 2007

On Mon, Mar 19, 2007 at 08:48:28AM +0100, Volker Grabsch wrote:
> On Fri, Mar 02, 2007 at 01:45:25PM +0100, Oliver Bandel wrote:
> > > > > Integration von x^2 ergibt eine Funktion, Integration
> > > > > von sin und cosergibt eine Funktion.
> > > > > 
> > > > > Für die Integration der Gauß-Funktion lässt sich KEINE
> > > > > Funktion angeben!
> > > > 
> > > > Was macht das Integral der Gauß-Funktion so besonders?
> > > 
> > > Die Gaußfunktion besitzt keine Stammfunktion.
> 
> Jede stetige Funktion besitzt eine Stammfunktion, so auch die
> Glockenkurve. Genau genommen besitzt sie sogar unendlich viele
> Stammfunktionen (... die sich aber nur durch Addition einer
> Konstanten unterscheiden).

OK, da habe ich Unsinn erzählt. Die korrekte mathematische Formulierung
ist mir nicht eingefallen. Hatte mich wegen der geschlossenen nicht-Lösbarkeit
noch mal umgeschaut. Das ist zwar ein gängiger Begriff, aber wohl
etwas schwammig. Den habe ich so aber imS tudium mit auf den Weg bekommen.

> 
> > [...]
> > Jedenfalls keine, die man mit elementaren Funktionen darstellen kann.
> 
> Na bitte, da hast du's ja doch endlich kapiert:

Au Mann, Dein Tonfall ist auch nicht megr so vorbildlich, wie Du ihn immer
von anderenerwartest (und bisher auch meistens praktiziert hast).

Läßt Du Dich vom Pöbel-Virus anstecken?

Dann eine kleine Lektion für Dich:
  1.Regel: "is' do' eh allet scheisse"

Damit fährt man dann bzgl. der Erstellung von Nerv-Mails ganz gut ;-)

> Die Frage ist nicht,
> *ob* man ihr Integral durch andere Funktionen darstellen kann, sondern
> ob man sie *mit einer bestimmten Grundmenge* von Funktionen darstellen
> kann.
> 
> Will sagen, das hängt alles davon ab, welche Funktionen du als
> "elementar" gelten lässt.
> 
> Beschränkst du dich z.B. auf die vier Grundrechenarten, so sind
> weder  e^x noch sin(x) geschlossen darstellbar. Ja, nichtmal die
> Wurzelfunktion.

Der Begriff der geschlossenen Integrierbarkeit wird da aber nicht angewandt.
Sorry, ist aber gägnige Praxis, das so zu benennen.
Ich habe den Sprachgebrauch von den Öehrkräften in meinem Studium aufgegriffen
und wenn das mathematisch ungenau sein sollte, dann hat man mir während meines Studiums
eben eine mathematisch ungenaue Sprachwahl beigebracht.

Das Problem in der Praxis bleibt aber dennoch bestehen:
Während Du für sinus und cosinus eine simple Formel
für das Integral angeben kannst, geht es beim Integral der
Gaußkurve nicht.

> 
> Nimmst du die Exponenten, Logarithmen, Wurzeln, trigonometrischen
> Funktionen und deren Umkehrfunktionen hinzu, kannst du sehr viel
> mehr darstellen. Das Integral der Glockenkurve gehört aber nicht
> dazu.

Eben.
Die macht es einem nicht so leicht.

> 
> Das ist in der Geometrie genauso: Die Quadratur des Kreises ist
> lediglich unlösbar, wenn man nur Konstruktionen mit *Zirkel und Lineal*
> zulässt. Sind einem mehr Hilfsmittel gegeben, wäre das u.U. durchaus
> lösbar.

Welche Hilfsmittel wären da notwendig?

> 
> In der Auswahl der Grundfunktionen liegt eben die Willkür. Was sind
> beim Computer Grundfunktionen? ln? sin? Nur, weil dir die Standard-
> Libs der verschiedenen Programmiersprachen entsprechende Funktionen
> bereitstellen? Die arbeiten genauso mit Näherungsformeln, oder
> "nummerisch", wie du es nennst. Deshalb nenne ich deine Argumentation
> willkürlich.

Aus mathematischer Sicht mag das stimmen, aus praktischer Sicht nicht.
Davon abgesehen: diese Willkürlichkeit, wie Du sie nennst ist aber gängige Praxis
und wurde mir beim Studium so beigebracht.
Das sind vielleicht die Nachteile eines FH-Studiums. Als praktischer
Hinweis ist dies aber nicht so ganz verkehrt.
Auch in der mathematischen Praxis schliesslich - ich denke da an Tabellenbücher,
in denen man Integrale nachschlagen kann - findet man für's Gaußintegral
nur Zahlentabellen.
Diese Willkür, wie Du sie nennst, ist also weiter verbreitet, als
Du vielleicht annimmst.

Und wenn dem so ist, bleibt die Frage, wieso das so gehandhabt wird.

> 
> Wo ist also der grundsätzliche Unterschied zwischen der Berechnung
> von sin() und des Integrals der Glockenkurve? Es gibt keinen!

sin und cos kann man geometrisch herleiten (stammen ja auch aus dem
Bereich) und möglicherweise
liesse sich daher das Integral auch geometrisch ermitteln.
(Mit Zirkel und Lineal??)

Bei der Gaussfunktion liegt der Fall anders.

> Es
> *könnte* höchstens sein, dass man keine guten Näherungsformeln für
> letzteres kennt, aber das wage ich sehr zu bezweifeln, schließlich
> ist diese Funktion in keiner Weise "bösartig".

Ist "bösartig" eine willkürliche Benennung?

Soweit ich weiss, gibt es auch keine Näherungsformeln für das
Gaußintegral. Aus dem Grunde findet man Zahlenwerte in den Tabellenbüchern.
Übrigens nicht nur in den Billig-Büchern, sondern auch im Bronstein-Semendjajew
findet man nur Zahlentafeln.

> ------------------------------------------------------------------------
> 
> Zurück zum Ausgangsthema: Insbesondere kannst du keine Rückschlüsse
> auf die Performance ziehen!
> 

Ich nehme an, daß die performance keine große sein wird, wenn ich mir
die Gauß-Funktion anschaue und die Art, wie man Taylorreihen entwickelt.

Bei der Gaußfunktion hat man die Kettenregel anzuwenden.
Für alle Elemente der Reihe hast Du solche Terme. Das bläht
die ganze Mimik auf.
Ich habe es nicht ausprobiert, ob man die vielen verschiedenen
Terme so zusammenfassen kann, daß die Formel einigermassen
simpel bleibt. Mag sain, das klappt, dann hättest Du recht,
daß das nicht unbedingt ein Performance-Bottleneck sein müsste.
Aber das müsste man ganz genau mal durchrechnen; auf den ersten Blick zumindest
sieht es so aus, daß der Ausdruck extrem aufwändig wird.

Und da in manchen Bereichen der Wissenschaft diese Funktion recht oft benutzt wird,
frage ich mich, wiesoman nirgends eine Reihendarstellung
bzw. nen Algorithmus vorfindet, der das Gaußintegral errechnet.

Ich habe den begründeten Verdacht, daß es daran liegt, daß
das zu rechenintensiv ist, und die Implementierung auch
aufwändig ist.
Aber vielleicht liege ich damit falsch und es sind die Leute alle
bloß zu faul. Glaube ich aber nicht wirklich, auch wenn ich es nicht
ausschliessen kann.

> Eine "geschlossene" Formel ist nur dann wertvoll, wenn die
> Grundfunktionen *wirklich* elementar sind (direkt vom Prozessor
> unterstützt).

Stimmt nicht. Man kann mathematische Gleichungslösungssysteme
heranziehen und lässt ohne eine numerische Integration durchzuführen,
sich das Ergebnis ausgeben.
Beipiele wären Integral/Ableitung von Polynomen und sinus/cosuinus/...,
oder eine Polynomdivision usw.

Man braucht da keine Näherungsformeln, man braucht kein Rechenwerk,
das geht mit symbolischer Mathematik und folglich hat man auch keine
Rundungsfehler. Man arbeitet nur symbolisch ohne Rechnerei.

Man kann so z.B. ein UNBESTIMMTES INTEGRAL für den Sinus
angeben, für die Gaußfunktion aber nicht.

Man kann also, wenn man das Gaussintegral braucht,
mit seinen Formelumstellereien nicht mehr weiter machen
und geht dann zwangsläufig auf numerische Mathematik über.

Wenn Du das als willkürlich bezeichnen magst, bitte.
Ich denke, es wird seine Gründe haben.

[...]
> Aber: Eine monströse geschlossene Formel aus 'zig anderen Funktionen wie
> arctan(), sin() und ln() kann durchaus sehr langsam sein, weil jede dieser
> Teilfunktionen separat "angenähert" wird.

Nur wird eine numerische Integration üblicherweise nicht so durchgeführt,
daß man eine Funktion in arctan/ln/sin-Termen darstellt.

Man nimmt Funktionswerte und nähert, indem man z.B. ein
Rechteckfenster oder ein Parallelogram zur Flächenberechnung heran zieht.
Bei der Gaussfunktion wäre es dann ein Quadrat-Term und eine e-Funktion.
Zweimal angewandt und eine Fläche berechnet Du hast schon eine Näherung
für dein Integral.
Wenn Du aber Deine Reihenentwiclung für die Gaussfunktion anwendest...
...wie gesagt, Kettenregel anwenden und man kommt auf sehr große
Terme. Nur, wenn man das zeugs gut zusammenfassen kann, macht es
Sinn, dies auch zu implementieren. Ansonsten rechnet man ewig lange
an seinen Reihen herum.

Da DU ja derjenige bist, der die gängige Praxis in Frage stellt,
müsstest DU es eigentlich auch sein, der das Proof-of-Concept
vorstellt. Du verlangst das ja ansonsten von mir auch.
Da ich mich bequeme, im Falle des Gaußintegrals den gängigen,
üblichen Vorgehensweisen zu folgen, wäre es Dein Task, einen besseren
Weg aufzuzeigen.

> Da ist ein direktes Näherungs-
> verfahren für die Zielfunktionen u.U. sogar performanter.

Wenn Du eine Funktion erst in arctan/sin/ln usw. umsetzen willst,
dann bestimmt. Nur macht man eine Taylorreihenentwicklung aber
NICHT auf diese Weise. Das geht nämlich mit einfachen Polynomen.
Bloß mögen die im Falle der Gaußfunktion eben auch nicht mehr so einfach sein
und man fährt mit einer numerischen Integration womöglich weitaus besser.
Zumindest bzgl. Performance. Wegen der Ungenauigkeiten der Näherungsverfahren
mag eine eigene Implementation für Gauß-Int sinnvoll sein.

Nur reden wir immer über, wie Du es ausdrückst, heisse Luft.
Wenn Du meinst, es geht mit Taylorreihenentwicklung und direkter Berechnung besser:
OK, gerne schaue ich Deinem Ergebnis zu, das Du uns demnächst präsentieren willst. ;-)
Da sage ich Dir sogar zu, daß ich es nicht so flüchtig lese,
wie ich sonst hier die Mails lese ;-) sondern es sogar aufmerksam
durchzugehen :)

> Das gilt
> ganz besonders dann, wenn man nur 2 oder 3 Nachkommastellen braucht.

Ich hatte die 100 Stellen Genauigkeit noch in Erinnerung :)
Ein bischen reizvoll muss die Sache ja bleiben. :)

> Dann ist ne selbstgebaute Näherung, z.B. die ersten 5 Glieder der
> Tailorreihe, i.d.R. sauschnell ... sogar schneller als ein einziger
> Aufruf von sin() oder ln().

Du machst das, was Du mir immer vorwirfst: Du redest theoretisch über Sachen.

Ich sage: Index auf Files wird schneller sein als Volltextsuche.
Die gängige Praxis (man hat Datenbanken entwickelt, weil man mit Indexen
sicherlich besser fährt als mit Volltextsuche) bestätigt meine Annahmen.
Daher gehe ich erst mal davon aus, daß die auch stimmig ist.
Dennoch wird erwartet, ich solle das belegen.

Ich sage: Gaußintegral-Berechnung wird vermutlich zu aufwändig sein
und es gibt einige Hinweise dafür, daß dem so sein könnte, und einer
der Hinweise sind fhlende Bibliotheken, die dies implementieren.
Du sagst: eine direkte Berechnung wird performanter sein und läufst damit
dem gängigen Vorgehen zuwider. Und dennoch wird von mir wieder erwartet,
einen beleg anzuführen, nur diesmal, daß ich nachweise, daß es Gründe gibt,
wieso man es bisher nicht so gemacht hat, wie Du annimmst, daß es - entgegen
gängiger Praxis - gemacht wird.

Findest Du nicht, daß die Erwartungen hier recht einseitig an meine
Person gerichtet sind?
Insbesondere, wo ich bei meinen Behauptungen bzgl. Indexsuche auf
gängige Praxis mich berufen kann, Du hingegen mit Deiner Behauptung
entgegen der gängigen Praxis stehst.

> 
> In interpretierten Sprachen mag das anders aussehen, weil dort selbst-
> gebaute Näherungsverfahren um Größenordnungen langsamer sind als die
> Standardfunktionen. Das heißt aber nicht, dass man Funktionen wie das
> Integral der Glockenkurve nicht performant berechnen *kann*, sondern
> nur, dass diese Sprache dafür ungeeignet ist. Würde man ne entsprechende
> C-Funktion analog zu sin(), ln(), etc. schreiben, ginge das sicher
> genauso performant.

Schaue Dir die Gaussfunktion an.
Dann schaue, was man machen muß: Ableitungen ohne Ende.
Und dann berücksichtige, man brauht die Kettenregel.

Wenn Du meinst, man kann da eine gute Reihenentwicklung angeben,
die performante Ergebnisse zeitigt, bitteschön. Zeig das mal.

Ich warte also auf Deine Ergebnisse
(genauso, wie ihr wohl auf meinen mbox-Indexer wartet).

OK, warten wir weiter. Ist man bei der BeLUG ja gewöhnt ;-)

Gruß,
   Oliver