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

[Oliver Bandel]

On Wed, Feb 28, 2007 at 10:22:29PM +0100, Volker Grabsch wrote:
> On Sun, Feb 25, 2007 at 11:12:41AM +0100, Oliver Bandel wrote:
> > On Sun, Feb 25, 2007 at 03:25:07AM +0100, Roland Penzin wrote:
> > [...] 
> > > 
> > > einfacher tip. bist du bei der normalverteilung, ist da integral dessen 
> > > nicht wirklich schwierig/anders . eine atan funktion wäre schon 
> > > schlimmer. aber was ist die atan funktion wirklich anders als das 
> > > integral der normalverteilung - und davon gibt es verteilungskurven - & 
> > > das trifft den sachverhalt richtig - oder  - richtiger. 
> > [...]
> > 
> > Das Integral der Normalverteilung lässt sich nur mit numerischer Integration,
> > nicht in geschlossener Form berechnen.
> 
[...]

> Auch sin und cos, ja sogar das Wurzelziehen, geschehen letztendlich
> näherungsweise durch eine kleine Iteration.
> 
> Für unsere Zwecke düften die ersten 3-10 Terme der Tailorentwicklung
> locker ausreichen. Noch schöner wär's natürlich, wenn das Integral
> der Glockenkurve gleich als Standardfunktion mit geliefert wird.

Was sind "unsere Zwecke"?

Du hattest etwas von Integralen der Gaußfunktion auf
100 Stellen Genauigkeit gesprochen... das braucht
reichlich Rechenzeit.


> 
> > Dafür wäre dann entweder einigermassen großer Rechenaufwand notwendig,
> 
> Unsinn. Für die benötigte Genauigkeit fällt das nicht ins Gewicht.
> Das dürfte fast genauso fix wie ein Cosinus gehen.

Deine Behauptung  mit den 100 Stellen Genauigkeit hast Du vergessen?


> 
> Die Frage ist eher, ob sich der Implementierungs-Aufwand lohnt.

In der Tat!

Ausserdem sind die in den Bibliotheken vorhandenen Funktionen
sicherlich direkt in Assembler codiert.
Wenn Du das in einer anderen Sprache nachbauen willst,
ist es fraglich, ob es was bringt, denn Du durch geeignete
Reihenentwicklung Umwege sparen willst.


> Und
> *das* ist der Grund, aus dem ich von solch einer komplexen Funktion
> eher abraten würde.

Es ist eben auch fraglich, ob es performanter ist, als
ein numerisches Integrationsverfahren zu nutzen und es
auf die Funktion, die man integrieren will, anzuwenden.

Die numerischen Verfahren haben das Problem, auch Ungenauigkeiten
ins Spiel zu bringen.

Andererseits, wenn man eine unendliche Reihe hat, dann muß man
auch - je nach geforderter Genauigkeit - genügend viele
Terme berechnen.

Und es sind da vermutlich - was den Rechenaufwand angeht -
die üblichen Verfahren doch im Vorteil, weil es weniger
Terme sind.

Wie es konkret ausschaut, müsste man einfach mal
ausprobieren; aber ich denke, der Rechenaufwand steigt
gegenüber den bekannten Verfahren der numer. Integration.

Wäre durchaus mal interessant, sowas mal zu konkretisieren.

> 
> > oder man geht wieder zurück auf die Idee mit den Arrays.
> 
> Nee, so schlecht *kann* die Performance nicht sein, nichtmal wenn
> du's auf 100 Nachkommastellen genau haben willst.

Da die üblichen Libs eh keine 100 Stellen Genauigkeit anbieten,
müsste man es eh alles selber bauen.
Damit wird dann natürlich mein Argument mit den in Assembler codierten
Funktionen (cos(), sin(), exp(), ...) hinfällig.


> 
> > Wenn man diesen Wert aber bloß einmal oder gegelegntlich berechnen muss,
> > und es nicht zeitkritisch ist, dann macht's Berechnen on the fly aber
> > vermutlich dennoch Sinn. 
> 
> ACK.
> 

Aus Spaß könnte man sowasja doch mal angehen und es programmieren ;-)


Gruß,
   Oliver