Matroids Matheplanet Forum Index
Moderiert von Bilbo matph
Matroids Matheplanet Forum Index » Informatik » Ergebnisse von Summen erläutern, Fehler in der Lösung?
Druckversion
Druckversion
Autor
Universität/Hochschule J Ergebnisse von Summen erläutern, Fehler in der Lösung?
Kajam
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2020
Mitteilungen: 262
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Themenstart: 2020-09-16


Hallo, ich bin gerade bei Aufgabe d) angekommen. Nun weiß ich erstmal nicht, wie die Summe bei "a)" zu Stande kommt. Mein Programm spuckt "0,001" raus. In der Lösung steht 0,0819139..? Zudem ist 5‾⁵=0,00001 und in der Lösung steht auf einmal 0,0001.. Also, wem soll ich jetzt glauben?

Lg, Kajam















Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 1635
Aus: Thüringen
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.1, eingetragen 2020-09-16


Ist nicht Feld der Größe 100 hier Feld[99] ? 0..99=100 Zellen


-----------------
Pech in der Liebe , Glück im Verlieren !!!



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
zippy
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 24.10.2018
Mitteilungen: 1487
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.2, eingetragen 2020-09-16


2020-09-16 21:12 - pzktupel in Beitrag No. 1 schreibt:
Ist nicht Feld der Größe 100 hier Feld[99] ? 0..99=100 Zellen

Nein. ${\tt Feld}[N]$ deklariert ein Feld mit den $N$ Elementen ${\tt Feld}[0]$ bis ${\tt Feld}[N-1]$.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 1635
Aus: Thüringen
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.3, eingetragen 2020-09-16


2020-09-16 21:28 - zippy in Beitrag No. 2 schreibt:
2020-09-16 21:12 - pzktupel in Beitrag No. 1 schreibt:
Ist nicht Feld der Größe 100 hier Feld[99] ? 0..99=100 Zellen

Nein. ${\tt Feld}[N]$ deklariert ein Feld mit den $N$ Elementen ${\tt Feld}[0]$ bis ${\tt Feld}[N-1]$.

Also er korriegiert dies intern automatisch ?

Ich kenne das so, das F[100] auch noch etwas speichern kann und hätte 101 Zellen.




-----------------
Pech in der Liebe , Glück im Verlieren !!!



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Scynja
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 23.02.2011
Mitteilungen: 332
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.4, eingetragen 2020-09-16


Da wird nichts korrigiert.

Du sagst:

Ich hätte gerne 100 Floats in einem Feld.

Also Ok:

Hier hast du 100*4Bytes reserviert. Startadresse ist Feldname[0]. Mit dem Rest mach, was du willst.

Du gibst nicht an, ich hätte gerne ein Array von 30 bis 130. (In einigen Sprachen können Arrays auch im Negativen beginnen. Das führt meist zu Problemen, die man nicht auf dem Schirm hat). Musste ich selbst schon erleben. Da ist dann auf einmal ArrayName[0] nicht mehr das erste Element.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
zippy
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 24.10.2018
Mitteilungen: 1487
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.5, eingetragen 2020-09-16


2020-09-16 21:38 - pzktupel in Beitrag No. 3 schreibt:
Ich kenne das so, das F[100] auch noch etwas speichern kann und hätte 101 Zellen.

Und woher kennst du das so? Von C oder C++ doch wohl sicher nicht:
C++
int main() {
  int feld[100];
  feld[100] = 1;
}
Cppcheck
[test.cpp:3]: (error) Array 'feld[100]' accessed at index 100, which is out of bounds.

[Die Antwort wurde nach Beitrag No.3 begonnen.]



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1172
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.6, eingetragen 2020-09-16


Achtung Compiler kennen die Ungenauigkeit von float und wollen gern optimieren.
Außerdem gibt es zig Compiler-Schalter.
Also habe ich mal Gleitkommamodel FAST eingestellt und dies mit
den unabhängigen AVX-Add- Befehl für 32Bit-Zahlen
__m256 s= _mm256_add_ps (ma, mb); -> in add_AVX32 gepackt
verglichen:

c++
float fSum=0,a[_max100];
for(int i=0; i<_max100;i++)  a[i]=1e-5;
for(int i=0; i<_max100;i++)  fSum+=a[i];
  printf("fSum....= %7.15f  fp:fast\n",fSum);//fSum= 0.001000000513159 precise
				             //fSum= 0.001000000047497 fast
fSum=0;
for(int i=0; i<_max100;i++)  fSum=add_AVX32(fSum,a[i]);
printf("addf....= %7.15f\n",fSum);
fSum=1000;
for(int i=0; i<_max100;i++)  fSum+=a[i];
printf("fSum1000= %7.15f \n",fSum-1000);
 
