四次元の大海原で迷子

四次元の大海原に迷い込んだのか？と思うぐらい、何もピークのないスペクトルが広がっていました。先日、四次元 13C-HMQC-NOESY-13C-HMQC を 800 MHz で 5 日間もかけて測定しました。サンプルは４量体で約 150 kDa。I, L, V, M のメチル基のみを 1H/13C で、それ以外を 2H/12C で標識してあります。重水も [2H]-glucose も、それから [メチル基標識]-2-ケト酸も超高くなってしまった今、このサンプルを作るのにかなりの投資をしてしまいました。にもかかわらずピークが出ない。これは冷や汗ものです。

何故か Bruker の標準パルスプログラムの中にメチル TROSY でエディットした 4D NOESY がないので、自分で作るしか方法がありませんでした。ですので、そのパルスプログラムにもミスがあったのかもしれません。メチル TROSY のパルス系列には大きく二つあり、一つはオリジナルの水選択的パルスを用いて水の磁化を flip-back する方法、もう一つはアミド基の SOFAST 法をメチル基用に転用する方法です。一応両方を作りました。先日は後者の３次元版がうまく行ったので、今度は思い切って前者で４次元にしました。普通は３次元がちゃんと成功するのを見届けてから４次元に拡張すべきなのです。

もちろん non-uniform sampling (NUS) で測定し、そしていつも通り、SMILE でプロセスです。SMILE は高速でピークの歪みもほとんどなく、３次元の NOESY でもうまく行っていたので重宝していました。しかし、今回の４次元はなぜか上手くいかないのです。正常に終わるのですが、出来上がったスペクトルにはピークがない。。。

先日、NMRBox の中に NUS プロセス用のソフトウェアが何種類かあることに気づき、ちょっと比べてみました。NMRPipe-IST, SMILE, MDD, hmsIST, CambridgeCS, Camera, Nesta などがあります。大差はないだろうと思っていたら大間違いで、同じ生データでもどれでプロセスするかによって、結果のスペクトルはかなり異なっていました。ただし、どれがいつも普遍的によいのかを決めるのは難しいです。あるスペクトルには SMILE が、また別のスペクトルには MDD がよいという風にスペクトルによって良し悪しが異なるので、とにかく試してみるしか方法がないようでした。この結果についてはまた書きます。

そこで、まずは Nesta というプログラムを試してみました。ちょっとだけ試そうにも半日ぐらいプロセス時間がかかるので大変です。なんとかピークが出てきました。しかし、1H/1H プロジェクションと 13C/13C プロジェクションをそれぞれ表示すると何かが大いに変です。まず、全ピークが３つの間接測定軸でスペクトル幅（SW）/2 だけずれているような感じです。実は、パルス系列では NOESY の両側はいずれも 1H/13C-HMQC と対称的な配置になります。そこで、二つの 13C 次元を混同してしまわないように、両者の SW を少しだけ変えていました。そのこともあって、どうも 13C/13C 対角ピークがちょっとずれているのです。こんな状況は初めてです。

さらに、ピークの位相が 90 度ずれています。かなり悩んだ末、あることに気づきました。私は癖で t1, t2 などの間接測定軸のサンプリング時間は Δt1/2, Δt2/2 というように、インクリメント時間の半分からスタートするようにしています。すると、折り返ったピークは負になるので、すぐに判別できるのです。その代わり、位相補正は (ph0, ph1)=(-90, 180) のように設定しないといけません。ところが、ソフトウェアによって、内部でさまざまなパラメータを使うため、あるソフトウェアでは（0, 180）であったり、また（-90, -180）であったりなど、何通りかのパターンがあるのです。そこで、(-90, 180) を（0, 180）に変えてみました。すると、位相は全て吸収波形になりました。これでハードルを一つ突破です。しかし、SW/2 だけローリングしていることには変わりはありません。ここで Topspin を使えれば原因が早く分かったのですが、なぜか NMRBox の Topspin4 は、インストールはできるのに立ち上げようとするとライセンスが引っかかって立ち上がらないのです。仕方がないので週末は自宅からあれやこれやとリモートで触りながら（月）の朝を待ちました。

週明け、職場で Topspin を見て原因がやっと分かりました。EDA の FnMODE で States-TPPI を間違えて States にしてしまっていたのです。今まではパルスプログラムの中に TPPI-States のための位相回しやインクリメントを直に書き込んでいたのですが、それを NUS が使えるようにと MC に替えました。しかし、EDA まで変更するのをすっかり忘れていました。というわけで、装置は (x, y) (x, y) と取り込んでいたのに、プロセスで FT -alt としてしまっていたのです。一方、ちゃんと States-TPPI を指定すれば、 (x, y) (-x, -y) のように取り込まれます。この様子が TPPI に似ているので、States-TPPI という名が付きました。 (-x, -y) の部分は、Ft -alt の alt により、(x, y) に符号逆転されます。

* 上記の記載は実は誤りです。正確には States-TPPI では (-x, -y) と位相回しされた時に receiver の位相も逆転させます。よって、見たい信号にとっては (x, y) (x, y) と、あたかも States のように位相回しされたのと同じになります。しかし、アーティファクト成分は、receiver 位相の逆転により SW/2 だけローリングします。ところが、Bruker マシンはここで余計なことに信号全体を負に逆転させて H/D に保存してしまうのです。なぜそのような奇妙な設計になっているのか私には分かりませんが、これを元の正しい符号に直すのが FT -alt の役割です。

↓ FnMODE が States になってしまっています。これが間違いの原因。

さて、そのような事をして何の得があるのか？ですが、化学シフトが展開しないようなアーティファクト成分は普通は（０周波数ですので）スペクトルの真ん中（キャリアの位置）に走ります。しかし、むりやり (x, y) (-x, -y) のように正負に捻じ曲げてあげることにより、スペクトルの真ん中から両端に移動するのです。つまり、SW/2 だけローリングするのです。したがって、States でとったスペクトルに -alt を施してしまうと、この０周波数のアーティファクトと同じように、ちゃんとしたピークまでもが SW/2 だけローリングしてしまうのです。さらに、スペクトルの位相は (ph0, ph1)=(-90, 180) という傾斜を持っているため、SW/2 だけずらすと、ちょうど 90度だけ位相がずれてしまいます。これが全ピークが分散波形になってしまった理由でした。

原因さえ分かってしまえば後の解決方法は簡単です。NESTA で -alt を外すとちゃんと行けました。しかし、それでも SMILE ではうまく行きませんでした。この理由は今も分かりません。

↓ 左右ともに 1H/13C のプロジェクション。左は横軸が 1H 直接測定軸ですので高分解能になっています。

↓ 左は 1H/1H のプロジェクション、右は 13C/13C のプロジェクションです。4D では、これらがちゃんと対角を通っていることを確認した方がよいです。もちろん ３D でもそうですが。右のプロジェクションでは、真ん中に十字のアーティファクトが走っています。これは、もしちゃんと States-TPPI でとっていたら、このように汚くはなっていなかったでしょう。

