「ほかの表計算アプリケーション」とは？

質問

Excel(のバージョンが何であれ、昔から)のヘルプによれば、LOOKUP関数の形式には、ベクトル形式と配列形式の 2 種類があって、さらに次のような記述があります。
>通常は、配列形式の LOOKUP関数の代わりに、HLOOKUP関数(先頭行を検索)
>または VLOOKUP関数(先頭列を検索)を利用するようにしてください。配列
>形式の LOOKUP関数は、ほかの表計算アプリケーションとの互換性を維持
>するために用意されている関数です。
(Excel 2002 のヘルプより)
(添付図は Excel 2013 のヘルプより)

ここで言う「ほかの表計算アプリケーション」とは何のことですか？
ひょっとして Lotus 1-2-3 のことでしょうか？ご存知の方はいらっしゃいますか？

「ほかの表計算アプリケーションとの互換性を維持するために用意されている関数」と聞くと、私は DATEDIF関数を想起します。

配列形式の LOOKUP関数の使い方は[関数の挿入]メニューやヘルプにも載せてあるのに、 実用されている DATEDIF関数の使い方は何処にも登場しないのはなぜなのでしょうか？

回答No.4

chie65536（@chie65535） · ベストアンサー

＞なるほど、先発(?)の Lotus 1-2-3 との互換性ですね。

違います。「古いEXCELとの互換性」です。

簡単に言うと「EXCEL95からEXCEL97に乗り換えた人の互換性を保つ為」です。

＞Mac版 Excel で日付シリアル値の開始年を４年ずらしたときは 1-2-3 や Win版 Excel との互換を考慮しなかったのでしょうか？

https://support.microsoft.com/ja-jp/kb/214330/ja
に

初期の Macintosh コンピュータの設計により、1904 年 1 月 1 日より前の日付はサポートされていませんでした。

と書かれています。

4年ズラしたのは、Macの初期のOSで1900年がサポートされて居なかった事が原因の、苦肉の策だと思われます。

実は、Win版のEXCELは、ブックごと（XLSファイルごと）に「1900年をベースにするか、1904年をベースにするか設定が可能」になっていて、Mac版のXLSブックと互換性が取れるようになっています。

なお、1900ベースと1904ベースのファイルが混在すると、上記ページで解説しているような「メンドクサイ調整」が必要になって、大変な目に遭います。

お礼

いろいろ興味深い情報をいただき、心からお礼を申し上げます。
ありがとうございました。

回答No.3

chie65536（@chie65535）

＞【追記】バグに似たものとして、幻の閏(うるう)年問題がありますね。
＞1900年の２月は閏日(2月29日)が実在しなかったのに Win版 Excel ではウッカリ存在させています。

これは「ウッカリ」ではなく「互換性を保つための仕様」です。

実は、以下ページに「互換性を保つための仕様」と明記されています。

https://support.microsoft.com/ja-jp/kb/214019/ja

＞＞Excel 95 までのバージョンの Excel が日付データとして扱えるのは 1900 ～ 2078 年であるため、
＞＞うるう年に関する 100 および 400 の除外規則が適用される年は 1900 年だけです。ただし Excel
＞＞では、他のプログラムとの互換性のため、1900 年をうるう年として扱います。

なお、当方は「最初に作ったヤツが手抜きをしたため、その手抜きが、あとあとまで残る黒歴史になった」と考えています。

どういう事かと言うと、最初にEXCELを作った者が「1900年は過去の年だから使わないし、年は2078年までだから、単純に、４で割り切れたらうるう年にしよう」という手抜きをしたと考えられるのです。実際、1904～2078年の範囲は「４で割り切れたらうるう年」です。

そして、EXCELのバージョンアップで、年が2079年以降も扱えるようになった時点で「古いバージョンと計算結果が異なると、ユーザーがバージョン判定しないといけなくなるので、昔の「間違った仕様」をそのままにしたのです。

これも、DATEDIFと同じで「1900/1/1～1900/2/28の範囲の曜日が間違っているからと、間違った値を正しい値に調整している式」をユーザーが使っている場合、マイクロソフトが勝手に修正して直してしまうと「調整が入っている部分のせいで、値が狂ってしまう」と言う事が起きます。

