Hallo zusammen, https://www.heise.de/news/Von-Excel-in-Datumsangaben-umgewandelt-Dutzende-Gene-umbenannt-4864993.html die einfache Lösung besteht darin, den Gennamen, die ja Strings darstellen sollen, ein "'" voranzustellen. Der lange Arm von Bill Gates reicht offensichlich auch bis zu den Genen. :)
:
Verschoben durch Moderator
Das HGNC hätte in seiner Richtlinie auch einfach von der Excel-Nutzung abraten können, bis Microsoft den Bug beseitigt hat. In der Zwischenzeit (und wahlweise natürlich auch danach) kann man ja LibreOffice benutzen, das diesen Bug nicht aufweist.
Jaja... wenn man zu unfähig ist die minimalsten Grundlagen einer Anwendung zu erlernen, ist natürlich die Anwendung schuld. Beziehungsweise der Anbieter. Wenn der Bauer nicht schwimmen kann.... Viele Dank für den Bericht der mal wieder den Zerfall der Medienkompetenz beweist. Natürlich nur unter dem Deckmantel des "Microsoft ist soooo böse... mimimi!"-Gequatsche. Gruß
Davon, dass Microsoft böse sei, steht da nichts. Es ist nur eine Tatsachenfeststellung. Allerdings finde ich das schon komisch. Da werden wissenschaftliche Festlegungen geändert, weil ein(!) Programm damit Probleme macht. Was kommt als nächstes? Normen werden umgeschrieben, weil ein CAD-Programm bestimmte Operationen nicht zuverlässig hinkriegt?
Im ersten Moment hatte ich erwartet, dass die Basenpaare jetzt A C G T U V W X Y Z heißen
Dussel schrieb: > Normen werden umgeschrieben, weil ein > CAD-Programm bestimmte Operationen nicht zuverlässig hinkriegt? Natürlich ;-) Und noch mehr: Da Excel nur 1048576 Zeilen kann, werden künftig in der Mathematik Vektoren und Mengen auf eben so viele Elemente beschränkt ;-) Weil Word mit aktivierter Autokorrektur fälschlicherweise oft Bindestriche durch Gedankenstriche ersetzt, werden die Bindestriche als Interpunktionszeichen komplett abgeschafft.
Hallo Yalu X., Yalu X. schrieb: > Dussel schrieb: >> Normen werden umgeschrieben, weil ein >> CAD-Programm bestimmte Operationen nicht zuverlässig hinkriegt? > > Natürlich ;-) > > Und noch mehr: > > Da Excel nur 1048576 Zeilen kann, werden künftig in der Mathematik > Vektoren und Mengen auf eben so viele Elemente beschränkt ;-) Jetzt verstehe ich wo das mit der "Finite-Elemente-Methode" herkommt. Das sind Excel-Benutzer. :) > Weil Word mit aktivierter Autokorrektur fälschlicherweise oft > Bindestriche durch Gedankenstriche ersetzt, werden die Bindestriche als > Interpunktionszeichen komplett abgeschafft. Die Datumssubstitution bei Excel ist eine Produkteigenschaft, die man gar nicht intelligent implementieren kann. Sie muss, wie Du sagtest als Fehler gelten. Bei der Ersetzung bei Bindestrichen und Gedankenstrichen verhält es sich genauso.
Ach komm, das ewige Windows Excel MS Bashing bringt uns doch echt nicht weiter... Ich erinnere an Umlaute unter Linux... Jahrelang hat das in allen möglichen Editoren nicht richtig funktioniert, oder nur nach Stunden des Herumprobierens. Keine Ahnung ob das inzwischen mit Unicode besser ist. Ich gebe es zu, ich habe dann irgendwann alle Umlaute weggelassen. War ja auch in Latex damals viel einfacher, ewig diese blöden \ eintippen. Computer sind auch heute recht unflexible Maschinen. Der Mensch muss (sollte) da einfach nachgeben, sonst kommt nix raus. Denn der Computer hat eine grosse Stärke: Er kann warten. Also: Abfinden mit dem Problem, es lösen, oder es ohne Jammern akzeptiern.
Scheusslich, wenn die Maschinen schlauer sein sollen, als die Menschen. Der gewöhnliche Kunde ist für solche "Steighilfen" womöglich dankbar, ohne zu wissen, dass er was falsch macht. Das nervt mich auch bei Suchmaschinen, die es für angebracht halten Resultate zu liefern, egal wie wenig sie mit dem ursprünglichen Suchbegriff zu tun haben. Und ich darf mich dann durch den ganzen Datenmüll wühlen, den die Suchmaschine ja eigentlich für mich sortieren sollte. Jüngstes Beispiel hier im Forum: https://www.bauhaus.info/suche/produkte?text=erder (aus dem Thread: Beitrag "Re: Erdstab vom Baumarkt")
Yalu X. schrieb: > Das HGNC hätte in seiner Richtlinie auch einfach von der Excel-Nutzung > abraten können, bis Microsoft den Bug beseitigt hat. Die automatische Datumsformatierung ist kein Bug, sondern tatsächlich ein feature und besteht schon seit diversen Excel-Generationen. Was diese Kröte im System mich schon an Arbeitszeit gekostet hat... Da importierst du eine csv mit 500k Werten und darfst erstmal alle 30 zeilen die falschen Formate per Hand nachbügeln.
Ja was ist es jetzt? Ein Bug, ein Feature oder eine Kröte? :D
udok schrieb: > Ach komm, das ewige Windows Excel MS Bashing bringt > uns doch echt nicht weiter... Wieso Bashing? Für manche Probleme gibt es erstaunlich einfache Lösungen, so dass auch andere mit Excel arbeiten können. Yalu X. schrieb: > Ja was ist es jetzt? Ein Bug, ein Feature oder eine Kröte? :D Es ist ein Feature, das sich als Kröte erwiesen hat und jetzt als Bug sein kümmerliches Dasein fristen muss. Mike B. schrieb: > Was diese Kröte im System mich schon an Arbeitszeit gekostet hat... > Da importierst du eine csv mit 500k Werten und darfst erstmal alle 30 > zeilen die falschen Formate per Hand nachbügeln. Schreib' einfach einen ASCII-Importfilter in VBA. Eine Schleife für die Zeilen, innen drin eine weitere Schleife für den Zeileninhalt. Ist simpel.
Peter M. schrieb: > Schreib' einfach einen ASCII-Importfilter in VBA. > Eine Schleife für die Zeilen, innen drin eine weitere Schleife für den > Zeileninhalt. Ist simpel. Wozu? Excel hat doch einen passenden Text Import Wizard, wo man die korrekten Formate (und einiges andere) beim Import problemlos festlegen kann. Nur weil manche Leute Excel nicht bedienen können, ist das noch lange kein Bug.
Ach das ist doch garnix im Vergleich zu anderen Katastrophen, die durch Abwärtskompabilität o.ä. verursacht wurden. So wäre das Space shuttle nicht explodiert, wenn man keine Dichtungen gebraucht hätte. Die Dichtungen brauchte man, weil die rakete in mehreren Teilstücken transportiert werden musste. Hätte man sie dicker bauen dürfen wären die Dichtungen unnötig. Aber dicker ging nicht weil die Römer halt dünne Esel hatten ... aber lest selbst: https://forum.archaeologie-online.de/discussion/623/eselkarren
Dennis S. schrieb: > Jaja... wenn man zu unfähig ist die minimalsten Grundlagen einer > Anwendung zu erlernen, ist natürlich die Anwendung schuld. > Beziehungsweise der Anbieter. Genau das ist der Punkt. MS hat dieses Verhalten genau deswegen eingebaut, weil die allermeisten Anwender zu doof sind, um einen Eimer Wasser umzuschuppen. Genau deswegen funktioniert die Sache für diesen Anwendertyp. Wenn aber Wissenschaftler damit hantieren, wird's hinderlich. Nun würde man ja erwarten, dass Wissenschaftler in der Lage sind, das triviale Problem und die genauso trivialen Lösungen (allesamt natürlich auch in Excel eingebaut) zu erkennen und anzuwenden. Aber nööö: wie ich aus praktischer Erfahrung weiss, sind die meisten Wissenschaftler genauso doof wie Otto-Normal-DAU. Halt nur irgendwie anders doof, aber mit Sicherheit genauso faul... Microsoft hat hier einfach eine pekuniäre Mehrheitsentscheidung gefällt. Es gibt halt unzählige Male mehr normaldoofe DAUs als wissenschaftlich gebildete DAUs und Microsoft versucht immer, es der geistig minderbemittelten Mehrheit so einfach wie möglich zu machen. Der Erfolg gibt dem Konzept Recht. Es hat sich ein System entwickelt, vor dem sogar Standardisierungsgremien einknicken. Der Standard wird schlicht der objektiven Realität angepaßt, die da heißt: Excel ist der der Quasi-Standard, den so gut wie jeder nutzt. So einfach ist das. Das muss man nicht mögen (nichtmal ich mag das), aber man muss damit umgehen können.
Dennis S. schrieb: > Jaja... wenn man zu unfähig ist die minimalsten Grundlagen einer > Anwendung zu erlernen, ist natürlich die Anwendung schuld. Wenn eine Anwendung versucht, klüger zu sein als ihre Anwender, dann ist das ein Fehler der Anwendung. Ich habe übrigens mal eine ähnliche Erfahrung gemacht, als ein Kunde die von meiner Software erzeugten CSV-Dateien mit Excel analysieren wolle und Excel sie wegen der Header-Zeile, die IIRC mit "ID" begann, falsch als irgendein uraltes Dateiformat aus den Achtzigern "erkannt" und interpretiert hat... > Viele Dank für den Bericht der mal wieder den Zerfall der > Medienkompetenz beweist. Natürlich nur unter dem Deckmantel des > "Microsoft ist soooo böse... mimimi!"-Gequatsche. In diesem speziellen Fall nicht böse, sondern nur schlecht. Aber Excel ist ja leider ohnehin die am häufigsten mißbrauchte Software der Welt -- und ja, das liegt nicht an Excel, sondern an den Anwendern.
Yalu X. schrieb: > Und noch mehr: > > Da Excel nur 1048576 Zeilen kann, werden künftig in der Mathematik > Vektoren und Mengen auf eben so viele Elemente beschränkt ;-) Vielleicht solltest Du die 16k Spalten noch erwähnen... > Weil Word mit aktivierter Autokorrektur fälschlicherweise oft > Bindestriche durch Gedankenstriche ersetzt, werden die Bindestriche als > Interpunktionszeichen komplett abgeschafft. Wer braucht schon Bindestriche? Außer den Binde-Strichern, natürlich. ;-)
udok schrieb: > Ach komm, das ewige Windows Excel MS Bashing bringt > uns doch echt nicht weiter... Wenn ein Produkt einen Fehler hat, ist es kein Bashing, darauf hinzuweisen. An sich sollten der Hersteller und die Anwender sich sogar freuen, daß sie jemand auf den Fehler hinweist, bietet das doch die Chance, das Produkt zu verbessern. > Ich erinnere an Umlaute unter Linux... > Jahrelang hat das in allen möglichen Editoren nicht richtig > funktioniert, oder nur nach Stunden des Herumprobierens. > Keine Ahnung ob das inzwischen mit Unicode besser ist. > > Ich gebe es zu, ich habe dann irgendwann alle Umlaute weggelassen. > War ja auch in Latex damals viel einfacher, ewig diese blöden \ > eintippen. Oh, wann soll denn das gewesen sein? Das Linux-Unicode-HOWTO ist von 2001 und die erste Linux-Distribution, die komplett auf Unicode bzw, genauer, UTF8 gesetzt hat, war Red Hat 8 im Jahr 2003. Jedoch, auch vorher schon waren Umlaute überhaupt kein Problem, dank ISO-8859-1 und später ISO-8859-15, das konnte dank inputenc.sty auch LaTeX, gerade extra für Dich nochmal nachgeschlagen in meinem alten Kopka. ;-) > Computer sind auch heute recht unflexible Maschinen. > Der Mensch muss (sollte) da einfach nachgeben, sonst kommt nix raus. > Denn der Computer hat eine grosse Stärke: Er kann warten. > > Also: Abfinden mit dem Problem, es lösen, oder es ohne Jammern > akzeptiern. Genau... wieviele Microsoft-Anwender braucht es, um eine Glühbirne zu wechseln? Keinen, Dunkelheit wird zum Standard erklärt... ;-)
Hallo Sheeva P., Sheeva P. schrieb: > In diesem speziellen Fall nicht böse, sondern nur schlecht. Aber Excel > ist ja leider ohnehin die am häufigsten mißbrauchte Software der Welt -- > und ja, das liegt nicht an Excel, sondern an den Anwendern. Excel ist eine Tabellenkalkulation, wird aber überwiegend als Tabellenverwaltung genutzt. Wie bestimmte Software-Verhaltensweisen entstehen, kann man hier am Beispiel der Datumsfunktionen von Excel gut nachvollziehen. Joel Spolski ist dieser Darstellung nach die treibende Kraft bei der Etablierung von VBA - Visual Basic for Applications. Falls Du diesen Artikel nicht kennst, einfach mal lesen, ich finde ihn nicht nur informativ sondern auch unterhaltsam! https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/
c-hater schrieb: > Es gibt halt unzählige Male mehr normaldoofe DAUs als wissenschaftlich > gebildete DAUs und Microsoft versucht immer, es der geistig > minderbemittelten Mehrheit so einfach wie möglich zu machen. Geht es auch ohne Beleidigungen? Oder kann das die in Sachen Sozialkompetenz mindererzogene junge Gesellschaft heutzutage nicht mehr?
:
Bearbeitet durch User
Unter welchen Umständen passiert dies denn bei Excel? Wenn eine Zelle nur Standardformat hat, dann scheint das ja üblich zu sein, daß Excel irgendwelche Daten umformatiert. Aber wenn man eine Zelle explizit als Text definiert, sollte das doch nicht passieren - oder ist das hier doch der Fall?
Peter M. schrieb: > die einfache Lösung besteht darin, den Gennamen, die ja Strings > darstellen sollen, ein "'" voranzustellen. Der einfachste Weg ist die Spalte, bei der man ja vorher weis dass man ausschließlich Text eintragen will, komplett zu markieren und als Text zu formatieren. Und das bringen diese tollen Forscher nicht zusammen und schämen sich nicht mal dafür? Kann deswegen Corona nicht entschärft werden, weil es nicht auf 1.März hört? Müssen wir wegen Excel alle sterben? ;D
Hallo Jens G.: Gib' mal 8.3 in eine Zelle ein. Dann steht da 8.3. Dann formatiere die Zelle als Zahl, dann steht da 43898, das ist die Kodierung des 8.3.2020 im Excel-internen Datumsformat. Wenn Du '8.3 eingibst, bleibt der Ausdruck als String erhalten. Du kannst aber nicht die Zelle vorab als String definieren. Wenn Du eine CSV-Datei aufmachst, dann wünscht man sich ja, dass man die einfach so öffnen kann. In dem Moment, wo Du das Problem hast, müsstest Du mit dem Import-Assistent werkeln, die Zellen als String importieren und dann wieder irgendwie manuell oder mit VBA in eine Zahl wandeln. Ich hatte deswegen mal vor Jahren so eine Importroutine in VBA geschrieben, die CSV-Dateien byteweise einliest und auswertet und das Ergebnis dann in Zellen schreibt. Für faule Leute wie stellt dieses Excel-Verhalten einen zeitraubenden Fehler dar.
Theor schrieb: > Das nervt mich auch bei Suchmaschinen, die es für angebracht halten > Resultate zu liefern, egal wie wenig sie mit dem ursprünglichen > Suchbegriff zu tun haben. Du hast wohl noch nie mit SharePoint arbeiten müssen ... Oh sorry, schon wieder M$ ...
Theor schrieb: > Scheusslich, wenn die Maschinen schlauer sein sollen, als die Menschen. Menschen sind doch auch nicht besser. Missverständnisse gibts überall. So hielt letzthin jemand Fahrspurende für genderwahnsinnige Personen.
Yalu X. schrieb: > Das HGNC hätte in seiner Richtlinie auch einfach von der Excel-Nutzung > abraten können, bis Microsoft den Bug beseitigt hat. Willst du die Forschung abschaffen? Was meinst du, wie lange es dauert, bis der letzte sein Excel auf dem aktuellen Stand hat? Wahrscheinlich muss mancher vorher erst noch sein WinXP aktualisieren. ;-)
Peter M. schrieb: > In dem Moment, wo Du das Problem hast, müsstest Du mit dem > Import-Assistent werkeln, die Zellen als String importieren und dann > wieder irgendwie manuell oder mit VBA in eine Zahl wandeln. Ja, klar - genau dafür ist doch der Import-Assistent da!? CSV ist nun mal nicht das eigene Dateiformat von Excel. Des Systemfehler besteht IMHO eher darin, dass bei der Installation von Excel die dateiendung .CSV standardmäßig Excel zugewiesen wird, was damit häufig Unfug anstellt. Wenn diese Verknüpfung nicht da wäre, würden viel mehr Nutzer CSV-Dateien nicht einfach mit Exel öffnen wollen, sondern doch eher nach einer Import-Möglichkeit suchen - und dann beim Import-Assistenten landen, der falsche Dateninterpretationen zu verhindern ermöglicht. Kann LibreOffice Calc solche Datumsdatenimporte ;-) von CSV eigentlich ohne manuellen Eingriff?
Am einfachsten wäre, wenn Excel beim Öffnen von CSVs generell den ohnehin eingebauten "Textkonvertierungs-Assistent" anzeigen würde, statt das man ihn teils aus einer leeren Arbeitsmappe heraus manuell aufrufen muss um CSVs wie gewünscht eingelesen zu bekommen. Also eigentlich genau so wie LibreOffice es tut. Bei der LibreOffice-Variante kann man auch beim Import alle Felder viel einfacher auf "Text" festlegen.
Jens G. schrieb: > Unter welchen Umständen passiert dies denn bei Excel? > Wenn eine Zelle nur Standardformat hat, dann scheint das ja üblich zu > sein, daß Excel irgendwelche Daten umformatiert. Ja. Immer, wenn es meint, ein Datum oder eine Zahl zu erkennen. Was äußerst lästig ist, weil es auch noch von den aktuellen Locale-Einstellungen abhängt, was Excel als Datum oder Zahl einstuft. Die Alternative für die Entwickler wäre aber gewesen, alles erstmal nur als dummen String zu interpretieren. Damit kann man aber nicht rechnen. Was dazu geführt hätte, dass die Mehrheit der DAUs mit ihrer teuren Tabellenkalkulation nicht kalkulieren kann, sie müssten Excel jeweils sagen: das ist eine Zahl oder das ist ein Datum... Im Prinzip handelt es sich um dieselbe Problematik wie bei Programmiersprachen, wo die Sache heißt: starke Typisierung oder halt nicht. > Aber wenn man eine Zelle explizit als Text definiert, sollte das doch > nicht passieren Und tut es auch nicht. Und man kann das auch spaltenweise anwenden. Wenn man wenigstens ein bisschen Ahnung hat. DAUs haben die aber halt nicht. Wie man sehen kann, auch DAUs mit wissenschaftlicher Bildung nicht...
A. K. schrieb: > Willst du die Forschung abschaffen? Was meinst du, wie lange es dauert, > bis der letzte sein Excel auf dem aktuellen Stand hat? Wahrscheinlich > muss mancher vorher erst noch sein WinXP aktualisieren Soll das heißen, dass es ohne Excel keine Forschung geben kann? c-hater schrieb: > Die Alternative für die Entwickler wäre aber gewesen, alles erstmal nur > als dummen String zu interpretieren. Keineswegs. Letztlich handelt es sich um eine Art Autokorrektur der Eingabe, die ja ohnehin interpretiert wird: der Benutzer gibt stets nur Zeichenketten ein.. Sofern man die fakultativ anlegt, kann jeder so arbeiten, wie er möchte.
Peter M. schrieb: > die einfache Lösung besteht darin, den Gennamen, die ja Strings > darstellen sollen, ein "'" voranzustellen. Natürlich nicht. Es geht um Import von Daten. Nachträglich als Text formatieren geht auch nicht, weil Information die verloren ist nicht wieder hergestellt werden kann. Interessanter ist doch, WAS zum Henker Excel alles als Datum interpretieren will. MWS schrieb: > Der einfachste Weg ist die Spalte, bei der man ja vorher weis dass man > ausschließlich Text eintragen will, komplett zu markieren und als Text > zu formatieren. Zu spät, siehe oben. > Und das bringen diese tollen Forscher nicht zusammen und schämen sich > nicht mal dafür? Und wenn beim Import von ein paar tausend Zeilen einige MARCH1 oder SEPT5 falsch übernommen werden fällt das erstmal nicht auf.
Sheeva P. schrieb: > Genau... wieviele Microsoft-Anwender braucht es, um eine Glühbirne zu > wechseln? Keinen, Dunkelheit wird zum Standard erklärt... ;-) Wieviele Linux-Anwender sind nötig, um eine Glühbirne zu wechseln? Es gibt keine offizielle Distribution, die das standardmäßig kann, aber im Darknet wird kolportiert, dass es mit Linux möglich sein soll, wenn man einarmigen Handstand macht und in dieser Haltung die klassische Glühbirne bei eingeschaltetem Strom dauerhaft mit der bloßen Hand (keine Handschuhe) in die Fassung presst. Linux-Anwender sehen diese Berichte als Beweis, dass Linux dem Microsoftschem Windows bei weitem überlegen ist. ;-)
Dussel schrieb: > Allerdings finde ich das schon komisch. Da werden wissenschaftliche > Festlegungen geändert, weil ein(!) Programm damit Probleme macht. Ja, das ist schon merkwürdig. Sind die dort so total abhängig von diesem einen Tool (das dafür offensichtlich weder gedacht noch geeignet ist)? udok schrieb: > Ich erinnere an Umlaute unter Linux... Da habe ich - im Gegensatz zu Windows - schon lange kein Problem mehr damit gehabt. Theor schrieb: > Das nervt mich auch bei Suchmaschinen, die es für angebracht halten > Resultate zu liefern, egal wie wenig sie mit dem ursprünglichen > Suchbegriff zu tun haben. Allerdings. Google tendiert dazu, sich bei mir aus den Suchbegriffen den wichtigsten rauszupicken und zu ignorieren. Bei manchen Suchergebnissen schreibt es dazu, dass dieser Suchbegriff gar nicht enthalten ist, bei anderen wird er heimlich weggelassen. Ich muss oft in den gefunden Seiten nochmal jeweils die Seite selber durchsuchen, um zu erkennen, ob das überhaupt ein valides Suchergebnis ist. Inzwischen habe ich aber schon ein leichtes Gespür dafür entwickelt, wann mich Google auf eine falsche Fährte lockt. Yalu X. schrieb: > Ja was ist es jetzt? Ein Bug, ein Feature oder eine Kröte? :D Es ist mit Absicht drin, also "it's not a bug, it's a feature". Ob Feature oder Kröte kommt auf den Anwendungsfall an. guest schrieb: > Excel hat doch einen passenden Text Import Wizard, wo man die > korrekten Formate (und einiges andere) beim Import problemlos festlegen > kann. Nur weil manche Leute Excel nicht bedienen können, ist das noch > lange kein Bug. Wie lädt man denn ein CSV so, dass keinerlei Interpretation der Inhalte durchgeführt wird? Und wie macht man das so, dass man nicht bei jeder einzelnen Datei alles wieder neu einstellen muss? Lustig ist diese automatische Erkennung auch bei Hex-Zahlen. Die, die nur aus auch den Ziffern 0-9 bestehen, werden als Zahlen erkannt und rechtsbündig dargestellt, die anderen als Text und linksbündig. Mike B. schrieb: > Geht es auch ohne Beleidigungen? > > Oder kann das die in Sachen Sozialkompetenz mindererzogene junge > Gesellschaft heutzutage nicht mehr? Auf die zweite Frage könnte man jetzt mit der ersten Frage antworten. :) Sheeva P. schrieb: > Wer braucht schon Bindestriche? Gut, viele scheinen Bindestriche heute nicht mehr vernünftig anwenden zu können. Anders lässt sich nicht erklären, warum so oft mitten im Wort ein Leerzeichen steht. Matthias L. schrieb: > Kann LibreOffice Calc solche Datumsdatenimporte ;-) von CSV eigentlich > ohne manuellen Eingriff? LibreOffice versucht leider, viele Einschränkungen und Probleme von Excel zu imitieren. Karl K. schrieb: > Interessanter ist doch, WAS zum Henker Excel alles als Datum > interpretieren will. Ja. Wer gibt "SEPT1" ein, wenn er den 1.9. des aktuellen Jahres will?
A. K. schrieb: > Yalu X. schrieb: >> Das HGNC hätte in seiner Richtlinie auch einfach von der Excel-Nutzung >> abraten können, bis Microsoft den Bug beseitigt hat. > > Willst du die Forschung abschaffen? Was meinst du, wie lange es dauert, > bis der letzte sein Excel auf dem aktuellen Stand hat? Das beträfe ja nur die Genforschung. Wenn diese dadurch etwas ausgebremst würde, fände ich das gar nicht einmal so tragisch ;-) Rolf M. schrieb: > Ja. Wer gibt "SEPT1" ein, wenn er den 1.9. des aktuellen Jahres will? Vielleicht ein Ami, wenn er das Leerzeichen zwischen "SEPT" und "1" vergisst. Dann schlägt wohl die Autokorrektur zu und macht aus dem "SEPT1" ein "SEPT 1", das in den USA als gültiges Datum interpretiert werden kann. In Deutschland interpretiert Excel "SEPT1" übrigens als "September 2001", was auch nicht gerade dem Prinzip der geringsten Überraschung entspricht. Jetzt sollte man meinen, mit der Deaktivierung der Autokorrektur im "Optionen"-Dialog sei das Problem gelöst. Leider ist es das nicht.
Percy N. schrieb: > der Benutzer gibt stets nur > Zeichenketten ein.. Sofern man die fakultativ anlegt, kann jeder so > arbeiten, wie er möchte. Genau das ist bei Excel doch umgesetzt: Wenn ich VOR der Eingabe festlege, das eine Zelle (oder eine Spalte oder das ganze Blatt) nur dumme Strings enthalten soll, dann wird Excel auch nichts mehr (fehl-)interpretieren, sonder brav alles als dummen String unverändert übernehmen. Auch wieder: ist wie bei Programmiersprachen mit starker Typisierung. Auch da muß ich vor der ersten Benutzung einer Variablen festlegen, welchen Typ diese haben soll. Das kann doch nicht so schwer zu verstehen sein?! Das einzige, was man Excel eventuell vorwerfen könnte, ist die Bevorzugung der Interpretation als Zahl oder Datum. Aber selbst die ergibt einen Sinn, wenn man sich vor Augen hält, dass Excel als Kalkulationsprogramm gedacht ist und es kalkuliert sich mit Zahlen schlicht besser als mit Zeichenketten... Lustig finde ich übrigens diese unsäglichen Typen, die bei ihrem geliebten C es für völlig normal halten, eine Variable erst deklarieren zu müssen, es aber bei Excel für einen Bug halten. Wenn das nicht Scheuklappen sind, was denn sonst?
Karl K. schrieb: > Und wenn beim Import von ein paar tausend Zeilen einige MARCH1 oder > SEPT5 falsch übernommen werden fällt das erstmal nicht auf. Genauso wenig offenbar wie Forscher auffallen, die einerseits das menschliche Genom kartografieren wollen, andererseits sich IQ-mäßig wie Toastbrot verhalten. c-hater schrieb: > Genau das ist bei Excel doch umgesetzt: Wenn ich VOR der Eingabe > festlege, das eine Zelle (oder eine Spalte oder das ganze Blatt) nur > dumme Strings enthalten soll, dann wird Excel auch nichts mehr > (fehl-)interpretieren, sonder brav alles als dummen String unverändert > übernehmen. Ganz genau. Und weil es "so wichtige" Forscher sind, wird nicht gefragt, wie dumm die sich verhalten haben, sondern es gibt einen Aufschrei nach Softwarefehler. Dass sich Heise dafür entblödet, ist verwunderlich.
Hallo Antiromaniker. Rom ist schuld schrieb: > So wäre das Space shuttle nicht explodiert, wenn man keine Dichtungen > gebraucht hätte. Die Dichtungen brauchte man, weil die rakete in > mehreren Teilstücken transportiert werden musste. Hätte man sie dicker > bauen dürfen wären die Dichtungen unnötig. Aber dicker ging nicht weil > die Römer halt dünne Esel hatten ... aber lest selbst: > https://forum.archaeologie-online.de/discussion/623/eselkarren Naja. Das Lichtraumprofil, welches für das "passen" durch z.b. einen Tunnel wesentlich ist, ist aber nur sehr lose mit der Spurweite verbunden. Obwohl gleiche Spurweite von 1435mm für "Normalspuren" in England, Europa und USA verwendet werden, sind die Lichtraumprofile in Europa breiter als in England (man hatte dazugelernt) und in den USA noch breiter (Man hatte noch mehr Erfahrung). Es gibt übrigens auch aktuell in Europa unterschiedliche Lichtraumprofile*). In Gegenden, in denen die Karrentechnik unabhängig von Rom entwickelt wurde**), z.B. in Asien, hat sich eine ähnliche Karrenspurweite herausgebildet. Der Wert scheint sich also empirisch als optimaler Wert herausgestellt zu haben. *) Im ersten Weltkrieg fuhren sich deutsche Dampfloks auf belgischen Strecken unter Brücken den Schornstein ab. Bei einigen Pfannenwagen, wie sie in Eisenhütten verwendet werden, ist das Lichtraumprofil auch derart, dass diese Wagen nur in besonders geeigneten Bereichen des Werksnetz verwendet werden können. U-Bahnen sind ein weiterer Punkt. 2019 klemmte bei einer Probefahrt ein neuer Zug der Düsseldorfer Rheinbahn in einem Duisburger U-Bahn Tunnel. ( https://www.derwesten.de/staedte/duisburg/u-bahn-prototyp-bahnhof-duisburg-rheinbahn-id215508937.html ) Scheint also doch kein triviales Thema zu sein. **) Räder gibt es schon seit dem Übergang Jungsteinzeit/Kupferzeit, also lange vor Rom, und sie werden sich daher auch schon lange vor Rom verbreitet haben. https://de.wikipedia.org/wiki/Laibacher_Moor#Radfund https://de.wikipedia.org/wiki/Arch%C3%A4ologie_des_Federseebeckens https://de.wikipedia.org/wiki/Rad#%C3%84lteste_Nachweise_des_Rades Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
c-hater schrieb: > Wenn ich VOR der Eingabe festlege, das eine Zelle (oder eine Spalte > oder das ganze Blatt) nur dumme Strings enthalten soll, dann wird Excel > auch nichts mehr (fehl-)interpretieren, sonder brav alles als dummen > String unverändert übernehmen. > Warum soll das der Benutzer tun? Wenn es default wäre, dann entstünde dem Anwender kein Nachteil: er muss sich ohnehin beizeiten entscheiden, dem Programm kund und zu wissen zu tun, welche Datentypen er wo verwenden möchte. Wenn er dazu eine Assitenzfunktion bemühen möchte, die seine Eingaben interpretiert, dann mag ihm das freigestellt werden. Es gehtxaber nicht an, Eingaben in einer Weise automatisch zu verändern, die es ausschließt, dass der ursprüngliche Zustand ebenso automatisch rekonstruiert werden kann. > Auch wieder: ist wie bei Programmiersprachen mit starker Typisierung. > Auch da muß ich vor der ersten Benutzung einer Variablen festlegen, > welchen Typ diese haben soll. > Und wenn er es nicht tut, gibt es einen error; ohne den Code intransparent zu modifizieren. Der garbage bleibt einfach stehen und wird beanstandet. Das ginge bei Excel genauso, man müsste nur wollen. Man = MS in diesem Fall. > Das kann doch nicht so schwer zu verstehen sein?! > > Das einzige, was man Excel eventuell vorwerfen könnte, ist die > Bevorzugung der Interpretation als Zahl oder Datum. Aber selbst die > ergibt einen Sinn, wenn man sich vor Augen hält, dass Excel als > Kalkulationsprogramm gedacht ist und es kalkuliert sich mit Zahlen > schlicht besser als mit Zeichenketten... Zahl, Datum, Zeitraum, Zellbezug ... im Auslegen seid frisch und munter; legt ihr's nicht aus, so legt was unter! Das darf Excel ja gern alles anbieten, höchst willkommen, angenehm und nützlich. Aber es sollte zumindest möglich sein, das in den Einstellungen defaultmäßig abzuschalten. Das hätte zudem den Vorteil, dass sich der Anwender gezielt Gedanken machen muss, welcher Datentyp wo sinnvoll ist. Klar ginge das auch mit Dokumentvorlagen. Für Anwender. Auch für Wissenschaftler?
c-hater schrieb: > Genau das ist bei Excel doch umgesetzt: Wenn ich VOR der Eingabe > festlege, das eine Zelle (oder eine Spalte oder das ganze Blatt) nur > dumme Strings enthalten soll, dann wird Excel auch nichts mehr > (fehl-)interpretieren, sonder brav alles als dummen String unverändert > übernehmen. Es ist halt ziemlich unintuitiv, alle Formate bereits zu Beginn definieren zu müssen. Zum einen gibt Excel dafür überhaupt kein Feedback, so dass man einer leeren Zelle überhaupt nicht ansehen kann, welches Format eingestellt ist bzw. ob man überhaupt schon eine Einstellung vorgenommen hat. Zum anderen weiß man vor der Eingabe der Zahlen nicht immer genau, wie groß die Tabellenbereiche für jede Gruppe von Daten werden müssen. Es ist ja nicht so, dass immer ganze Spalten oder Zeilen ein einheitliches Format haben sollen. > Auch wieder: ist wie bei Programmiersprachen mit starker Typisierung. > Auch da muß ich vor der ersten Benutzung einer Variablen festlegen, > welchen Typ diese haben soll. Nicht unbedingt, es gibt auch Sprachen mit Type-Inference (bspw. Haskell und Clean). In den ganz seltenen Fällen, wo die Type-Inference kein eindeutiges Ergebnis liefer kann, wird eine Fehlermeldung ausgegeben. > Das einzige, was man Excel eventuell vorwerfen könnte, ist die > Bevorzugung der Interpretation als Zahl oder Datum. Aber selbst die > ergibt einen Sinn, wenn man sich vor Augen hält, dass Excel als > Kalkulationsprogramm gedacht ist und es kalkuliert sich mit Zahlen > schlicht besser als mit Zeichenketten... Es ist ja prinzipiell auch in Ordnung, wenn Zahlen in einer gültigen Darstellung als solche interpretiert werden, solange dabei nichts hinzugedichtet wird. Aber einen Textstring, der kein gültiges Datumsformat hat, trotzdem als Datum zu interpretieren und den Benutzer darüber im Dunkeln zu lassen, ist IMHO ein konzeptioneller Fehler. > Lustig finde ich übrigens diese unsäglichen Typen, die bei ihrem > geliebten C es für völlig normal halten, eine Variable erst deklarieren > zu müssen, es aber bei Excel für einen Bug halten. Wenn das nicht > Scheuklappen sind, was denn sonst? Du übersiehst ein paar wesentliche Unterschiede: - In C kann man die Deklaration direkt sehen, in Excel nur mit aufwendiger Herumklickerei. - Wenn man in C die Deklaration vergisst, wird man vom Compiler darauf hingewiesen. Dann fügt man die Deklaration hinzu, und alles ist in Ordnung - Wenn man in Excel die "Deklaration" (also die Definition eines Zellenformats) vergisst, gibt Excel keine Fehlermeldung aus, sondern interpretiert die Eingabe in einer undokumentierten und teilweise schwer nachvollziehbaren Weise. Bemerkt man den Fehler dennoch, genügt es nicht, einfach die fehlende "Deklaration" hinzuzufügen, da die Originaleingabe zu diesem Zeitpunkt bereits verloren ist. Es bleibt also nichts weiter übrig, als die Eingabe zu wiederholen.
Percy N. schrieb: > Warum soll das der Benutzer tun? Damit vor Übergabe der Daten das Programm weis, wie das Übergebene zu interpretieren ist. Das ist wichtig, weil es in einer Exceltabelle verschiedene Zelleigenschaften gibt, diese Eigenschaften haben auf die anzuwendenden Funktionen Einfluss, wonach ein Datum anders zu behandeln ist, als eine Fliesskommazahl oder ein Text. CSV kennt diese Eigenschaften nicht, da ist alles Text. Wenn nun das eine in das andere übergeführt wird, dann muss es a) der User mitteilen, oder b) es wird vom empfangenen Excel interpretiert. Das Problem ist doch, dass diese sog. Wissenschaftler so wenig Ahnung von der Materie hatten, dass sie an eine Vorformatierung des Excelblattes entsprechend der erforderlichen Zelleigenschaften nicht einmal dachten. > Auch für Wissenschaftler? Ich sehe keine Wissenschaftler, die das angerichtet haben, ich sehe Dilettanten.
c-hater schrieb: > Wenn aber Wissenschaftler damit hantieren, wird's hinderlich. Nun würde > man ja erwarten, dass Wissenschaftler in der Lage sind, das triviale > Problem und die genauso trivialen Lösungen (allesamt natürlich auch in > Excel eingebaut) zu erkennen und anzuwenden. Aber nööö: wie ich aus > praktischer Erfahrung weiss, sind die meisten Wissenschaftler genauso > doof wie Otto-Normal-DAU. Halt nur irgendwie anders doof, aber mit > Sicherheit genauso faul... > Das ist fast schon zu schmeichelhaft. Ich hatte vor einigen Jahren die Gelegenheit, die Entstehung eines Readers aus der Nähe zu beobachten. Der Herausgeber ind Hauptautor hatte sich um alkes gekümmert: bundesweit Kollegen für das Projekt begeistert, Themenwahl der einzelnen Beiträge koordiniert usw. Insbesondere hatte er vom Verlag eine .dot-Datei vesorgt, due dieser gewiss nicht nurxaltruistisch zur Verfügung gestellt hat. Inter Verwendung dieser Vorlage solkten die Beiträge erstellt werden. So weit die Theorie, so schön der Plan. Tatsächlich schickten die Herren Professores ihre Elaborate auf den verschiedensten Diskettenformaten (damals zeitgemäß!) ein; nach deren Übertragung auf das System des Herausgebers kam das böse Erwachen: die Vorkagendatei war von den meisten Einlieferern vollständig ignoriert worden, vermutlich wussten sie nichts damit anzufangen (und ihre allfälligen Schreibkräfte wohl auch nicht). Dafür war aber fast jeder Beitrag wunderschön nach den jeweiligen Vorstellungen des Verfassers formatiert; manches sah recht nett aus, hatre aber nicht die geringste Ähnlichkeit mit der Vorgabe des Verlages. Dafür gab es ausschließlich harte Zeilenumbrüche und Textauszeichnungen... > > Das muss man nicht mögen (nichtmal ich mag das), aber man muss damit > umgehen können. Jetzt kann man sich fragen, warum die Leute so doof sind. Zum einen ist es sicherlich das Prinzip TEAM: Toll, ein anderer macht's! Man muss allerdings auch sehen, welche Möglichleiten (und Motivation) diese Zeitgenossen hatten, sich mit den Besonderheiten und Möglichkeiten ihrer Software vertraut zu machen. Von MS kenne ich nur die .hlp bzw .chm, und die kann man insoweit in die Tonne kloppen. Eine vernünftige, gleichwohl hinreichend schlanke, deutschsprachige Einführung wurde wimre früher bei StarWriter mitgeliefert. Was heute bei Star, Libre oder SonstwasOffice verfügbar ist, schreckt ab.
:
Bearbeitet durch User
Yalu X. schrieb: > Es ist ja prinzipiell auch in Ordnung, wenn Zahlen in einer gültigen > Darstellung als solche interpretiert werden, solange dabei nichts > hinzugedichtet wird. Aber einen Textstring, der kein gültiges > Datumsformat hat, trotzdem als Datum zu interpretieren und den Benutzer > darüber im Dunkeln zu lassen, ist IMHO ein konzeptioneller Fehler. Hinzu kommt das Problem, dass der Originalzustand uU nicht zweifelsfrei rekonstruierbar ist: war das jetzt MAR1 oder MARCH1?
MWS schrieb: > Percy N. schrieb: >> Warum soll das der Benutzer tun? > > Damit vor Übergabe der Daten das Programm weis, wie das Übergebene zu > interpretieren ist. > Das muss das Programm erst dann wissen, wenn es diese Daten weiterverarbeiten soll. Bis dahin isr alles nichts weiter als ein String. > Das ist wichtig, weil es in einer Exceltabelle verschiedene > Zelleigenschaften gibt, diese Eigenschaften haben auf die anzuwendenden > Funktionen Einfluss, wonach ein Datum anders zu behandeln ist, als eine > Fliesskommazahl oder ein Text. > Ja, so kann der Anwender dem Programm mitteilen, was er möchte. Das sollte aber nicht zwingend vor der Eingabe geschehen müssen. > CSV kennt diese Eigenschaften nicht, da ist alles Text. Wenn nun das > eine in das andere übergeführt wird, dann muss es a) der User mitteilen, > oder b) es wird vom empfangenen Excel interpretiert. Ja. Ind bei Glatteis ist auf der Straße besondere Vorsicht geboten. > > Das Problem ist doch, dass diese sog. Wissenschaftler so wenig Ahnung > von der Materie hatten, dass sie an eine Vorformatierung des > Excelblattes entsprechend der erforderlichen Zelleigenschaften nicht > einmal dachten. Das ist mE ihr gutes Recht. Sie sind Benutzer des Prigramns, nicht dessen Diener. Wenn Excel mitxder Eingabe nichts anzufangen weiß, mag das für den Augenblick stören, darf aber nicht dazu führen, dass Daten zerstört werden.
Sheeva P. schrieb: > In diesem speziellen Fall nicht böse, sondern nur schlecht. Aber Excel > ist ja leider ohnehin die am häufigsten mißbrauchte Software der Welt -- > und ja, das liegt nicht an Excel, sondern an den Anwendern. Die Verwendung als Minidatenbank wurde wimre von MS propagiert.
Trotz des etwas niedrigen Sprachniveaus musste ich darüber lachen, wie kurz und prägnant sich die wesentlichen Eigenschaften von MS Office zusammenfassen lassen: https://www.heise.de/forum/heise-online/Kommentare/Von-Excel-in-Datumsangaben-umgewandelt-Dutzende-Gene-umbenannt/Microsoft-Office-arbeitet-wie-ein-Verdauungstrakt/posting-37178473/show/
Percy N. schrieb: > Das muss das Programm erst dann wissen, wenn es diese Daten > weiterverarbeiten soll. Bis dahin isr alles nichts weiter als ein > String. Nein, das behauptest Du nur. Tatsächlich findet eine Überführung eines "dummen" Formates in ein "intelligentes" Format statt. Das sollte dem User bereits daraus klar werden, da eine gänzlich andere grafische Darstellung erfolgt und die Zellen für Berechnungen nutzbar sind. > Ja, so kann der Anwender dem Programm mitteilen, was er möchte. Das > sollte aber nicht zwingend vor der Eingabe geschehen müssen. Bei einer manuellen Eingabe hätten es die Schlaumeier vielleicht sogar gemerkt, aber beim Öffnen einer CSV findet ein Import statt. Das sollte man wissen und man sollte auch spezielles Verhalten eines Programms kennen, wenn man professionell damit umgeht. Genauso wie man natürlich die Datenintegrität beim ersten Male eines Imports überprüft, wenn man denn schon ein Excelblatt als Datenblatt missbraucht. Man sollte also wissen, was man macht. Das haben die forschen Forscher wegen eigener Überheblichkeit übersehen, nach dem Motto, "Lassen Sie mich durch, ich bin Wissenschaftler, ich kann das". Nichts konnten die und jetzt wird auf der Software rumgehauen. > Das ist mE ihr gutes Recht. Sie sind Benutzer des Prigramns, nicht > dessen Diener. Es ist niemandes gutes Recht sich dumm wie Toastbrot anzustellen und dann auf andere zu schimpfen wenn's wie erwartet scheitert. Es wird im Zeichen der Wischtabletts und Fremdintelligenz offenbar vergessen, dass man sein Handwerk verstehen muss, wenn's klappen soll. > darf aber nicht dazu führen, dass Daten zerstört werden. Ein Leiden unserer Zeit, dass die Verantwortung einzelner immer mehr verlorengeht und jeder denkt, nur weil er eine Tastatur einigermaßen fehlerfrei bedienen kann, hätte auch von den komplizierteren Dingen Ahnung.
Yalu X. schrieb: > wie kurz und prägnant Kurz, prägnant und falsch. > musste ich darüber lachen Einen seichten Lacher vielleicht, alles andere fände ich bedenklich. Und ich bin kein besonderer Freund von MS-Produkten.
Jens G. schrieb: > Unter welchen Umständen passiert dies denn bei Excel? > Wenn eine Zelle nur Standardformat hat, dann scheint das ja üblich zu > sein, daß Excel irgendwelche Daten umformatiert. > Aber wenn man eine Zelle explizit als Text definiert, sollte das doch > nicht passieren - oder ist das hier doch der Fall? Nein. Da Excel seit etwa 10 Jahren es besser weiß als der Anwender, reicht es nicht (mehr) die Zelle als Text zu formatieren. Excel schmiert ebenso regelmäßig ein "=" vor einen Text von dem es glaubt eine Formel zu sein, um dann über Fehler in der Formel zu meckern. Texte, die Excel so nehmen soll wie der Anwender es eingibt, müssen mit dem Hochkomma eingeleitet werden.
Ist doch ne praktische Lösung, vielleicht auch ne Namensänderung wenn jemand Oktavia heißt. Oder solche Namen besser gleich amtlich verbieten :-). und typisch Excel, hab mich auch oft mit diesen Datumsänderungen herumgeärgert. Der .csv Standard sieht aber für mehrdeutige Daten (Zahlen/Datum/Text) vor diese in Anführungszeichen zu setzen. Dann erkennt Excel diese auch als Text. Bei ODBC Abfragen hatte ich das Problem auch noch nie. Obwohl ich das schon ewig mache. Da geht Excel wohl davon aus das die Daten von Profis kommen ;-).
Roland E. schrieb: > Texte, die Excel so nehmen soll wie der Anwender es eingibt, müssen mit > dem Hochkomma eingeleitet werden. Bullshit, wenn ich Zellen mit "Text" formatiere, kann ich eingeben was ich will, ohne daß eine Umformatierung eintritt. Kannst du übrigens selbst probieren, wenn es dich nicht überfordert.
c-hater schrieb: > Lustig finde ich übrigens diese unsäglichen Typen, die bei ihrem > geliebten C es für völlig normal halten, eine Variable erst deklarieren > zu müssen, es aber bei Excel für einen Bug halten. Wenn das nicht > Scheuklappen sind, was denn sonst? Ähm, es geht hier darum, dass das bei Excel gerade nicht so ist. Es interpretiert meine Eingabe und versucht, anhand irgendwelcher nicht klar durchschaubarer Regeln zu erraten, welcher Typ der gewünschte sein könnte. Das macht C nicht, hat es nie und wird es auch nie tun. MWS schrieb: > Und weil es "so wichtige" Forscher sind, wird nicht gefragt, > wie dumm die sich verhalten haben, sondern es gibt einen Aufschrei nach > Softwarefehler. Dass sich Heise dafür entblödet, ist verwunderlich. Kannst du bitte mal den Teil des Heise-Artikels zitieren, wo die Forscher als so wichtig bezeichnet werden und wo dieser Aufschrei nach Softwarefehler steht? Ich kann ihn dort beim besten Willen nicht finden.
Rolf M. schrieb: > Ja, das ist schon merkwürdig. Sind die dort so total abhängig von diesem > einen Tool (das dafür offensichtlich weder gedacht noch geeignet ist)? Du unterschätzt erheblich den Zwang des Faktischen: Ich hab mal eine Schrittmotoransteuerung und Datenerfassung per AD-Karte mit VB in Excel programmiert. Inklusive Peakfitting und Darstellung der Werte. Warum? Geplant war LabView. Aber die LabView-Treiber der Karte gingen nicht mit dem alten LabView. Für ein neues LabView war kein Geld im Projekt. Aber es gab Basic-Treiber für die Karte. Und Excel war eh auf den Rechnern. Natürlich hat effektiv meine Zeit die Steuerung in VB nochmal zu programmieren nachdem es in LabView bis auf die AD-Karte schon fast fertig war mehr gekostet als ein neues LabView. Aber ich war in den Projektkosten. Ein neues LabView nicht.
Rolf M. schrieb: > Gut, viele scheinen Bindestriche heute nicht mehr vernünftig anwenden zu > können. Anders lässt sich nicht erklären, warum so oft mitten im Wort > ein Leerzeichen steht. Auf der Tablet- oder Smartphone-Tastatur muss man dazu immer die Tastaturebene wechseln.
Yalu X. schrieb: > Das beträfe ja nur die Genforschung. Wenn diese dadurch etwas > ausgebremst würde, fände ich das gar nicht einmal so tragisch ;-) Die gerade versucht einen Impfstoff zu entwickeln, damit Du wieder unbeschränkt nach Malle darfst? Mutige Einstellung.
Yalu X. schrieb: > Jetzt sollte man meinen, mit der Deaktivierung der Autokorrektur im > "Optionen"-Dialog sei das Problem gelöst. Leider ist es das nicht. Vermutlich eher "automatische Zahlenerkennung" oder sowas. Aber wie gesagt, das Problem tritt nicht nur bei der händischen Eingabe, sondern vor allem beim Datenimport aus CSV-Dateien auf.
c-hater schrieb: > Genau das ist bei Excel doch umgesetzt: Wenn ich VOR der Eingabe > festlege, das eine Zelle (oder eine Spalte oder das ganze Blatt) nur > dumme Strings enthalten soll, dann wird Excel auch nichts mehr > (fehl-)interpretieren Boah, Junge, was ist an "beim Datenimport" so schwer zu verstehen? Wenn du eine CSV aufmachst weil der Kollege CSV verschickt hat dann hast Du mit Glück einen Einstellungsdialog. In dem Dialog sieht alles ok aus, auch in der Vorschau. Dass irgendwo in Zeile 100 in der Spalte in der alles als Text interpretiert wird plötzlich ein MARCH1 als Datum interpretiert wird siehst du nicht.
MWS schrieb: > Der einfachste Weg ist die Spalte, bei der man ja vorher weis dass man > ausschließlich Text eintragen will, komplett zu markieren und als Text > zu formatieren. MWS schrieb: > Das Problem ist doch, dass diese sog. Wissenschaftler so wenig Ahnung > von der Materie hatten, dass sie an eine Vorformatierung des > Excelblattes entsprechend der erforderlichen Zelleigenschaften nicht > einmal dachten. c-hater schrieb: > Genau das ist bei Excel doch umgesetzt: Wenn ich VOR der Eingabe > festlege, das eine Zelle (oder eine Spalte oder das ganze Blatt) nur > dumme Strings enthalten soll, dann wird Excel auch nichts mehr > (fehl-)interpretieren, sonder brav alles als dummen String unverändert > übernehmen. IchGlaubeEsNicht schrieb: > Bullshit, wenn ich Zellen mit "Text" formatiere, kann ich eingeben was > ich will, ohne daß eine Umformatierung eintritt. Mal ganz ehrlich: Macht ihr euch tatsächlich immer die Mühe, die Excel-Zellen vorzuformatieren, bevor ihr mit der Eingabe von Daten beginnt?
Karl K. schrieb: > Yalu X. schrieb: >> Das beträfe ja nur die Genforschung. Wenn diese dadurch etwas >> ausgebremst würde, fände ich das gar nicht einmal so tragisch ;-) > > Die gerade versucht einen Impfstoff zu entwickeln, damit Du wieder > unbeschränkt nach Malle darfst? Mutige Einstellung. Kein Problem, da war ich schon, und ein zweites Mal muss nicht sein ;-) Außerdem sollten sich die Impfstoffentwickler mehr mit der Entwicklung von Impfstoffen beschäftigen und sich weniger mit dafür ungeeigneten Werkzeugen herumschlagen. Es ist ja kein Wunder, dass wir viele Monate, wenn nicht Jahre auf den Impfstoff warten müssen, wenn die Forscher ihre Zeit erfolglos damit vertrödeln, Excel für ihre Zwecke gefügig zu machen.
Yalu X. schrieb: > Mal ganz ehrlich: Macht ihr euch tatsächlich immer die Mühe, die > Excel-Zellen vorzuformatieren, bevor ihr mit der Eingabe von Daten > beginnt? Nee, ich falle auch gelegentlich erst mal mit dem Quick-and-Dirty-Versuch auf die Schnauze. Dann fluche ich natürlich auch - aber über MICH, denn es ist MEIN Fehler und nicht der eines Anderen. Es gibt ja schließlich eine Möglichkeit, beim Datenimport den Datentyp jeder Spalte auszuwählen! Karl K. schrieb: > Aber wie gesagt, das Problem tritt nicht nur bei der händischen Eingabe, > sondern vor allem beim Datenimport aus CSV-Dateien auf. Nee, beim echten Import eben NICHT. Genau da kann man den Datentyp jeder Spalte festlegen und den Fehler dadurch vermeiden. Der Fehler tritt vielmehr dann auf, wenn man den Import zu vermeiden sucht und die CSV-Datei stumpf mit Excel öffnet - dass diese Möglichkeit überhaupt besteht, halte ich für den eigentlichen Fehler.
Matthias L. schrieb: > Genau da kann man den Datentyp jeder > Spalte festlegen und den Fehler dadurch vermeiden. Auch da: Die Spaltenvorschau sieht in Ordnung aus, dass irgendwo weiter unten plötzlich aus Text ein Datum wird sieht man nicht. Es ist schon ein Designfehler, dass Excel mitten in der Tabelle das Zahlenformat der Spalte ändert.
Yalu X. schrieb: > Außerdem sollten sich die Impfstoffentwickler mehr mit der Entwicklung > von Impfstoffen beschäftigen und sich weniger mit dafür ungeeigneten > Werkzeugen herumschlagen. Es ist nun leider so, dass Genforscher sich mit Genetik auskennen, aber eher selten gleich C und Python können und sich ihre Tools selbst programmieren. Man wirft ja Informatikern auch nicht vor, dass sie bei Kopfschmerzen mit C-ans-Kreuz fertige Kopfschmerztabletten einwerfen und die nicht selbst zusammenrühren. Witzig, wie hier über die Inkompetenz der Forscher abgelästert wird - aber ein passenderes Tool als Excel konnte auch keiner von den Ekschbärden nennen.
Rolf M. schrieb: > Kannst du bitte mal den Teil des Heise-Artikels zitieren, wo die > Forscher als so wichtig bezeichnet werden und wo dieser Aufschrei nach > Softwarefehler steht? Ich kann ihn dort beim besten Willen nicht finden. Überschrift: "Wegen Excel-Verhalten Gene umbenannt" Da steht nicht: "Wissenschaftler dumm wie Toast" Sollte es aber.
Yalu X. schrieb: > Mal ganz ehrlich: Macht ihr euch tatsächlich immer die Mühe, die > Excel-Zellen vorzuformatieren, bevor ihr mit der Eingabe von Daten > beginnt? Ja, weil mir das Verhalten bekannt ist, z.B. wenn ich aus der Fritzbox die Telefondaten als CSV downloade und in Excel zwecks Sortierung hole. Dann neigt Excel dazu, Telefonnummern z.B. als 156,567E6 oder ähnlich zu interpretieren. Ein Wissenschaftler lernt dagegen seine Ergebnisse zu verifizieren, wenn er das vergisst taugt er nichts. Der Heise-Artikel hätte gar nicht erst entstehen können, da der Wissenschaftler oder wissenschaftliche Angestellte bei der ersten oder zweiten Konvertierung hätte merken müssen, dass das umgewandelte Ergebnis mangelhaft ist. Da hätte er noch nicht einmal erweitertes Wissen um Excel besitzen müssen, das man allerdings für diese Tätigkeit voraussetzen muss. Ergo: die waren dumm wie Toastbrot und wenn solches oder ähnlich dummes Volk dann vielleicht auch noch für die Erforschung von Covid19 zuständig ist, dann: Gute Nacht.
Karl K. schrieb: > Es ist schon ein Designfehler, dass Excel mitten in der Tabelle das > Zahlenformat der Spalte ändert. Nein, es ist eine (problematische) Designentscheidung. Schließlich ist es ein Feature, dass Du zB mitten in der Tabelle einen neuen Abschnitt beginnen oder neue Spaltrnköpfe einschalten oder Text einfügen kannst. Blöd ist halt nur die relativ irreversible Konversion ohne Warnhinweis.
Karl K. schrieb: > Witzig, wie hier über die Inkompetenz der Forscher abgelästert wird - > aber ein passenderes Tool als Excel konnte auch keiner von den > Ekschbärden nennen. Das ist auch gar nicht möglich, solange man nicht weiß, wozu genau die Genforscher Excel verwenden. Ich habe oben mal LibreOffice genannt, was vermutlich ebenfalls weit entfernt vom Optimum ist, aber – unabhängig davon, für welche Zwecke es genutzt wird – gegenüber Excel schon einmal einen deutlichen Fortschritt darstellt. MWS schrieb: > Ergo: die waren dumm wie Toastbrot Ich glaube nicht, dass die Forscher ganz so dumm sind wie von dir und einigen anderen dargestellt. Vermutlich kennen sie auch die genannten Workarounds für das Problem, scheuen aber den damit verbundenen stark erhöhten Arbeitsaufwand. Es ist eben ein Unterschied, ob man jede Woche einen oder jeden Tag hunderte Datensätze bearbeiten muss. Da summiert sich der Aufwand für den "Textkonvertierungs-Assistenten" schon deutlich auf, zumal dieser seiner Bezeichnung "Assistent" überhaupt keine Ehre macht, wie ich gerade mit Erschrecken feststellen musste: Ich habe mal eine CSV-Datei mit ein paar Zahlenwerten und Pseudogennamen erstellt. Diese Datei kann ich nun importieren, indem ich erst ein leeres Sheet anlege, dann mit "Daten" -> "Externe Datei abrufen" -> "Aus Text" den tief im Menübaum verborgenen Dialog des Assistenten aufrufe und mich dort durchkämpfe, bis ich schließlich auf der letzten Dialogseite angelangt bin ("textkonvertierungs-assistent.png"). Zunächst einmal ist hier nichts Verdächtiges zu erkennen, da die Namen "OKTO1" und "SEPT5" als ganz normale Textstrings und nicht als Datum dargestellt werden. Man ist also versucht, "Fertig stellen" anzuklicken und ist damit schon in die Falle getappt. Selbst im Excel-Sheet selber sind die Fehler nur schwer zu erkennen ("sheet.png"). Wer also nach dem Import denkt, er könne die CSV-Datei löschen, weil jetzt ja alle Informationen in der Excel-Datei enthalten sind, hat nun ein noch viel größeres Problem. Ok, zweimal denselben Fehler macht man natürlich nicht, also möchte ich im Assistenten für alle 48 Spalten mit Gennamen das Datenformat "Text" einstellen, das Format der 49 Spalten mit den Zahlenwerten aber beibehalten. Am liebsten würde ich ja alle Spalten mit den Gennamen markieren und dann das Format für alle in einem Rutsch ändern. Das geht aber nicht, weil die Spalten nicht zusammenhängend sind. Schlimmer noch: Auch Strg-Mausklick geht aus unerfindlichen Gründen nicht. Ich komme also nicht umhin, alle 48 Spalten einzeln anzuklicken und jeweils das "Text"-Format auszuwählen. Nach insgesamt weit über 100 Mausklicks für eine einzige CSV-Datei bin ich endlich am Ziel angekommen :D Falls das einfacher geht, möge doch einer der Excel-Spezialisten das genaue Vorgehen beschreiben. Ganz anders sieht die Sache mit LibreOffice Calc aus, denn dort führt schon der intuitive Weg in einem winzigen Bruchteil der Zeit geradewegs zum Ziel: Dort erscheint der Text-Import-Assistent auch beim ganz normalen Öffnen oder Doppelklicken der Datei. Der Umweg über das leere Sheet und das verschachtelte Menü für den Dateiimport entfällt also. Im Dialog muss nur das Trennzeichen (Tab, Komma, ...) ausgewählt und dann "Ok" geklickt werden. Da das Programm sich das eingestellte Trennzeichen vom letzten Aufruf merkt, ist dies aber nur beim ersten Mal erforderlich. Man braucht als statt über 100 Klicks genau 1 Doppelklick und 1 Klick auf Ok, um Calc zu starten und darin eine CSV-Datei zu öffnen. Über die Gründe, warum die Genforscher der Excel-Software ihre Nomenklatur geopfert haben und nicht einfach auf das weitgehend kompatible LibreOffice Calc umgestiegen sind, kann nur spekuliert werden. Die Migration würde sicher nur einen Bruchteil des Aufwands erfordern, der bereits in die Erarbeitung von Workarounds für Excel (wozu u.a. auch die Umbenennung der Gene gehört) gesteckt worden ist und noch gesteckt werden wird.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Über die Gründe, warum die Genforscher der Excel-Software ihre > Nomenklatur geopfert haben und nicht einfach auf das weitgehend > kompatible LibreOffice Calc umgestiegen sind, 1.Mit dem Wissen wächst der Zweifel. 2.Nicht alles ist gleich. Versuche z.B. Strg U um in Spalte ALLES schnell auszufüllen dann in LibreOffice. 3.Übrigens Excel-Lehrgang 1. Stunde lernte man, dass man die Zellen ERST richtig formatiert BEVOR man sie füllt.
oszi40 schrieb: > Excel-Lehrgang 1. Stunde lernte man, dass man die Zellen ERST richtig > formatiert BEVOR man sie füllt. Du hast alle bisher abgehaltenen bzw veröffentlichten Excel-Lehrgänge besucht bzw anderweitig internalisiett? Alle Achtung!
Yalu X. schrieb: > Vermutlich kennen sie auch die genannten > Workarounds für das Problem, scheuen aber den damit verbundenen stark > erhöhten Arbeitsaufwand. Ich kann jetzt nicht so genau erkennen, was Du damit sagen willst. Du sagst: Den Arbeitsaufwand scheuen sie, importieren falsch, stellen in Folge fest dass sie in Anzahl x Tabellen unbrauchbare Werte haben. Statt dessen sie nun ihre eigene peinliche Blödheit korrigieren und zugeben, dass sie monumentale Vollpfosten sind, beschweren sie sich lauthals bei der Presse, Heise greift es in Folge auf und berichtet über den bösen Softwarefehler. Du merkst schon, Deine Argumentation hält kein Wasser, etwas unhöflicher geschrieben ist sie monumentaler Blödsinn. > Über die Gründe, warum die Genforscher der Excel-Software ihre > Nomenklatur geopfert haben und nicht einfach auf das weitgehend > kompatible LibreOffice Calc umgestiegen sind, kann nur spekuliert > werden. Da muss man nicht spekulieren: die sind einfach DUMM. Ansonsten wäre die Geschichte nicht passiert.
MWS schrieb: > Da muss man nicht spekulieren: die sind einfach DUMM. > Ansonsten wäre die Geschichte nicht passiert. Nun ja, die verbringen ihre Zeit halt mit Genforschung. Andere bereichern die Menschheit, indem sie sie hier an ihrer Genialität zwar nicht teilhaben, sie diese aber bewundern lassen. Das ist bestimmt sehr viel klüger; macht jedenfalls zumindest vermutlich mehr Spaß im Rahmen der jeweiligen persönlichen Kompetenz.
:
Bearbeitet durch User
Yalu X. schrieb: > Karl K. schrieb: >> Yalu X. schrieb: >>> Das beträfe ja nur die Genforschung. Wenn diese dadurch etwas >>> ausgebremst würde, fände ich das gar nicht einmal so tragisch ;-) >> Die gerade versucht einen Impfstoff zu entwickeln, damit Du wieder >> unbeschränkt nach Malle darfst? Mutige Einstellung. > > Kein Problem, da war ich schon, und ein zweites Mal muss nicht sein ;-) Egoist! Egoistenmod?
Karl K. schrieb: > Auch da: Die Spaltenvorschau sieht in Ordnung aus, dass irgendwo weiter > unten plötzlich aus Text ein Datum wird sieht man nicht. Zugegebenerweise gibt's ja verschiedene Excel-Versionen, die bestimmt auch unterschiedliche Import-Dialoge haben. Bei denen, die ich kenne, kann man aber durchaus den Datentyp der zu importierenden Spalte lesen. Wenn da "Standard" steht, dann überlässt man Excel die Entscheidung, was es damit anfangen soll - das ist häufig Unsinn. Anderslautenden Gerüchten entgegen sind Computer meist keineswegs intelligent, sondern können nur schnell rechnen... Wenn man also möchte, dass mit diesen Daten etwas bestimmtes passiert (z.B. dass sie als Text interpretiert werden), dann kann man im Importdalog an diesem Spaltenkopf auch den Datentyp "Text" setzen. Dass Excel dann trotzdem (!) irgendwo weiter eigenmächtig einen Text zu einem Datum umwidmet, das ist mir (!) bisher noch nicht passiert. Mit dem Datentyp "Standard" schon, ja - der ist dann aber schlicht ungeeignet. Woher soll so ein Programm denn wissen, wie es Daten interpretieren soll, wenn man's ihm nicht sagt?? Ich würde auch begrüßen, wenn die Satandardeinstellung wäre: Was aus einer Textdatei stammt, ist TEXT, solange nix anderes bestimmt wird. Ist aber halt nicht so... Yalu X. schrieb: > Ganz anders sieht die Sache mit LibreOffice Calc aus, denn dort führt > schon der intuitive Weg in einem winzigen Bruchteil der Zeit geradewegs > zum Ziel: > > Dort erscheint der Text-Import-Assistent auch beim ganz normalen Öffnen > oder Doppelklicken der Datei. Das ist zweifellos die bessere Lösung. Dass Calc den Datentyp der einzelnen Spalten ohne Unterstützung aber auch nicht hellseherisch ermitteln kann, hast du bei der Zählung der Mausklicks elegant unterschlagen...
:
Bearbeitet durch User
Matthias L. schrieb: > Ich würde auch begrüßen, wenn die Satandardeinstellung wäre: Was aus > einer Textdatei stammt, ist TEXT, solange nix anderes bestimmt wird. Ist > aber halt nicht so... Zumindest wäre das schön konservativ. Btw:"Satan" passt ganz gut ... ;-)
MWS schrieb: > Ich kann jetzt nicht so genau erkennen, was Du damit sagen willst. Ok, mein Beitrag war auch viel zu lang, um von jedem in Gänze gelesen zu werden ;-) Kurz zusammengefasst wollte ich aussagen, dass das Einlesen einer CSV-Datei in Excel ohne die unerwünschte Datumskonvertierung mit dem Textkonvertierungsassistenten zwar prinzipiell möglich, aber bei einer größeren Spaltenzahl kaum mehr praktikabel ist. Grund: Die manuelle Festlegung der Datenformate für die einzelnen Spalten kann ziemlich arbeitsintensiv werden, weil sie in ungünstigen Fällen für jede Spalte separat erfolgen muss. Das macht sich insbesondere dann negativ bemerkbar, wenn nicht nur eine, sondern viele Dateien zu bearbeiten sind. Die Genforscher arbeiten nun einmal mit größeren Datenmengen als bspw. die BWLer. Zum Vergleich habe ich das Vorgehen zum Einlesen einer CSV-Datei in LibreOffice Calc gegenübergestellt, das unabhängig von der Spaltenzahl sehr fix vonstatten geht. Das liegt daran, dass dort im Gegensatz zu Excel - der Import-Assistent ohne Verrenkungen erreichbar ist und - dieser die Formatierungen auch ohne manuellen Eingriff richtig macht. Aber vielleicht bin ich ja selber zu dumm, Excel richtig zu bedienen, und es gibt noch irgendwelche mir unbekannten Tricks, um den CSV-Import zu beschleunigen. Deswegen habe ich im obigen Beitrag darum gebeten, ggf. bessere Vorgehensweisen zu erläutern.
Percy N. schrieb: > Nun ja, die verbringen ihre Zeit halt mit Genforschung. Ich hab' kein Verständnis dafür deren Blödheit zu entschuldigen. Es ist immer das Ergebnis, das zählt und zum vollständigen Ergebnis gehört die fehlerfreie Dokumentation. Wenn man dokumentiert, muss man darauf achten, dass sich die Dokumente wieder korrekt lesen lassen. Das lässt sich leicht testen, indem man die Excel-Datei nach dem Import wieder als CSV exportiert und vergleicht. Wenn mir als Gentechniker das Wissen um das verwendete Programm fehlt, wie in diesem Fall Excel, dann suche ich mir in meinem Institut eben jemand, der sich auskennt, besonders mit möglichen Stolperfallen. Haben die Wissenschaftler alles scheinbar nicht gemacht, anstatt dessen haben sie Datensalat produziert. "Blöd" ist noch die freundliche Umschreibung, "grob fahrlässig" trifft's besser. Tatsächlich hätte ich erwartet, dass für so eine fundamentale Geschichte institutsübergreifend eine Datenbankanwedung entwickelt wurde, in der jeder Forscher seine Erkenntnisse einträgt. Geld sollte nicht das Ding sein, für die Corona-App waren auch 20Mios da. Das ist schon der Hammer, dass mit Exceltabellen umeinandergefrickelt wird.
Yalu X. schrieb: > Zum Vergleich habe ich das Vorgehen zum Einlesen einer CSV-Datei in > LibreOffice Calc gegenübergestellt, das unabhängig von der Spaltenzahl > sehr fix vonstatten geht. Das liegt daran, dass dort im Gegensatz zu > Excel > > - der Import-Assistent ohne Verrenkungen erreichbar ist und Das ist besser und wünschenswert, völlig einverstanden! Yalu X. schrieb: > - dieser die Formatierungen auch ohne manuellen Eingriff richtig macht. Das GEHT NICHT! Woher soll die dumme Kiste wissen, was "richtig" ist?? Der Ursprung ist eine TEXTdatei, da kann sonstwas drinstehen. Ein Programm, das alles daraus als "Text" interpretiert, macht sicher erst mal nichts völlig falsch - aber keineswegs sicher alles richtig! Vielleicht soll die eine oder andere Spalte ja doch ein bestimmtes Zahlenformat haben - aber welches? Da steht ja nur Text!
Yalu X. schrieb: > MWS schrieb: >> Ich kann jetzt nicht so genau erkennen, was Du damit sagen willst. > > Ok, mein Beitrag war auch viel zu lang, um von jedem in Gänze gelesen zu > werden ;-) Nein, der Inhalt war nicht zu lang. Jedoch bezog ich mich mit "kann nicht genau erkennen" auf das hier: Yalu X. schrieb: > Vermutlich kennen sie auch die genannten > Workarounds für das Problem, scheuen aber den damit verbundenen stark > erhöhten Arbeitsaufwand. Es gäbe diese Szenarien: 1) Sie kennen in der Mehrheit das Problem nicht und erzeugen unbeabsichtigt Datensalat. 2) Sie kennen das Problem und erzeugen beabsichtigt Datensalat, weil ihnen die fehlerfreie Form wg. stark erhöhtem Aufwand nicht liegt. 3) Sie kennen das Problem und vermeiden Excel. 4) Sie kennen das Problem, nehmen Excel und passen die Namensgebung an. Der Originalbericht las sich nach (1) und schliesslich (4). (3) passierte nicht, sonst gäb's den Bericht nicht. (2), was Deinem Kommentar entsprach, ist dermassen unsinnig, dass ich schrieb, dass ich den Sinn dahinter nicht erkenne. Denn (2) bedeutet ja, dass der Forscher bei der Sequenzierung eine Ergebnis erlangt und dieses Ergebnis selbst im Wissen darum, dass dieses von Excel unsinnig verändert wird, trotzdem so in sein CSV einträgt, weil ihm etwas anderes zu aufwändig ist. Das kann ich mir nicht vorstellen.
Matthias L. schrieb: > Vielleicht soll die eine oder andere Spalte ja doch ein bestimmtes > Zahlenformat haben - aber welches? Da steht ja nur Text! Das Problem besteht seit Urzeiten der Datenverarbeitung, daß gelieferte Daten oft fehlerhaft sind und geprüft werden müssen. Man kann dann entscheiden allen Müll zu importieren oder alles wegen Fehler zurückzuweisen. Für eine Variante dazwischen ist oft viel Aufwand nötig.
Richtig! Wobei die (an Excel) gelieferten Daten hier ja nicht FALSCH waren, sondern interpretationsbedürftig - und diese Interpretation hat Excel vergeigt - dem prinzipiell dummen Programm hat aber auch schlicht niemand mitgeteilt, was es damit anfangen soll! Da kann man schon verschiedene Fehler sehen. Ein Programm, das Daten interpretiert, dem Nutzer aber nicht mitteilt, was es da tut, das muss sich Kritik gefallen lassen. Ein Nutzer, der ein Werkzeug nutzt, ohne sich mit dessen für die konkrete Anwendung grundlegenen Funktionen vertraut gemacht zu haben, muss sich ebenfalls Kritik gefallen lassen.
Matthias L. schrieb: > Das GEHT NICHT! Woher soll die dumme Kiste wissen, was "richtig" ist?? > Der Ursprung ist eine TEXTdatei, da kann sonstwas drinstehen. Ein > Programm, das alles daraus als "Text" interpretiert, macht sicher erst > mal nichts völlig falsch - aber keineswegs sicher alles richtig! > Vielleicht soll die eine oder andere Spalte ja doch ein bestimmtes > Zahlenformat haben - aber welches? Da steht ja nur Text! Dazu müsste man wissen, was die damit überhaupt vorhatten. Zahlen braucht man vorwiegend dann als solche, wenn man mit ihnen auch Berechnungen anstellken möchte. Falls es lediglichcdarum ging, die Ereignisfrequenzen bestimmter Veibachtungen zu dokumentieren, ist dies zunächst nicht zwingend erforderlich. "Interessante" Erkenntnisse gibtxes aber sicherlich in dem Moment, da man zB nach dieser Spalte aufsteigend sortiert. Da die ursprünglichen Werte aber als Text konserviert vorliegen, bedarf es lediglich eines Mausklicks, das Manko zu beheben. Das ist allemal besser, als die hoffentlich noch vorhandenen Daten erneut einzuspielen.
oszi40 schrieb: > 3.Übrigens Excel-Lehrgang 1. Stunde lernte man, dass man die Zellen ERST > richtig formatiert BEVOR man sie füllt. Was zum Henker hast du jetzt zum fünften Mal nicht verstanden an: Das Problem tritt beim Importieren auf. Da hast du noch keine Spalten, die du formatieren kannst.
Matthias L. schrieb: > Wobei die (an Excel) gelieferten Daten hier ja nicht FALSCH waren, > sondern interpretationsbedürftig - und diese Interpretation hat Excel > vergeigt - Nö. Excel hat etwas hineingelesen, um es anschließend herauszulesen - der klassische Eisegese-Exegese-Fehlschluss. - dem prinzipiell dummen Programm hat aber auch schlicht > niemand mitgeteilt, was es damit anfangen soll! Eigentlich sollte es damit zunächst einmal genau nichts anfangen, außer gut darauf aufzupassen. Also Schaden abwenden, aber zunächst nicht Nutzen mehren. Ganz einfach. Und das hat es gründlich versiebt.
:
Bearbeitet durch User
Die Genetiker verwenden ein defektes Werkzeug. Das ist klar. LibreOffice zu empfehlen mag richtig sein (vielleicht gibts da auch Probleme, nur andere), geht aber doch an der Realität vorbei. Das Werkzeug ist Fakt, dessen Dominanz ist es ebenso. Das muss man nicht mögen, aber wer für sich zu Hause entscheidet, der ist in einer anderen Situation als jemand, der von der Verwaltung den PC gestellt bekommt. Die Konsequenz, nun Gene umzubenennen, ist der richtige Weg für sie. Sie haben damit das Problem vom Hals und können sich dem widmen, was ihre Aufgabe ist. Und es ist nicht die Aufgabe von Genetikern, einen Krieg gegen ein IT-Werkzeug, dessen Hersteller oder die Verwaltung des Instituts zu führen.
:
Bearbeitet durch User
Matthias L. schrieb: > Yalu X. schrieb: >> - dieser die Formatierungen auch ohne manuellen Eingriff richtig macht. > > Das GEHT NICHT! Woher soll die dumme Kiste wissen, was "richtig" ist?? Mit dem "richtig" bezog ich mich auf den konkreten Anwendungsfall. LibreOffice wird aus einem Gennamen, der aus ein paar Buchstaben, direkt gefolgt von einer Ziffer, nie ein Datum machen, was völlig korrekt ist, da in keinem Land der Welt die Tages- oder Jahreszahl direkt an den Monatsnamen geklebt wird. Excel hingegen tendiert dazu, sehr vieles als Datum zu interpretieren, bspw. auch Brüche (selbst dann, wenn in den Ländereinstellungen Deutsch ausgewählt wurde, wo der Schrägstrich kein gültiges Datumstrennzeichen ist):
1 | Eingabe Interpretation |
2 | ────────────────────────────────────────────────────────────── |
3 | 1 2/13 1+2/13 als Bruch |
4 | 2/13 1. Februar 2013 (und nicht 2/13 als Bruchzahl) |
5 | 2/12 2. Dezember 2020 (und nicht 2/12 als Bruchzahl, |
6 | aber auch nicht 1. Februar 2012) |
7 | ────────────────────────────────────────────────────────────── |
So erlebt man immer wieder nette Überraschungen :) LibreOffice lässt die Eingabe im Zweifelsfall einfach unverändert als Text stehen, was zwar in einigen seltenen Fällen unerwünscht, aber nie falsch ist.
Yalu X. schrieb: > Matthias L. schrieb: >> Yalu X. schrieb: >>> - dieser die Formatierungen auch ohne manuellen Eingriff richtig macht. >> >> Das GEHT NICHT! Woher soll die dumme Kiste wissen, was "richtig" ist?? > > Mit dem "richtig" bezog ich mich auf den konkreten Anwendungsfall. > LibreOffice wird aus einem Gennamen, der aus ein paar Buchstaben, direkt > gefolgt von einer Ziffer, nie ein Datum machen, was völlig korrekt ist, > da in keinem Land der Welt die Tages- oder Jahreszahl direkt an den > Monatsnamen geklebt wird. > > Excel hingegen tendiert dazu, sehr vieles als Datum zu interpretieren, > bspw. auch Brüche (selbst dann, wenn in den Ländereinstellungen Deutsch > ausgewählt wurde, wo der Schrägstrich kein gültiges Datumstrennzeichen > ist): Das scheint mir der Kernpunkt des Problems zu sein. Es gibt einige "richtige" Schreibweisen. Es sei mal dahingestellt, ob aufgrund einer Norm oder Tradition oder auch einer Logik. MS hat offenbar (ich kann das nur vermuten) auf die ungenügende Kenntnis einer Vielzahl von Benutzern, vermutlich sogar vorauseilend, reagiert. Noch schlimmer: Inzwischen gilt das "Richtige" schon als "umständlich", "altmodisch", "überflüssig". Sogar als Mittel zur Ausgrenzung. (Man denke etwa an die immer wieder hier vorkommende Reaktionen, wenn man sich erlaubt, auf die korrekte Rechtschreibung hinzuweisen). Nun also richtet sich die Wissenschaft, über einen Umweg, nach den Unwissenden. So sehe ich das jedenfalls.
MWS schrieb: > Es gäbe diese Szenarien: > > 1) Sie kennen in der Mehrheit das Problem nicht und erzeugen > unbeabsichtigt Datensalat. > 2) Sie kennen das Problem und erzeugen beabsichtigt Datensalat, weil > ihnen die fehlerfreie Form wg. stark erhöhtem Aufwand nicht liegt. > 3) Sie kennen das Problem und vermeiden Excel. > 4) Sie kennen das Problem, nehmen Excel und passen die Namensgebung an. > > ... > > (2), was Deinem Kommentar entsprach, ist dermassen unsinnig, dass ich > schrieb, dass ich den Sinn dahinter nicht erkenne. Das wäre in der Tat unsinnig. Ich habe aber auch nirgends geschrieben, dass die Leute absichtlich Datensalat erzeugt haben. Da ich – anders als du – den Genforschern keine toastbrotmäßige Dummheit unterstelle, lief die Sache meiner Meinung nach so (oder so ähnlich) ab: Bevor die Gennamen MARCH1 und SEPT5 eingeführt wurden, gab es keinerlei Probleme, und alle waren glücklich. Als mit der Einführung dieser Namen die Probleme auftraten, wurden diese zunächst durch Festlegung der Spaltenformate im Import-Assistenten umgangen. Sehr bald stellte sich jedoch heraus, dass dieses Vorgehen nicht nur ziemlich nervig, sondern bei größeren Spaltenzahlen völlig unpraktikabel war. Also wurde nach einer anderen Lösung gesucht. Sicher wurden da mehrere Optionen diskutiert, aber am Ende hat man sich (aus Gründen, die wir nicht kennen) für die Umbenennung der betroffenen Gen entschieden. Dass zuvor in größerem Umfang Datensalat produziert worden ist, glaube ich kaum, da so etwas schnell auffällt, wenn die Daten in irgendeiner Form weiterverarbeitet werden und nicht einfach nur im Archiv landen.
Yalu X. schrieb: > Ich habe aber auch nirgends geschrieben, > dass die Leute absichtlich Datensalat erzeugt haben. Doch, logischerweise hieraus hervorgehend: Yalu X. schrieb: > Vermutlich kennen sie auch die genannten > Workarounds für das Problem, scheuen aber den damit verbundenen stark > erhöhten Arbeitsaufwand. > lief die Sache meiner Meinung nach so (oder so ähnlich) ab: > ... Deine Geschichte hört sich ja sowas von nett und harmlos an, ein Märchen eben. Hat wohl mit der Realität wenig zu tun. Diese Harmlosigkeit hat's immerhin nach Heise geschafft, sonst gäb's diese Diskussion nicht. Und dass die Kartografierung des menschlichen Genoms per Tabellenkalkulation erfolgt, ja das ist ein Treppenwitz, der mich irgendwie nicht so an die Intelligenz der beteiligten Forscher glauben lässt.
Angehängte Dateien:
-
Excel_Incel.jpg
21 KB
Yalu X. schrieb: > Excel hingegen tendiert dazu, sehr vieles als Datum zu interpretieren Tja, einige Witze funktionieren leider nur im Englischen.
Theor schrieb: > Es gibt einige "richtige" Schreibweisen. Es sei mal dahingestellt, ob > aufgrund einer Norm oder Tradition oder auch einer Logik. Nur wo bitte auf der Welt ist MARCH1 oder SEPT1 eine "richtige" Schreibweise für ein Datum? Excel ist hier einfach übereifrig.
Peter M. schrieb: > Sheeva P. schrieb: >> In diesem speziellen Fall nicht böse, sondern nur schlecht. Aber Excel >> ist ja leider ohnehin die am häufigsten mißbrauchte Software der Welt -- >> und ja, das liegt nicht an Excel, sondern an den Anwendern. > > Excel ist eine Tabellenkalkulation, wird aber überwiegend als > Tabellenverwaltung genutzt. Ja, oder als "Datenbank". > Wie bestimmte Software-Verhaltensweisen entstehen, kann man hier am > Beispiel der Datumsfunktionen von Excel gut nachvollziehen. Das ist die eine Sache; daß Anwender ihre Software dazu mißbrauchen, um Dinge zu machen, die die Software nicht kann und wozu sie nicht gedacht oder gemacht ist, damit sie vermeiden können, sie erlernen zu müssen, das andere. ... und um den Datenaustausch mit den Kollegen zu vereinfachen, nehmen oft sogar Anwender, die es besser wissen, Software, die nicht zum Anwendungsfall paßt. > Joel Spolski ist dieser Darstellung nach die treibende Kraft bei der > Etablierung von VBA - Visual Basic for Applications. > > Falls Du diesen Artikel nicht kennst, einfach mal lesen, ich finde ihn > nicht nur informativ sondern auch unterhaltsam! > > https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/ Den Artikel habe ich vor so langer Zeit gelesen -- Danke für den Hinweis!Joel ist übrigens immer eine gute Quelle für den Bkick "von oben"... ;-)
Uwe G. schrieb: > Sheeva P. schrieb: >> Genau... wieviele Microsoft-Anwender braucht es, um eine Glühbirne zu >> wechseln? Keinen, Dunkelheit wird zum Standard erklärt... ;-) > > Wieviele Linux-Anwender sind nötig, um eine Glühbirne zu wechseln? > > Es gibt keine offizielle Distribution, die das standardmäßig kann, Ja, das stimmt, obwohl es bei den openbulb-Entwicklern entsprechende Tendenzen und sogar Prädispositionen geben soll. > aber > im Darknet wird kolportiert, dass es mit Linux möglich sein soll, wenn > man einarmigen Handstand macht und in dieser Haltung die klassische > Glühbirne bei eingeschaltetem Strom dauerhaft mit der bloßen Hand (keine > Handschuhe) in die Fassung presst. Absolut korrekt. (Aber, unter uns: das machen wir nur mit Windowstypen.) > ;-) ;-)
Hallo Sheeva Plug. Sheeva P. schrieb: >> Wieviele Linux-Anwender sind nötig, um eine Glühbirne zu wechseln? >> >> Es gibt keine offizielle Distribution, die das standardmäßig kann, > > Ja, das stimmt, obwohl es bei den openbulb-Entwicklern entsprechende > Tendenzen und sogar Prädispositionen geben soll. Da aktuelle LED Beleuchtung selten wechselbare Leuchtmittel hat, ist eine solche Entwicklung zunehmend obsolet. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
MWS schrieb: > Rolf M. schrieb: >> Kannst du bitte mal den Teil des Heise-Artikels zitieren, wo die >> Forscher als so wichtig bezeichnet werden und wo dieser Aufschrei nach >> Softwarefehler steht? Ich kann ihn dort beim besten Willen nicht finden. > > Überschrift: "Wegen Excel-Verhalten Gene umbenannt" Ja, ist doch eine neutrale Beschreibung. Genau das ist ja passiert: Gene wurden umbenannt, weil sich Excel so verhält, wie es das eben tut. > Da steht nicht: "Wissenschaftler dumm wie Toast" Das dagegen wäre keine neutrale Beschreibung, sondern eine Beleidigung einer ganzen Branche gleich in der Überschrift. Gut, dass du kein Journalist bist, offensichtlich wärst du als solcher "dumm wie Toast". MWS schrieb: > Du sagst: Den Arbeitsaufwand scheuen sie, importieren falsch, stellen in > Folge fest dass sie in Anzahl x Tabellen unbrauchbare Werte haben. Statt > dessen sie nun ihre eigene peinliche Blödheit korrigieren und zugeben, > dass sie monumentale Vollpfosten sind, beschweren sie sich lauthals bei > der Presse, Heise greift es in Folge auf und berichtet über den bösen > Softwarefehler. Nochmal: Ich sehe in dem Artikel nichts von einem "bösen Softwarefehler", und woher weißt du, dass sie sich "lauthals bei der Presse" beschwert haben? > Da muss man nicht spekulieren: die sind einfach DUMM. > Ansonsten wäre die Geschichte nicht passiert. Die sind halt ganz einfach keine Software-Experten, so wie du kein Experte für Journalismus bist. MWS schrieb: > Ein Wissenschaftler lernt dagegen seine Ergebnisse zu verifizieren, wenn > er das vergisst taugt er nichts. Ja, die Ergebnisse, die er produziert, aber nicht unbedingt, ob eine Software die Daten, die man ihr gibt, auch unverändert übernimmt oder erst noch manipuliert. Die Interpretation der Daten ist als eine Komfortfunktion gedacht, aber sie ist nicht unbedingt intuitiv. Und wenn ich eine Tabelle mit ein paar Tausend Zeilen importiere, ist es auch nicht gleich auf den ersten Blick zu erkennen, ob in Zeile 3725 ein Eintrag zum Datum uminterpretiert wurde.
Rolf M. schrieb: > Das dagegen wäre keine neutrale Beschreibung, sondern eine Beleidigung > einer ganzen Branche gleich in der Überschrift. Gut, dass du kein > Journalist bist, offensichtlich wärst du als solcher "dumm wie Toast". Dir ist schon klar, dass das provokativ überzeichnet von mir war, wie wohl die Überschrift des Heise-Artikel und die Threadüberschrift zu Gunsten der beteiligten Forscher ausgesprochen freundlich war. Nach dem Motto: so ein Forscher muss eine schlauer Mensch sein, da kann man doch nicht schreiben, dass er Fehler in der Auswahl des geeigneten Speicherformats gemacht hat. Also: Forscher bauchpinseln und Software verunglimpfen. > Nochmal: Ich sehe in dem Artikel nichts von einem "bösen > Softwarefehler" Was impliziert der geneigte Leser, wenn er liest "Wissenschaftliche Artikel von Excel verfälscht"? Als Redakteur muss/darf man nicht schreiben "Depp", aber man kann "Depp" so umschreiben, dass der Leser "Depp" versteht. > und woher weißt du, dass sie sich "lauthals bei der > Presse" beschwert haben? Weil der Bericht existiert und ich ihn lesen kann. Mit der geeigneten Sorgfalt seitens der Forscher und unter Einbeziehung von qualifizierten Softwerkern mit Excel-Erfahrung hätte es das Problem nie in die freie Welt geschafft, sondern wäre in einem Vormittag erledigt gewesen. > Die sind halt ganz einfach keine Software-Experten, so wie du kein > Experte für Journalismus bist. Wenn ich journalistisch tätig werden will, muss ich entweder lernen, oder ich muss mir jemand suchen, der's kann. Das sahen diese Forscher wohl anders, wie von mir schon angesprochen: "Lassen Sie mich durch, ich bin Forscher, ich kann alles". Tja, war wohl nichts. Wenn ich bereits als Nicht-Forscher um das Excel-Verhalten weiß, dann wäre die Erlangung dieses Wissens auch für diese Forscher einfach möglich gewesen, aus Überheblichkeit, Dummheit oder Selbstüberschätzung haben es diese Forscher schließlich verbockt. > Ja, die Ergebnisse, die er produziert, aber nicht unbedingt, ob eine > Software die Daten, die man ihr gibt, auch unverändert übernimmt oder > erst noch manipuliert. Wie auch schon erwähnt, so einem Forscher stehen Softwerker zur Hand, der Forscher muss nur den Auftrag raus geben, dass die Eignung von Excel, bzw. die Datenintegrität entsprechend der zu speichernden Daten überprüft wird. Haben sie nicht gemacht, waren zu dumm dafür. Was mich stört ist, dass die Verantwortung auf eine Software geschoben wird, statt dass sich die Forscher verantwortlich zeigen. Und dazu gehörte der Tenor des Heise-Artikels, der die Forscher bauchpinselt, bzw. nicht einmal auf die Idee kam, auf deren Verantwortung einzugehen.
MWS schrieb: > Yalu X. schrieb: >> Ich habe aber auch nirgends geschrieben, >> dass die Leute absichtlich Datensalat erzeugt haben. > > Doch, logischerweise hieraus hervorgehend: > > Yalu X. schrieb: >> Vermutlich kennen sie auch die genannten >> Workarounds für das Problem, scheuen aber den damit verbundenen stark >> erhöhten Arbeitsaufwand. Aha. Deine Logik bei der Interpretation von Prosatext scheint ja noch schräger zu sein als die von Excel bei der Interpretation von Gensymbolen :) >> lief die Sache meiner Meinung nach so (oder so ähnlich) ab: >> ... > > Deine Geschichte hört sich ja sowas von nett und harmlos an, ein Märchen > eben. Was hättest du lieber? Ein Geschichte von Verschwörung, dunklen Machenschaften, Mord und Totschlag? Ok, denk dir eine aus und geh damit auf die nächste Anti-Corona-Demo, da triffst du auf das richtige Publikum :) > Hat wohl mit der Realität wenig zu tun. In einem Punkt lag ich tatsächlich daneben: So groß sind die Dateien wohl doch nicht, deswegen ist auch nicht der immense Arbeitsaufwand beim Import der Grund für die Namensänderungen. Der wahre Grund: Diese Daten gehen durch viele Hände, teils als Excel- und teils als CSV-Datei, wobei jedesmal ein paar Einträge hinzugefügt werden. Die Gefahr, dass bei einer dieser Änderungen durch eine kleine Unaufmerksamkeit eines der Beteiligten die Formatierung verloren geht, wurde als zu groß angesehen: https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates Der Rest meiner – für deinen Geschmack zu harmlosen – Geschichte stimmt aber. Insbesondere ist – entgegen deiner Behauptung – die holprige Methode für den korrekten Import von CSV-Dateien in Excel bei den Genforschern schon länger bekannt. Das zeigt eine Videoanleitung, die vom HGNC bereits im März 2019 veröffentlicht wurde: https://www.youtube.com/watch?v=SppKiKIdCkI Also halte dich mit deinen Unterstellungen besser etwas zurück.
:
Bearbeitet durch Moderator
Dussel schrieb: > Was kommt als nächstes? Normen werden umgeschrieben, weil ein > CAD-Programm bestimmte Operationen nicht zuverlässig hinkriegt? War das nicht der Hintergrund, dass der Kreis um das Transistor-Symbol abgeschafft wurde, weil damalige CAD-Programme das nicht gut darstellen konnten, und die ersten Matrix-Drucker das verstümmelt haben?
MWS schrieb: > Dir ist schon klar, dass das provokativ überzeichnet von mir war, wie > wohl die Überschrift des Heise-Artikel und die Threadüberschrift zu > Gunsten der beteiligten Forscher ausgesprochen freundlich war. Ich weiß ja nicht, ob dir bewusst ist, wie überzogen deine Formulierungen hier ankommen. > Also: Forscher bauchpinseln und Software verunglimpfen. Wie schon gesagt: So was kann ich in dem Artikel nicht erkennen. > Was impliziert der geneigte Leser, wenn er liest "Wissenschaftliche > Artikel von Excel verfälscht"? Steht so nicht da. Das hast du da rein interpretiert. Was da steht ist, dass die Namen einiger Gene von Excel als Datumsangaben interpretiert wurden und diese Namen daher so geändert wurden, dass das nicht mehr passiert. Das sind einfach ganz nüchterne Fakten, ohne bauchpinseln und verunglimpfen. >> und woher weißt du, dass sie sich "lauthals bei der >> Presse" beschwert haben? > > Weil der Bericht existiert und ich ihn lesen kann. Du meinst, sie sind zur Presse gegangen, um sich über ein Feature von Excel zu beschweren? Nachdem sie das Problem eh schon umgangen haben? Ich halte das für sehr unwahrscheinlich. >> Die sind halt ganz einfach keine Software-Experten, so wie du kein >> Experte für Journalismus bist. > > Wenn ich journalistisch tätig werden will, muss ich entweder lernen, > oder ich muss mir jemand suchen, der's kann. Das sahen diese Forscher > wohl anders, wie von mir schon angesprochen: "Lassen Sie mich durch, ich > bin Forscher, ich kann alles". Ich habe eher den Eindruck, dass du von Forschern erwartest, dass sie alles wissen und perfekt sind - auch bei allen Dingen, die außerhalb ihres Themenbereichs liegen. Forscher = müssen perfekt sein = dürfen niemals und bei nichts Fehler machen. > Wenn ich bereits als Nicht-Forscher um das Excel-Verhalten weiß, Das meine ich. Deine Erwartung "Forscher = weiß alles auf der Welt" ist halt falsch. > dann wäre die Erlangung dieses Wissens auch für diese Forscher einfach > möglich gewesen, aus Überheblichkeit, Dummheit oder Selbstüberschätzung > haben es diese Forscher schließlich verbockt. Ich vermute, es war schlicht fehlende Erfahrung mit dem Tool. Man muss ja erst mal auf die Idee kommen, dass es so was machen könnte. Erst dann kann man einen Handlungsbedarf erkennen. Und jetzt wurde das als Problem erkannt, und man hat sich entschieden, es durch Umbenennung der Gene (was laut Artikel gar nicht mal so was ungewöhnliches ist) zu umgehen, damit nicht jeder weitere, der sich mit Excel noch nicht auskennt, in die gleiche Falle tappt.
Ich fürchte dieser thread wird keine weiteren Erkenntnisse bringen als - Excel wird gern als Tabellenwerkzeug gebraucht im Sinne eines Minimal DBMS - Die Importfunktion von Excel kann Daten verfälschen - Wissenschaftler haben dies erkannt und daraufhin ihre Vorgehensweise an ihre Umweltbedingungen angepasst, was dem einen oder anderen als trottelhaft erscheint - andere finden diese Bewertung zumindest überheblich - Konkurrenzprodukte weisen diese Eigenschaft in geringerem Umfang auf - niemand weiß, was die benannten Wissenschaftler überhaupt mit den Excel-Tabellen vorhatten ... Was kommt jetzt noch außer leerem Stroh?
Es ist halt ein Problem, wie man solche Verhaltenweisen öffentlich qualifiziert. unter welchen persönlichen Voraussetzungen und ob man das überhaupt macht oder machen darf, sollte etc. Es ist eigentlich kaum anzunehmen, dass die Gen-Forscher, der gewöhnliche Benutzer (also eher Nicht-Techniker oder Akademiker) oder die Entwickler bei Microsoft etc. hauptsächlich "dumm" oder "ignorant" sind. Es hat demnach keinen Sinn, sie pauschal so zu bezeichnen. Es eröffnet einfach keine vernünftige Handlungsalternative. Effektiv haben die Gen-Forscher ihre Entscheidung getroffen. Sie scheint mir rational, wenn auch für fragwürdig. Aber welche Entscheidung hat nicht auch ihre Kehrseiten? MS hat seine Entscheidung getroffen, die mit einiger Wahrscheinlichkeit von Erwägungen über den Markt geleitet war. Meine war, wenn möglich (nicht absolut) MS-Produkte zu vermeiden. Wohin soll uns das bringen, nun zu entscheiden, ob das als "dumm" oder mit sonst einem, im Grunde völlig obskuren, Begriff dieser Art bezeichnet werden kann? Wenn ich das so überlege, dann hat das doch nur den Effekt eine Gruppe zu diskreditieren, die versucht empirisches und rationales Wissen zu generieren. Das halte ich, in Bezug auf die Allgemeinheit, für destruktiv.
Rolf M. schrieb: >> Was impliziert der geneigte Leser, wenn er liest "Wissenschaftliche >> Artikel von Excel verfälscht"? > > Steht so nicht da. Doch, das steht tatsächlich etwa in der Mitte des Artikels, sogar in ziemlich großen Buchstaben. Natürlich ist diese Aussage etwas reißerisch formuliert. Aber genau deswegen sollte sie den Geschmack von MWS treffen, der ja nach eigener Aussage keine "harmlosen Geschichten" mag ;-) Außerdem ist die Aussage nicht falsch, denn in der Informationskette Autor -> Excel -> Veröffentlichung hat der Autor das Gensymbol "SEPT5" fehlerfrei eingegeben, in der Veröffentlichung stand aber "Sep-05". Also muss irgendwo dazwischen ein Fehler aufgetreten sein, und da die Informationskette nur aus drei Gliedern besteht, kommt dafür nur Excel in Frage. Man jetzt dem Autor vorwerfen, Excel nicht in Form einer manuellen Formatierung explizit darauf hingewiesen zu haben, dass es sich bei "SEPT5" nicht ein Datum, sondern einen Namen (also einen gewöhnlichen Text) handelt. Aber ist dieser Vorwurf gerechtfertigt? Das Ganze erinnert mich an eine Episode vor etwa einem Jahr, als ein Wissenschaftler der Frau Baerbock von den Grünen etwas von Cobalt im Zusammenhang mit Lithium-Akkus erzählte und diese daraus in einem späteren Interview einen Kobold machte. Wer war der Verursacher dieses Missgeschicks? - War es der Wissenschaftler, der es unterlassen hatte, Frau Baerbock bei dem Gespräch noch einmal nachdrücklich darauf hinzuweisen, dass er mit Cobalt wirklich das Metall und nicht den Hausgeist meint? Sollte man ihm deswegen vielleicht sogar das von MWS ins Spiel gebrachte Attribut "dumm wie Toast" angedeihen lassen, weil er nicht mit Politikern umgehen kann? - Oder war es Frau Baerbock, die schlecht zugehört hat und wegen des Fehlens von Cobalt in ihrem Wortschatz ohne rückzufragen einfach Cobalt in Kobold "autokorrigiert" hat? Wer sich für eine der beiden Alternativen entschieden hat, ersetze einfach den Akkuwissenschaftler durch den genforschenden Autor und Frau Baerbock durch Excel und hat damit sofort auch die Antwort auf die Frage gefunden, wer für den verfälschten Artikel verantwortlich ist :)
Yalu X. schrieb: > ersetze > einfach den Akkuwissenschaftler durch den genforschenden Autor und Frau > Baerbock durch Excel Frau Baerbock durch Excel zu ersetzen mag für den einen oder anderen eine reizvolle Idee sein, trotzdem ist dieser Vergleich nicht mal in der Lage zu hinken, denn ihm fehlen beide Beine. Dass ein Computerprogramm per se strunzdumm ist, das ist doch wohl konsensfähig, oder? Ein Mensch hingegen - pauschale Verunglimpfungen gegen Politiker bitte mal außen vor - ist normalerweise durchaus in der Lage, das eigene Tun zu reflektieren - und das kann so ein Computerprogramm nun mal nicht. Das ist ein Werkzeug, nicht weniger - aber auch nicht mehr. So wie ein Hammer (um mal bei hinkenden Vergleichen zu bleiben). Damit kann man sinnvolle Dinge tun, z.B. Nägel einschlagen. Man kann damit sinnlose Dinge zu tun versuchen, vielleicht die schmale Seite als Schraubendreher zu benutzen und dann darüber zu moppern, dass das Ding ja völlig falsch konstruiert ist. Und man kann sich damit auf den Daumen hauen. Daran ist dann der Hammer schuld, ja nee, is' klar. Natürlich sind diese einprogrammierten Eigenmächtigkeiten in Anwenderprogrammen einfach ärgerlich, das finde ich auch. Ich würde beispielsweise auch gerne mal mit der Maus ein halbes Wort markieren... Aber es sind Werkzeuge, und mit jedem Werkzeug muss man den Umgang erlernen. Beim Hammer ist das recht einfach. Beim Schraubendreher wird's schon interessanter (was ist das schon wieder für ein Kreuzschlitz??). Bei der Getriebedrehbank mit Hebeln und Rädern in einer Anzahl wie bei einer Dampflok wird's richtig interessant. So, und welche Komplexitätsstufe von Werkzeugen entspricht jetzt der einer Tabellenkalkulation mit hunderttausenden von Codezeilen?
Matthias L. schrieb: > Dass ein Computerprogramm per se strunzdumm ist, das ist doch wohl > konsensfähig, oder? Ein Mensch hingegen […] ist normalerweise > durchaus in der Lage, das eigene Tun zu reflektieren - und das kann so > ein Computerprogramm nun mal nicht. Dann sollte das stellvertretend für das Computerprogramm sein Schöpfer tun. Der ist aber nicht einmal bereit, kurz zu dem Problem Stellung zu nehmen, geschweige denn, über eine Änderung des Verhaltens nachzudenken. Das ist mir letztendlich aber auch egal, weil ich diesen Flickenteppich von Software sowieso nicht nutze.
Wieso verändert Excel den Zeileninhalt überhaupt? Ich meine, bei den Formeln bleibt diese ja auch als Eingabe bestehen, auch wenn im Feld das Ergebnis angezeigt wird. Wieso wird also ein erkanntes Datum normalisiert, wenn man es wie bei den Formeln einfach nur so in der Zelle Anzeigen könnte, während man den eigentlichen Wert der Zelle unangetastet lässt? Selbes beim Umformatieren. Und beim Rechnen könnte man ja einfach die Typen, die die Funktionen und Operatoren nehmen, eindeutig machen. +-*/ -> Zahl, Datumsmanipulationsfunktionen -> Datum, Textfunktionen => Text, Concat operator . -> Text. Es wäre so einfach. Beim Export, per Default einfach die Ursprungswerte ausgeben, aber die Rechenresultate statt die Formel nehmen, aber beides per checkbox umstellbar machen. Und schon hätte es die Ambiguität gar nicht erst gegeben. Daten und Formatierung zu trennen ist ja auch nichts neues, warum wurde das hier nicht gemacht? Und wieso musste LibreOffice Excel in der Hinsicht kopieren, die Exceller würden doch so oder so nie wechseln?
Matthias L. schrieb: > Dass ein Computerprogramm per se strunzdumm ist, das ist doch wohl > konsensfähig, oder? Ein Mensch hingegen - pauschale Verunglimpfungen > gegen Politiker bitte mal außen vor - ist normalerweise durchaus in der > Lage, das eigene Tun zu reflektieren - und das kann so ein > Computerprogramm nun mal nicht. Hmm. Eines meiner ersten Diktate, Jahrzehnte her, ent hielt das Wort "nullum". Die Schreibkraft verstand es nicht, sah aber davon ab, mich anzurufen und nachzufragen; das hätte ihre Zeit gekostet, und sie hatte noch andere Sachen liegen. Stattdessen schrieb sie "Nullnummer". War das strunzdumm? Zum Glück habe ich den Text vor der Unterzeichnung gründlich durchgelesen, dabei fiel der Fehler auf. Ich habe ihn handschriftlich korrigiert und das Typoskript zurückgegeben. In der Folgezeit habe ich schwierige Wörter beim Diktat buchstabiert, wenn sie nicht vermieden werden konnten. Der weitgehende Verzicht auf Fremdwörter hat bestimmt nicht geschadet. Mit der Zeit lernte ich, den Diktatstil an die Kompetenz der Schreibkraft anzupassen. Alles kam fehlerfrei getippt in der Mappe an. Eigentlich hätte ich auf das Korrekturlesen verzixhten können. Dann kam der Tag, an dem zu diktieren war, der Bewohner eines Hauses könne "nicht entsetzt werden". Seitdem wusste ich die Vorzüge von Stenotypistinnen gegenüber Phonotypistinnen zu schätzen. Ich bezweifele, dass irgend jemand eine Spezialschulung für Schreibkräfte fordert. Im medizinischen Bereich gibt es so etwas tatsächlich, aber auch sauteure Diktiersoftware. Soll heißen: nicht immer lässt sich die Problemlösung delegieren. Falls doch, ist das .mitunter nicht wirtschaftlich.
? DPA ? schrieb: > die > Exceller würden doch so oder so nie wechseln? Blödsinn. Man kann ganz ideologiefrei mit beiden Programmen arbeiten. Ich finde ja auch, dass ein Programm keine Veränderungen an den Eingangsdaten vornehmen dürfte ohne darauf hinzuweisen. Was aus einer Textdatei kommt, ist Text und fertig. Wenn der User etwas anderes haben möchte, dann muss er sich eben durch den Importfilter wühlen - wie bei jedem anderen Programm auch. Wäre irgendwie eingängiger. Nur - man KANN sich eben auch bei Excel gezielt bei jedem Import durch den Importfilter wühlen, man muss es nur TUN. Und wenn man das eben nicht tut, dann hat man an den Folgen zumindest eine Mitschuld. Ich bin ja weit entfernt davon, MS-Produkte in den Himmel heben zu wollen. Aber den Fehler NUR bei Excel zu suchen, das ist mir zu platt!
? DPA ? schrieb: > Wieso verändert Excel den Zeileninhalt überhaupt? Excel versteht sich als Tabellenkalkalationsprogramm für statistische, kaufmännische und ähnliche Anwendungen. Die eigentliche Aufgabe ist also mit dem Inhalt der Zellen mathematische Operationen durchzuführen. Mit Strings ist das nicht möglich, also wird versucht, die eingegebenen Daten zu interprätieren, sodass auf möglichst der ganzen Tabelle Rechenoperationen möglich sind. Der Inhalt, mit dem die Autokorrektur nichts anfangen kann, bleibt als string stehen. Es könnte als Bug bezeichnet werden, dass keine Warnung erscheint, wenn ein String nicht "korrigiert" werden kann. Bei manueller Eingabe der Daten ist das ein sekundäres Problem. Für alles Andere gibt es den Importassistenten. Zum verwalten von Strings ist ein Datenbankmanagementsystem das richtige Werkzeug. Viele Genetiker nutzen also ein ungeeignetes Werkzeug, dass erst umständlich überredet werden muss um seinen eigentlichen Einsatzzweck zu vergessen.
QQ schrieb: > ? DPA ? schrieb: >> Wieso verändert Excel den Zeileninhalt überhaupt? > > Excel versteht sich als Tabellenkalkalationsprogramm > für statistische, kaufmännische und ähnliche Anwendungen. > Die eigentliche Aufgabe ist also mit dem Inhalt der > Zellen mathematische Operationen durchzuführen. Genau. Und da "Fettdruck", "Unterstrichen" und "Kursiv" mathematische Grundoperationen sind, sind sie natürlich in der Werkzeugleiste von Excel enthalten. Alles klar.
Yalu X. schrieb: > Oder war es Frau Baerbock, die schlecht zugehört hat > und wegen des Fehlens von Cobalt in ihrem Wortschatz > ohne rückzufragen einfach Cobalt in Kobold > "autokorrigiert" hat? Von der Wortherkunft her ist das ja auch nicht ganz falsch. Trotzdem ist es kurios, dass Frau Baerbocks Vasen offenbar "koboldblau" sind und möglicher Krebs bei ihren Vorfahren mit der "Koboldkanone" behandelt worden sein soll.
Yalu X. schrieb: > Mal ganz ehrlich: Macht ihr euch tatsächlich immer die Mühe, die > Excel-Zellen vorzuformatieren, bevor ihr mit der Eingabe von Daten > beginnt? Natürlich. Jedenfalls immer dann, wenn ich es als Quasi-Datenbank verwende und nicht als Kalkulationsprogramm, wie es eigentlich mal gedacht war. Denn dann gelten einfach mal die Gesetze von Datenbanken: Lege erst die Felddefinitionen fest, dann lass' es Daten regnen... Simpler Sachverhalt, sollte auch (und gerade) für Wissenschaftler durchaus erfassbar sein...
Karl K. schrieb: > Was zum Henker hast du jetzt zum fünften Mal nicht verstanden an: Das > Problem tritt beim Importieren auf. > > Da hast du noch keine Spalten, die du formatieren kannst. Natürlich kannst du beim Importieren den Datentyp jeder Spalte festlegen. Du kannst es halt nur nicht tun, wenn du in nasenpopelnder Vollidiotie nur den Doppelklick auf eine *.csv-Datei beherrschst. Denn das ist kein kompetenter Datenimport, sondern "Rusissch Roulette". Man würde wünschen, auch die Konsequenzen wären ähnlich treffsicher wie bei Russisch-Roulette. Dann brächten wir uns schon sehr bald mit einem Sechstel dieser Idioten nicht mehr rumärgern. Und die anderen würden es früher oder später auch noch schaffen, das Endziel zu erreichen. ;o) Naja, manche (einige Wenige) würden vielleicht ja sogar lernen können, wie man Daten aus *.csv sinnvoll nach Excel importiert...
Egon D. schrieb: > Trotzdem ist es kurios, dass Frau Baerbocks Vasen offenbar > "koboldblau" sind und möglicher Krebs bei ihren Vorfahren > mit der "Koboldkanone" behandelt worden sein soll. Ach bitte, wieviele von der "E-Autos sind bösen wegen dem Kobalt, dafür müssen Kinder arbeiten"-Fraktion wissen denn, dass in den Zylinderköpfen, Kurbelwellen, Ventilstößeln und anderen hochbelasteten Stahlteilen ihrer Verbrenner seit Jahrzehnten Kobalt verwendet wird?
Rolf M. schrieb: >> Was impliziert der geneigte Leser, wenn er liest "Wissenschaftliche >> Artikel von Excel verfälscht"? > > Steht so nicht da. Das hast du da rein interpretiert. Steht im Heise-Artikel so ziemlich zentral in großer fettiger Schrift. Hast Du Dein Okular verlegt? ;-) > Ich habe eher den Eindruck, dass du von Forschern erwartest, dass sie > alles wissen und perfekt sind - auch bei allen Dingen, die außerhalb > ihres Themenbereichs liegen. Ich erwarte von einem Forscher, dass er weiß wo er sich auskennt und wo nicht. Wo er sich nicht auskennt, soll er Spezialisten machen lassen. > Ich vermute, es war schlicht fehlende Erfahrung mit dem Tool. Es war kollektive Selbstüberschätzung aka Dummheit. Mein Post dachte ich als Gegenpol für die flauschig gespülte Berichterstattung, die so etwas wie Eigenverantwortung des Forschers ignorierte und auch nicht forderte. Ein Leiden unserer Zeit. Und hier stand ja auch noch "Genforscher" dran, der Raketenwissenschaftler der Biomasse sozusagen, quasi eine Ehrfurcht gebietende Wesenheit auf Kohlenstoffbasis. Da darf natürlich nur die Software kritisiert werden und nicht das Toastbrot, das sie benutzt und die Feinheiten nicht kennt.
MWS schrieb: > Es war kollektive Selbstüberschätzung aka Dummheit. Zumindest kein Hinweis auf Megalomanie, bei diesen Leuten.
c-hater schrieb: > Du kannst es halt nur nicht tun, wenn du in nasenpopelnder > Vollidiotie nur den Doppelklick auf eine *.csv-Datei beherrschst. Es ist in Windows aber so vorgesehen, dass beim Doppelklicken auf eine nicht ausführbare Datei automatisch die zugehörige Standardanwendung mit der Datei als Argument gestartet wird. Daran hat sich der Windows-Nutzer gewöhnt, und meistens funktioniert das ja auch ganz gut. Wer aber bei Excel und CSV-Dateien ähnlichen Komfort erwartet, ist ein nasenpopelnder Vollidiot :D Normalerweise wird man beim Öffnen einer Textdatei von Excel ja automatisch durch den Import-Assistenten geleitet, sozusagen als Aufforderung, sich genau zu überlegen, wie man die Datei importieren möchte. Nur wenn diese Textdatei die Endung CSV hat, wir der Import-Assistent übersprungen. Gibt dafür eigentlich irgendeinen stichhaltigen Grund? Oder ist das auch wieder so ein als Feature deklarierter Bug mit Kröteneigenschaften?
Yalu X. schrieb: > Es ist in Windows aber so vorgesehen, dass beim Doppelklicken auf eine > nicht ausführbare Datei automatisch die zugehörige Standardanwendung mit > der Datei als Argument gestartet wird. Ich kenne noch aus alten Zeiten, dass der Benutzer Standardargumente und -optionen vorgeben konnte. Hier wäre an die Möglichkeitxder Unterdrückung des Autoimports zu denken sofern ein entsprechender Schalter existiert.
Yalu X. schrieb: > Es ist in Windows aber so vorgesehen, dass beim Doppelklicken auf eine > nicht ausführbare Datei automatisch die zugehörige Standardanwendung mit > der Datei als Argument gestartet wird. Das war früher(tm) so. Inzwischen hat Winzigweich hier deutlich aufgerüstet. Leider... Es kann nämlich auch ein Shell-Handler gestartet werden, der dann über das weitere Vorgehen entscheidet. DAS ist erst richtig übel. Z.B. langjährige VisualStudio-Nutzer die darauf angewiesen sind, mit verschiedenen Versionen davon zu arbeiten, werden verstehen, wovon ich rede... Es betrifft aber inzwischen praktisch jede nichttriviale Anwendung. Insbesondere auch für den Fall, dass für einen Datentyp mehrere Anwendungen zuständig sein könnten. > Daran hat sich der Windows-Nutzer > gewöhnt, und meistens funktioniert das ja auch ganz gut. Wer aber bei > Excel und CSV-Dateien ähnlichen Komfort erwartet, ist ein nasenpopelnder > Vollidiot :D Nunja es gibt da halt den feinen Unterschied zwischen "Datei öffnen" und "Daten importieren". Findet sich auch in UNZÄHLIGEN "Linux-Programmen", übrigens auch das Problem mit der Mehrfachzuständigkeit... Ich erspare es mir jetzt mal, Beispiele herauszusuchen. Ich bin überzeugt, deine Eigenintelligenz wird es dir erlauben, sie selber zu finden. Wenn du nur mal deine unsäglich großen Scheuklappen abstreifen könntest...
Karl K. schrieb: > Witzig, wie hier über die Inkompetenz der Forscher abgelästert wird - > aber ein passenderes Tool als Excel konnte auch keiner von den > Ekschbärden nennen. Wenn ich das richtig sehe, haben verschiedene Teilnehmer bereits auf LibreOffice verwiesen, das diese (und andere) Dinge wesentlich reibungsärmer macht. Dank seiner Lizenz und seiner Erweiterbarkeit löst es gleichzeitig auch das Problem, das Du in Deinem anderen Beitrag [1] ansprichst, daß nämlich für die richtige Lösung kein ausreichendes Budget für ein Upgrade einer kommerziellen Software vorhanden ist. Übrigens habe ich es auch schon erlebt, daß für ein Upgrade von MS Office gerade kein Geld vorhanden war und die Mitarbeiter eines Unternehmens zum Teil mit der neuesten, andere hingegen mit älteren Versionen arbeiten mußten -- was einerseits erhebliche Mehraufwände und Reibungsverluste nach sich zog und andererseits ein Hinweis darauf ist, daß man sich bei Kernkomponenten seiner Arbeit nicht von kommerziellen Softwarepaketen und dem Goodwill, der Gier oder der ökonomischen Lebensfähigkeit kommerzieller Softwarehersteller abhängig machen sollte. Sowas ist immer ein strategischer Fehler, auch wenn natürlich bei vielen Entscheidern immer noch gilt: "nobody ever got fired for buying IBM" (bzw. Microsoft). Andererseits hat auch Libreoffice das bedauerliche Problem mit der limitierten Zahl von Zeilen und Spalten, sogar noch schlimmer, da es statt Excels 65k Spalten derer leider lediglich 1k kann. Möglicherweise ließe sich das allerdings durch gepatchte, selbstübersetzte Pakete beheben, aber im Grunde genommen sehe ich meinen Standpunkt bestätigt, daß Tabellenkalkulationen nun einmal, grundsätzlich und prinzipbedingt, nicht zur Analyse und Visualisierung von Massendaten geeignet sind. Deswegen würde ich für diesen Anwendungsfall eine darauf spezialisierte OpenSource-Software empfehlen, zum Beispiel Orange [2]. Ironischerweise wird ebendiese Software ausgerechnet an einem Bioinformatiklabor der Universität Lubljana entwickelt... [1] Beitrag "Re: Wegen Excel-Verhalten Gene umbenannt" [2] https://orange.biolab.si/
Hallo Bernd, Bernd W. schrieb: > Sheeva P. schrieb: > >>> Wieviele Linux-Anwender sind nötig, um eine Glühbirne zu wechseln? >>> >>> Es gibt keine offizielle Distribution, die das standardmäßig kann, >> >> Ja, das stimmt, obwohl es bei den openbulb-Entwicklern entsprechende >> Tendenzen und sogar Prädispositionen geben soll. > > Da aktuelle LED Beleuchtung selten wechselbare Leuchtmittel hat, ist > eine solche Entwicklung zunehmend obsolet. Also ich verwende hier an verschiedenen Stellen LED-Leuchtmittel mit klassischen E27- und E14-Fassungen. Aber zumindest hier in Europa wird es wohl über kurz oder lang dazu kommen, daß wir unseren Kids den Witz erklären müssen -- ähnlich wie die Sache mit dem Raider und dem Wählscheibentelefon... Deswegen habe ich insgeheim schon eine aktuelle Version des Witzes entwickelt, bei dem "Glühbirne" durch "LED" ersetzt wird... aber pssst, das ist noch geheim! ;-)
Sheeva P. schrieb: > Deswegen habe ich insgeheim schon eine aktuelle > Version des Witzes entwickelt, bei dem "Glühbirne" durch "LED" ersetzt > wird... ... der auch nicht funktioniert: Ich hab hier in Bad, Küche, Arbeitszimmer... seit Jahren keine LED-Lampen mehr gewechselt.
Rolf M. schrieb: > Ähm, es geht hier darum, dass das bei Excel gerade nicht so ist. Es > interpretiert meine Eingabe und versucht, anhand irgendwelcher nicht > klar durchschaubarer Regeln zu erraten, welcher Typ der gewünschte sein > könnte. Das macht C nicht, hat es nie und wird es auch nie tun. Deshalb hat man C++ templates eingeführt und nennt das type deduction ;-)
Hallo Matthias L., Matthias L. schrieb: > Peter M. schrieb: >> In dem Moment, wo Du das Problem hast, müsstest Du mit dem >> Import-Assistent werkeln, die Zellen als String importieren und dann >> wieder irgendwie manuell oder mit VBA in eine Zahl wandeln. > > Ja, klar - genau dafür ist doch der Import-Assistent da!? wie oft würdest Du den Import-Assistenten bedienen, bevor Dir die wiederholten Schritte auf den Geist gehen? Wenn Du die Datei Excel bearbeitest, liegt es nahe, deren Layout so zu optimieren, dass sie ohne zusätzliche Eingriffe sofort lesbar ist. Diese Haltung entwickelt man natürlich auch nur dann, wenn man viel mit Excel arbeitet. > > CSV ist nun mal nicht das eigene Dateiformat von Excel. Des Systemfehler > besteht IMHO eher darin, dass bei der Installation von Excel die > dateiendung .CSV standardmäßig Excel zugewiesen wird, was damit häufig > Unfug anstellt. Das sehe ich anders. Der Versuch, die Eingaben des Nutzers zu interpretieren, geht in die Hose. > Wenn diese Verknüpfung nicht da wäre, würden viel mehr > Nutzer CSV-Dateien nicht einfach mit Exel öffnen wollen, sondern doch > eher nach einer Import-Möglichkeit suchen - und dann beim > Import-Assistenten landen, der falsche Dateninterpretationen zu > verhindern ermöglicht. Es geht um Effizienz und Optimierung. Natürlich kannst Du immer wieder diesen Assistent bedienen. Solche ermüdenden Wiederholungen sollte man aber auch denen überlassen, die so etwas nicht nervt! :) > Kann LibreOffice Calc solche Datumsdatenimporte ;-) von CSV eigentlich > ohne manuellen Eingriff? Das Trennzeichen musst Du bei LibreOffice Calc noch angeben. Aber mein altes LibreOffice 5.4 manipuliert die Daten nicht. Ich habe Dir eine Musterdatei angehängt. Bitte erst mit einem Editor angucken, dann mit Excel und dann mit LibreOffice öffnen.
es geht auch nicht nur um das importieren von Dateien auch beim copy&paste von Tabellen aus dem Webbrowser bekommt man oft die Krätze die amerikanischen Fliesskomma-Zahlen wie 1.2, 1.4, 1.11, 2.5 usw. mit dem Punkt statt dem Komma werden von Excel gnadenlos in Datumswerte umgewandelt Will man schnell mal was nachrechnen sitzt man erstmal die meiste zeit daran, die ganzen Zellen manuell nachzubearbeiten, denn Ersetzen von . durch geht nicht, ist ja ein Datumswert es geht also mehr Zeit dabei drauf, Microsofts "feature" zu berichtigen als für die drei Summen, Summenprodukte, Gruppensummen oder Durchschnitte die man eigentlich schnell berechnen will
Das kannst du in den Einstellungen ändern. Das ist das erste, was ich mache. Damit interpretiert Excel dann auch die cvs Datei von r2d3 richtig.
Computer dürfen eben Eingaben nicht ohne Zustimmung des Nutzers ändern. Das gilt für Programme genauso wie zum Beispiel für Suchmaschinen. Wenn ein Benutzer etwas eingibt und der Computer gibt ihm die Möglichkeit, die Eingaben mit wenigen Klicks anzupassen, freut sich der Benutzer. Wenn er aber etwas eingibt und der Computer ändert das einfach, ärgert sich der Benutzer oft zurecht, weil der Computer die Eingaben des Benutzers sabotiert.
Hallo @all,
ich bin mir nicht sicher, ob man den Heise Artikel ernst nehmen soll,
bzw. ob diese Nachricht nicht nur Schleichwerbung für Softwaremüll ist.
Wozu braucht man Excel, wenn alle Daten perfekt und jederzeit online
abrufbar sind (Beispiel "results.txt"):
* ja, ich weiß, es gibt unverbesserliche "Alles Download"-Fans. *
>
HGNC ID Status Approved symbol Approved name
HGNC:14668 Approved MMEL1 membrane metalloendopeptidase like 1
HGNC:9103 Approved PLXNB1 plexin B1
HGNC:10751 Approved SELENOP selenoprotein P
Wie zu sehen, ist das Fomat "Text und Tab".
Mit einer SQL-Zeile "LOAD DATA ..." in MySQL oder angepasst im Terminal,
bzw. als PHP- oder Shell-Script, ist die results.txt ohne Klimmzüge in
einer Datembank.
Das funzt mit *.CSV genauso.
Wiedermal viel Lärm um nichts :-)))
Gruss Claus
Peter M. schrieb: > diverse sinnlose Fragen Ich habe oben in mehreren Posts geschrieben, dass hier Fehler sowohl bei Excel zu suchen sind (v.a. dass der Anschein erweckt wird, man könne damit CSV-Dateien "ganz einfach schnell mal" öffnen) als auch bei dessen Anwendern, die erst ein nicht optimal geeignetes Werkzeug auswählen und dann damit nicht umgehen können oder wollen. Matthias L. schrieb: > Ich bin ja weit entfernt davon, MS-Produkte in den Himmel heben zu > wollen. Aber den Fehler NUR bei Excel zu suchen, das ist mir zu platt! Ich habe oft genug CSV-Dateien beim Wickel, dein Beispel ist daher (für mich) überflüssig...
Hallo Matthias L., Matthias L. schrieb: > als auch bei dessen > Anwendern, die erst ein nicht optimal geeignetes Werkzeug auswählen und > dann damit nicht umgehen können oder wollen. zu hause ist das alles kein Problem, wo man alle Freiheiten hat. Wer aber am Arbeitsplatz wie ich technischen Einschränkungen unterlegen ist, der muss halt mit dem leben, was da so vorhanden ist. Ich gehöre nicht zu den 0,1% Prozent der Mitarbeiter, die neben dem Firmenetz einen selbst administrierten Kinderspielplatz ihr eigen nennen, auf dem sie eigenverantwortlich installieren können, was sie wollen.
:
Bearbeitet durch User
Peter M. schrieb: > einen selbst administrierten Kinderspielplatz So kann man aber LibreOffice oder eine gute Datenbank nicht nennen. LibreOffice und Standard-Fragen hatten wir aber schon ganz gut an anderer Stelle diskutiert. In c't stand mal, dass sogar Intel sich angeboten hatte, Excel zu "optimieren". Wie genau funktioniert die angesprochene Behinderung am Arbeitsplatz ?
rbx schrieb: > In c't stand mal, dass sogar Intel sich angeboten hatte, Excel zu > "optimieren". War das irgendwann in den neunziger Jahren, als Excel aufgrund des fdiv-Bugs in Pentium-Prozessoren falsche Ergebnisse geliefert hat? :-) Gruß, Bernd
Peter M. schrieb: > Wer aber am Arbeitsplatz wie ich technischen Einschränkungen unterlegen > ist, der muss halt mit dem leben, was da so vorhanden ist. Ich glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den Wissenschaftlern an Softwarewerkzeugen ausschließlich Word und Excel zur Verfügung stehen. Evtl. darf nicht jeder nach Lust und Laune auf seinem PC heruminstallieren, aber eine freundliche Anfrage bei der IT-Abteilung sollte auch die Installation weiterer Software ermöglichen, wenn diese begründbar die tägliche Arbeit erleichtert.
Yalu X. schrieb: > ch glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den > Wissenschaftlern an Softwarewerkzeugen ausschließlich Word und Excel zur > Verfügung stehen. Natürlich nicht. Ohne PowerPoint ist eine seriöse Erkenntnisgewinnung heutzutage schlechterdings unmöglich. SCNR
Hallo rbx und Yalu X., rbx schrieb: > Peter M. schrieb: >> einen selbst administrierten Kinderspielplatz > > So kann man aber LibreOffice oder eine gute Datenbank nicht nennen. Bitte genau lesen, was ich geschrieben habe. Wer ein Datenblatt auswerten kann, sollte auch mit einem einfachem Text von mir zurecht kommen. Yalu X. schrieb: > Ich glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den Ich habe meine Aussage nie auf Forschungseinrichtungen beschränkt. Mitarbeitern an Forschungseinrichtungen unterstelle ich viele Freiheitsgrade. > Wissenschaftlern an Softwarewerkzeugen ausschließlich Word und Excel zur > Verfügung stehen. Evtl. darf nicht jeder nach Lust und Laune auf seinem > PC heruminstallieren, aber eine freundliche Anfrage bei der IT-Abteilung > sollte auch die Installation weiterer Software ermöglichen, wenn diese > begründbar die tägliche Arbeit erleichtert. Die meisten Excel-Installationen werden zu rein kaufmännischen Zwecken verwendet. Wenn man dann in die Situation kommt, mit großen CSV-Dateien arbeiten zu müssen, wird es lustig, besonders wenn einem nur ein Thin Client zur Verfügung steht. Da wird nicht auch mal eben ein R oder andere schicke Werkzeuge installiert - der Rechner ist komplett verrammelt. Freut Euch über Eure Freiheiten.
Percy N. schrieb: > Yalu X. schrieb: >> ch glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den >> Wissenschaftlern an Softwarewerkzeugen ausschließlich Word und Excel zur >> Verfügung stehen. > > Natürlich nicht. Ohne PowerPoint ist eine seriöse Erkenntnisgewinnung > heutzutage schlechterdings unmöglich. Mist, ja, die allerallerwichtigste Software für alle und jeden habe ich komplett vergessen. Mit Powerpoint kann man ja sogar Texte schreiben und Tabellen malen, so dass Word und Excel eigentlich obsolet sind :) Peter M. schrieb: > Yalu X. schrieb: >> Ich glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den > > Ich habe meine Aussage nie auf Forschungseinrichtungen beschränkt. Aber genau darum geht es in diesem Thread doch. > Mitarbeitern an Forschungseinrichtungen unterstelle ich viele > Freiheitsgrade. Du bekommst auch in den meisten Industriebetrieben problemlos die Software deiner Wünsche installiert, wenn du einige Mitstreiter findest, die diese Software ebenfalls nutzen wollen, und du den Verantwortlichen vorrechnest, um wieviel Prozent du damit die Entwicklungskosten und – noch wichtiger – die Time-to-Market reduzieren kannst.
Hallo Yalu X., Yalu X. schrieb: > Peter M. schrieb: >> Yalu X. schrieb: >>> Ich glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den >> >> Ich habe meine Aussage nie auf Forschungseinrichtungen beschränkt. > > Aber genau darum geht es in diesem Thread doch. Mir ging es zu einen um die Schnapsidee der Excel-Entwickler, Daten interpretieren zu wollen. LibreOffice macht das nicht. Zum anderen geht es um die Konsequenzen, wie im Artikel aufgezeigt. Wenn man nun in einer neueren Excel-Version dieses Verhalten ändern würde, dann würde es vermutlich ganz häufig zu Problemen führen, weil viele Anwender in Ihrem Code auf das fehlerhafte Verhalten reagiert haben. > >> Mitarbeitern an Forschungseinrichtungen unterstelle ich viele >> Freiheitsgrade. > > Du bekommst auch in den meisten Industriebetrieben problemlos die > Software deiner Wünsche installiert, wenn du einige Mitstreiter findest, > die diese Software ebenfalls nutzen wollen, und du den Verantwortlichen > vorrechnest, um wieviel Prozent du damit die Entwicklungskosten und – > noch wichtiger – die Time-to-Market reduzieren kannst. Leider arbeite ich nicht in einem Industriebetrieb.
Peter M. schrieb: > Bitte genau lesen, was ich geschrieben habe. > Wer ein Datenblatt auswerten kann, sollte auch mit einem einfachem Text > von mir zurecht kommen. Die 0,1 suggerieren Genauigkeit wo keine ist. Solche Zahlenspiele werden gerne missbräuchlich eingesetzt. Das Argument selber, nicht unnötig zu verallgemeinern (+ Genauigkeit vorzugaukeln) bleibt davon eher unabhängig. Der Thread hatte augenzwinkernd und begrüßenswert angefangen. Ich nutze Excel selber gar nicht, bei meiner Schulzeit kam das Programm nur am Rande vor. Deswegen hatte ich hier nur mitgelesen, und wäre gerne dabei geblieben. Ich wollte nur auf ein Sinken der Argumentationstiefe und der Betrachtungsgenauigkeit hinweisen - gerade, weil das im Moment so in Mode zu sein scheint. In anderen Forenbereichen wurde ich auch schon öfter korrigiert, wenn ich nicht genau bei der Sache war. Deswegen mag ich ja das Forum auch so. Man kann sich in den meisten Fällen auf die Hilfe bzw. eine ordentliche Diskussion oder eben eine nette technische "Schlacht" verlassen. Warum fand ich eigentlich den Thread begrüßenswert? So ein wenig auch deswegen: https://de.wikipedia.org/wiki/Priming_(Psychologie)
Bernd B. schrieb: > War das irgendwann in den neunziger Jahren, als Excel aufgrund des > fdiv-Bugs in Pentium-Prozessoren falsche Ergebnisse geliefert hat? :-) Nein, das war ein Artikel von 2003-2010 irgendwo dazwischen. Es ging ja u.a. auch um Vergleiche zwischen verschiedenen Tabellenkalkulationsprogrammmen. Generell drehte sich der Artikel eher um Microsoft Office Programme - und darum, dass Excel so langsam ist - Glaube ich. Ich muss bei Gelegenheit mal nachsehen, ob ich den Artikel wiederfinde.
Andere haben sich auch schon Gedanken gemacht: https://www.heise.de/ratgeber/Excel-CSV-Import-Dialog-erzwingen-4842956.html Leider auch keine zuverlässige automatische Lösung.
Percy N. schrieb: > Andere haben sich auch schon Gedanken gemacht: > > https://www.heise.de/ratgeber/Excel-CSV-Import-Dialog-erzwingen-4842956.html > > Leider auch keine zuverlässige automatische Lösung. Dabei könnte MS das Problem wahrscheinlich in einer Minute beheben. Der Code für die Unterscheidung der verschiedenen Dateiformate beim Öffnen einer Datei sieht vermutlich so (oder so ähnlich) aus:
1 | ...
|
2 | // handle native file formats
|
3 | if (!strcmp(extension, "xlsx")) |
4 | readXlsxFile(); |
5 | else if (!strcmp(extension, "xls")) |
6 | readXlsFile(); |
7 | // handle foreign file formats
|
8 | ...
|
9 | // handle text file formats
|
10 | else if (!strcmp(extension, "csv")) // please just remove |
11 | readTextFile(csvParams); // these two lines |
12 | else
|
13 | readTextFile(getParamsFromImportWizard()); |
14 | ...
|
Es müssten also nur die beiden kommentierten Zeilen gelöscht werden, und das Lesen von CSV-Dateien – egal ob über einen Doppelklick im Explorer oder das Datei-Öffnen-Menü – würde (unter Mithilfe des Benutzers im Import-Wizard) funktionieren. Nur weil die Programmierer bei MS dazu zu faul sind oder so sehr den Überblick über ihre Software verloren haben, dass sie die entsprechende Stelle nicht mehr finden, sind Millionen Nutzer täglich genervt, weil sie ihre CSV-Dateien umbenennen oder zu anderen üblen Tricks greifen müssen.
Yalu X. schrieb: > Nur weil die Programmierer bei MS dazu zu faul sind oder so sehr den > Überblick über ihre Software verloren haben, dass sie die entsprechende > Stelle nicht mehr finden, sind Millionen Nutzer täglich genervt, weil > sie ihre CSV-Dateien umbenennen oder zu anderen üblen Tricks greifen > müssen. Ich fürchte, der Grund ist hier nicht Faulheit: mit dieser Änderung, würde man das Verhalten der Konkurrenz (LibreOffice) übernehmen. Und Das geht ja überhaupt nicht.
Yalu X. schrieb: > Nur weil die Programmierer bei MS dazu zu faul sind oder so sehr den > Überblick über ihre Software verloren haben, dass sie die entsprechende > Stelle nicht mehr finden, sind Millionen Nutzer täglich genervt Starke Worte ohne Beleg. Ist das jetzt wieder Prosatext? Sagen wir mal so: Die meisten Nutzer kommen damit klar, bzw. begrüßen den Automatismus. Ist es gerechtfertigt, für die wenigen (Millionen/Tag, ja, ja, LOL) unzufriedenen Nutzer die Software zu ändern und gewünschte Funktionalitäten zu entfernen? Ich denke nicht. > sieht vermutlich so (oder so ähnlich) aus: Da geht's nicht darum, dass der MS-Programmierer nicht mehr wüsste, wo der Quelltext zum CSV-Import zu finden ist, sondern ob man Automatismen ändern möchte um den einen zu gefallen, aber sich dafür Beschwerden der anderen Nutzer einzuhandeln. Der Bericht ist doch nichts anderes als ein Sturm im Wasserglas, nur weil Forscher zu dumm, inkompetent, whatsoever waren, sich ein vernünftiges Format auszusuchen. Wenn diese Forscher schon ihre Ergebnisse (Daten) speichern wollten, warum nicht das natürliche Programm dafür nehmen? Nennt sich "Datenbank". Und eine Tabellenkalkulation nennt sich so, weil man damit rechnen kann/soll, deswegen nennt es sich nicht "Tabellenbank". Ist man MS-gebunden, dann kostet Access vielleicht zusätzlich. Wenn man ansonsten bloß Excel zur Verfügung hat, sicher ein Argument. Allerdings keines für Forscher, die ja immerhin das menschliche Genom entschlüsseln wollen. Wenn man sich die notwendigen Laborgeräte und Kosten dafür betrachtet, dann weine ich denen für diese Extrakosten eine Träne in meine Tränenvase. Ein paar Dollares extra um die Ergebnisse der sehr teuren Forschungsarbeit fehlerfrei abzulegen, sollten im Etat schon noch drin sein. Alles was für diese Forscher wichtig wäre, CSV, XLS importieren XLS exportieren kann Access. Mehr noch, beim Import von CSV wird kein Importassistent aufgerufen (zumindest so in meiner uralten Version), wenn man in eine bestehende Tabelle importiert, da dort die Formatierung bereits vorgegeben ist. D.h. eine leere Access-Tabelle kann als Template verwendet werden, um aus CSV entsprechend der gewünschten Zellformatierung zu importieren. Das leere Template kann für den nächsten Import kopiert werden. Als Zusammenfassung: Forscher schreien Zeter und Mordio (sonst gäb's den Heise-Artikel nicht), Grund dafür ist dass sie in ihrer Unbescheidenheit eine ungenügende Anwendung ohne vorherigen gründlichen Test missbraucht haben. Die richtige, bessere Anwendung dagegen wurde nicht benutzt. Ergo: selber schuld. Statt dass jetzt bei diesen Forschern wenigstens eine Minute kollektives Schämen angesagt ist, weil eben der verwendete Heuwagen nicht richtig zum Panzertransport taugte, wird der Fokus und die Schuld auf die Software geschoben. Wie ich bereits schrieb: das Leiden unserer Zeit ist der Mangel selbst Verantwortung zu übernehmen. Alles wird abgewälzt, jeder hat's gut gemacht, niemand ist schuld. Außer der andere, oder wie hier die böse Software halt.
MWS schrieb: > Da geht's nicht darum, dass der MS-Programmierer nicht mehr wüsste, wo > der Quelltext zum CSV-Import zu finden ist, sondern ob man Automatismen > ändern möchte um den einen zu gefallen, aber sich dafür Beschwerden der > anderen Nutzer einzuhandeln. Warum sollte es Beschwerden geben, wenn sich das Verhalten in den Einstellingen steuern könnte? Automatiken ind Assistenzfunktionen sind schön, wenn man sie braucht; wenn nicht, sind die nur nervig. Ich habe nichts gegen Bremskraftverstärker oder ABS, aber Kompetenzgerangel mit dem Spurhalteassi käme wahrscheinlich immer dann auf, wenn's denn gar nicht passt, ergo: abschaltbar oder überhaupt nicht. Tracking-Control meinethalben im Zusammenhang mit Automatikgetriebe; mit Schaltgetriebe fahre ich am Berg bei Glatteis im Zweifel sanfter an. > > Der Bericht ist doch nichts anderes als ein Sturm im Wasserglas, nur > weil Forscher zu dumm, inkompetent, whatsoever waren, sich ein > vernünftiges Format auszusuchen. Immerhin: Deine Hybris ist recht stabil! MWS schrieb: > Als Zusammenfassung: Forscher schreien Zeter und Mordio (sonst gäb's den > Heise-Artikel nicht), Grund dafür ist dass sie in ihrer Unbescheidenheit > eine ungenügende Anwendung ohne vorherigen gründlichen Test missbraucht > haben. Die richtige, bessere Anwendung dagegen wurde nicht benutzt. Eine sportliche Ansage, wenn man bedenkt dass Du nicht den blassesten Schimmer einer Ahnung hast, warum diese Leute diese Daten überhaupt in Excel einlesen wollten. MWS schrieb: > Wie ich bereits schrieb: das Leiden unserer Zeit ist der Mangel selbst > Verantwortung zu übernehmen. Alles wird abgewälzt, jeder hat's gut > gemacht, niemand ist schuld. Außer der andere, oder wie hier die böse > Software halt. Ein Hauptleiden unserer Zeit sind Maulhelden, die hinterher immer alles vorher besser gewusst haben, und das selbst dann, wenn sie immer noch nicht wissen, worum es überhaupt geht.
:
Bearbeitet durch User
Hallo Percy N., Percy N. schrieb: > Ein Hauptleiden unserer Zeit sind Maulhelden, die hinterher immer alles > vorher besser gewusst haben, und das selbst dann, wenn sie immer noch > nicht wissen, worum es überhaupt geht. Danke! Geschätzte 50% der Beiträge in diesem Faden handeln davon, dass andere schlichtweg doof sind. :) MWS schrieb: > Alles was für diese Forscher wichtig wäre, > CSV, XLS importieren > XLS exportieren > > kann Access. Vielleicht. Aber die Klientel, die von der MS-KI behindert wird, nutzt nicht Access. Und die möchte den Umweg über Access nicht gehen, wenn sie sowieso gleich in Excel rechnen muss.
Percy N. schrieb: > MWS schrieb: >> Die richtige, bessere Anwendung dagegen wurde nicht benutzt. > > Eine sportliche Ansage, wenn man bedenkt dass Du nicht den blassesten > Schimmer einer Ahnung hast, warum diese Leute diese Daten überhaupt in > Excel einlesen wollten. Zitat aus dem Heise-Artikel: "Laut einer Studie aus dem Jahr 2016 waren 20 Prozent der genetischen Daten, die zu fast 3600 geprüften und veröffentlichten Wissenschaftsartikeln verfügbar gemacht wurden, diesbezüglich fehlerhaft." Keine Behauptungen plappern, wenn Du den Artikel nicht gelesen hast. > Ein Hauptleidem underer Zeit sind Maulhelden, die hinterher immer alles > vorher besser gewusst haben, und das selbst dann, wenn sie nicht wissen, > worum es überhaupt geht. Beziehst Du das auf Dich? Mich kannst Du nicht gemeint haben, denn ich weise nur darauf hin, dass es in der Verantwortung der Forscher lag, das geeignete Speicherformat oder Programm zu verwenden. Die Forscher scheiterten daran. Klar stellt sich immer erst nach einem Un-/Vorfall die Frage, was falsch lief, selbstverständlich hätte ich und viele andere das besser gewusst. Und genauso selbstverständlich ist es notwendig darauf hinzuweisen, da a) der Heise-Artikel den falschen Tenor vertritt und b) diese Brezensalzer aus der Forschung sonst glauben, sie wären gar schlau oder gut beraten gewesen.
MWS schrieb: > Und genauso selbstverständlich ist es notwendig darauf hinzuweisen, da > a) der Heise-Artikel den falschen Tenor vertritt und b) diese > Brezensalzer aus der Forschung sonst glauben, sie wären gar schlau oder > gut beraten gewesen. Jetzt beschimpft der Microsoft-Most-Valued-Representative jetzt auch noch die eigene Klientel - das kann sich nur der Marktführer erlauben.
Peter M. schrieb: > Aber die Klientel, die von der MS-KI behindert wird, nutzt > nicht Access. Und die möchte den Umweg über Access nicht gehen, wenn sie > sowieso gleich in Excel rechnen muss. Da beneide ich Dich um Deine Kenntnisse, Du kennst die Bedürfnisse dieser Klientel scheinbar genau, sogar dass die damit tatsächlich gerechnet hätten. Also das, was man eigentlich mit einem Tabellenblatt täte. Und nicht das, was im Heise-Artikel beschrieben wird, nämlich zur Veröffentlichung, also Weitergabe in wissenschaftlichen Artikeln.
MWS schrieb: > Zitat aus dem Heise-Artikel: > "Laut einer Studie aus dem Jahr 2016 waren 20 Prozent der genetischen > Daten, die zu fast 3600 geprüften und veröffentlichten > Wissenschaftsartikeln verfügbar gemacht wurden, diesbezüglich > fehlerhaft." > > Keine Behauptungen plappern, wenn Du den Artikel nicht gelesen hast. Das besagt nur, dass dieses Problem ubiquitär in der Wissenschaft auftritt, was Deine Vorwürfe noch lächerlicher erscheinen lässt. Ein Widerspruch zu meiner Aussage ist hingegen nicht erkennbar.
Peter M. schrieb: > Jetzt beschimpft der Microsoft-Most-Valued-Representative jetzt auch > noch die eigene Klientel - das kann sich nur der Marktführer erlauben. Dann will ich Dir mal ein wenig von der dritten Dimension in Dein eingeschränktes zweidimensionales Weltbild bringen: Ich nutze Linux als auch Windows, ich nutze Excel und Open/Libre Office, Open Office auch unter Windows, ich schätze die bessere Konfigurierbarkeit von Open/Libre Office, genauso wie ich Excel schätze. Aber Forscher, die in einem 2020 Bericht zugeben, dass seit 2016 veröffentlichte Daten fehlerhaft waren, weil sie zu überheblich oder dumm waren, vor Konvertierung und Weitergabe der Daten einen Excel-Spezialisten zu konsultieren, die verdienen selbst den Titel "First Class Brezensalzer". Das ist doch nur noch peinlich.
Percy N. schrieb: > MWS schrieb: >> Zitat aus dem Heise-Artikel: >> "Laut einer Studie aus dem Jahr 2016 waren 20 Prozent der genetischen >> Daten, die zu fast 3600 geprüften und veröffentlichten >> Wissenschaftsartikeln verfügbar gemacht wurden, diesbezüglich >> fehlerhaft." >> >> Keine Behauptungen plappern, wenn Du den Artikel nicht gelesen hast. > > Das besagt nur, dass dieses Problem ubiquitär in der Wissenschaft > auftritt, was Deine Vorwürfe noch lächerlicher erscheinen lässt. Der Heise-Artikel besagt es für diesen speziellen Fall des Genomprojekts, im Artikel steht nichts von "ubiquitär" = "allgemein, überall verbreitet", halte Dich doch bitte von der Verwendung von Fremdwörtern fern, von denen Du keine Ahnung hast. Das war Dein Argument: Percy N. schrieb: > dass Du nicht den blassesten > Schimmer einer Ahnung hast, warum diese Leute diese Daten überhaupt in > Excel einlesen wollten. Dafür zitierte ich den Heise-Artikel und wenn Du lesen/verstehen könntest, dann wäre Dir speziell der Abschnitt "veröffentlichten Wissenschaftsartikeln" aufgefallen. Dafür wurden die Excel-Tabellen verwandt. > Ein Widerspruch zu meiner Aussage ist hingegen nicht erkennbar. Selbstverständlich ist Dir als Blinder nichts erkennbar.
MWS schrieb: > Dann will ich Dir mal ein wenig von der dritten Dimension in Dein > eingeschränktes zweidimensionales Weltbild bringen: Ich nutze Linux als > auch Windows, ich nutze Excel und Open/Libre Office, Open Office auch > unter Windows, ich schätze die bessere Konfigurierbarkeit von Open/Libre > Office, genauso wie ich Excel schätze. Wieder ein nicht registrierter Forist mit Leseschwäche - hat ich nicht weiter oben erklärt, dass ich mir am Arbeitsplatz nicht das µc-Optimum der versammelten µc-Checker zusammeninstallieren kann?! MWS schrieb: > Aber Forscher, die in einem 2020 Bericht zugeben, dass seit 2016 > veröffentlichte Daten fehlerhaft waren, weil sie zu überheblich oder > dumm waren, vor Konvertierung und Weitergabe der Daten einen > Excel-Spezialisten zu konsultieren, die verdienen selbst den Titel > "First Class Brezensalzer". > > Das ist doch nur noch peinlich. Natürlich ist die Überheblichkeit der µc-Superstecher peinlich. Salve, Guru! Excel, Libre Office, Open Office! Ich möchte denjenigen sehen, der seinem Chef sagt: "Ich möchte einen Excel-Spezialisten beauftragen, die CSV-Dateien in meine Excel-Arbeitsmappe zu importieren!" Irgendwie hängen auf µc zuviele Bewohner von Melmac herum, die sich mit den Gepflogenheiten auf diesem Planeten nich auskennen.
Sheeva P. schrieb: > Übrigens habe ich es auch schon erlebt, daß für ein Upgrade von MS > Office gerade kein Geld vorhanden war und die Mitarbeiter eines > Unternehmens zum Teil mit der neuesten, andere hingegen mit älteren > Versionen arbeiten mußten Mir kommen da glatt die Tränen... Wenn eine Firma nichtmal das Problem stemmen kann, jedem Mitarbeiter eine Lizenz für den Quasi-Standard der weltweiten Wirtschaftsbezieungen bereitzustellen, ist die Firma definitiv akut vom Untergang bedroht... > aber im Grunde genommen sehe ich meinen Standpunkt bestätigt, > daß Tabellenkalkulationen nun einmal, grundsätzlich und prinzipbedingt, > nicht zur Analyse und Visualisierung von Massendaten geeignet sind. Das sehe ich absolut genauso. Dafür sind Datenbanken zuständig. Und im Zusammenspiel mit Excel können die sogar ihre gesamte Power ausspielen. Übrigens unabhängig davon, wie sie konkret heißen... Excel kann mit fast allem, es muss nur einen ODBC oder OLE-DB-kompatiblen Treiber bereitstellen.
Ingo W. schrieb: > mit dieser Änderung, würde man das Verhalten der Konkurrenz (LibreOffice) > übernehmen. Stimmt, das würde ja mit der Jahrzehnte alten Tradition brechen, Dinge irgendwie ähnlich, aber anders zu machen als die anderen, nur damit sie eben anders sind.
Peter M. schrieb: > hat ich nicht > weiter oben erklärt, dass ich mir am Arbeitsplatz nicht das µc-Optimum > der versammelten µc-Checker zusammeninstallieren kann?! Doch, schon. Man KANN aber auch mit dem zwangsweise verordneten (und hier nicht geeigneten) Excel die Daten RICHTIG importieren - es ist allerdings lästig, keine Frage. Da muss man mit den Entscheidungsträgern in deren Sprache kommunizieren: Ich muss x mal täglich diese Daten importieren; wenn ich das richtig machen soll, dauert das jedes Mal y Minuten/Sekunden. Das Projekt läuft über z Monate, über die gesamte Laufzeit kostet der Importaufwand damit x y z Sekunden, das ergibt soundsoviele Arbeitsstunden und bei meinem Stundensatz soundsoviele Euro. Das Geld könnten Sie sparen, wenn ich a) die Dingsda-Software installiert bekomme, die kostet soundsoviel an Lizenzkosten und soundsoviel Supportaufwand (Das Ergebnis hier sollte deutlich niedriger sein als oben...) b) vom IT-Support ein angepasstes Import-Macro geschrieben und auf meinem Rechner freigegeben bekomme, das sollte mit soundsoviel Aufwand zu realisieren sein c) ... Wenn das nicht wirkt, sondern stattdessen die Ansage kommt: "Und wenns noch so lästig ist, Sie machen bitte so weiter wie bisher!", naja, dann wird Jammern im Forum die Situation auch nicht verbessern...
Peter M. schrieb: > Wieder ein nicht registrierter Forist mit Leseschwäche - hat ich nicht > weiter oben erklärt, dass ich mir am Arbeitsplatz nicht das µc-Optimum > der versammelten µc-Checker zusammeninstallieren kann?! Was hat die Registrierung damit zu tun, dass Du nicht diskutieren kannst? Geantwortet habe ich auf: Peter M. schrieb: > Jetzt beschimpft der Microsoft-Most-Valued-Representative jetzt auch > noch die eigene Klientel - das kann sich nur der Marktführer erlauben. Wie kommst Du auf die absurde Idee, dass ich mir vor einer Antwort auf diese Behauptung, Dein uninteressantes Geseiere von "weiter oben" durchzulesen habe? > weiter oben erklärt, dass ich mir am Arbeitsplatz nicht das µc-Optimum > der versammelten µc-Checker zusammeninstallieren kann?! Na, Du bist halt ein Knecht und ich ein Chef, ich kann installieren was ich will. Und so sieht's bei Genforschern auch aus, da gibts die Adminknechte und es gibt die Forscherscheffos, wenn der sagt: "Ohne diese Software XYZ kann ich meine Forschungsergebnisse nicht fehlerfrei verarbeiten", dann rennt der Knecht und macht den Forscher glücklich. > Natürlich ist die Überheblichkeit der µc-Superstecher peinlich. > Salve, Guru! Excel, Libre Office, Open Office! Keine Ahnung was das soll, ich habe Dir nicht geschrieben, dass Du ein kleiner Mann wärst. Wenn Du Dich so fühlst, dann ist das Dein Problem. > Ich möchte denjenigen sehen, der seinem Chef sagt: > "Ich möchte einen Excel-Spezialisten beauftragen, die CSV-Dateien in > meine Excel-Arbeitsmappe zu importieren!" Es kommt immer darauf an, was Dein Job verlangt, wenn Du der Büroknecht bist, der für so was eingestellt wurde, dann kommt das evtl. schlecht an. Dann sagst Du aber trotzdem Deinem Chef: "Sehen Sie selbst, ich bekomme hier die Fehler soundso und benötige deshalb Software XYZ", oder: "Sehen Sie, mit Software ABC benötige ich das fünffache an Zeit wie mit XYZ, ich könnte viel effektiver mit XYZ arbeiten." Ein Genforscher forscht dagegen Gene, der muss kein Excel forschen und kann problemlos andere fragen, bzw. beauftragen. > Irgendwie hängen auf µc zuviele Bewohner von Melmac herum, die sich mit > den Gepflogenheiten auf diesem Planeten nich auskennen. Nö, Du kannst nur nicht über Deinen Suppenteller hinaussehen und dieser Teller ist eh schon ein wenig klein.
Sheeva P. schrieb: > Genau... wieviele Microsoft-Anwender braucht es, um eine Glühbirne zu > wechseln? Keinen, Dunkelheit wird zum Standard erklärt... ;-) Deswegen wurde doch der Darkmode entwickelt. SCNR
:
Bearbeitet durch User
MWS schrieb: > Percy N. schrieb: >> MWS schrieb: >>> Zitat aus dem Heise-Artikel: >>> "Laut einer Studie aus dem Jahr 2016 waren 20 Prozent der genetischen >>> Daten, die zu fast 3600 geprüften und veröffentlichten >>> Wissenschaftsartikeln verfügbar gemacht wurden, diesbezüglich >>> fehlerhaft." >>> >>> Keine Behauptungen plappern, wenn Du den Artikel nicht gelesen hast. >> Das besagt nur, dass dieses Problem ubiquitär in der Wissenschaft >> auftritt, was Deine Vorwürfe noch lächerlicher erscheinen lässt. > > Der Heise-Artikel besagt es für diesen speziellen Fall des > Genomprojekts, Nix da, der spricht von 3.600 Veröffentlichungen. > im Artikel steht nichts von "ubiquitär" = "allgemein, > überall verbreitet", halte Dich doch bitte von der Verwendung von > Fremdwörtern fern, von denen Du keine Ahnung hast. > Lerne Du erst einmal Ubiquität erkennen, wenn Du ihr begegnest. Oder möchtest Du ernsthaft behaupten, die erwähnten 3.600 Veröffentlichungen stammten alle von dieser einen Forschergruppe? > Das war Dein Argument: > > Percy N. schrieb: >> dass Du nicht den blassesten >> Schimmer einer Ahnung hast, warum diese Leute diese Daten überhaupt in >> Excel einlesen wollten. > > Dafür zitierte ich den Heise-Artikel und wenn Du lesen/verstehen > könntest, dann wäre Dir speziell der Abschnitt "veröffentlichten > Wissenschaftsartikeln" aufgefallen. Dafür wurden die Excel-Tabellen > verwandt. Willst Du jetzt such noch behaupten, die hätten versucht, Excel als Layout-Programm zu verwenden? Was sonst soll der Hinweis auf "veröffentlicht"? Du hast schlicht keine Ahnung, was die Leute mit diesen Tabellen bezweckt haben, entblödest Dich aber nicht, zu behaupten, das ginge mit Access alles viel besser. > >> Ein Widerspruch zu meiner Aussage ist hingegen nicht erkennbar. > > Selbstverständlich ist Dir als Blinder nichts erkennbar. Oh, schon mit den Sachargumenten am Ende? Schlag doch gleich mal "ad hominem" nach, falls das Fremdwörterbuch noch griffbereit liegt, und berichte uns auch insoweit vom Ergebnis Deiner Ermittlungen. Vielleicht kannst Du ja auch das mit ein paar ausgesucht phantasielosen persönlichen Invektiven würzen, wer weiß? Besser wäre es allerdings, Du würdest diesen Thread mit Deinen Belanglisigkeiten verschonen.
MWS schrieb: > Und nicht das, was im Heise-Artikel beschrieben wird, nämlich zur > Veröffentlichung, also Weitergabe in wissenschaftlichen Artikeln. Ich kann es nur wuederholen: Percy N. schrieb: > Ein Hauptleiden unserer Zeit sind Maulhelden, die hinterher immer alles > vorher besser gewusst haben, und das selbst dann, wenn sie immer noch > nicht wissen, worum es überhaupt geht.
Percy N. schrieb: > Besser wäre es allerdings, Du würdest diesen Thread mit Deinen > Belanglisigkeiten verschonen. Chapeau! Du triffst den Kern...
Percy N. schrieb: > Lerne Du erst einmal Ubiquität erkennen, wenn Du ihr begegnest. Oder > möchtest Du ernsthaft behaupten, die erwähnten 3.600 Veröffentlichungen > stammten alle von dieser einen Forschergruppe? Ich schrieb nicht Forschergruppe, sondern "Genomprojekt": MWS schrieb: > Der Heise-Artikel besagt es für diesen speziellen Fall des > Genomprojekts, Lerne doch erst mal beim Lesen zu verstehen, bzw. nicht mit dem Ziel der Täuschung zu antworten. Vielleicht willst Du natürlich nicht täuschen, sondern Du verstehst nur "anders". Die haben also innerhalb ihres Projektes als Gruppe geschafft, einen fortgesetzten Fehler aufgrund Dummheit oder Überheblichkeit über einen längeren Zeitraum zu machen? Respekt, LOL. Percy N. schrieb: > Lerne Du erst einmal Ubiquität erkennen, wenn Du ihr begegnest. Soll ich jetzt schreiben: verwende eine Sprache, die Du verstehst? Wär' zu einfach, sagen wir mal so: wenn die Wissenschaft allgemein und nicht nur die Brezensalzer des Genomprojektes ihre wissenschaftlichen Erkenntnisse mit Excel verfälschen würden, dann würde "allgemein, überall verbreitet" zutreffen. Ist aber nicht so > Du hast schlicht keine Ahnung, was die Leute mit diesen Tabellen > bezweckt haben, Schrieb ich doch, verstehst Du nur nicht, scheinbar zu stumpf dafür. > entblödest Dich aber nicht, zu behaupten, das ginge mit > Access alles viel besser. Aber hallo und wieviel das besser geht. Ohne die Fehler, welche die Forscher produzierten. Das zu wissen empfinde ich sicher nicht als "entblöded". Bist Du u.U. auch so ein Brezensalzer, der in der Wissenschaft beschäftigt ist? Das entschuldigt Dich natürlich. Percy N. schrieb: > Oh, schon mit den Sachargumenten am Ende? Schlag doch gleich mal "ad > hominem" nach, falls das Fremdwörterbuch noch griffbereit liegt, und > berichte uns auch insoweit vom Ergebnis Deiner Ermittlungen. Du bist ein "Schwaller", Bericht genug?
Percy N. schrieb: > Invektiven > Belanglisigkeiten > wuederholen Nicht aufregen, nachher bleibt Dir noch was. ;D
MWS schrieb: >> Invektiven >> Belanglisigkeiten >> wuederholen > > Nicht aufregen, nachher bleibt Dir noch was. ;D Just 4 U: Small things please simple minds.
Percy N. schrieb: > Just 4 U: > Small things please simple minds. Musst Dich nicht mehr anstrengen, Du hast durch mehrfache Anwendung von Fremdwörtern, ausgewählter Ausdrucksweise und jetzt noch mit einem angelsächsischen Sprichwort dermaßen Eindruck gemacht, dass ich jetzt schon hin und weg bin. Solltest Du mir die nächste Antwort noch in gelungenem Ausdruckstanz vortanzen, dann kann ich nicht mehr. :-)
Peter M. schrieb: > Ich gehöre nicht zu den 0,1% Prozent der Mitarbeiter, die neben dem > Firmenetz einen selbst administrierten Kinderspielplatz ihr eigen > nennen, auf dem sie eigenverantwortlich installieren können, was sie > wollen. Das ist ja nicht schlimm, im Gegenteil: wenn Du jemanden hast, der Deine Büchse für Dich administriert, dann ist es natürlich seine Aufgabe, Dir eine arbeitsfähige und effiziente Umgebung zur Verfügung zu stellen. ;-)
Peter M. schrieb: > Yalu X. schrieb: >> Ich glaube nicht, dass es viele Forschungseinrichtungen gibt, wo den > > Ich habe meine Aussage nie auf Forschungseinrichtungen beschränkt. Darum geht es aber in diesem ganzen Thread. Oder arbeitest Du in der Genforschung, aber außerhalb einer Forschungseinrichtung? > Die meisten Excel-Installationen werden zu rein kaufmännischen Zwecken > verwendet. Es wäre schön, wenn das so wäre. > Wenn man dann in die Situation kommt, mit großen CSV-Dateien arbeiten zu > müssen, wird es lustig, besonders wenn einem nur ein Thin Client zur > Verfügung steht. Gerade bei Thin Clients ist es ja sogar noch einfacher, da installiert und pflegt Deine IT die benötigte Software auf dem Server und alles ist gut. > Da wird nicht auch mal eben ein R oder andere schicke Werkzeuge > installiert - der Rechner ist komplett verrammelt. Bei einem Thin Client gehört sich das ja auch so, weißt Du. Das ist ja die ganze Idee von Thin Clients (und neuerdings der Entwicklung von webbasierter Software), daß man die gesamte Software nur auf wenigen zentralen Systemen installieren und warten muß.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.