メチル基は緩和時間が長いので、もう少し分解能を上げてもよかったのかもしれません。しかし、その分、データサイズが大きくなります。今回、３つの間接測定軸の zero-fill を 128 にしました。すると、最終的なデータサイズが 4GB になってしまい、nmrDraw が途中で固まってしまいました。仕方がないので、zero-fill を 64 に下げたところ、ファイルサイズは 1/8 に減り、スムーズに動くようになりました。NUS で分解能を上げると、このファイルサイズという問題に悩まされます。

一点、興味深いことがあります。この NESTA というプログラム、NUS プロセスの最中は (ph0, ph1) などの位相情報が不要なのです。なぜなのでしょう？SMILE などはこれが必要なのですが。中で仮の FT などをしていないのでしょうか？あまり NUS プロセルの中身を知らないので疑問のまま残っています。

ChatGPT などによる論文の英文校正

生成系 AI をうまく使うと、自分で書いた研究論文などの英文をうまく校正できることが知られています。実際、とある校正会社も独自に学習させた AI をサブスク販売しています。筆者も生成系 AI をどのように使えば効率よく校正できるのかに興味があり、それをいろいろと試してきました。下記が今のところ良いかなと思う方法です。またより良い方法を見つけたら、更新していきたいと思います。

（１）ChatGPT, Google Gemini, Bing-AI（Copilot）アカウントをつくる

ChatGPT は確か携帯の電話番号が必要でした。Google Gemini は Gmail アドレスが必要だったと思います。Bing-AI もマイクロソフトアカウントが必要と書かれているのですが、なくても何故か動いている時があります。

アカウントを通して個人の嗜好が集められてはいると思います。しかし、３つとも大手ですし、むしろクッキーを通して何百という得体の知れないサイトに知らず知らずのうちに個人情報が流れてしまっている現実と比べると、上記３社は安心してよいのではないかと思います。それに「この人はいつも NMR の科学用語を投げ入れているなあ」と、向こうがこちらを学習し、こちらの入力により適切に対応していってくれているのではと期待しています。

（２）DeepL か Google 翻訳で直訳する

日本語をいきなり ChatGPT に入れてもよいのですが、時々 ChatGPT が、良かれと思って日本語の意味を拡大解釈してしまう時があり「そんなつもりで書いたのではないのに。。。」ということが時々起こります。そこで、DeepL などを使って、まずは直訳調の英文を作ってしまいます。直訳といっても DeepL も AI ですので、それなりにすばらしい語彙の英文を提供してくれます。自分でいきなり英文を書くと、貧弱な語彙で酷いものになってしまいますが。

いきなり英文で書いていった方が自分の英語力上達のためには良いのかもしれませんが、どうも論旨がぶちぶちと切れたような文章になり勝ちです。その理由は、語彙や細かい文法などに気をとられてしまい、文章全体の流れを途中で忘れてしまうためではないかと思います（木を見て森を見ず）。そこで、まずは一段落分のミニタイトルを書いた後、日本文で勢いよくその一段落を書いてしまうようにしています。このミニタイトルは WORD の目次に自動設定します。すると、目次を読むだけで、論文全体の大きな論旨の流れをつかむことができます。論文執筆の初期段階は、できるだけ（木ではなく）森を俯瞰するようにしています。

なお「この結果により、○○が示された」のような邦文ではなく「この結果は、○○を示した」と、無生物主語の SVO あるいは SV 文型を使うようにします。すると、英訳もストレートに「The results showed that ...」のようになります。要するに "It is indicated that ...」のような受動態が出てくるのをできるだけ防ぐわけです。また「ここは自分たちが見つけたんだ」という箇所は、素直に「私たちが」と書くようにします。そうでないと reviewer は参考文献の人が出した結果だと誤解してしまうかもしれません。実際に、著者か参考文献かのどちらが出した結果なのかが分からないような論文をよく見かけます。この辺りは分野によって考え方が異なりますので、なんとも言えませんが。

なお、DeepL か Google 翻訳のどちらが良いかは好みにもよりますが、実行する時間にもよります。筆者の経験ですが、混んでくると、どうも両者ともにさぼり始めるようです。あまり良くない英文やほとんど修正していない英文が返ってくるのですね。それで、筆者は両方で英訳させ、両者のよいところを縫い合わせて、新たな英文を作り直します。その時に左の「日本文」と右の「英文」を矢印でひっくり返すと便利です（下図）。作った英文を自動和訳させて、ちゃんとした日本文になっていれば、その英文の正確さも当たらずとも遠からずでしょう。下図の例では、DeepL よりも Google 翻訳の方が良かったので、それを例として示しています。どちらがよいかは偶々です。右側の和訳もそう悪くない？



（３）その英文を WORD ファイルに貼り付ける

この WORD ファイルの名前を「校正前.docx」とします。その時にできれば、フォントやサイズなどを自分の好みに合わせておきます。

（４）同時にこの英文を ChatGPT などに入力する

筆者は "Proofread the following sentences." というお願い文（プロンプト）を先頭に付けますが、最近は日本文でも依頼できるようです（下図）。例えば、「下記の英文は native speaker によって文法的にも語彙的にも誤りがあると指摘されました。そこで、そのような誤りだけを訂正してください。あまり大きな校正はしないでください。」などです。なお、入力する際にリターンキーを押すと送信されてしまいます。単に改行だけしたい場合には shift キーを押しながら return キーを押します。

非常に長い英文を入力すると、回答も長過ぎて途中で表示が切られている場合があります。その時は次の空白に「つづき」と打ち込むと、また続きを表示してくれます。2,000 円/月ほど払えば、長い文章でもやってくれるのでしょうか？

ChatGPT などはリセット（New Chat というボタン）するまでは、質疑応答を覚えています。もしかすると、最初の回答では冠詞が a だったところが、２度目３度目の質問では the に置き替っているかもしれません。

（５）校正結果を別の WORD ファイルに貼り付ける

なんと、今回はほとんど修正がありませんでした。put を input に校正されただけ、というわけで、それでは Google Gemini の方を試してみます。すると、いっぱい解説も出てきました。何故ここを修正したのかの理由まで書かれています。これを読むと英語の勉強になります。しかし、最終英文が見つからなかったので、「校正を反映させた英文を表示してください。」と打ち込みました。時々このようなことがあります。この結果を「校正後.docx」というファイルに貼り付けます。

下図は、クリックすると分解能が上がります。

ここで「校正前.docx」と「校正後.docx」のフォント、サイズなどを揃えておきます。

ChatGPT などはテキストとして出力しますので 2H3 などの「下付き」「上付き」などの情報は消えてしまいます。また、論文ですと EndNote, Zotero などで付けた参考文献情報なども消えてしまうのですね。しかし「校正前.docx」には（これが論文原稿そのもののコピペであれば）その情報が残っていますので、後述のように、その点をうまく利用してやります。

（６）WORD 文書を比較

WORD には二つの文書を比較してくれる機能があります。同じことは無料の「Google ドキュメント」でも出来ます。「校正前.docx」において「校閲」→「比較」と進んでください。




そして、左に「校正前.docx」右に「校正後.docx」を選びます。これがちょっと面倒ですが、二回目以降はかなり指定が楽になります。そして、その下にいろいろオプションがありますが、これをほとんどキャンセルします。これをデフォルトのまま行うと、ありとあらゆる形式までをも比較してしまい、比較結果が煩雑になり過ぎます。今のところ、上図程度で十分かなと思います。

