Intel-HEX-File - nibbles tauschen?

Bei uns hat mal eine Entwicklerversion einer Radiosoftware unter bestimmten Umständen den Lautsprecher stummgeschaltet, weil die mit Excel berechnete Lautstärketabelle falsch war. Kurzfassung: die Zellen enthielten Hexadezimalwerte. Excel betrachtete Zellen mit Inhalt der Form 0E72 auch bei expliziter Markierung als Text als Zahlen mit dem Wert 0.

Stefan

Das haute alles sauber hin. Beim elektrischen Teil hatte ich SPICE bevorzugt weil es mir vertrauter ist und die Plots konntest Du nachher uebereinanderlegen.

Hint: In dem Bereich wird nichts freigegeben was nicht mindestens x-mal per Hand und/oder Versuch nachgeprueft wurde.

Zitat "Nur Excel 2007 ist von dem Bug betroffen. Alle Vorgängerversionen rechnen also richtig."

Vielleicht verstehen Thomas und andere jetzt besser warum ich oft bei gut abgehangener aber erprobter Software bleibe :-)

Zitat "Name manager will show a warning message ..."

Wenn eine rote Lampe angeht ist das doch in Ordnung. Wenn auch laestig.

Na ja, sooo viel Dynamikbereich hatte noch nichts was mir je ueber den Tisch lief :-)

Oder neue Versionen aussitzen bis die Bugs alle weg sind.

Nur muss man dann auch sicherstellen, dass das Service-Pack auch wirklich ueberall installiert wurde.

Der Excel-2007-Bug mit 65535 und 65536 ist insofern gemein, dass Excel falsch anzeigt, aber intern korrekt weiterrechnet. Es sei denn, exportiert das Ergebnis als CSV oder benutzt 'round' (Laut dem was ich finden konnte). Boese das...

Gerrit

Das Problem hast Du immer, auch bei Open Source Software.

Tja, einer der Gruende warum ich abgehangene Software mag. Da sind die Kinderkrankheiten raus. Excel hat hier z.B. noch nie falsch gerechnet.

Soweit dir bekannt ist... ;)

Gerrit

Da haette es schon laengst mal gescheppert :-)

Ich meinte uebrigens Excel 97. Das meiste einfachere mache ich allerdings mit MS-Works Spreadsheets. Auch da traue ich Versionen nach

Auch die Wahrscheinlichkeit daß "keine bekannten Fehler" sich "keine vorhandenen Fehler" annähert steigt mit dem Alter.

Oh, tatsächlich.

Solange ein Programm nicht symbolisch rechnet ist es hoch riskant Rechenergebnisse aus Fließkommazahlen auf einen bestimmten Wert zu testen. Ob die Rundungsfehler 5 oder 500 Stellen nach dem Komma auftauchen spielt dafür keine Rolle. Für Numbercrunching ist Excel eh aus anderen Gründen ungeeignet.

Von meinen Sheets weiß ich, daß sie taugen.

A fool with a tool...

Wenn jemand Rechenoperationen mit Texten durchführt, sollte er im Handbuch lesen, wie das Programm damit umgeht. Die Ergenisse aus Textzellen mit Hexzahlen, die zufällig nur Dezimalziffern enthalten, waren auch nicht besonders korrekt.

Am 19.06.2010 19:53, schrieb Joerg:

Excel schleppt schon seit Ewigkeiten einen Bug mit der Datumsberechnung mit.

Dieses Problem stellt bei der OpenOffice-Konvertierung ein echtes Problem dar, da mit diversen Excel-Formel diese Problem umgangen wird. Die Umgehung funktioniert aber nur wenn Excel auch tatsächlich falsch rechnet.

So kommt es in OpenOffice-Calc zu Rechenfehler, weil Calc richtig rechnet.

Jedenfalls hat sich M$ für die falsche interne Abbildung von Datum/Uhrzeit entschieden, die sich am aufwendigsten pflegen lässt.

Wenn ich jetzt die Sekunden seit einem bestimmten Datum haben möchte so kann Excel überhaupt Nichts mit Schaltsekunden anfangen (die von der PTB erst bei Bedarf eingeführt wurden).

Damit Excel damit umgehen könnte, müsste in Excel ein kompleziertes Modell der Schwerkraft- und Bahnberechnung eingebaut werden. Leider wird dieser Bereich gerade noch erforscht und auf Supercomputern oder der Playstation3 berechnet.

