von Stephan » Mo, 15.02.2010 13:18
famo war schneller, aber ich hatte schon offline vorgeschrieben und kopiere das jetzt mal hier rein.
Der TEil der Formel:
"1/"&JAHR(A6+4-WOCHENTAG(A6;2))
liefert einen String (in Excel und OOo 3.2 und OOo 3.1.1). Dieser wird augenscheinlich in Excel und OOo 3.1.1 mit Toleranz auch als Wert akzeptiert, wohingegen in 3.2 augenscheinlich die explizite Wertumwandlung nötig ist.
Mithin funkioniert:
=KÜRZEN((A6-WOCHENTAG(A6;2)+11-WERT(("1/"&JAHR(A6+4-WOCHENTAG(A6;2)))))/7)
Ich habe jetzt nicht in den ReleaseNotes nachgesehen, aber es dürfte sich somit um eine Bereinigung der Funktion in 3.2 handeln.
Gewnerell treten solche Probleme gelegentlich auf weil Excel (frei gesprochen, denn ich habe nicht jeden Einzelfall im Kopf) im Allgemeinen versucht Werte/Texte/Konstrukte selbstständig zu interpretieren, wohingegen sich Calc genauer an das hält was der Nutzer tatsächlich hinschreibt.
Das Herangehen von Calc ist also meist formal richtiger (deshalb i.A. auch leichter herzuleiten auch wenn man das Programm noch nicht kennt), das Herangehen von Excel für den Nutzer häufig bequemer (setzt aber in manchen Situationen explizites Wissen um das Programmverhalten voraus).
Wie sich das Ganze zukünftig insgesamt entwickelt kann ich nicht sagen, Fakt ist jedoch das Calc bei Tabellenformeln/Funktionen sich seit Version 2.0 in sehr vielen Details (die meist nie im Fokus der Öffentlichkeit stehen) kompatibler zu Excel geworden ist, wobei ich leider keine generelle Richtungentscheidung kenne Calc (betreffs Formeln) völlig handhabungskompatibel zu Excel zu machen.
Das hier im Thread thematisierte Problem (DEine Formel) dürfte wohl ein Beispiel für weniger Kompatibilität sein (sofern ich den Kern der Ursache richtig herausgefunden habe), gleichzeitig bringt es aber eine Verbesserung im Hinblick auf konsistentes Verhalten von Calc.
Gruß
Stephan
famo war schneller, aber ich hatte schon offline vorgeschrieben und kopiere das jetzt mal hier rein.
Der TEil der Formel:
"1/"&JAHR(A6+4-WOCHENTAG(A6;2))
liefert einen String (in Excel und OOo 3.2 und OOo 3.1.1). Dieser wird augenscheinlich in Excel und OOo 3.1.1 mit Toleranz auch als Wert akzeptiert, wohingegen in 3.2 augenscheinlich die explizite Wertumwandlung nötig ist.
Mithin funkioniert:
=KÜRZEN((A6-WOCHENTAG(A6;2)+11-WERT(("1/"&JAHR(A6+4-WOCHENTAG(A6;2)))))/7)
Ich habe jetzt nicht in den ReleaseNotes nachgesehen, aber es dürfte sich somit um eine Bereinigung der Funktion in 3.2 handeln.
Gewnerell treten solche Probleme gelegentlich auf weil Excel (frei gesprochen, denn ich habe nicht jeden Einzelfall im Kopf) im Allgemeinen versucht Werte/Texte/Konstrukte selbstständig zu interpretieren, wohingegen sich Calc genauer an das hält was der Nutzer tatsächlich hinschreibt.
Das Herangehen von Calc ist also meist formal richtiger (deshalb i.A. auch leichter herzuleiten auch wenn man das Programm noch nicht kennt), das Herangehen von Excel für den Nutzer häufig bequemer (setzt aber in manchen Situationen explizites Wissen um das Programmverhalten voraus).
Wie sich das Ganze zukünftig insgesamt entwickelt kann ich nicht sagen, Fakt ist jedoch das Calc bei Tabellenformeln/Funktionen sich seit Version 2.0 in sehr vielen Details (die meist nie im Fokus der Öffentlichkeit stehen) kompatibler zu Excel geworden ist, wobei ich leider keine generelle Richtungentscheidung kenne Calc (betreffs Formeln) völlig handhabungskompatibel zu Excel zu machen.
Das hier im Thread thematisierte Problem (DEine Formel) dürfte wohl ein Beispiel für weniger Kompatibilität sein (sofern ich den Kern der Ursache richtig herausgefunden habe), gleichzeitig bringt es aber eine Verbesserung im Hinblick auf konsistentes Verhalten von Calc.
Gruß
Stephan