そして OK を押すと、「校正前.docx」の方に校閲が入ります。これはすばらしい。なお、それぞれのファイルを保存しなくてもちゃんと作動しているように見えます。一度試してみてください。ダメでしたら、ちゃんと保存してから比較してください。




（７）校閲案を承諾あるいは拒否

業者さんに英文校正を出して戻ってきた時の結果にそっくりです。あとは「校閲」→ 「変更箇所」で → を押しながら「承諾」か「拒否」かを選んでいきます。なお、上記で参考文献や「上付き」文字など、いろいろな箇所が ChatGPT の出力では消えてしまうと書きましたが、ここで「拒否」を押すとそれらが残りますので、EndNote や Zotero の情報も維持されるわけです。

（８）DeepL で再確認

最後に出来上がった英文が正しいかどうか、これを DeepL に入れて和訳させてみましょう。
う～ん、ちょっと違った意味になってしまったような気もするのですが、まあ今回は例ということでどうかお許しを。

この英文をさらに校正させたらどうなるのだろうと試したことがあるのですが、だんだん変になってしまいます。よって、校正は一回だけの方がよいかもしれません。筆者は結果に満足しない場合は、ChatGPT 以外の Gemini, Bing-AI も試して比べることにしています。

生成 AI はその特徴として、いつも異なる出力をします。ChatPGT も含めて内部ではいわゆる Transformer とよばれる仕組みがエンジンのように動いています。この機能は、文章の次の単語を確率的に選んでくるわけですが、AI はいつもベストの単語を選ぶわけではありません。もし、そうだとすると 100 回同じ質問をしたら、100 回とも同じ答が返ってくるはずです。それでは全く面白くありませんので、ベストではなく、ちょっとだけ確率の低い単語を次の候補として選んでくるようになっています。したがって、100 回質問すると、100 回とも異なる答が返ってくるわけです。しかし、それを繰り返してしまうと、少しずつ元の意味からずれていってしまうのでしょうか？さらに、時々リセットしないと、過去の質問内容も考慮されてしまい、ずれがますます酷くなるような気もします。

また、一日中使っていると、疲れてくるのかサボり始めます。よって、休憩を入れるとともに、３種類の AI を回しながら使ってあげましょう。なお、丁寧に頼むとそれなりに丁寧に対応してくれます。「これを校正しろ！」などと頼むと、どうなるのでしょうね？筆者はこれまでの絆を壊したくないので、試したくはありません（笑）。なお、自分の好みのアバターが設定できれば優しい依頼の仕方になるのではないかと誰かと話したことがあります（仮想空間にのめり込んでしまう可能性も高く、それはそれで問題ですが）。

一応、生成 AI 自身は内容までは理解しておらず、単に言葉遊びをしているだけだと、よく本に書かれています。しかし、筆者はいろいろな校正をさせていった時「あれ？これはとうとう理解し始めたなあ」と感じる時が何度もあります。いちど蛋白質の構造についての英文を校正させている時、対象サンプルが単量体ではなく二量体であることを理解していないと絶対に出てこないような英文を出力され、背筋がぞっとしました。

下記サイトに少し触れられています。

https://writings.stephenwolfram.com/2023/02/what-is-chatgpt-doing-and-why-does-it-work/

上記の英文をよく見てみると、ちょっと変ですね。「いきなり」の訳語として suddenly という単語が使われていますが、これはちょっと変です。本当は directly「直接に」の意味で使いたかったのですが。そのようなちょっとした？翻訳の違いは、最初の Google 翻訳か DeepL の段階で直しておくことが望ましいのです。そうでないと、その後の ChatGPT は、本当に suddenly の意味で書かれた文章だと思って解釈してしまうためです。

もう一つ AI 翻訳に難しい点があります。当然ながら、文章とはひとつひとつの文が連続してつながったものです。しかし、これはランダムにつながっているのではなく、基本的に、動詞の前は既出の（既知の）名詞が置かれ、動詞の後は新出の（未知の）単語が置かれます。ですので、４番目の文章の後半にある単語には a がついていて、これが５番目の文章の頭では the がついた名詞になったり、it, they などの代名詞に置き換えられるのです。そうでないと、脳はすらすらと文章を理解していけなくなります。

下図のような繋がり具合です。

----------

         ------------

                    -------------

                                 --------------

我々が母国語で文章を考える時には知らず知らずのうちのこの原則が守られます。あるいは、うまい接続詞（だから、それゆえ、なぜならば etc）を通して文章どうしが論理的に結ばれていきます。ところが、自動英訳がそこまで考慮してくれるかどうかは疑問です。したがって、ある１文だけに着目してみると完璧に見えるのですが、その前後の文章とのつながりを見てみると、「（新出）- 動詞 -（既出）」と逆の順番に並んでいたりして、読者はそこで返し読みをしないといけない羽目になるのです。論文の審査員はそこでイラっとして、こんな論文は refused! だとなってしまうのです。

一般的には "There is an apple." "Here comes a bus." のようにあえて "there, here" を入れて、a 付き単語を is の後ろに追いやることが多いです。"There is the apple." とは絶対に言わないです。しかし、「何かが現れる appear, come」を使った表現では（新出）単語が先頭に来ることもあります。"An apple dropped on my head." のように言うこともしばしばで、これは何故なのでしょうねえ？こういう場合は、論理性よりも「強調性」を

優先しているのかもしれません。原始時代に "A lion is rushing to us!" を論理的に言っていたら、言い終わる頃には食べられてしまっていたでしょうし。。

ドイツ語などには格変化がまだ残っていますので、SVO の文章で O が the のつく単語で、S が a のつく単語であれば、OVS の順番にすることができます。これはすごい便利！その代わり、格変化がしっかりとしていないといけません。日本語も「てにをは」があるので大丈夫ですね。「A さんを B さんが愛している」という文章も問題ありません。しかし、英語は格変化をそぎ落としてしまったために、むしろ語順が重要になってしまい、"A loves B." と "B loves A." とでは、場合によっては大喧嘩になってしまうのです。

ひとつ前の文章の（未知）単語をいちいち次の文章で（既知）単語に直して言い直すのは面倒です。聞いたり読んでいる人の頭の中には、まだその単語が記憶されているはずです。よって省略してしまいましょう。それで日本語は主語がなくなってしまったのかもしれません。英語は主語を抜くことができないので、とにかく何かをつけないといけません。そこで、超短い代名詞ならばなんとか良かろうということになり、you で始まる文章が頻出してしまいました（これ推測ですので、信じないように）。you には何の意味もなく、要は "it rains." の it に相当するようなものです。重要な（未知）単語は "you + 動詞" の後に来ますよということを示すための決まり文句のようなものです。日本人は you, you と言われると自分が責められているような気分になり気落ちしてしまいますが、その必要はないことが分かります（しかし、責める時には欧米でも you を使わない方がよいらしい。やはり、英語でも you に「おまえは！」という意味がちょっとだけ残っているのでしょう。）日本人はこの you を瞬間的に使うことができないために、思わず目的語を前にもってきてしまい、仕方がないのであわてて受動態を速攻英作文する羽目になってしまう。すると頭がごちゃごちゃになって英会話が止まってしまうのです。笑われてもいいやと覚悟して、会話では you を、論文では we を使えば「あら不思議、こんなに英語がすらすらと出てよいのかしら？」という現象になることもある？