確かに、EXCEL95とEXCEL97で結果が変わってしまったら、ユーザー側で「バージョン判定して式を変える」など、メンドクサイ処理が必要になってしまいます。

お礼

コメント、ありがとうございました。

》 これは「ウッカリ」ではなく「互換性を保つための仕様」です
なるほど、先発(?)の Lotus 1-2-3 との互換性ですね。
Mac版 Excel で日付シリアル値の開始年を４年ずらしたときは 1-2-3 や Win版 Excel との互換を考慮しなかったのでしょうか？

ちなみに、私は Mac を使わなくなって久しいので、Mac版 Excel でも DATEDIF関数が使えるかどうかの検証ができません。

回答No.2

mshr1962

>ひょっとして Lotus 1-2-3 のことでしょうか？
その通りです

>「ほかの表計算アプリケーションとの互換性を維持するために用意されている関数」と聞くと、
・隠し関数「DATESTRING」と「NUMBERSTRING」
http://www.offinet.com/news/entry_74202.html

>実用されている DATEDIF関数の使い方は何処にも登場しないのはなぜなのでしょうか？
他の方がすでに回答されてますけど、完全再現できなかったからですね。

お礼

コメント、ありがとうございました。

回答No.1

chie65536（@chie65535）

＞ここで言う「ほかの表計算アプリケーション」とは何のことですか？
＞ひょっとして Lotus 1-2-3 のことでしょうか？ご存知の方はいらっしゃいますか？

Lotus 1-2-3の事で合ってます。

他社製品なので、具体的な名称は、マイクロソフトのヘルプには書けません。

＞実用されている DATEDIF関数の使い方は何処にも登場しないのはなぜなのでしょうか？

DATEDIFもLotus 1-2-3に存在する関数ですが、EXCELのDATEDIFは、バグがあって特定の条件下で間違った値を返します（特定の条件化でLotus 1-2-3と異なる結果になります）

その為、マイクロソフトは「DATEDIFなど存在しない」と言う姿勢を取っています。

つまり「マイクロソフトは、DATEDIF関数の存在を認めていない」のです。

簡単に言うと「バグってるから、無かった事にした」のです。

なお、このバグは「新バージョンで返って来る結果を変えてしまうと、今まで使ってた人が困る」と言う理由から「修正されないまま放置」されています。

例えば「バグっていると判っていて、返って来る間違った値を正しい値に調整している式」をユーザーが使っている場合、マイクロソフトが勝手に修正して直してしまうと「調整が入っている部分のせいで、値が狂ってしまう」と言う事が起きます。

つまり「EXCELのバージョンによって、書く式を変えなきゃいけなくなってしまう」のです。

これでは「使う側が困る」ので「例え結果が間違っていたとしても、どのバージョンのEXCELでも同じ結果になる」と言うのが重視されたのです。

その結果「DATEDIFなど存在しない」って事になっちゃったのです。

お礼

》 その為、マイクロソフトは「DATEDIFなど存在しない」と言う姿勢を取っています
如何にもＭＳらしい、大変興味深い話でした。
Excel を使い始めて「バグがあって特定の条件下で間違った値を返」すと耳にしたことはありました。
でも、それは Lotus 1-2-3 でも同じだったのだろう（つまり、バグの責任は Lotus社に）と今まで信じておりました。パクっちゃったんだから、「ＭＳは問題として認識しております」なんてな紋切り型のバグ告白もできないのだろうと。
「バグってるから、無かった事にした」ですか、言い得て妙ですね。

コメント、誠にありがとうございました。

【追記】バグに似たものとして、幻の閏(うるう)年問題がありますね。
1900年の２月は閏日(2月29日)が実在しなかったのに Win版 Excel ではウッカリ存在させています。
ＭＳは、此れについても「ほかの表計算アプリケーションとの互換性を維持するために」と主張しているに違いない、なんて推察しております。
でもそのことには頬被りして、Mac版 Excel では日付シリアル値の開始年を４年ずらして 1904年としています。この４年が姑息な知恵の結果のように思えます。