遺伝学論文5本に1本、Microsoft Excelの自動書式エラーを含む
(science.org)- 遺伝学研究データがスプレッドシートで扱われる過程で、Excelの自動書式が遺伝子名を変更し、論文の誤りにつながっていた
- 主要な科学ジャーナルの遺伝学論文5本に1本で、この種のエラーが見つかり、データ検証プロセスの脆弱性が明らかになった
- 根本原因は、遺伝子名がExcelで日付や数値として自動変換され、入力値と保存値が異なってしまうことにある
- SEPT2 のように日付として解釈されうる略語は
2-SEPに変わり、2016年9月2日のような日付値として保存されることがある - Excelを使い続けるなら、列をテキスト形式に指定し、結果を目視で確認する必要があり、Google Sheetsは同じ自動変換エラーを避ける代替手段になりうる
Excelの自動書式が生んだ遺伝子名エラー
- Microsoft Excelの自動書式機能が遺伝学論文のデータに誤りを生み、新たな分析では主要な科学ジャーナルの遺伝学論文5本に1本にこの種のエラーが含まれていることが確認された
- 問題は、スプレッドシートが一部の遺伝子名を暦の日付や数値として解釈してしまうことで発生する
- 利用者は遺伝子名を入力したつもりでも、保存されたデータは別の値に変わってしまうことがある
代表的な事例
- Septin-2 という遺伝子は、一般に SEPT2 と略して書かれる
- Excelは SEPT2 を
2-SEPに変え、これを2016年9月2日の日付として保存することがある - このような変換は、論文に含まれる遺伝子リストや解析データの信頼性を損なう可能性がある
対応方法と代替案
- Excelを使い続ける場合は、該当列をテキスト形式に指定し、自動変換が起きていないか注意深く確認しなければならない
- Google Sheetsは遺伝子名を入力されたまま保存するため、同種の自動変換エラーを避ける代替手段になりうる
- 関連する分析は Genome Biology に掲載された
1件のコメント
Hacker Newsのコメント
Excelが科学的記数法のように見える文字列を数値に自動変換するのは本当に腹立たしい。オフにもできない。
大規模なデータのエクスポートに固有の位置コードのような値が入っていると、ある時点で一部が変に見えるようになり、単に表示が変わっただけではなく、セルの内容そのものがExcelによって勝手に書き換えられている。
何年たっても、こういう細かいが人をつまずかせ続ける問題を直さないのはあり得ない。Microsoftはたいてい「多くの顧客に影響するものだけに取り組む」と言うが、バグ報告を閉じ続ければ、毎回「1人にしか影響していない」と言ってまた閉じられる。
むしろ再現できないなら次のためにデバッグを追加するか、「要望者は少ないが、変更すると他の領域や後方互換性が壊れる可能性がある」といった追跡可能な理由を残す形で、きちんと扱うべきだ。
非技術系ユーザーが作った膨大なマクロ、VBAスクリプト、ワークフローが、こうした挙動に微妙に依存している。JavaScriptの奇妙な癖に似ていて、変えるとどこかの古いものが壊れる。
Microsoftはもっと直接的にそう言うこともできるだろうが、当然そういう議論は避けたいはずだ。
2020年8月の以前の人気スレッド: https://news.ycombinator.com/item?id=24070385
「科学者たちが、MS Excelが遺伝子名を日付と誤読しないようにヒト遺伝子名を変更した」という内容。
関連する詳細として、2023年にMicrosoftはExcelの遺伝子記号の日付変換問題を防ぐアップデートを出しており、Excelが誤認識した遺伝子名を自動で修正・更新するGene Updaterもある。
https://www.pcmag.com/news/microsoft-finally-fixes-excel-gli...
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9325790/
道具のことをきちんと理解すべきだ。こういうタイトルを見ると、世界のありようと発展を妨げる障害物に悲しくなり、最も怠惰なユーザーのためにあらゆる道具を設計する愚かさに腹が立ち、同時にプロプライエタリソフトウェアとそのユーザーたちの失敗が滑稽にも思える。
使っている道具がひどいことはあり得る。ならば、そのひどい道具を自分で扱うか、より良い道具を学ぶか、道具のエコシステムを探索して結果を出せる有能なコンピューター専門家を連れてくるべきだ。
結果検証の問題にはまだ触れてもいない。公的資金で運営される研究環境で、Microsoftに金を払いプロプライエタリな道具を使って失敗するというのは、苦い状況だ。
そのため、責任著者、編集者、ジャーナル職員など、連鎖のどこかにいる誰かがExcelでファイルを開いて再保存する。バイオインフォマティシャンがExcelで解析しているわけではない。
スプレッドシートを教育に使わなくなった理由の一つは、算術演算の優先順位バグをずっと引き継いできたため。この「バグ」とは、古くからの数学の慣習と矛盾するという意味
セルに
-3^2と入力して Enter を押すと、スプレッドシートは9だと言う。しかし数学では累乗が単項マイナスより優先されるため、-9になるべき。たとえば学生にy = -x^2のグラフを描けと言えば、下向きに開いた放物線を描くべき最新の Excel は確認できないが、Excel 97 ではそうだったし、現在の LibreOffice Calc も
9を返す。おそらく初期のスプレッドシートの一つが優先順位を誤って実装し、その後みんなが互換性のために追随したのだろう一方で maxima と Python はどちらも
-9を返す。数学書の数式をスプレッドシートにコピーする人たちも、この問題に引っかかっているのか気になる^の副産物のように見える。数学で指数は上付き文字なので、二項演算子ではなく項の一部コンピュータのテキストでは直接表現できないもののために二項演算子を作り出し、キャレットが一般的で最初に登場したが、
**も別の例伝統的に単項マイナスは項の一部と見なされるため、二項演算子より優先順位が高い。ところが指数を演算子に変えたうえでその論理を維持すると、話がこじれる
除算でも似た問題が見られる。
/は実際の除算記号がなかった環境で作られた二項演算子で、本来は分数の横線を表すべきもの。分数線は両側の式全体をまとめる役割を持つが、これを/に単純置換すると、優先順位規則の影響を受けて誤った結果になることがある-a*bは(-a)*bとしてパースされるが、c-a*bはc-(a*b)としてパースされる。単項マイナスは二項演算子より優先順位が高い通常は符号を移動できるので気づかないが、未定義動作に関わる境界ケースでは問題が起きる
0 - INT_MIN/2は0 - (INT_MIN / 2)としてパースされるので問題ないが、-INT_MIN/2は(-INT_MIN) / 2としてパースされるので問題がある。2 の補数表現の性質上、INT_MINには加法逆元が存在しない場合があるこの問題に二つの慣習があることは知っているので、望む動作を得るには単に括弧を使う
学生時代は数学が得意だったが、
-3^2が-9になるべきだと考える人がいるとは知らず、一部の電卓やプログラムの奇妙な特性だと思っていただけだった。この表現を声に出してどう読むのかも気になる。「負の 3 の二乗」と考えるなら(-3)^2が自然で、「3 の二乗の負数」と読んで初めて-9が正しい中学校のとき、電卓にこうした式を入力して期待と違う結果を見るよう教わり、それ以降は「括弧を使うべきだな」と思っただけ。少し異なる優先順位の慣習を好むからといって、電卓を捨てたり他人に使うなと言ったりするほどではない
-2^2=4だが0-2^2=-4になる。前者を、累乗より優先される単項-と見なすため技術的には正しいと主張できるかもしれないが、一般的な工学・科学のバックグラウンドで普通の作業をしようとする人にとっては、非常に直感に反する。このため多くの人が Nim を使わなくなる可能性もあると思う
POWER関数の省略形にすぎない。その観点では、数学的には間違っているかもしれないが、Excel の動作としては正しいと思うExcel の問題は、ほぼすべてを一つのソフトウェアツールでやろうとするところにある。フロントエンドの編集・表現、分析、意味モデリング、データストア・データベースまで
合理的なエンジニアの大半は、このアプローチには何かがおかしいと見る。しかし日常的なコンピュータユーザーの大半は、コンピューティングとは本来そういうものだと考えている
ときどき、自分でもなぜ特定の作業で自発的に Excel を開くのか不思議に思う。それでも、あらゆる批判にもかかわらず、Excel は自分にとってリンディ効果の閾値を超えており、これからも残り続けるだろう
https://en.wikipedia.org/wiki/Lindy_effect
多くの技術系スタートアップは「人々が Excel でやっていたことを専用ツールで置き換える」もの
構造化データと非構造化データの間の完璧なポイントを突いているので、ただセルを埋めて何が起きるかを見るのに向いている
「そうすべきではない」と言う理由は、うまく動いている解決策から、きちんと製品化されたコードベースのアプローチへ抜け出す道が非常に苦痛になり得るため
http://www.catb.org/jargon/html/Z/Zawinskis-Law.html
ドイツ語には「腕の悪い職人はいつも道具のせいにする」という言い回しがある
Excelには奇妙な点がたくさんあるが、数字を素早くまとめておきながら数式の入力値も変更できるという点では、今でもその存在に感謝している
少なくとも記事当時は、
SEPT2のような特定の文字列を日付に自動変換する機能をオフにする方法がなかった。これをオフにする設定さえあれば、深夜まで働いたり締め切りに追われたりする研究者たちが生んだ多くのエラーを防げたはずだツールの利用者が最善の使い方を学ぶ努力を払うべき場面があるのは確かだ。だが開発者側も努力すれば、よくあるエラーを防ぎ、ユーザーの時間を大きく節約できる
すべての道具ではない。古い業界標準や慣習のために強制された道具でもなければ、本来なら絶対に使わないような愚かな道具なのに選択肢がない場合でもない
Excelがスプレッドシートを発明したわけでもない。Excelがなくても、その時点の WhateverCalc の後継プログラムのようなものを使っていただろうし、Excelはそこに余計なものを足しただけだ
https://simple.wikipedia.org/wiki/Spreadsheet
いったいなぜ日付の自動認識をオフにできないのか？ 設定にチェックボックスを入れて、ユーザーである自分がExcelにそんな馬鹿げたことをしないよう指示できるようにすればいい
これを常にオンにしておくべきだと、反論不能な形で主張できる人がいるのだろうか？
デフォルト値は何なのか？ バージョンごとにデフォルト値が違うのか？ コンピュータやインストール環境が違っても、どう一貫性を保つのか？ その場でその機能が実際に必要になったらどうするのか？
CSVエクスポートを思い出す。Windowsは10年間使っていないが、小数の数値のエクスポート方式を変えるにはロケールを変えてコンピュータを再起動しなければならなかったことを覚えている。Excelの設定を1つ変えるためにそんなことをするのは正気ではない。チェックボックスのパッチをあちこちにばらまくのも、これと大きくは変わらない
https://insider.microsoft365.com/en-us/blog/control-data-con...
2週間前、職場で似たようなことがあった。ログファイルを取り込みながら、
HH:MM:SS.uuuuuuのタイムスタンプを別のツールが扱えるように、エポック以降のナノ秒に変換するawkスクリプトを書いたところが、
awkが内部的に数値に浮動小数点を使うことを知らず、変換関数が結果を誤って丸めてしまい、その後の分析を分かりにくい形で台無しにしたさらに悪いことに、Visidataでデータを眺めているときにも同じ問題が再発したが、正確には覚えていない簡単な回避策があった
職場では、Excelが異なるロケール形式のせいで数値入力を変えてしまう問題に何度も遭遇し、原因がExcelだと突き止めるまで何時間も失ったことが多い
住民登録番号や電話番号のような値も、Excelにとってはまったく扱いにくい型だ。遺伝子よりはるかに一般的な用途で、Excelの標準的なユースケースにより近いはずなのに、それでも壊してしまう
2024年になっても、CSVファイルを開くことはExcelではダブルクリックで終わる単純作業ではなく、過度に複雑な作業になっている。他のスプレッドシートプログラムはCSVファイルをずっと簡単に扱う
最悪なのは、Excelはたいてい非技術系ユーザーが使うため、こうした独特な挙動を誤解して時間が繰り返し浪費される点だ
ただし、たいていは自分が保護・ロック機能を十分うまく使っていないせいでもある。説明メモは無視されることも分かっている
そのため共有ファイルには、ほぼ必ず空の初期用バックアップを1つ置き、実際に使うファイルを別に置く形で少し緩和している
同じテーマの2016年の記事「Gene name errors are widespread in the scientific literature」も興味深い
https://genomebiology.biomedcentral.com/articles/10.1186/s13...
記事によると、Excelソフトウェアが遺伝子記号を誤って日付や浮動小数点数に変換してしまう問題は、2004年に初めて記述された。たとえば
SEPT2やMARCH1のような遺伝子記号が、デフォルトでそれぞれ2-Sep、1-Marに変換される