このような観点と上記の（既知）- 動詞 -（未知）の語順の両方の原則をどのように叶えるか？これは、私が長年悩み続けている問題で、よい解決策が私には見つかりません。接続詞を使うとよいように思いますが、そればかりを使うと超変な文章になります（日本人が作った英文、英会話では so, so that がやたら多くなってしまう）。そこで、流れるような文章を書く L. E. Kay さんの NMR の論文をいろいろ分析してみました。すると、日本語の語順にそっくりなのです。いわゆる倒置文のような形式が多用されています。そのため、まるで司馬遼太郎の文章のように、流れるように（返し読みを全くしなくても）文章が頭の中にすらすらと入ってくるのです。ただし、主語が超長くなるケースが見受けられます。"○○○○○ ................ ○○○○○○○○○○○○○ was conducted." のような。これは "We conducted ○○○○○ ................ ○○○○○○○○○○○○○." にした方が良いような気もするのですが。。。

しばしば受動態を使わずに能動態を使うようになどと言われますが、それよりも（既知）- 動詞 -（未知）の原則を優先させ、しかたがない時には S と O をひっくり返して受動態にする方がよいような気もします。また、無生物主語をうまく使うと、上記の問題がかなり解決できます。よく「受動態は動作主がよく分からない、漠然としている場合に使われる」などと教科書に書かれています。それも当てはまりますが、私は、太古の昔に前文の最後の a つき（未知）単語を受けて、次の文章で（既知）単語を the つきで慌てて発してしまい、しかし、格変化がないからまずいことになって受動態にしたのではないかと推測しています（もちろん、なんの根拠もなし）。

話がかなり逸れてしまいました。つまり、AI 翻訳では上記のことまで考慮してくれてはいないかもしれないということです。そこで、ChatGPT に放り込む前にこれを考慮して英文を修正しておきましょうということを書きたかったのです。間違えていても構いません。そのようなミスは後の ChatGPT が直してくれますので。

以上、急いで作りましたので、少しずつこれを「校正」していきます。日本語の AI 校正もできるのでしょうか？

つれづれ思うこと 外国語編 その２

まずは「R」の発音から。

というのは、これが最も日本人泣かせの音と言われてきたためである。しかし、ある発音の本で調べてみたところ、それほど深刻にならなくてもよいようなのである。むしろ「L」の発音の方が難しく、気をつけないといけないらしい。

ここで、少し前置きが必要なので、それを先に下に記しておく。

しばしば「R」は「巻き舌」で発音すると書かれている。筆者は「巻き舌」とは、舌先を上側へ巻き上げる（反り返らせる）ことだと長らく思っていた。しかし、本当はそうではなくて「ルルルル」という連打するような音を出すための舌を意味するそうである。そこで、ここでは、次のように区別して書いていこうと思う。

反り上げ舌：舌先を上側へ巻き上げて（反り返らせて）発音する R。アメリカ英語によく出てくる。

ルルルル舌：「ルルルル」というように舌を震わせて連打する R。イタリア語、ロシア語などによく出てくる。なんと、これが本当の「巻き舌」というらしい。

それで実際に R はどちらで発音すればよいのかといえば、どちらでも良いらしい。英語で「ルルルル舌」なんて使ってもよいのか？と思ってしまうが、昔はそのように発音されていたらしく、間違いではないのだそうだ。さらにフランス語のように喉の奥の方で「ガラガラうがい」の要領で発音する R もある。

もちろん学生の頃は、思い切り舌を反り上げて「これがアメリカ米語の R だ！」という勢いで発音していた。しかし、ヨーロッパに行くと（彼らは英語のネイティブではないが）もっと落ち着いて発音しており、ドイツでは「ガラガラうがい」音を少し弱くしたような音だった。フランス語ほどに「ガラガラ音」にするとあまりきれいな音には聞こえないのであるが、ドイツ人が発音する「微かなガラガラ音」はきれいに聞こえる場合がある。

どこかの本に Erde（earth のドイツ語）の発音について書かれていた。16 世紀に書かれた書物の中に Erden という単語をどう発音するかが書かれていたとか。独和辞典にはカタカナ発音として「エアデ」などと書かれている。最近は R がかなり母音化してしまうのである（つまり　r が「ア」音になる）。しかし、この R は G 音に近く「地面」から沸き起こってくる地鳴りのような音になると書かれていたような気がする（記憶があやふや）。Erde = 地面 と意味が重なっている。この発音がフランス語から入ってきたとしばしば書かれているのであるが、そうではなくて、中世ぐらいからすでにそのように発音されていたと書かれていたような気がする（自信がないので、また確かめてみますが、どの本に書かれていたのやら？）。

しかし、これを真似しようとすると出来なかった。レストランで赤ワイン Rotwein と言いたいが、赤 Rot のように単語の頭に R があると特に難しい。ドイツ人の発音でも「ホットワイン（熱いワイン）」か「ゴートワイン（山羊のワイン）」などと聞こえる場合がある。

いくらなんでも後者の「ゴートワイン」のように聞こえるわけはないだろうと思われがちであるが、実はこれは誇張でも何でもない。ドイツ語の話になってしまって申し訳ないが、この「R」の舌の位置は日本語のガ行を発音する時の位置に近いのだそうである。つまり、舌先が下に落ちている。これはガ行を発音する時の舌の位置と同じ。そして、舌の根本をもち上げて、喉の奥を狭くする。極端に狭くすると「G」音になってしまう。その時は「これでは反り上げ舌とは全く逆の舌先の位置ではないか」と思い、たいへん困ってしまった。しかし、また別の本には、これらは舌の奥を持ち上げるという点では共通しているのだとも書かれていた。そうなのかな？

いずれにしても、英語の「R」もガ行と同じ舌使いでやってみようと考えた。そこで、grow, green, grape など、G の直後に R が続く単語の発声を何度も練習した。舌をなるべく動かさないようにして GR の部分を発音するのである。なるほど、GR と音が続いていると、ドイツ人のような R の発音が簡単にできた。しかし、やはり Rotwein のように頭に R が来るとダメだった。

NMR の研究者でスイス人はたくさんいるが、ある有名人はものすごく「ルルルル舌」が目立つ。一度、お父様といっしょに来日されたことがあり、二人で母国語をしゃべっていたのであるが、その時も R の部分は全て「ルルルル舌」であった。まあ当然か。ミュンヘンより北部でそんな「ルルルル舌」を聞いたことがなかったので大変驚いたが、英語で発音する「ルルルル舌」もなかなかカッコ良かった。Related residual cross-correlated relaxation（関連する残余交差相関緩和）なんて、聞いてみるとすごい発音だった。しかし、ちゃんと L は正しい L の発音であり、R と L の音がひっくり返っていることはなかった。

