[gelöst] Spielen mit Dezimal- Dual

[Constructus]

Gruß an die Tüftler hier,

ich hab hier noch ein weiteres Rechen"werk" mit Fragen. Gibt es Lösungen dazu?

I. Wie kann die Spalte D so angezeigt werden, daß sie, von unten nach oben ausgelesen, waagerecht lesbar wird? (in meinem Beispiel II0I0I0III0III0I0I bin. für 218997 dez.) Klar, daß in D auch mit REST () gearbeitet werden kann; vgl. H. Verketten kann ja sehr kompliziert werden bei vielen Ergebniszellen – könnte das einfacher gehen?.

II. Lassen sich dabei vielleicht sogar die Anfangsnullen entfernen (erst ab dem ersten 1- Wert mit der Anzeige beginnen – hier per WENN- VK erreicht))?

III. Könnte in G3 der Summenformel beigebracht werden, daß sich der 2. Zellname automatisch ändert, wenn ab der letzten Zeile weitergezogen wird? (Die Lösung mit einer großen Zeilennummer ist ja ein bischen vorsintflutlich...)

IV. Und zuletzt: wäre die Spalte D (nur) bei der waagerechten Ausgabe so abzuändern, daß die 1 durch I ersetzt wird?

Im Moment lassen sich die Zeilen ziehen bis zur Grenze von Calc... nur die Lesbarkeit könnte unübersichtlich werden.