double dSum=0,d[_max100];
for(int i=0; i<_max100;i++)  d[i]=0.00001;
for(int i=0; i<_max100;i++)  dSum+=d[i];
printf("dSum....= %7.15f \n",dSum);
dSum=1000;
for(int i=0; i<_max100;i++)  d[i]=0.00001;
for(int i=0; i<_max100;i++)  dSum+=d[i];
printf("dSum1000= %7.15f \n",dSum-1000);
std::cin.get();

Ausgabe:
fSum....= 0.001000000047497  fp:fast
addf....= 0.001000000513159
fSum1000= 0.000854492187500
dSum....= 0.001000000000000 //ab hier double zum Vergleich
dSum1000= 0.000999999999294

Es gibt logischerweise kleine Abweichungen
und bei Addition mit 1000 "fallen die hinteren Nachkommastellen runter".

ABER 0,0819139 ist viel zu groß -> vermutlich größere Summe, um mehr Rundungsfehler zu bekommen.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Kajam
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2020
Mitteilungen: 262
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.7, vom Themenstarter, eingetragen 2020-09-17


Also, ist jetzt die "0,0001" in der Lösung falsch?



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1172
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.8, eingetragen 2020-09-17


"0,0001" ist für
a) nicht falsch, sondern wegen der primitiven Ausgabefunktion zu stark gerundet, um eine Aussage zur Genauigkeit zu tätigen.

Schau Dir c) noch mal an.

Ziel der ganzen Sache ist doch, dass man durch geeignete Informatik-Algorithmen die Schwäche des relativ ungenauen Types float
ausbügeln oder verschlechtern kann:

a) primitive Addition kann bei 100facher Wiederholung bei diesen Zahlen  höchstens 10 Nachkommastellen genau sein.

b) Durch ungeeigneten Offset (Kommaverschiebung nach rechts) fallen hintere Nachkommastellen (also die Stellen rechts vom Komma) natürlich weg, da die Bit-Speicherung (32 Stück) sich auf ALLE Ziffern & das Vorzeichen bezieht/aufteilt.
Da es verschiedene Additions-Maschinenbefehle und Compilerinterpretationen des Types "float" gibt, und dieses Beispiel genau an der Grenze mit der "schlechtesten Genauigkeit" herunterfällt, kommt bei Euch als Summe 0 heraus, während moderne CPUs & Compiler da noch was "retten" können.

c) Ob man das nun mit "Mantisse" kompliziert begründet, mag dem Lehrer gefallen. In Worten könnte man auch schreiben, dass geeignete Vielfache von 2er Potenzen erst in kleineren Zwischensummen zusammengefasst wieder mittelgroße 2er Potenzen ergeben, die dann wieder bei Addition "glatte" 2er Potenzen ergeben. So "fallen hinten" nie Nachkommastellen "herunter", da man sich immer innerhalb des vollen Gültigkeitsbereiches befindet und exakte Genauigkeit erreichen kann. Solche Doppelsummen sind aber sehr langsam!
Noch einfacher & schneller: wenn man die 10^(-5) mit 10^5 multipliziert ->
dann die 100 ganze Zahlen addiert (da reicht hier im Beispiel Type Byte = 8 Bit), und dann die Summe 100 am Ende wieder durch 10^5 teilt (natürlich dann mit casten & Typ float).



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
AlphaSigma
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 23.11.2012
Mitteilungen: 222
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.9, eingetragen 2020-09-17


Hallo Kajam,

im Aufgabenteil C fängt die zweite for-Schleife mit j = 0 an. In deiner Lösung jedoch mit int j = 1. Daher wird bei dir feld[0] gar nicht geändert und SumC = feld[0] liefert nur den Wert der zuvor in feld[0] abgelegt wurde, d.h. 0.00001 = 1e-5.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1172
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.10, eingetragen 2020-09-17


Übrigens ist das in der Physik oft genau so:
Da es keine perfekten Bauelemente gibt, versucht man immer den optimalen "Gültigkeitsbereich" auszunutzen.

Beim Transistor ist die Verstärkungskurve "unten" & "oben" nicht linear.
Um das Über- & Untersteuern (z.B. bei Musik) zu verhindern gibt man bei kleinen Strömen/Spannungen ein Offset (Vorspannung) und nach "oben" begrenzt man -> und bleibt so innerhalb der Linearität (guter Klirrfaktor).

Beim Auto ist das die Gangschaltung, um möglichst im optimalen Bereich (Drehzahl, Leistung, Drehmoment, Verbrauch) zu bleiben...



[Die Antwort wurde nach Beitrag No.8 begonnen.]



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Kajam hat die Antworten auf ihre/seine Frage gesehen.
Kajam hat selbst das Ok-Häkchen gesetzt.
Neues Thema [Neues Thema]  Druckversion [Druckversion]

 


Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2020 by Matroids Matheplanet
This web site was originally made with PHP-Nuke, a former web portal system written in PHP that seems no longer to be maintained nor supported. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]