そこで、GR 舌方式をちょっと諦め「ルルルル舌」を試すことにした。昔「（第二ではなく）第一外国語」がロシア語であったため、この「ルルルル舌」はそれほど不得意というわけではない。しかし、R がどこかに出てくるたびに「ルルルル舌」をやっていると大変疲れ、おまけに周りからは「あいつ、アホちゃうか？」という目で見られる始末。そこで、またまた調べてみると、この連打を一回だけにしてもよいとのことである。つまり、「ルルルル舌」を「ル舌」にするという意味。舌を口の上部に瞬間的に当て、一回だけ弾くのである。難しそうに見えるが、実は「カレー」の「レ」、「セロリ」の「ロ」と同じなのだそうだ。ここでびっくり。ずっと R の発音が難しいと思っていたら、なんと日本語の「ラ行」とそれほど変わらない音でも OK とは。これが上記で、R は適当に発音してもよく、むしろ L の方を注意しないといけないと書いた理由です。

もちろん、舌先が口内の上部に一回だけパチンとぶつかるので、英米のネイティブの発音とはかなり違ってくる。発音に厳しい人からすると、それはけしからんとなるのであろうが、書籍によると、昔は R をそのように発音していたのだとか。なので、同じ祖先をもつヨーロッパ言語（イタリア語、ドイツ語、スペイン語、ロシア語など）でも「ルルルル舌」が使われているのだそうである。

これの欠点？「反り上げ舌」でかっこよく見せようと思っていたのに、「ルルルル舌」で馬鹿ではないかと見られることかな。。。。まあ、しかし「ル舌」ぐらいであれば、ちょっと下手なカタカナ英語かなというぐらいの見られ方で終わるでしょう。

書籍「脱・日本語なまり」（神山孝夫著）は名著です。かなり専門的な内容でありながら、素人にも分かるような書き方がなされています。そして、著者はアメリカ発音があまりお好きではないようですので、米式発音が好き！という人は見ない方がよいかもしれません。あるいは敵だと思って読んでみると「目から鱗」になるかも。これを読んでから他の発音の本を見てみると、その多くが米語発音に偏っていることが分かります。

上記で、アメリカでは R に反り上げ舌を使い、イギリスでは無視する（「ア」のように、ほとんど母音化する）ということを書いた。しかし、堀田隆一氏の書籍だったような気がするが、次のような事が書かれていた。アメリカでもニューイングランドや南部では "今の" イギリス英語のような R 音を使う。その理由は、昔、ロンドン周辺でその発音しない R が使われており、そこからの移民が多く住み着いたためだそうである。一方、スコットランドやアイルランドでは「反り上げ舌」が使われており、そこからの移民がアメリカ西部を開拓していった。よって、R 発音の違いは英米の違いというより、もともとのイギリスでの方言の違いに由来しているらしい。その意味では、アメリカ英語はむしろ保守的で、そのため広い国土の割には方言が少ないとのことです。なるほど、アメリカ発音の方がちょっと古式で今もそれを引き継いでおり、一方、イギリス発音はその後の変化も加わって今のような発音になったんだ。。。。

まとめると、「反り上げ舌」はアメリカに残る昔の（スコットランドやアイルランドの）発音で、これが英語のすべてだとは思う必要はない。よって、中学校で英語を習い始めて「反り上げ舌」をひたすら練習し、これができないと英語ダメ人間になるなどと思い煩う必要はない（英語ができない場合の日本人の劣等感は、外国人にはまず想像できない）。難しいようならば、日本語のラ行（「カレー」の「レ」）で OK。NHK のラジオ英語講座などは昔からアメリカ英語の発音を重視しており、少し偏りがある。それが英語だと思っていると、ヨーロッパではびっくりする。むしろ、重要なのは「L」の発音であり、カッコいい英語にしたいならば、こちらを徹底的に練習すべし。

魔法の粉 ATP

今回は「口の中に ATP 試薬とゆで卵を頬張りモグモグしていると、口の中で生卵になるかもしれない？」というお話。

A. Patel, L. Malinovska, S. Saha, J. Wang, S. Alberti, Y. Krishnan, and A. A. Hyman (2017) ATP as a biological hydrotrope. 356, 753-756. DOI: 10.1126/science.aaf6846

ミオシンは ATP を分解して筋収縮を引き起こすが ATP との相互作用の Km 値は 40 μM である。まあ薬が受容体にくっつく時の強さと比べると弱いが、生体内ではこの数十 μM の Kd 値でくっついたり離れたりを繰り返す例がよく見られる（薬とは異なり、くっついたままだと逆に悪い場合もある）。それに対して 10-100 倍モル量の ATP が細胞内（～5 mM）にはある。ATP をエネルギー源として使うのであれば、Kd 値と同じぐらいの濃度があれば、それで機能するのではないかと普通は考える。

この論文では、ATP がハイドロトロープ(Hydrotrope) であると主張されている。Hydrotrope とは、低分子量でありながら、その中に親水性と疎水性の両方の部分をもち、他の疎水的な有機化合物を水溶液中に高濃度に溶解させるような特徴をもつ物質のことである。いわゆる洗剤（界面活性剤 detergent）とは異なり、hydrotrope は疎水性部分が短いので、自発的にミセルを組むようなことはない（高濃度にすると自己会合することはあるが）。しばしば ATP のように、負電荷の親水性部分と芳香環の疎水性部分とからなる（両親媒性）。ちなみに detergent などの脂質は疎水性のしっぽの長さによって、自己集合体の形が違ってくる。界面活性剤 detergent はしっぽが短めなので、集合すると小さい球形のミセルとなる。しかし、しっぽが長くなってくると、集合体の直径も長くなり大きい球形のリポソームなどになってくる。さらに長くなると、球にはなりきれずにバイセルや細胞膜のように平面状になる。これで hydrotrope がミセルのように丸くならない理由がイメージできそうである。

著者らは、ATP が細胞内濃度である 2-8 mM に達すると、アミロイドの生成、卵の熱凝縮、液液相分離（1-25 μM FUS etc. with 8 mM ATP-Mg, APPNP-Mg）などを阻害することを示した。要するに、蛋白質どうしの相互作用を ATP が邪魔するのである。これまでは ATP-dependent な酵素のせいで凝集が解けるのだろうと思われていたが、実は hydrotrope としての機能が関与している可能性が出てきた。

塩濃度は液滴に大きな影響を与えなかった（ここでは）。液滴の中には ATP が４倍ほど濃縮されていた。加齢やミトコンドリアの酸化的リン酸化の劣化により細胞内の ATP 濃度が減ると、それにより細胞内にミスフォールドした蛋白質が凝集し、流動性が制限され、病気を引き起こす可能性がある。アルツハイマー病やパーキンソン病のような多くの神経変性疾患は老齢になってから発病するが、これは歳をとるにつれて ATP 濃度が減少するからなのかもしれない。

ATP が FUS 液滴を溶かす点については、GTP も ATP と同じぐらいの効果を示した。一方、ADP, AMP については、さらに高濃度が必要であった。やはり３リン酸の部分が親水性として機能しているためであろう。ADP, AMP, GTP などの細胞内濃度は 200-800 μM であるので、ATP ほどには大きな影響をもたらさないだろう。また、リン酸部分-Mg のみでも効果はなく、アデニン芳香環の疎水性部分が要ることが分かった。