Glaskugeln funktionieren in Redmond ziemlisch schlecht weil es dort zu bewoelkt ist :-)

Fur solch praesize Langfriststatistiken braeuchte man dann doch ein dickeres Programm, was professionelleres. So wie ich natuerlich auch keine Netzwerksimulation damit anstelle, besonders nicht wenn Schwingkreise hoher Guete wie etwa Quarze drin sind oder spektrale Unreinheiten bis -100dBc berechnet werden sollen. Eine Firma die Auftragsentwicklungen fuer einen Kunden macht tut es bei Schaltreglern allerdings schon (mit Erfolg).

Excel hat immerhin Funktionen zur Konvertierung von und nach Hex, die auch verwendet wurden, weil es sonst ja gar nicht funktioniert hätte.

Zu Details bin ich aber überfragt, ich mach sowas normalerweise in Perl, da kann ich mir gleich ein #includebares Headerfile rauswerfen lassen.

Stefan

Stefan Engler schrieb:

Dass der Tag 60 bei Excel der 29.2.1900 ist, dieser Bug stammt aber schon von Lotus 123. Damals war es wohl wichtig, dass Multiplan und dann Excel zu Lotus kompatibel waren. Vielleicht gab's den Fehler auch schon in Visicalc?

Gruß Willi

Die Umwandlungsfunktionen funktionieren. 0E72 ist übrigens eine gültige Darstellung von 0. Mein Tipp: der hat hex2dez gar nicht benutzt und die Hexzahl 0872 wurde von Excel zu dezimal 872 gewandelt.

Für diverse const Definitionen habe ich mir schon öfter gültigen C-Code erzeugen lassen.

Excel hat solche Funktionen, das stimmt. (Werden allerdings in der Standard-Installation nicht mitinstalliert).

Das Hauptproblem von Excel im Allgemeinen ist die fehlende Typsicherheit. Um all den BWLer-Idioten das Problem abzunehmen, sich mit der Tatsache auseinandersetzen zu müssen, daß eine Zahl was anderes ist als ihre Zeichenketten-Representation, mußten Kompromisse geschlossen werden und die daraus resultierenden Inkonsistenzen sorgen an unzähligen Stellen für Folgeprobleme.

Das hat Excel übrigens mit diesen ganzen Scriptsprachen gemeinsam, die den Anfänger nicht mit Überlegungen zu Datentypen belasten wollen...

Nunja, eins davon ist bei Excel der Anzeige-Layer, also die Formateinstellungen. Man muß sich darüber im Klaren sein, daß man damit bei LEEREN Zellen tatsächlich den Datentyp beeinflussen kann. Steht in der Zelle aber erstmal was drinne (und hat sich damit die automatische Typbestimmung festgelegt), kann man nur noch das Anzeigeformat beeinflussen.

Das führt oft (nicht nur im Zusammenhang mit den Hex-Funktionen) zu verwirrenden Ergebnissen, wenn man keine Ahnung von den Hintergründen hat. Die Ergebnisse sind aber NICHT FALSCH, sondern nur eine Folge von falschen Eingaben. Shit in->shit out.

Fazit: Mit Excel ist's wie mit jedem Werkzeug. Wenn was sinnvolles beim Werkzeugeinsatz rauskommen soll, muß man es beherrschen.

Joerg schrieb:

Hab ich meiner Firma empfohlen. Antwort: "Die Amis haben immer den neuesten Kram und schicken uns jetzt schon Dokumente, mit denen wir nichts anfangen können." Das wird noch spaßig.

Hanno

Am 20.06.2010 23:01, schrieb Hanno Foest:

Ein Kunde bat darum, doch bitte .odt zu schicken. OpenOffice sei schließlich kostenlos und sie sähen *keinen* *Nutzen* darin, jede neue Version von MS-Office zu kaufen, nur um eine Spezifikation lesen (und in ihre Vorlagen integrieren) zu können.

Falk

Firmen die mit Ruestung und so zu tun haben koennen schonmal dazu gezwungen sein. Ich habe mit keinem meiner Kunden solche Probleme und Office-2007 gibbet hier im Buero nich. Genausowenig wie Vista oder Win7. Wir tauschen haeufiger *.doc und *.xls Files aus, damit mehrere Leute in unterschiedlichen Zeitzonen dran arbeiten koennen.