Release Candidate schrieb am 12. März 2007 11:43
> Rashim schrieb am 12. März 2007 11:07
>
> > Release Candidate schrieb am 12. März 2007 7:42
>
> > > Naja, falls deine Matrix und der Vektor gerade richtig beschaffen
> > > sind (Matrtix- und Vektornorm hinreichend klein (aber nicht zu
> > > klein)).
> > > Aber ja, das ist _sehr_ unwahrscheinlich.
> >
> > Das kann man vor allem bei neuronalen Netzen nicht garantieren. Da
> > hat man ja gar keine Ahnung in welchem Bereich sich einige Werte
> > befinden und vor allem wohin sie sich entwicklen werden.
>
> Keine Ahnung, zu neuronalen Netzen kann ich nichts sagen.
Da sehen die Matrizen jedesmal lernen anders aus. Da kannst Du nicht
sagen, was in einer Zelle steht, ausser dass sie den gesamten Bereich
abdecken kann. Sie werden iA auch mit Zufallswerten initialisiert.
> > > Ja, aber manchmal geht's nicht anders (und funktioniert auch ohne
> > > Probleme mit double Prec.).
> >
> > Also ohne Probleme würd ich einen Verlust der signifikanten Stellen
> > in der Grössenordnung von 6-8 nicht nennen.
>
> Ich auch nicht, das Beispiel darfst du jetzt nicht zaehlen.
Wenn es nett ist, dann kann man aber auch mit floats iterieren ;).
> > > Das ist auch gut so, da du bei einer Addition von
> > > Floating-Point-Zahlen immer signifikante Stellen verlierst (damit das
> > > immer stimmt, verliert man halt manchmal 0 signfik. Stellen ;).
> >
> > Eine Addition ist da richtig harmlos. Die Sub ist böse, da sie in dem
> > Fall ja das Rauschen zum wichtigsten Beitrag machen kann.
>
> Aeh, es gibt nur zwei Operationen, Addition und Multiplikation ;)
:)
> Aber ja, eine Subtraktion ist das, was mehr Probleme macht.
>
> > > [*] was bei den US Patriots (Scud-Abwehrraketen) im Golfkrieg
> > > passiert ist.
> > > Wenn die laenger (mehrere Tage) durchgelaufen sind haben die nichts
> > > mehr getroffen. Die Geschwindigkeit der Scudraketen wurde mit einem
> > > Differenzenquotient ermittelt ((s1 - s0)/(t1 - t0)), wobei die Zeiten
> > > als Sekunden seit dem Start der Patriot gegeben waren. D.h. nach
> > > einiger Zeit sind die Zahlen gross mit sehr kleinen Unterschieden :)
> >
> > Urks, wer kommt auf sowas? Das muss ja schief gehen. Man sieht aber
> > schön, dass die Tests alle sehr kurz waren ;).
>
> Ja, _den_ Fehler haette auch ein Student im ersten Semester Numerik
> erkennen muessen.
Oder zumindest jeder Techniker, der mit Industriesteuerungen zu tun
hat. Fertigungsstrassen laufen auch länger ;).
> > Da muss man Ints nehmen und Takte zählen.
>
> Sie haetten einfach die Zeiten sinnvoller waehlen koennen, es geht
> schliesslich nicht um absolute Zeiten (es ist der Scud ziemlich egal,
> wann der Steuerrechner der Patriot gestartet wurde ;).
Ja, ist nur die Frage wie man zur Differenz kommt. Entweder einen
zusätzliche Hardware, die gestartet wird und dann mitzählt, oder eben
die Zeit in Takten zählen. Zweiteres hat man meist irgendwo bei der
Hand.
> > Die haben den Vorteil, dass sie sogar gehen,
> > wenn sie einen Überlauf hatten. Man braucht also nicht unbedingt
> > 64Bit, sondern es reichen 32Bit, selbst wenn man damit gerade mal ein
> > paar Minuten abdecken kann (der darstellbare Zeitraum muss aber schon
> > deutlich grösser als der notwendige sein).
>
> Ohja, und dann wird die gleiche Software fuer ein Nachfolgeprodukt
> verwendet, fuer das dass nicht mehr stimmt, weil etwa die
> Beschleunigung auf einmal _deutlich_ hoeher ist (ESA und Ariane 5 ;)
Die Beschleunigung ist egal, es müssen die Messintervalle passen und
natürlich die Genauigkeit des Taktes im Messzeitraum. Wenn Du mit
10ns zählst, dann hast Du alle 42s einen Überlauf bei einem 32Bit
Zähler. Wenn Du aber mit 10ns zählst, dann wirst Du hoffentlich nicht
alle 30s einen Regelzyklus einlegen.
Wenn Du die absolute Zeit auch brauchst, dann kannst Du einen 64Bit
Zähler nehmen. Der dürfte fast nicht mehr überlaufen (die wenigsten
Geräte werden 4G an 42s erleben ;)) und wenn doch, dann hat man genug
Zeit um auf den Überlauf reagieren zu können. Bei Differenzen ist er
eh egal, er wirkt sich nur bei absoluten Zeiten aus.
Rashim
> Rashim schrieb am 12. März 2007 11:07
>
> > Release Candidate schrieb am 12. März 2007 7:42
>
> > > Naja, falls deine Matrix und der Vektor gerade richtig beschaffen
> > > sind (Matrtix- und Vektornorm hinreichend klein (aber nicht zu
> > > klein)).
> > > Aber ja, das ist _sehr_ unwahrscheinlich.
> >
> > Das kann man vor allem bei neuronalen Netzen nicht garantieren. Da
> > hat man ja gar keine Ahnung in welchem Bereich sich einige Werte
> > befinden und vor allem wohin sie sich entwicklen werden.
>
> Keine Ahnung, zu neuronalen Netzen kann ich nichts sagen.
Da sehen die Matrizen jedesmal lernen anders aus. Da kannst Du nicht
sagen, was in einer Zelle steht, ausser dass sie den gesamten Bereich
abdecken kann. Sie werden iA auch mit Zufallswerten initialisiert.
> > > Ja, aber manchmal geht's nicht anders (und funktioniert auch ohne
> > > Probleme mit double Prec.).
> >
> > Also ohne Probleme würd ich einen Verlust der signifikanten Stellen
> > in der Grössenordnung von 6-8 nicht nennen.
>
> Ich auch nicht, das Beispiel darfst du jetzt nicht zaehlen.
Wenn es nett ist, dann kann man aber auch mit floats iterieren ;).
> > > Das ist auch gut so, da du bei einer Addition von
> > > Floating-Point-Zahlen immer signifikante Stellen verlierst (damit das
> > > immer stimmt, verliert man halt manchmal 0 signfik. Stellen ;).
> >
> > Eine Addition ist da richtig harmlos. Die Sub ist böse, da sie in dem
> > Fall ja das Rauschen zum wichtigsten Beitrag machen kann.
>
> Aeh, es gibt nur zwei Operationen, Addition und Multiplikation ;)
:)
> Aber ja, eine Subtraktion ist das, was mehr Probleme macht.
>
> > > [*] was bei den US Patriots (Scud-Abwehrraketen) im Golfkrieg
> > > passiert ist.
> > > Wenn die laenger (mehrere Tage) durchgelaufen sind haben die nichts
> > > mehr getroffen. Die Geschwindigkeit der Scudraketen wurde mit einem
> > > Differenzenquotient ermittelt ((s1 - s0)/(t1 - t0)), wobei die Zeiten
> > > als Sekunden seit dem Start der Patriot gegeben waren. D.h. nach
> > > einiger Zeit sind die Zahlen gross mit sehr kleinen Unterschieden :)
> >
> > Urks, wer kommt auf sowas? Das muss ja schief gehen. Man sieht aber
> > schön, dass die Tests alle sehr kurz waren ;).
>
> Ja, _den_ Fehler haette auch ein Student im ersten Semester Numerik
> erkennen muessen.
Oder zumindest jeder Techniker, der mit Industriesteuerungen zu tun
hat. Fertigungsstrassen laufen auch länger ;).
> > Da muss man Ints nehmen und Takte zählen.
>
> Sie haetten einfach die Zeiten sinnvoller waehlen koennen, es geht
> schliesslich nicht um absolute Zeiten (es ist der Scud ziemlich egal,
> wann der Steuerrechner der Patriot gestartet wurde ;).
Ja, ist nur die Frage wie man zur Differenz kommt. Entweder einen
zusätzliche Hardware, die gestartet wird und dann mitzählt, oder eben
die Zeit in Takten zählen. Zweiteres hat man meist irgendwo bei der
Hand.
> > Die haben den Vorteil, dass sie sogar gehen,
> > wenn sie einen Überlauf hatten. Man braucht also nicht unbedingt
> > 64Bit, sondern es reichen 32Bit, selbst wenn man damit gerade mal ein
> > paar Minuten abdecken kann (der darstellbare Zeitraum muss aber schon
> > deutlich grösser als der notwendige sein).
>
> Ohja, und dann wird die gleiche Software fuer ein Nachfolgeprodukt
> verwendet, fuer das dass nicht mehr stimmt, weil etwa die
> Beschleunigung auf einmal _deutlich_ hoeher ist (ESA und Ariane 5 ;)
Die Beschleunigung ist egal, es müssen die Messintervalle passen und
natürlich die Genauigkeit des Taktes im Messzeitraum. Wenn Du mit
10ns zählst, dann hast Du alle 42s einen Überlauf bei einem 32Bit
Zähler. Wenn Du aber mit 10ns zählst, dann wirst Du hoffentlich nicht
alle 30s einen Regelzyklus einlegen.
Wenn Du die absolute Zeit auch brauchst, dann kannst Du einen 64Bit
Zähler nehmen. Der dürfte fast nicht mehr überlaufen (die wenigsten
Geräte werden 4G an 42s erleben ;)) und wenn doch, dann hat man genug
Zeit um auf den Überlauf reagieren zu können. Bei Differenzen ist er
eh egal, er wirkt sich nur bei absoluten Zeiten aus.
Rashim