ANS と混ぜて蛍光のシフトを観てみると、hydrotrope としての効果がわかる。そこで、ATP と古典的なハイドロトロープを比べてみた結果、ATP は疎水性分子のための可溶化微小環境を作るのに、はるかに効率的であることが示された（つまり溶けにくい油性分子の周りに、溶けやすくするための粉がまぶされているような感じ。きな粉がまぶされたワラビ餅？）。

タウリンやトレハロースのようなオスモライト（浸透圧調節物質）も蛋白質の安定性に寄与しているといわれているが、FUS 液滴を溶かす効果まではない。

細胞内の ATP 濃度が必要以上に高い理由として、ATP/ADP モル比が 50 倍ほどないと、ATP をエネルギー物質として利用するための代謝がうまく機能しないからという説がある。確かに ATP から ADP に化学変化するためには、モル比として ATP が圧倒的に多くないといけない。ATP に火を点けようとしても燃えないという事実から分かるように、ATP は特に高エネルギー物質というわけではない。しかし、例えば細胞膜を隔てて高低のモル比をつけて分離してやると、ルシャトリエの法則にみられるように、それだけでエネルギーを出せる物質となる。ならば、別に ATP でなくてもよいではないかと思われるが、実はその通りであろう。そして、分解の結果でてきた PP ピロリン酸は加水分解され、ただのリン酸となって散らばってしまうため、再びルシャトリエの法則によって、ますます ATP が ADP に変化していく。少なくともこの２点により ATP が高エネルギー物質として表彰された。

細胞内には 100 mg/mL 以上の蛋白質があり（別の文献ではもっと多い）、これらが凝集しないように保たれている。しかし、老齢化して ATP が減ると、神経変性疾患などを引き起こすのかもしれない。また、蛋白質複合体が複雑な方向に進化した際、凝集の問題が浮上した。そこで、それを防ぐための物質として、生物は DNA/RNA の一部品でもある ATP を採り入れた。おりしも ATP はエネルギー供給物質としても機能しており、後から hydrotrope として採用された可能性もある。

さて、文頭の「口の中で生卵が復活するか」という話に戻る。熱で固まった卵蛋白質（リゾチームなど）の間には、パーマの後の毛髪のように、ランダムにジスルフィド結合がかかっており、これが固茹でを実現している。よって、この S-S 結合を切るための還元剤が必要であった。ビタミン C ぐらいでは弱すぎてダメだけど、まあ冗談で苺も口に頬張ると生卵になったりして。

大腸菌培養の最少培地 M9 その６

「その５」をアップしたのが 2020 年 1 月ですので、早 4 年近く経つことになる。歳とった。。

その後に、次のような論文が出ていたらしい。

M. Cai, Y. Huang, J. Lloyd, R. Craigie, G.M. Clore (2021) A simple and cost-effective protocol for high-yield expression of deuterated and selectively isoleucine/leucine/valine methyl protonated proteins in Escherichia coli grown in shaker flasks. J. Biomol. NMR 75, 83-87. doi: 10.1007/s10858-021-00357-x

同じ著者で過去にも数報が出ており、いずれも M9 培地での培養の効率を上げる内容となっている。

この論文には、D2O を 1/10 量の 100 mL に減らしながら、これまでの 1 L 培養と同じ量のタンパク質を調製するための方法が書かれている。私も「重水 100 mL 培養は良いよ」とどこかに書いたような気もする。蛋白質を重水素化して methyl-TROSY を測ると、数 μM のような濃度でも観える。したがって、15N, 13C 安定同位体の培地を 1 L 作るのと、2H, methyl 1H/13C の培地を 0.1 L 作るのとでは、コストの面でそれほど大差はなくなってくるのである（とは言え、怖くて厳密に価格を計算していない）。それでいて、分解能は 2H 化の方が圧倒的によい。

重水 M9 培地に LB (D2O) が少しコンタミするそうであるが、3% までは 1H のコンタミの点で大したことはないそうである（本当か？）。著者らは 0.1% でも、むしろ大腸菌の成長にとって十分に効果ありと言っている（ただし、transfer cross saturation 実験に使う場合には、極力 1H の混入を避けた方がよいだろう）。

以下は論文から抜粋しているが、"100 mL" 培地に対してであることに注意

α -ketoisovaleric 32 mg
α -ketobutyric acid 16 mg
[2H]-glucose 1.8 g
[15N]-NH4Cl 0.5 g
LB (D2O) 1/1,000

グルコースの量が非常に多い。我々は 2 g/L ほど入れているが、彼らはそれの 9 倍量を入れていることになる。また、15NH4Cl も、我々は 2 g/L ほど入れるが、彼らはそれの 2.5 倍量を入れていることになる。

さらに硫黄源も多い。我々は MgSO4 の形で 2 mM ほど入れている。しかし、この論文では K2SO4 の形で 7 倍量の 14 mM も入れている。では、MgSO4 を 14 mM も入れても大丈夫なのだろうか？Mg2+ が多過ぎてダメだろうか？しかし、著者らは何故 Mg2+ の量を前回の論文での 10 mM から今回の 1 mM に減らしてしまったのだろう？我々は 2 mM 入れているが、Mg が多いと何かまずいことが起こるのだろうか？来週、学生に試してもらおう（どこかで後述）

これら、グルコース、塩化アンモニウム、硫黄源は、我々の現在の仕様より何倍も多く、これらが大腸菌の増殖に効くのだろう。さらに、微量金属やビタミンミックスもちゃんと？入れている。1/1,000 の LB 混入も効くのだろう（我々は遠心して大腸菌だけを植菌しているが）。

著者らの方法により、IPTG での誘導時の OD600 は 10 に達し、100 mL の重水培地から最終的に 11 mg の精製蛋白質がとれたそうである。確かにグルコースが通常の 10 倍近く入っている。もし、とれる蛋白質量がグルコースの絶対量に比例するならば（きっとそうだろう）、納得のいく数値である。ただし、いくつかの注意点も書かれている。

ひとつは、植え継ぎをこまめにすることである。Pre-culture を main-culture に入れて終わりというのではなく、次に植えた時に 10 倍以上は薄まらないように気をつけている（図２が分かりやすい）。こちらでも、100 mL を 1L に植えると成功するのに、20 mL を 1L に植えてしまい何度も失敗したことがある。なんと何億匹もいるはずの大腸菌が一匹残らず全滅するのである。二個目の注意点はバッフル付きの大きなフラスコを使うことである。培地の量はフラスコ容量の 1/10 以下に抑えている。これはエアレーションをよくするためであろう。ただし、上にも書いたが、実験目的が transfer cross saturation の場合には、培地の攪拌によってあまり多量の 1H 水蒸気を入れたくないので、ここが難しいところである。

著者らの方法により、たったの 100 mL で 1 L 培養と同じ量の蛋白質がとれた。もちろん、グルコースの絶対量は同じであるが、2-ケト酸や重水そのものは少なくてすむ。今、日本で重水を買うと 30 万円/L（= 2,100 USドル）であるので、かなりの節約になるだろう。