Im OO- Wiki habe ich keinen Beitrag zu diesem Thema gefunden. Das Wikipedia hatte einen langen Beitrag {http://de.wikipedia.org/wiki/Dualsystem, s. o.}, aber keine direkten Formeln für Calc. Im Forum hier gibt es einen Thread aus Anfang 08, der mir aber insgesamt zu wenig nachvollziehbar ist (Makros, zu wenig Erläuterungen).
viewtopic.php?f=2&t=15869&start=0&st=0& ... Dualzahlen

DEZINBIN kann das ganze zwar wesentlich kürzer, kommt aber nicht unter -512 und über +511 (dez.) hinaus.
So eine Darstellung wie diese sollte mal bei einer Schulung um '94/ '95 herum den Hintergrund zu Dualzahlen veranschaulichen, damals aber "rein zu Fuß".
Die Spalten D, F, G erlauben auch die umgekehrte Rechnung (Bin. in Dez.)

Wenn's nicht zuviel nervt, freue ich auf ein paar Antworten

Constructus

P. s.: der Text oben steckt in der Datei noch einmal drin.

[hawe]

Iterative Prozesse sind nur sehr unzureichend in Formeln umzusetzen und wenn dann sind Array-Formeln angebracht.
Siehe dazu http://www.excelformeln.de
Ansonsten stellt man dafür besser eine eigene Funktion an, etwa

Code: Alles auswählen

Function Dez2Basis(zahl As Long, basis As Integer) As String
'(C)oded 2000 by hw
'Bei Hex ist die Basis 16, bei Octal 8, bei Binär 2
Dim ret as string ,h
h = Array(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, "A", "B", "C", "D", "E", "F")
Do
    ret = h(zahl Mod basis) & ret
    zahl = Int(zahl / basis)
Loop Until zahl < 1
Dez2Basis = ret
End Function

[Constructus]

Oh hawe,

so tief wollte ich eigentlich in die Materie garnicht einsteigen. Iterationen, Arrays – geht das nicht schon in Richtung höhere Mathematik?
Ich hab mal den Link mit den Excelformeln verfolgt- oha, ganz schön tief- sinnig...

Meine Berechnung ist allerdings vom Sinn her Spielerei, es geht mir einfach nur darum, zu Demonstrationszwecken zeigen zu können, wie eine Dezimalzahl in eine Dualzahl umgewandelt werden kann (oder umgekehrt). Die Kalkulationsprogramme machen das ja millionenfach automatisch, ohne daß man sehen kann, was da intern passiert.
Die Spalte mit den verdreht angezeigten 0-1 kann ich übrigens auch rein optisch aus Calc unter Vermittlung von Draw herausholen und dann als Bitmap z. B. in die Waagerechte drehen und so zurechtbiegen, bis es für andere Anwendungen paßt. Nur ist dies dann eben kein Text mehr. Zu Berechnungen nutzbare Zahlen sind das ja eigentlich in der Ergebnisspalte auch nicht, sondern lediglich Ziffernfolgen.

Aber was anderes: Dein Makro aus 2000 kann ich leider nicht umsetzen, weil ich selbst in Calc noch nie mit Makros gearbeitet habe (o Jessas). Früher habe ich mal selbst in Excel Makros mit dem Rekorder erzeugt, die immense Arbeit zur Wiederholung dabei in Calc aber gescheut (die waren ziemlich umfangreich, nicht aber sehr kompliziert). Das Makro selbst kann ja wohl garnichts, sondern arbeitet erst in Verbindung mit einer Tabelle. Ich hab leider keinen Plan, wie ich Makros – die ja sehr oft hier im Forum angeboten werden – jetzt mit Tabellen verknüpfe. Klar, das WIKI... Bisher hatte ich noch keinen wirklichen Anlaß, unter dem Thema dort nachzusuchen. Muß ich wohl nachholen?

Danke erstmal für Deine Antwort

Constructus

[hawe]

Array sagt in diesem Fall nur, das nicht eine einzelne Zelle, sondern ein Feld aus mehreren Zellen als Argument betrachtet wird. Nix, was mit Mathematik zu tun hat...

Naja, das Einsetzen ist keine Kunst.
Alt+F11
Dann die Datei auswählen, die das Makro verpasst bekommen soll. Standard-Ordner öffnen und mittels Schalter Neu ein Modul anlegen und Code da rein kopieren. Das was's.
Nun verfügt die Tabelle über eine neue Funktion Dez2Basis, die kannst DU einsetzen wie jede andere Tabellenfunktion auch...

Wenn Du ein waagerecht angezeigtes Ergbnis haben willst, wie so rechnest Du dann über die Zeilen ud nicht über die Spalten?

[regina]

Hallo Constructus,

Meine Berechnung ist allerdings vom Sinn her Spielerei, es geht mir einfach nur darum, zu Demonstrationszwecken zeigen zu können, wie eine Dezimalzahl in eine Dualzahl umgewandelt werden kann (oder umgekehrt).

Wenn es dir nur ums Demonstrieren geht, dann kannst du für jeden Iterationsschritt eine eigene Zeile in Calc benutzen. Ich versuche mal eine solche Datei anzuhängen (habe Anhängen zuvor noch nie gemacht).

mfG
Regina

[regina]

Hallo,
ich hab's schon bemerkt, die Ziffern im ganzzahligen Anteil sind verkehrt herum. Die berichtigte Version kommt.

mfG
Regina

[Constructus]

Guten morgen hawe oder besser Hans (?),

ich muß Deinen Tipp mit dem Makro mal nachvollziehen- nur gerade ist‘s schlecht, weil mein Rechenknecht ein wenig spinnt. Ich hab unabhängig am frühen Abend mal probiert, ob ich das Makro an eine leere Calc- Datei angesetzt bekomme. Da war zwar dann ein Modul integriert – aber das mache ich dann doch besser in einer Kopie meiner Original- Rechendatei, damit ich wenigstens testen kann, ob‘s auch bei mir funktioniert.

Grundsätzlich hast Du recht mit der Aneinanderreihung der 01- Werte in Spalten statt in Zeilen; zum einen ist meine Anordnung Gewohnheit bzw. stammt aus dem handschriftlichen Original, hat aber auch mit der Ansicht einer Tabelle ohne Sonderformatierung zu tun. Habe ich große Werte dual, sind einige Dutzend ”normal“ breite Zellen kaum nebeneinander zu lesen, ohne den Bildmaßstab zu verkleinern und/ oder die Spalten sehr stark schmaler zu machen.
Ich müßte aber auch die Formelentwicklung umkehren, da ich ja von unten nach oben (bei meiner Anordnung) bzw. bei Berechnung nach Deinem Tipp von rechts nach links lesen müßte, wenn ich das Arbeitsfeld mit Ziehen vergrößern will. Der kleinste Wert bei der Berechnungsweise entsteht eben am Anfang der Zeilen bzw. Spalten. Dann aber muß ich die Zellenlesefolge per Makro oder Funktion gemäß Deiner Berechnung nochmal umdrehen- gewonnen habe ich damit eigentlich nichts. Oder denke ich wieder verkehrt herum? Jedenfalls überkreuzen sich die hintereinandergereihten Dezimalwerte und die Dualwerte (die ja eigentlich nur die Ausgabe der Reste der Dezimalzahldivisionen sind!).

Guten morgen Regina,

ich hab mal versucht, die Datei nachzuvollziehen. Darin tauchen Formeln auf, die wieder neu für mich sind und die ich erst studieren muß. Allerdings sehe ich in den Spalten A- D ab Zeile 10/ 11 nur noch #NAME?. Wenn da ein Fehler drinsteckt, wüßte ich gern, wie dieser zu beheben ist. Irgendwie ist‘s schon ein bischen spät- aber ich finde einfach keine Reihe, die eine Dualzahl in gewohnter Form anzeigt, ich sehe nur Nullenreihen...

Vorab schonmal danke an euch beide für das weitere Interesse

Constructus

[regina]

ich hab mal versucht, die Datei nachzuvollziehen. Darin tauchen Formeln auf, die wieder neu für mich sind und die ich erst studieren muß.

Stimmt, eine Erklärung habe ich nicht mitgeliefert.

B4: GANZZAHL berechnet den ganzzahligen Anteil. Das Gegenstück "Fraction" gibt es leider nicht, daher in F4 die Subtraktion.

B6: =VERGLEICH(0;B10:B102;0) sucht von oben nach unten in dem Bereich B10:B102 nach dem ersten Auftreten von 0 (erster Parameter) und liefert die relative Indexposition. Bei einer Schleife in einem Makro wäre =0 die Abbruchbedingung.

In der Spalte D wird aus den Ziffern das Ergebnis als Text gebildet. Dabei wird jede neue Ziffer vor die schon vorhandene Ziffernfolge gestellt. Dabei werden natürlich auch überflüssige führende Nullen erzeugt.

B7: =INDIREKT("d"&B6+9) Hier wird auf eine Zelle zugegriffen, deren Adresse berechnet wird. Die Adresse setzt sich zusammen aus dem "d" für die Spalte und einer Zeilennummer. Für die Zeilennummer wird die relative Position aus Zelle B6 genommen und 9 hinzuaddiert, was die Anfangszeile des Bereichs ist.

Bei der Berechnung der Nachkommastellen gibt es keine allgemeine Abbruchbedingung, deshalb musst du in Zelle F6 von Hand eintragen, wie viel Nachkommastellen du haben möchtest. Bei einem Makro müsste man die Anzahl der gewünschten Nachkommastellen als Parameter übergeben.

Allerdings sehe ich in den Spalten A- D ab Zeile 10/ 11 nur noch #NAME?. Wenn da ein Fehler drinsteckt, wüßte ich gern, wie dieser zu beheben ist.

#NAME? darf gar nicht erscheinen. Da läuft irgendwas schief. Welche OOo-Version setzt du ein?
Kannst du mit dem Detektiv herausbekommen, wo die erste fehlerhafte Zelle ist und wie die Formel darin bei dir lautet? Hier zum Vergleich:

Zeile 10:
A: =B4 (das ist der umzurechnende Wert)
B: =QUOTIENT(A10;2) (berechnet die ganzzahlige Division mit Divisor 2)
C: =REST(A10;2) (berechnet den Rest bei Division durch 2)
D: =TEXT(C10;0) (wandelt die Zahl in Zelle C10 in einen Text um, mit dem Formatcode 0. Möchte deine OOo-Version vielleicht den Formatcode als Text haben, also =TEXT(C10;"0")?)

Zeile 11:
A: =B10 (der Quotient aus dem vorigen Schritt)
B: =QUOTIENT(A11;2) (nächster Iterationsschritt, sonst wie Zeile 10
C: =REST(A11;2)
D: =TEXT(C11;0)&D10 (Hier werden die neue Ziffer vor den schon vorhandenen Teil gestellt.)

Irgendwie ist‘s schon ein bischen spät- aber ich finde einfach keine Reihe, die eine Dualzahl in gewohnter Form anzeigt, ich sehe nur Nullenreihen...

Das Ergebnis steht eigentlich in der grünen Zelle B8, bzw. für ganzahligen Anteil und Nachkommastellen getrennt in B7 bzw. F7.

Ich habe die Datei mit OOo-DEVm41 erstellt und wüsste schon gerne, wodurch bei dir der Fehler entsteht.

mfG
Regina

[Constructus]

Hallo Regina,

meine groben OO- Daten stehen als letzte Zeile in der Signatur...

" =QUOTIENT(A11;2) " in B11 ist der "Gipfelwert", der das #NAME? ausgibt; ab Zeile 12 bis 56 sind alle Zellen in Spalte A- D damit ausgefüllt. Es kann natürlich sein, daß OO 2.3.1. mit irgendwelchen Bedingungen (noch) nicht umgehen kann und deshalb diese Anzeige ausgibt.
In B11 gibt's keine Spur zum Vorgänger, nur 2 Verweise auf Nachfolger (A12, B6)

Probeweise hab ich mal in B3 31,5 als Wert eingetragen; in meiner eigenen Datei ergibt 31 IIIII (,5 wird nicht richtig gerechnet bei mir), in Deiner Datei tauchen 5 Einser hintereinander nirgendwo auf.
F6 erschließt sich mir leider nicht: welche richtige Zeilennummer könnte das sein? Automatisch steht dort 32.

Deine Erläuterungen zuvor können aber recht hilfreich sein; da ich ein Freund von Anleitungen bin, werde ich alle Hinweise, die Deine Datei betreffen, in eine neue Tabelle der Datei setzen.

Zwar ist das Thema für mich eher eine Spielerei, aber Spielen kann ja auch interessant sein und Spaß machen...

In dem Sinne schonmal vielen Dank

Constructus

[regina]

Hallo Constructus,

meine groben OO- Daten stehen als letzte Zeile in der Signatur...

Eine Stelle, die ich meistens überlese. OOo2.3.1 ist zwar schon ziemlich betragt, aber die Funktionen waren schon immer dabei und selbst mein StarOffice7 arbeitet das Dokument fehlerfrei ab.

" =QUOTIENT(A11;2) " in B11 ist der "Gipfelwert", der das #NAME? ausgibt; ab Zeile 12 bis 56 sind alle Zellen in Spalte A- D damit ausgefüllt. Es kann natürlich sein, daß OO 2.3.1. mit irgendwelchen Bedingungen (noch) nicht umgehen kann und deshalb diese Anzeige ausgibt.
In B11 gibt's keine Spur zum Vorgänger, nur 2 Verweise auf Nachfolger (A12, B6)

Dass alle folgenden Zellen den Fehler zeigen ist klar, weil Fehler weitergereicht werden. Es wundert mit aber, dass die Zelle B10, die ja die entsprechende Formel enthält, keinen Fehler erzeugt. Schreibe die Zeile 11 (A-D) doch mal neu von Hand. Die Zeile kannst du dann anschließend nach unten ziehen.

Probeweise hab ich mal in B3 31,5 als Wert eingetragen; in meiner eigenen Datei ergibt 31 IIIII (,5 wird nicht richtig gerechnet bei mir), in Deiner Datei tauchen 5 Einser hintereinander nirgendwo auf.

Kann ja auch nicht, wenn bei der Berechnung überall #NAME? steht.

F6 erschließt sich mir leider nicht: welche richtige Zeilennummer könnte das sein? Automatisch steht dort 32.

Die Zahl steht dort nicht automatisch, sondern weil ich sie als Beispiel eingetragen habe. Wenn du z.B. die Zahl 123,456 umwandeln lässt, sieht man das Problem ganz gut. Es wird ja nicht tatsächlich dezimal gerechnet, sondern die Zahlen werden zum Rechnen in Dualzahlen umgewandelt. Dabei werden aus endlichen Dezimalbrüchen meist unendliche Dualbrüche. Folglich wird irgendwo abgeschnitten, bei dem von OOo intern benutzten "double"-Format nach ca 53 signifikanten Dualziffern. Wenn man nun von dieser Zahl etwas subtrahiert was gleich anfängt, fallen die vordersten Dualziffern weg. Dann wird die Folge der Dualziffern entsprechend nach vorn gerückt und hinten wird irgendwas (zunächst die Sicherheitsbits und später 0) nachgezogen. Diese Ziffern sind aber nicht mehr "gültig"; sie entsprechen nicht mehr der ursprünglichen Dezimalzahl.
Wenn du in die Spalte F schaust (ich hoffe, die funktioniert ohne Fehler) dann siehst du, wie auf diese Weise allmählich "Schrott" von hinten nach vorne wandert. Wenn er so weit vorne ist, dass die Einerstelle beeinflusst wird, ist das Ergebnis nicht mehr gültig. Du musst daher eine Zeile, die davor liegt, als letzte gültige Zeile in F6 eintragen. Wann das Problem entsteht, hängt von der Ausgangszahl ab und lässt sich daher nicht automatisieren.

Man kann das Problem nur dann vermeiden, wenn man nicht rechnen lässt, sondern gänzlich auf Zeichenketten arbeitet und alle Rechenroutinen neu als Operationen auf Zeichenketten programmiert. (Auf Maschinenebene könnte man den Prozessor umstellen, aber das steht selbst OOo intern nicht zur Verfügung.) Das wäre eine typische Übungsaufgabe für Erstsemester. Aber selbst dann hast du ja noch immer das Problem, dass endliche Dezimalbrüche zu unendlichen Dualbrüchen führen, nur du könntest diese ziemlich genau berechnen, 64K Zeichenkette ist schon ganz schön lang.

Deine Erläuterungen zuvor können aber recht hilfreich sein; da ich ein Freund von Anleitungen bin, werde ich alle Hinweise, die Deine Datei betreffen, in eine neue Tabelle der Datei setzen.

Das ist in der Tat sinnvoll, sonst weiß man nach einem halben Jahr nicht mehr worum es geht.

Ich füge auch ein entsprechendes Makro ein. Auch dort musst du beim Aufruf die Anzahl der Nachkommastellen mit angeben. Das X in dec2binX hatte ich mir als Abkürzung für eXtended überlegt. Das Makro ist nicht gänzlich neu, das hatte ich schon mal früher für mich gemacht.

Code: Alles auswählen

function dec2binX(byVal zahl as double, byVal places as integer) as string
'split number
dim ganzteil as long
dim bruchteil as double
dim vorzeichen as string
if zahl<0 then
	vorzeichen = "-"
else
	vorzeichen = ""
end if
ganzteil = int(abs(zahl))
bruchteil =abs(zahl) - ganzteil
'convert integerpart
dim result as string
result =""
dim temp as double
temp = ganzteil
dim modteil as integer
do
	modteil = temp mod 2
	temp = int(temp/2)
	if modteil = 0 then
		result = "0" + result
	else
		result = "1" + result
	end if 	
loop while temp > 0
'convert fractionpart
dim i as integer
if bruchteil > 0 then
	result = result + ","
	temp = bruchteil
	for i=1 to places
		temp = temp * 2
		if temp >= 1 then
			result = result + "1"
			temp = temp - 1
		else
			result = result + "0"
		end if
	next i
end if
dec2binX = vorzeichen+result	
end function

Kann man hier auch Dateianhänge wieder löschen?

mfG
Regina

[Constructus]

Hallo Regina,

ich hab schon ein wenig gekämpft...

Eine Stelle, die ich meistens überlese.

Das haben einige Mitstreiter hier aber auch "untendran". Vorteil ist, daß man nicht ewig das gleiche schreiben muß – und es steht auch ohne Nachfrage da.

Schreibe die Zeile 11 (A-D) doch mal neu von Hand. Die Zeile kannst du dann anschließend nach unten ziehen.

Hut ab, kannst Du Ferndiagnosen stellen? Nein, Spaß beiseite, das scheint‘s gebracht zu haben. Die Fehlermeldungen sind weg. Möglich ist, daß in einer Formel ein Leerzeichen zu viel war.

Die Zahl steht dort nicht automatisch, sondern weil ich sie als Beispiel eingetragen habe.

Das habe ich nicht gemerkt, weil das zufällige 31,5 von mir fast dazu paßt...

Wenn du z.B. die Zahl 123,456 umwandeln lässt, sieht man das Problem ganz gut.

{1111011,01110100101111000110101 sehe ich jetzt da in B8}

Wenn du in die Spalte F schaust

Bei mir wechseln dort 0 und 1 in den Zeilen vor dem Komma unregelmäßig ab. Unter Zeile 55 stehen nur noch 0 da – wäre dann Zeile 55 mit 1,0000... die letzte gültige? Wenn diese Rechenweise neu für jemanden ist, ist das leider recht schwer nachzuvollziehen.
0111010010111100011010100111111011111001110111 steht nach Eingabe von 55 in Zelle F6 bzw. 1111011,0111010010111100011010100111111011111001110111 in B8 (bei 123,456 in B3). Habe ich Deine Beschreibung jetzt richtig nachvollzogen? Mir hat sich der Kopf so oft gedreht, daß ich mich jetzt von hinten begucken kann...

Das wäre eine typische Übungsaufgabe für Erstsemester.

Erstsemester? In welchem Fach denn? Oh, Regina, das ganze klingt schon recht anspruchsvoll. Ich nehme aber mal an, daß auch andere Leute hier ihren Honig heraussaugen können. Mir gefällt das Thema sehr, obwohl ich manchmal doch ein wenig rotiere.

Das Makro ist nicht gänzlich neu, das hatte ich schon mal früher für mich gemacht.

Hast Du das in einer neuen Datei integriert, die jetzt weggelöscht ist, oder sollte ich das nach hawes Tipp vom 12.02. 20:06 noch einbauen?
Wenn ich jetzt behaupte, daß der Thread bis hierher auch für Knobler interessant ist – erzähl ich da zuviel?

Muchos gracias (?) jedenfalls

Constructus

[Stephan]

Kann man hier auch Dateianhänge wieder löschen?

Sollte eigentlich gehen, an der Stelle wo Du auch die Datei hochlädst gibt es auch einen Button zum löschen.

loeschen.gif (13.97 KiB) 4072 mal betrachtet

Vorteil ist, daß man nicht ewig das gleiche schreiben muß – und es steht auch ohne Nachfrage da.

und Nachteil ist das dadurch viele posts uneindeutig werden, denn wenn Du die Signatur aktualisierst steht dann natürlich auch bei alten posts (bei denen eine alte Version von OOo galt) plötzlich eine neue Version da und niemandem ist im Nachhinein mehr klar um welche Version es ursprünglich ging.



Gruß
Stephan

[regina]

Hallo Constructus,

{1111011,01110100101111000110101 sehe ich jetzt da in B8}

Das habe ich auch. Das Tabellenblatt ist somit jetzt wohl in Ordnung.

Bei mir wechseln dort 0 und 1 in den Zeilen vor dem Komma unregelmäßig ab. Unter Zeile 55 stehen nur noch 0 da – wäre dann Zeile 55 mit 1,0000... die letzte gültige? Wenn diese Rechenweise neu für jemanden ist, ist das leider recht schwer nachzuvollziehen.

Es ist mathematisch nicht wirklich schwer. Wenn man den Nachkommateil f mit 2 multipliziert und dabei eine Zahl 2f entsteht, die größer als 1 ist, dann muss die Ausgangszahl f mindest 1/2 enthalten. Wenn man nun 1 von 2f subtrahiert, dann hat man 2f-1, das kann man sich auch als 2*(f-1/2) vorstellen. Man hat also eigentlich den Zweierbruch 1/2 subtrahiert. Wenn man nun wieder mit 2 multipliziert, hat man eigentlich 4*(f-1/2). Entsteht dabei eine Zahl, die größer als 1 ist, muss f-1/2 mindestens 1/4 enthalten. Wieder 1 subtrahieren bringt 4*(f-1/2)-1, was man als 4*(f-1/2-1/4) schreiben kann. Wenn keine Zahl größer 1 entstand, dann fehlt der entsprechende Zweierbruch. So guckt man der Reihe nach, ob die Zweierbrüche enthalten sind oder nicht.

Du kannst natürlich auch nacheinander - so weit möglich - die Brüche 1/2, 1/4, 1/8, 1/16 usw. subtrahieren. Mach dir einfach eine Spalte mit den Zweierbrüchen und subtrahiere sie nacheinander, falls das Zwischenergebnis noch größer als der Bruch ist. Wenn du subtrahieren konntest, notiere eine 1 sonst eine 0.

0111010010111100011010100111111011111001110111 steht nach Eingabe von 55 in Zelle F6 bzw. 1111011,0111010010111100011010100111111011111001110111 in B8 (bei 123,456 in B3). Habe ich Deine Beschreibung jetzt richtig nachvollzogen? Mir hat sich der Kopf so oft gedreht, daß ich mich jetzt von hinten begucken kann...

Die Genauigkeitsprobleme entstehen rechts am Ende der Zahlen. Es fängt mit 0,456000000000003 an. Dort steht am Ende eine 3, obwohl beim händischen Zerlegen der Dezimalteil von 123,456 natürlich nur 0,456 ist. Da man nun laufend mit 2 multipliziert und immer wieder intern zwischen dezimal und dual umgewandelt wird, wandert diese Fehlstelle weiter nach links.
In Zeile 28 sind wir dann schon bei 0,664000000804663 und in Zeile 44 bei 0,904052734375000. Von Hand gerechnet hätten wir nur 0,664 bzw. 0,904 also drei Stellen nach dem Komma wie am Anfang auch. In der Zeile 49 ist dann der Moment erreicht, wo ein Übertrag aus diesen Fehlstellen in die eigentlichen Ziffern unserer Zahlenfolge reinreicht und diese dadurch ungültig macht. Mmh, vielleicht könnte man zwischendurch immer auf die ursprüngliche Anzahl von Dezimalstellen runden? Das habe ich noch nicht ausprobiert.

Erstsemester? In welchem Fach denn?

Informatik

Oh, Regina, das ganze klingt schon recht anspruchsvoll. Ich nehme aber mal an, daß auch andere Leute hier ihren Honig heraussaugen können. Mir gefällt das Thema sehr, obwohl ich manchmal doch ein wenig rotiere.

Das liegt nur daran, dass solche Umrechnungen im "normalen" Leben nicht vorkommen und man auch in der Schule nicht diesen Algorithmus benutzt, sondern einfach Zweierpotenzen subtrahiert.

Hast Du das in einer neuen Datei integriert, die jetzt weggelöscht ist, oder sollte ich das nach hawes Tipp vom 12.02. 20:06 noch einbauen?

Ich hatte es nicht integriert, du musst es noch wie von hawes beschrieben einbauen. Ich habe mir zusätzlich einen Ordner mit Code-Schnipseln angelegt. So kann ich bei Bedarf eine Lösung einfach wieder bei einer neuen Datei einfügen.

Wenn ich jetzt behaupte, daß der Thread bis hierher auch für Knobler interessant ist – erzähl ich da zuviel?

Auch Spielen muss ab und zu sein.

Viel Spaß beim Rumprobieren.
Regina

[Constructus]

Hallo Regina,

spannendes Spiel...

Du bist Dir aber doch sicher, daß wir über die gleiche Datei reden?

Code: Alles auswählen

Zeile	Spalte E		Spalte F
47	0,232421875000000	0,464843750000000
48	0,464843750000000	0,929687500000000
49	0,929687500000000	1,859375000000000

sehe ich bei mir.

Wenn Spalte E zutrifft, ergibt sich ein Übertrag von der 4. Stelle hinter dem Komma zur 3. Stelle in Zeile 49; damit wäre Zeile 48 noch korrekt. Trifft dagegen Spalte F zu, rückt der Übertrag eine Zeile höher, Zeile 48 wäre bereits falsch, Zeile 47 wäre noch korrekt. Ich glaube nicht, daß ich irgendetwas an den Zeilen oder Spalten geändert habe (gelöscht oder eingefügt).
Ich hab mir probeweise mal 3 Rechtecke in die betreffenden Zeilen gezogen, die ich gruppiert habe. Diese sind unterschiedlich gefärbt und mit 60% Transparenz versehen. Die Höhe der Rechtecke ist die Zeilenhöhe, die Breite zweier Rechtecke reicht von Nachkommastelle 4 bis Ende, über dem unteren liegt ein weiteres, das nur 2 Ziffern breit ist, aber halb über das linke Ende der unteren großen Zelle ragt. Effekt ist, daß ich die Gruppe in jede Zeile ziehen kann und sofort deutlich wird, wo der Übertrag stattfindet.

Das Makro teste ich noch, und die Idee mit der Spalte zum Bruchsubtrahieren kommt testweise sicher auch noch dran. Den Zweizeiler nach dem mmh überlasse ich Dir gern... Die anderen Abteilungen Deiner Antwort muß ich sicher noch 3 x lesen, bevor ich das einordnen kann. Rechentechnisch und verstandesmäßig nachvollziehbar sind die Erläuterungen, sie erfordern aber eine ziemliche Konzentration. Aber alles easy, alles einfach muß das Thema hier ja nicht sein, weil etwas Gescheites dabei herauskommen soll und kein blabla. Freuen würde ich mich, wenn auch der eine oder Nachleser bestätigen könnte, daß er mit dem Thema hier etwas anfangen kann.

Zwischendurch mal wieder ein Dankeschön

Constructus