  |
はてなキーワード: Catchとは
1978年にイギリスに亡命したソ連軍参謀本部情報総局（GRU）の情報将校、ウラジーミル・ボグダーノヴィチ・レズン（亡命後のペンネームとしては“ヴィクトル・スヴォーロフ”の名を用い、この名の方で著名である）によってであり、レズンは当時としては機密の壁に阻まれて謎の多かったソビエトの軍事情報について西側に数多くの情報を提供した。民間に広く知られたのもスヴォーロフ名義の著書である『Aquarium』(英語版)（1985年刊）に記述されていたことがきっかけである。
『Aquarium』の記述によれば
"He carries on his right calf a huge knife ... and on his left calf four spare blades. The Spetsnaz knife is no ordinary knife. It has a powerful spring in it so that when you remove the safety catch and press the release button the knife blade shoots out with a terrible hiss ... the blade can carry 25 meters. If It lands in a tree it is not always possible to pull it out"
「（スペツナズの）兵士は右ふくらはぎに大型のナイフを携行しており（中略）左ふくらはぎに4本の替刃を携行している。スペツナズの用いるナイフは通常のナイフではなく、強力なバネが内蔵されており、安全装置を解除してリリースボタンを押し込むと、刀身が大きな音を立てて射出される（中略）刀身は25メートル飛翔し、木に命中した場合なら簡単に抜くことができないほどに突き刺さる」[注釈 4]
女子中高生ら装いＳＮＳで交流相手募ったら…９時間で１６０人返信、性的要求が大半
https://news.yahoo.co.jp/articles/b8a19d3749989c993e2730e4f95e285f66617a65
これさあ、実態を把握するのは意味があるし、ゲスいアプローチの地獄絵図なのも気持ち悪いけど、
学術的な裏付けにもとづく安全管理や法的根拠や倫理性に細心の注意が必要なので
記事中でも、2020年のチェコのドキュメンタリー映画「SNS―少女たちの10日間―」を参考にしたと書いてあるが
それであれば当然2007年のアメリカのリアリティショー「To Catch a Predator」も念頭に置くべきで、
こちらは番組がおとりの少年少女を用意して接触してきた大人にカメラクルーが突撃するという番組。
最終的に、13歳の少年を装ったおとりにひっかかった検事に突撃したらその場で自殺したという事件があって放送打ち切りになった。
そもそも借金抱えている人の前に大金の入った財布を落としておくような、
ギリギリで犯罪を犯さないように耐えている人の背中を押すような行為はどうなのかとか
いろいろ論点があるのをわかったうえでやっているのかこの報道だけでは疑問が残る。
こういうこと言うと犯罪者や予備軍の擁護と言われるんだろうけど
クズ人間だからといってそのすべての人権を無視していいわけではない、と思うだけ。
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
知らんけどプログラミングスクールとか専門学校とかプラクティス的な教育が中心なんでしょ？
新卒で現場に放り込まれて、現場に転がってるコードをお手本にして育って、リーダブルコードに書かれてるようなお作法に触れてないプログラマってコードがひどいよね。
まあ「コメントはしっかり書きましょう」程度のことは知ってるけど、方向性がおかしくて、装飾がやたらと多い凝った書式のコメントを書くのに命をかけてたり、情報量ゼロのコメントを大量に書いて満足してるとか、そんなのになりがちだし。
クラスとかも、同じような目的で使うサブルーチンをとにかく全部つっこんで「これ、クラスじゃなくてネームスペースつかうところじゃね？」みたいになってたりするし。
全部のメソッドを catch (Exception e) で括って「絶対に落ちないプロのコード」とか誇らしげだったりするし。
Bluetooth端末で動作する。(CC0 License)
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>A10 Cyclone SA easy controller</title> </head> <body> <span id="status">initializing...</span> <script> let status = document.querySelector('span#status'); let device, characteristic; const connect = async _ => { try { device = await navigator.bluetooth.requestDevice({ filters: [{ services: ['40ee1111-63ec-4b7f-8ce7-712efd55b90e'] }], }); status.textContent = 'connecting...'; let server = await device.gatt.connect(); let service = await server.getPrimaryService('40ee1111-63ec-4b7f-8ce7-712efd55b90e'); characteristic = await service.getCharacteristic('40ee2222-63ec-4b7f-8ce7-712efd55b90e'); } catch (e) { status.textContent = `failed to connect: ${e.message}`; return; } document.addEventListener('pointermove', evt => { evt.preventDefault(); let y = evt.y / innerHeight * 2 - 1; let data = Math.abs(y) * 0x7f | (y < 0 ? 0x80 : 0x00); characteristic.writeValue(new Int8Array([0x01, 0x01, data])); }); status.textContent = 'swipe up and down to move'; document.removeEventListener('click', connect); } document.addEventListener('click', connect); status.textContent = 'tap screen to connect'; </script> </body> </html>
https://georgebest1969.typepad.jp/blog/2020/03/事実に誠意を.html
これが原文です。
外国から問い合わせが来ているけれども時間がなくて訳せないということで、DeepLの性能確認ついでにやってみました。
この私訳と岩田健太郎先生は無関係なのでよろしくお願いします。
訳された文章を原文と見比べ、翻訳で文章がおかしくなったところや慣用句は「必ず日本語側の文章をいじることで」できるだけ解消しました。
よって改変した文章だけをこちらに載せ、改変する必要がなかったところは段落番号しか載せていません。元文章は元ブログを当たってください。
英語に詳しいパーソンが精査していただけると幸いです。
1 Most of what I'm about to write is no different from what I've said and done in the past. However, I have been asked the same question repeatedly, so I would like to reiterate it. We have received many inquiries from overseas as well, so we should have prepared the same content in English, but due to time constraints, I'm afraid I'll have to skip it. This article is designed to be read without basic knowledge of infectious diseases and jargon, but it is rather difficult to understand. Please forgive me for that.
感想：「Chromeかなにかでそれぞれ母国語に訳してお読みいただけると幸いです。」がきれいさっぱり消えている。DeepLの自負心だろう。
2 The fact that the number of COVID-19 reports in Japan is very low compared to other countries is attracting attention from home and abroad. Is it true? It has been pointed out that the number of tests is so small that we may be misreading the actual number of infected people.
3 However, this point is wrong at various layers. In the first place, Japan does not aim to capture all the numbers of COVID-19. Whether it's administrative testing or insured care, the state basically has a testing strategy in mind to diagnose, hospitalize, and isolate critically ill patients who need to be hospitalized. It is natural that they "haven't figured it out" and they don't intend to. That's not a bad thing.In fact, the situation is the same in every country, large or small, and no country, whether in the United States, Europe, or Asia, is aiming to "capture the whole number.
感想：最後の文はなぜか他の文と一緒に入力すると訳してくれなかった。この文一つだけ入力すると訳してくれた。
よく考えると「多かれ少なかれ」は通じないだろうから直した方がよかった。なぜかDeepLに繋がらなくなったのでもう直せない。
WHOもそんなことは求めていない。もっとも、そのわりに日本は帰国者無症状者にPCRをやってみたり、無症状な検査陽性者を入院隔離させてみたり（軽症者は自宅じゃなかったの？）、プリンシプルにおいて首尾一貫していない。だから、「彼らがなにがやりたいか私たちはよくわからない」ので、人々は不安になる。リスコミにおける失敗と言えよう。
The WHO is not asking for such a thing. But instead, Japan gives PCR to asymptomatic returnees and isolates asymptomatic test-positive people in hospital (wasn't it home for people with minor illnesses?). It has not been coherent in its principles. So, people get anxious because "we're not sure what they want to do". It's a failure in the press.
感想：「なにがやりたいかよくわからない」に主語を付与する必要があった。リスコミがpressになった。よくわかったな。
「〜は自宅じゃなかったの？）、」の、が.になっているのがよくわからない。なぜかDeepLに繋がらなくなったのでもう直せない。
4 The difference between Korea and Japan is the "result" and not the "purpose". In South Korea, where the number of infected people had surged in one place, we had to focus on inspections in and around the area. If such a phenomenon (let's call it an overshoot) occurs in Japan, the number of inspections will increase. When the situation is different, arguing only on the basis of the number of tests without observing the situation is like trying to say, "That team made 50 sliding tackles while this team made only one," without watching a football game. In games where you don't have to slide (e.g., when you're in possession the whole time), even 0 times isn't a "mistake," and of course 50 times isn't a mistake.
5 全数把握ができていない疾患など山のようにある。日本ではインフルエンザの「全数」把握はしておらず、定点観測である。疫学上、感染対策上、それで十分な情報が得られているからだ。日本で毎年風邪が何例発生しているか、正確に把握したデータはない。レセプトデータを見ればわかるじゃないか、というのも間違いで、なぜなら多くの風邪患者は（ぼくのように）受診せずに自然に治るまで待っている。医療に限らず、経済学でも政治学でもデータはサンプリングから母数を推定するのがほとんどで、「全数」は非効率的な状態把握法なのだ。
There are many diseases for which the total number of patients is not known. In Japan, we do not have a "total" number of influenza cases, but only a fixed-point observation. Because that's enough information, both epidemiologically and in terms of infection control. There is no accurate data on how many cases of the common cold occur each year in Japan. It's also a mistake to say that you can tell by looking at the receipt data, because many cold patients (like me) don't see a doctor and wait until they are cured naturally. Not only in medicine, but also in economics and political science, data are mostly based on sampling to estimate population numbers, and "whole numbers" is an inefficient way of grasping the situation.
感想：ちょこちょこ変えてある。日本語の文章が多少おかしくなっているのは勘弁してほしい。接続詞を適切に入れると格段に翻訳が正確になる。
6 We have not seen the devastation in Japan as in Italy, Spain or New York City. There is no medical collapse in a critically ill patient, no use of the operating room as an ICU, no piling up of bodies on a skating rink with no place to put them. Even if the "numbers" are not known, it is a fact that the current situation in Japan (including Tokyo) is much better controlled than in other countries.
7 Even so, you may be interested in "Well, what about the actual situation? There are estimates. For example, Dr. Hiroshi Nishiura and his group estimate that the number of mild illnesses in Japan may be twice the reported number. The catch rate is 0.44, with a 95% confidence interval of 0.37-0.50.
8 Although the study was based on data from China, there is no guarantee that the Chinese COVID-19 demographic is the same as the Japanese one. Also, since the original study did not include asymptomatic patients or those with minor illnesses that did not require hospitalization, the number of infected patients estimated on that basis would inevitably be an underestimate. If you are more paranoid, it's not unreasonable to believe that "the Japanese and Chinese viruses are different because of the mutation" (although I don't think so).
9 This does not diminish the value of the paper itself. The model must always use existing parameters, and it is often impossible to prove the external validity of these parameters. If the underlying parameters are not reasonable, the predictions will not be correct. A model assumes a simplified world insofar as it is a model. A model without simplification, which is an adjectival contradiction.
数理モデルのこうした「前提」にイチャモンを付けるのは、例えばAという疾患を対象にランダム化比較試験をしたときに、「Bという疾患については説明できないじゃないか」と文句を言うようなもので、業界の仁義に反する意味のない揚げ足取りである。
To complain about these "assumptions" of the mathematical model is like complaining, for example, "You can't explain disease B," when a randomized controlled trial is conducted for disease A. This is a meaningless tirade against the honor of the industry.
感想；「分からない」を「説明できない」に変えた。多分これでいいと思う。思いたい。
However, it is different for the reader of the paper.
A mathematical model that assumes a certain hypothesis should have internal academic validity, but it is the responsibility of the reader, as a resident of the real world, to appraise it in the real world.
Aという疾患を対象にしたRCTの知見をBという疾患に使ってはならないように、数理モデルの制限を理解し、現実世界にアプライするときに十分注意するのは当然だ。
Just as the RCT findings for disease A should not be used for disease B, it is natural to understand the limitations of the mathematical model and to be careful when applying it to the real world. For example, it would be wrong to read the paper and conclude that the total number of infected people in Tokyo is about 500 as of March 26.
感想；「読み手は別である」を「読み手にとっては別である」に変更し、「制限や限界」は「limitations and limitations」になったので片方削った。
11 People make mistakes. The models are also wrong. Being wrong is not a big deal. The problem is to notice your mistakes and make corrections. Already, a group at Imperial College London has admitted that its original estimate that the peak of the infection should be moderated was "wrong" and has revised its prediction that the ICU will soon fail if it does not fight the virus fairly aggressively.