つれづれ思うこと 外国語編 その１

Perl 編を 10 編ほど書いてきたが、だんだんと書くことがなくなってきてしまい、次はどうしようかと思った時、ふと同じく「言語」というジャンルで「外国語編」を書きたくなってしまった。

英語を勉強し始めてからもうかれこれ 40 年以上も経っていることに、年齢の引き算をして初めて気づいた。それほど力を抜いた訳でもなく、ちょっとずつながらも努力を続けてきた "つもり" ではあったが、「英語」は、いや「英語」もやはりダメだった。特にリスニング（昔はヒヤリングと言ったが）がダメ。年齢とともに、日本語でも細く高い声が聞き取りにくくなってきた。いつも視るテレビのデフォルト音量もこの 10 年間で確実にアップしている。ましてや、イギリス英語の１万ヘルツを超える音声ともなると、風のささやきのようにしか聞こえない。

それではスピーキングは大丈夫なのかというと、これまた怪しい。日本語でも会話の中で人の名前は７割以上は出てこない。年齢の近い友人どうしでは「あの A さん」で会話を通すことが多い。翌日になっても「A さん」の本名が出てこない。名前に限らず、頭の中にはその物体が浮かんでいるのに、それを表す名詞が出てこない。これが英単語になってくると、もっと酷くなる。

数年前に、通勤の途中で単語集でも暗記しようと奮起したことがある。しかし、前日どこのページまで進んだかすら忘れてしまう始末である。「歳をとっても暗記力は変わらない」という研究結果があるとどこかで読んだことがあるが、それは絶対に嘘である！というより、実験の仕方が悪いと固く信じている。

今、大学生ぐらいの人たちに言っておきたい。スマホを触っている時間があるなら、それを少しでも削って英語を勉強しなさい。若い時の暗記力は 30 年後の 10 倍以上はある。

とは言え、Google 翻訳、DeepL、そして ChatGPT の登場により、果たして英語を勉強する必要はあるのか？と私自身も時々ふと思うようになってしまった。英語にかける莫大な時間と労力を、もっと数学や理科（理系ならば）にかけた方が良いような気がしてきた。ほとんどの人にとって外国語はあくまでツールであり、何かを論理的に考えるための土台とはならない。

もしかすると、30-40 年後は母国語をきっちりと間違いなく書くことが最重要視され（今でもそうなのであるが）、それさえ出来れば、あとは AI を含めて情報科学が確実に正しい諸外国語に翻訳してくれるのかもしれない（逆翻訳もまた然り）。誤訳されたとしたら、それはそもそも母国語が間違えているためだと判断されるほど、自動翻訳技術が発達するかもしれない。いや、きっとそうなるだろう。

すると「英語」は何のために勉強するのか？このような思考が頭の中をぐるぐると回り、この１年間ほど自分の頭の中で結論を出せなかった。

ところで、非難轟々を覚悟でいうが、英語ができる人は恰好よく（かっこよく）見える。頭も良いように見えてしまう（実際、その場合もある）。特に学会などで、日本人がアメリカ発音でべらべらと外国人と質疑応答をしようものなら、「あれは誰だろう？」と振り返ってしまう。一方、これがカタカナ発音のしどろもどろ英語であったりすると、何の感情も起きない。これは何故だろう？同じスピードでしゃべったとしても、アメリカ発音とカタカナ発音とでは、日本人のそれに対する見方に雲泥の差があるように思う。

それでは、米語発音の中のどれが聞いている日本人に一種の羨望のような感情を引き起こさせるのだろうか？筆者は「R」と「T」の音にあるのではないかと思っている。米語では「R」は舌を上に反り返らせて発音する傾向がある。そして「T」はラ行のように発音する。例えば、water は「ワラー（& 舌反り返し）」letter は「レラー（& 舌反り返し）」という具合にである。この二つの音は日本語にはなく異質である。そこに欧米文化へのあこがれや西部劇俳優のかっこよさ等が加わり、結果として英語ペラペラの人がかっこよく見えるのではないだろうか？

かく言う私も大学生の時には、この発音にあこがれ、アクセントを徹底的に調べつつ「R」と「T」を米語式に、そして「TH, F, V, W」を native 発音に近くなるように、まるで何かにとり憑かれたかのように練習した。さらに母音では「A」を「ア」と「エ」の中間音にしたり、「O」を極端に「ア」と発音したり（top は「タップ」に）した。いずれもそれが正しいというか唯一であると思い込み、またそうすることでかっこよく見れらたかったからである。

しかし、この 10 年間ほど、今はこれらの発音を極力しないように、どちらかというとカタカナ発音に近くなるようにむしろ努力している。どちらかというと米語ではなくイギリス英語に近い発音とでも言おうか、しかし、これまたイギリス英語を発音の手本とするのではない。最終目標は、アメリカ英語、イギリス英語のどちらへにも偏らず、それでいて世界中の誰にでも間違いなく伝わるような発音である。

なぜそれを目指すようになったかは続きでおいおい語ることにするが、要は、英語はもはや世界共通語となってしまったので、どこかの国の訛に固執するのも変ではないかと思ったためである。例えば、日本国内でも大阪のテレビニュースで司会者が「ほな次行くで。さっき大阪市で火事あって電車止まってん」などと発話することはまずない。ちゃんとした標準発音でしゃべられる。これは極端な例であるが、英語でも同じように、イギリス、アメリカに特化せずに、しかし英語に共通した発音は守りつつ、しゃべることは出来ないだろうか？と思う。

しかし、もう 40 年間もアメリカ発音こそが英語と思い込んできただけに、今さら water を「ワラー」ではなく「ウォーター」と発音するのは結構しんどい。授業でも最初は標準日本語でしゃべっていても（多くの受講生はそうなっていないと主張するが、私本人はそのつもり）、授業が遅れてくるとつい「そいで電子が葉緑体の膜ん中渡ってく時に、水素イオンがどさくさ紛れで汲み出されるんや」といった調子になってしまう。その方が速くて疲れない。

発音は運動と同じで、毎日少しずつでも練習していないとすぐに口と舌の筋力が落ちてしまい、上手く発音できなくなる（若い人はまだそれほど実感はしないと思うが）。「R」と「L」をひっくり返して発音してしまうことなんてザラである。これからも練習を続けていきたい。

ちなみに、上記の「そいで電子が...」の関西弁、BARD は完全に正確に英訳してしまった。恐るべし。

アメリカ英語では I don't want to ... を「アイダナワナ」などと発音する。この音をローマ字で表記すると「aidanawana」となる。このようにアメリカ発音はローマ字でいうところの「a」音が多いような気がする。一方、関西弁もローマ字で表記すると「a」が多いような気がする。

関東弁「それでは、しないといけないですね。」

関西弁「ほな、やらなあかんやん。」

これをローマ字で表記すると

関東弁「soredewa sinaito ikenai desune」i が多い

関西弁「hona yarana akanyan」a が多い

これは偶然の一致というか、いかに口をパクパクしないで、流れるように話そうとすると、このように a 音が自然に多くなるためではないかという気がしている。よって、西部劇ではタバコを加えたクリントイーストウッドが口をあまり動かさないで「かっこよく」話す。一方、シャーロックホームズがドラマでこれをしようとすると、口からタバコが落ちてしまうだろう。

つれづれ思うこと Perl 編 その９

Mathematica が他のプログラミング言語と異なる点の中で、筆者が面白いと思ったことを紹介します。

x = 3;
y = 4;
ab = {x, y};
ab

と書くと、ab には {3, 4} という具体的な数値が代入されます。後から x や y の値を変えても ab は変わりません。これは、一般的なプログラムと同じです。ところが、

ab = {x, y};
x = 3;
ab

というように、今度は行の順番を変えてみると、一行目で ab には {x, y} という文字式が代入されます。そして、面白いことに、二行目で x や y の文字変数の値を変えると、ab も {3, y} に変わるのです。続けて、

x = 8;
ab

と打つと、なんと ab は {8, y} に変わります。ab の中の x という文字はまだ生きているのです。これは Perl などの一般的なプログラムとは異なる点です。

詳細は Mathematica の「遅延割当」という項目をご覧ください。

これは Mathematica が数値計算だけでなく数式処理もできるためですが、いま大変重宝しています。例えば、ある時は数値計算を、またある時には数式処理をしたいとします。いずれにしても、ab = {x, y} のような公式にあたる箇所を先にプログラミングで組み立てておきます。もし、数式処理をしたければ、これでそのまま数式での答を得ることができます。

一方、数値計算をしたい場合には、ここに具体的な数値（たとえば、x = 8）を代入すれば数値としての答を得ることができます。次に x = 4 の場合を計算したければ、続けて x = 4 を実行するだけです。Mathematica は Jupyter のように使うことができるので、二度も ab = {x, y} を実行する必要はありません。実は、再び ab = {x, y} を実行してしまうと、ab は {8, y} となってしまい、もう x = 4 のケースを計算できなくなってしまいます。

上記のような書き方は数値計算に特化されていないので、実は余計に計算時間がかかってしまうのですが、いろいろな数値を入れて答を比べてみたい時には助かります。

よって、次のような計算もできます。

d = e;
e = f;
f = 8;
d

d を表示させると、８ になっています。
これは、普通のプログラミング言語とは行の順番が真逆です。

ややこしくなりますが、次のような配列を含む演算でも同じことが言えます。

blist = alist;　(* 先に変数を結び付けておく *)
alist = {2, 4, 6, 8, 10};　(* そして alist に偶数の配列を代入する *)
alist　(* 試しに alist を表示 *)
{2, 4, 6, 8, 10}　(* もちろん alist は偶数の配列 *)
blist　(* そして blist も表示 *)
{2, 4, 6, 8, 10}　(* blist も同じ偶数の配列 *)

alist[[3]] = 100;　(* それでは alist の３番目の要素に 100 を代入 *)
alist　(* を表示させてみる *)
{2, 4, 100, 8, 10}　(* ちゃんと３番目の要素は 100 に変わっている OK *)
blist　(* それでは blist は？ *)
{2, 4, 100, 8, 10}

先に blist = alist のように公式を組み立てておくと、このような結果になります。

Perl ではこのような行の順番で書くことはできませんので、下記のように上の行から下の行へと水が流れ落ちるように書くことになります。

#!/usr/bin/perl

@alist = (2, 4, 6, 8, 10);
@blist = (1, 3, 5, 7, 9, 11);
@blist = @alist;
$alist[2] = 100;
print "alist = @alist\n";　# 2 4 100 8 10 と表示
print "blist = @blist\n";　# 2, 4, 6, 8, 10 と表示

以上より @blist = @alist という表現では、alist のコピーが blist に複写されているようです。つまり、alist の先頭アドレスが blist に代入されたわけではありません。

しかし、次のように書くと、

#!/usr/bin/perl

@alist = (2, 4, 6, 8, 10);
@blist = (1, 3, 5, 7, 9, 11);
$blist = \@alist;
$alist[2] = 100;
print "alist = @alist\n";　# 2 4 100 8 10 と表示
print "blist = @$blist\n";　# 2 4 100 8 10 と表示
print "blist = @blist\n";　# 1 3 5 7 9 11 と表示

$blist には @alist の先頭アドレス（レファレンス）が入り、それとは別に @blist の配列そのものはちゃんと維持されるようです。

話が急に配列そのもののコピーか、それともアドレス（参照）のコピーかに飛んでしまいましたが、Perl, Python, JavaScript とごちゃまぜに書いていると、いつも分からなくなって困ってしまう点です。どこかに比較対照表のようなものをまとめたブログはないでしょうか？

おそらく Python では次のようになります。

a = [1, 1]
b = a
a[1] = 2
print(b) #［1，2］が表示される

多くの HP には「数値はイミュータブル（変更不可）、一方、リストはミュータブル（変更可能）」などといった説明が載っており、それはそれなりに説得力があるのであるが、Perl と比較しながら理解しようとすると混乱してしまいます。上記の Python は、いわば C 言語でいうところの、配列名はその先頭アドレスを表すという概念と似ています。

Python でリスト（配列）そのものをコピーするには、
b = copy.copy(a) ＃ 浅いコピー
としないといけないようです。二次元以上の配列になってくると、またちょっと複雑。

b = copy.deepcopy(a) ＃ 深いコピー
を使わないといけない。

一方、Perl では
@blist = @alist;
と書くと、配列そのもののコピー（複写）になることに注意しないといけません。

Mathematica でも同じ複写ですが、blist = alist を先に書いてから、後で具体的な数値の配列を alist に入れるという方式をとると、これはアドレス渡しのように振る舞うことになります。

いや～もう疲れた。もう JavaScript まで行きたくない。が、ついでだ！思い切ってやってみよう。もう混乱してきたので、詳細は他の情報源に譲ることにして要点だけ。

JavaScript の配列では参照渡しとなるようです。配列を値渡しに（複写）するには、slice や concat の引数なしを使うようです。

var arr1 = [0, 1, 2, 3, 4];
var arr3 = arr1.slice();

ということは C 言語と似ているということ？

C 言語では、配列名は先頭アドレスを指しますよね。
なので、b = a の後で、a の中身を変えると、b も変わって見える。

C　参照渡し
a[3] = {1, 2, 3};
b = a;

Python　参照渡し
a = [1, 2, 3]
b = a

JavaScript　参照渡し
a = [1, 2, 3];
b = a;

Perl　値渡し
@a = (1, 2, 3);
@b = @a;

ただし、$b = \@a; のように、b をポインタ変数のように使うことも可能。この場合は、それ以降 @$b の形で配列 b を使う。「\」は、C 言語のアドレス演算子「&」と似ている。

Mathematica 1　値渡し
a = {1, 2, 3}
b = a

Mathematica 2　参照渡し
b = a
a = {1, 2, 3}

こうして見てみると、Python は、まあ C と似ているのかも。
Perl や Mathematica がむしろ異端児なのか？

以上は一次元配列での話でしたが、NMR データのように二次元配列の場合、配列のコピーはどのようになるのでしょう？おそらく C 言語では memcpy を使う？

もう限界なので、ここでやめておきます。