  |
はてなキーワード: コンテキストとは
https://twitter.com/fumokmm/status/1703977187903426995
「むしろこれが正解」「速度を出すときにはこういうことをする」「作ろうとする姿勢が大事」
とか逆張りで褒めてるやつが多いけど、普通にこんなんダメだから
何がダメって、FizzBuzzを教えるタイミングって100%がfor文とif文を教えた直後なんよ
まずfor文を教えて「1から100までの数字を出力してみましょう」っていう問題が出されるわけ
そのときにfor文を使いこなせなくてSystem.out.printlnで書くやつはいっぱいいるけど問題無い
ちゃんと教える側が「for文を使えば簡単かつ正確に書けますよ」って形でfor文を教える
その次に「if文を使って偶数のときだけ出力しましょう」とかを教える
そうすることでfor文の中でif文を使えば繰り返し処理を制御できるってことを教える
「FizzBuzzっていう英語圏で遊ばれるゲームがあるんだよ」
っていう形で出題するわけ
ユーザーに数字を入力させてFizzBuzzを判定させる、とかのゲームを作らせるのがいいんだけど
「まずは単純にFizzBuzzの正解を表示させてみましょう」
っていうコンテキストで出題されるわけ
そのときの回答としてSystem.out.printlnを大量に書くようなやつがいたら、もう一回for文からやり直せっていうのが正解
この回答が合っている要素なんて一ミリも無い
ワイ： 「めちゃめちゃ厳しい人たちが不意に見せた○○」の○○の中に単語を入れて面白い文章を作ってください
AI：「めちゃめちゃ厳しい人たちが不意に見せたカラオケスキル」
ワイ：4音で
AI：ごめんなさい、間違えました。「めちゃめちゃ厳しい人たちが不意に見せた恋愛」
ワイ：4音節で
ワイ：いいね
AI：うれしいです、気に入っていただけて！他に何か質問がありましたら、お気軽にどうぞ。
AI：あなたが指している特定の「元ネタ」は私にはわかりません。あなたの質問は、日本語のフレーズの一部を完成させる形式でしたが、それが特定のメディアやポップカルチャーから来ているとは限定されませんでした。私の知識は2021年までのもので、それ以降の情報は持っていませんので、もし最近の流行やメミーに関連しているなら、私はそれを把握していません。あなたが参照している具体的な元ネタをもう少し詳しく説明していただけますか？
AI：「微笑みの爆弾」は日本のアニメ「機動武闘伝Gガンダム」のエンディングテーマであり、その一部に「めちゃめちゃ厳しい人たちが不意に見せた微笑み」の歌詞があります。
あなたが提供してくれたコンテキストを元に、「めちゃめちゃ厳しい人たちが不意に見せた○○」というフレーズを作成するという私の理解が進みました。今回のタスクは、その歌詞を参照し、○○の部分に新たな4音節の単語を入れて面白い文章を作るというものだったのですね。
「めちゃめちゃ厳しい人たちが不意に見せたキンタマ」
まともなコメントもあるけど
松本人志が審査員ばっかりしてたら、松本人志色の強い芸人しかこの世界で生き残れないので、
中田の意見を否定しているわけじゃなくて、これはおもしろい切り口だと思う
まったくその通りでテレビ番組だからTV局のプロデューサーとかの人選なんよなあ
偏差値65
マネーで計算すんのか、影響力で計算すんのか。いろんな見方あるけど。中田くんもそんなに言わんで。松本さんが審査員全部辞めるわってなったら、スポンサーもつかんわ、番組成り立たんわってなったら、これどないすんの？
すまん、ほんこん。ワイはお前を完全に舐めてた
感情に任せてコンテキスト無視したとんちんかんな文句言うネトウヨと同じレベルの無能な芸人とはちゃうかった
さんまさんの意見にも通じる。TVやし。そうよね、スポンサーつかんかったらTVとして成り立たん。その視点はまともよ
偏差値50
誰よりも神格化してるのかな
なんでそうなんねん。
番組を作ろうっていうお笑い関係者が松本を神格化しているっていうのはあっても
中田は違うだろう。
そして、中田の発言に論理性ゼロのコメントを出す人間こそが松本神格化して全てを擁護しようとしているんじゃないのだろうか？
偏差値35
真っ直ぐ勝負ってそんな自分ルール持ち込んで文句言われてもなあ
偏差値30
いやいや中田そんなこと言ってないし
おまえがおもしろくないって考えるのは勝手だけど、それ擁護にはなってないし
ただただ浮いたコメント
偏差値25
いっぺんやってみ、審査員！、こんなこと言われたら腹立つわ
いっぺんやってみって何よ。中田のコメントは別に俺にやらせろでもなければ、やったところで何も意見が変わるものでもない
偏差値15
この意見が一番ひどい。
そのべきって何だよ。権力者だけが権力者に意見言えますって何だよ。
そんな考えだから独裁が生まれ、多様性が失われるってことがわからんかなー。権力の犬かよ。
頭のいいポジション狙って学歴ロンダリングに夢中だけど、到底無理だよ
芸人でロジカルにもの考えられるのあとはカズレーザーくらいかな？
この件では何も意見言ってないと思うけど
他誰か何か言ってたっけ？
なんかわかんねーけどよぉ
俺は永遠について考えちまうわけだ。俺は、俺なんかは。
ま、でもそりゃあ珍しいことでもなんでもなくって、
文章書くやつなんてみんなそうだろって思ってたわけよ。
生まれたからにはどんな形でもいいから普遍とか永遠に触れてみてぇ、
まずここにいる俺のためにこの文章はあって、
ほとんど俺とコンテキストを共有できてないような、下手したらほとんど言葉も通じねぇような奴、
そいつに何かが伝わるなんてことを夢想したりするもんなんじゃねぇの。
でも今はもう
今通じることを
ってのが主流なんですかね？
いや共感されてぇってのはわかるよ、俺だってある、今ここで分かられてぇ時もある。
でもね、
昨日はOKだったけど今日はダメ、でも明日んなったらまたOKになるかもしれねぇ代物だろ。
虚空に向かって放つつぶやきだぜ？
どうせ俺らは時代精神ってのにどっぷり浸されちまっていて、
表現の自由、とか大上段に立った話じゃなくてもよ、
俺は書く時くらいは何にも囚われないでいてぇって思うよ。
つーか、何にも囚われない感覚を得るために書くってこともあんじゃねぇか？
技術的負債というワードはウォード・カニンガムが発祥と言われており、それこそ「スピード」と「コードの品質」のトレードオフのことを指している。スピードを得るために、借金をすることで、未来のコードの品質を改善するために利子を払い続ける必要があるという意味のメタファーである。
しかし、最近は技術的負債という言葉の誤用が広まり、それが定着化している。
例えば「モダンではない（古い）技術選定」「要求仕様の変化によって荒れたコード」を指して会話していることが多い。
誤用であるので会話の最中に自分とコンテキストが一致しないこともある。とはいえ時代の変化とともに言葉の扱われ方が変わるのは、事実であるので、これは65535歩譲って理解はできる。
しかし、問題なのは誤用で解釈しているエンジニア達がこぞって「技術的負債」という存在そのものを生み出しているエンジニアを糾弾していることだ。
残念ながら、彼らに「技術的負債はなぜ悪なのか」を聞くと「自分の開発体験が損なわれるから」という利己的な解像度でしか相手に伝えられない場合が多く、コミュニケーション能力も乏しいと感じることが多々ある。
開発体験が損なわれると「感じる」というのはわかるが、彼らはこれに対して数字で反論することはない。感情的なのだ。
彼らは自分自身を利口で地頭がよく、論理的に物事を捉えていると誤認しているが、これらの行動原理はただの感情ベースであり、彼らもまた感情的な生き物であることがよくわかる。
脱線するが一部のエンジニアには「○○言語が書けるから入社を決める」みたいな頭が悪い会社の選び方をする者もいる。
好きな言語を仕事にしたいという安易な発想で、糾弾している技術的負債を目の当たりにし、自分が書きたいと思ったコードが書けないで会社を去るものもいるだろう。本当に愚かである。残る選択をしたエンジニアは技術的負債に手を加えて、自分が嫌悪しているのにも関わらず技術的負債を生み出すのである。
そして、彼らもビジネスの都合で技術的負債を生み出して、後に入社するエンジニアに技術的負債を生み出したことで糾弾されるのである。数ヶ月、もしくは数年後にはモジュールなどのエコシステムが刷新されることによって、結果としてオナニーコードが技術的負債として罵られるのである。滑稽としか思えない。
つまり誤用の技術的負債ワードを用いるエンジニアが、技術的負債を糾弾するというのは無知によるポジショントークであり、自分自身が技術的負債を生み出していることに気づかないピエロなのだ。
さらに言えば、言葉の定義にうるさい割に、技術的負債という言葉の定義を自分たちの都合のいいように解釈して誤用しているのである。
歴史修正乙
当時未成年の女性芸能人がお色気シーンのある少年漫画を擁護したことに対して「さんざん叩かれた過去から学んだ保身」なる妄想をもとに発せられた誹謗中傷ツイートが起源でありコンテキスト含め擁護の余地はない
コンテキストを無視するお前のような男が差別を助長させてるんだろ
ちんよし とかは、ミソジニストの女性に対する差別攻撃への反撃としての言葉なんだから、差別ではないし、むしろ反差別のための言葉だってことは分かるでしょ
もちろん漫画を擁護することはミソジニーとは関係がないし発言者によるtogetterまとめでの更なる中傷を見るに差別攻撃に対するカウンターではなく単なる嫌がらせでしかない
参考
今週号の『ゆらぎ荘の幽奈さん』に物申す！！ (週刊少年ジャンプ2017年31号) #wj31 - Togetter
はるかぜちゃんに対する中傷を告発する事はジャンプ批判者の攻撃になる？ジャンプ巻頭問題提起者の新たな問題提起 - Togetter
https://arxiv.org/pdf/2305.00833.pdf
Learning to Reason and Memorize with Self-Notes
大規模な言語モデルは、限られたコンテキスト メモリと多段階の推論に苦労することが示されています。
モデルが自己メモを取ることを可能にすることにより、これらの問題の両方を解決するための簡単な方法を提案します。
最近のスクラッチパッド アプローチとは異なり、モデルはいつでも入力コンテキストから逸脱して明示的に考えることができます。
これにより、モデルはコンテキストを読み取りながら情報を想起し、オンザフライで推論を実行できるため、メモリが拡張され、複数ステップの推論が可能になります。
複数のタスクに関する私たちの実験は、推論時に自己メモを取ることにより、トレーニング設定からより長く複雑なインスタンスに私たちの方法がうまく一般化できることを示しています.
1. イントロダクション
Transformers (Vaswani et al., 2017) および同様のバリアントは、シーケンスベースのタスクで印象的な結果を示しています
特に、GPT-3 (Brown et al., 2020) などの大規模な言語モデル (LM) はトランスフォーマーを使用し、質問応答 (QA) などのさまざまな NLP タスクを解決できます。
LM を QA タスクに使用すると、図 1 (上) に示すように、事実情報と質問を含むコンテキスト プロンプトが与えられ、モデルが直接回答を生成します。 ただし、この自己回帰の「ワンステップ」アプローチは、複数ステップの推論タスクと格闘します (Austin et al., 2021; Press et al., 2022a; Creswell et al., 2023)。 これは、バニラ LM が各トークンに対して固定された計算を行い、現在のコンテキストに応じてさらに「考える」オプションがないという事実から生じると主張します。 (2021) 図 1 (中央) に示すように、モデルが質問に答える前に推論トークンを生成できるようにするスクラッチパッドの使用を提案しましたが、完全なコンテキストと質問を読み取った後です。 同様に、一連の思考を促す方法 (Wei et al., 2022; Zelikman*Equal Contributor 1Meta AI. への対応: JackLanchantin <jacklanchantin@meta.com>, Sainbayar Sukhbaatar<sainbar@meta.com>.et al., 2022; Huang et al., 2022) は、モデルをプッシュして、一度に 1 ステップずつ答えを説明し、より首尾一貫した最終的な答えに導きます。 非線形タスク (Fan et al., 2020)、LSTM (Hochreiter and Schmidhuber, 1997) などの再帰型先行モデルが十分に備えられているもの。 Fan et al., 2020; Ju et al., 2022; Hutchins et al., 2022)、しかし、それでも与えられたプロンプトに対して一定量の計算を使用します。 推論と状態追跡メモリがより扱いやすくなります。 私たちの方法である「Self-Notes」により、LM はオンザフライでコンテキスト プロンプトから逸脱し、明示的な推論トークンを生成できます。 図 1 (下) に示すように、スクラッチパッドとは異なり、モデルは生成されたトークンを入力コンテキストとインターリーブできます。 このようなセルフ ノートは、明示的な中間推論ステップと状態追跡用のメモリの両方として機能します。 具体的には、推論ステップで 2 つの事実を組み合わせる必要がある場合、結果として得られる推論をセルフ ノートに書き込んで、将来の推論に使用することができます。したがって、中間推論ステップとして機能します。 たとえば、「アリスは箱を持っています」と「アリスは公園にいます」が与えられた場合、「箱は公園にある」と推測してそれを自己メモに書き、将来のステートメント「鍵は in the box」で「鍵は公園にある」と結論付ける。 さらに、コンテキストをトラバースしながらモデルがエンティティの最新の状態を新しいトークンとして書き込むことができるため、SelfNote はワーキング メモリの形式として機能できます。 たとえば、プログラミング環境では、最初に x=5 を想定し、次に x を 1 ずつ増やします。モデルが x=6 をセルフ ノートとして正しく記述していると仮定すると、元の x=5 ステートメントをそのコンテキストから安全に削除できます。 モデルが x の値について問い合わせられた場合、モデルは既に答えを持っています。
私たちの提案した方法と、スクラッチパッド (Nye et al., 2021)、思考の連鎖 (Wei et al., 2022)、または内部独白 (Huang et al., 2022) などの以前の研究との主な違いは、モデルを許可することです。 各コンテキストステートメントを順番に読み取るときに、複数のメモを明示的に書き出す。 InarXiv:2305.00833v1 [cs.LG] 2023 年 5 月 1 日図 1: (上) ベースライン バニラ LM は、コンテキスト (C) と質問 (Q) が与えられると、回答 (A) を直接生成します。 (中央)スクラッチパッドを使用すると、モデルは質問に答える前に中間推論トークンを生成できますが、コンテキストが表示された後です。 (下) 私たちの Self-Notes メソッドにより、モデルはいつでも推論してメモを取るために入力コンテキストから逸脱することができます。言い換えれば、私たちのアプローチは、将来の推論に役立つ可能性のある情報でコンテキストを補強するスクラッチパッドのインライン形式です。 私たちはこれを、人間が読む方法と同様に、明示的に述べられていない情報を推測するための行間の読み取り (および書き込み) の形式と見なします (van den Broek et al., 2009)。 以前の方法では、モデルが完全なコンテキストを読み取った後に反芻することができ、読み取っている間ではなく、最後に大量の推論を行うように強制されます。
さらに、そのようなポストコンテキスト推論は、推論が開始される前に以前のコンテキストトークンがモデルのコンテキストウィンドウからすでに出ている可能性があるため、メモリとして機能できません。 たとえば、数週間または数か月の対話履歴を持つインテリジェント エージェントを考えてみましょう。 直観的には、最初から考え直すことなく、以前の対話で行った推論ステップを使用できることは理にかなっています。自己メモを生成するようにモデルに教えるために、トレーニング中に、入力の一部としてグラウンド トゥルース自己メモを言語モデルに提供することを検討します。 コンテクスト。 推論中に、トレーニング中に学習した特別なトークンを生成する場合、モデルはコンテキストから逸脱し、SelfNote を生成できます。モデルが Self-Note の生成を完了すると、元のコンテキスト トークンが引き続き供給されます。 これにより、モデルは最後だけでなく、入力トークンの処理中にメモリを推論および作成できます。 また、Self-Notes をトレーニングするための半教師ありおよび教師なしの方法も提案します。多段階の推論と状態追跡を評価するように設計された 5 つのテキスト データセットでこの方法をテストします。 , 2020; Anil et al., 2022)、および 2 つの現実世界のチェス ゲーム タスク (Toshniwal et al., 2022)。 私たちの方法は、明示的なメモ取りを行わない微調整された言語モデルとスクラッチパッドのベースラインの両方よりも優れています.2. 方法シーケンス内の次のトークンを予測する自己回帰変換モデル M を考えてみましょう
友達は超重要。ただし、一人の友人に影響を受けすぎるのは博打が高すぎるので、１年目は広く浅くを心がけよう。
バイトは最重要。あなたは世間知らずなので、いろいろな手段で生活費を稼いでいる人に触れよう。同じバイトは半年以上続けず、仕事を覚えたら次のバイトに移行しよう。
コンビニバイトは日本の小売や流通システムを集約しているので１回は経験しておくとよいが長居不要。優秀なあなたは遺留されるだろうが、アルバイトはきっぱり辞める権利がある。辞めるときに経営者()から不本意な雑言で罵倒されることもあるだろうが、その言葉はしっかりメモしておき今後の糧としよう。
初級バイトは同世代の若者がやっているようなコンビニとかカフェとかでよいが、最終的にはいい歳した大人がそれで生計をたてているようなところを狙っていこう。たぶん今後一生直接関わることのない人たちの生き様を学べる。
ゼミの選択はクリティカルだが、ローカルコンテキストに完全依存するため、最善のアドバイスはできない。一般的なアドバイスとしてはモラハラ教授だけは人生詰むレベルなので避ける。
授業は優秀なあなたならバイト等である程度手を抜いていても２年目にはほぼ必須は終えていて、３年目以降は流していけるようになっているだろう。そうでないならあなたは優秀ではないので本稿の対象ではない。
私は長くソフトウェアの業界で技術者として働いていて、ドキュメントを書くべきだって多くの人が言うのを見てきた。それには賛成するものの、過去の経緯や決断、知見を文書にしたところで、私の周りじゃそれを読まない人も多かった。
たとえばBig Tech出身だったりする、業界的には優秀と評されるのであろうエンジニアたちとも仕事をしているけれど、そういう人たちも同じ傾向だ。先日も「なんでこうなってるの？もっとxxすべきだ」って言われたから過去の経緯を説明したら「そういう過去のstoryはドキュメントに残しておいたほうがいい」だと。あのね、正にそのドキュメントあるんですわ・・・知らなかった？ここにドキュメントあるから目を通しておいてねって何度か伝えたよね・・・キミが読んでないだけだよね・・・キミほんといま現在のコードしか見ようとしないもんな。
でも別にこれは彼だけの話じゃない。私はこの業界でずっとそういう、ドキュメントが読まれない風景を見てきている。もうそれを殊更に責める気持ちにはならなくて、ああまたか、と思うだけになった。諦めている。ほとんどの人は読まない。自分が何か具体的な問題に直面し、ドキュメントにその答えがありそうだと人に教わって、ようやくチェリーピックして読む（かもしれない）。それまで資料は見ない。本も読まない。先人の知見や歴史を自分から学んだりはしない。でも例外的にGoogleみたいなキラキラした権威がやってるとされる何かは真似したい人も多いみたい。だってGoogleがやってるんだぜ！クールに決まってる！自分たちとはコンテキストが違うだって？Googleのやってることが役に立たないとでも言うのか？アンタは新しいものが受け入れられないだけだ！おいここに老害がいるぞ！
閑話休題。ドキュメントは書くべきなんだろうけど、ドキュメントを読むべきっていうのももっと言われて然るべきではないのかなとは思う。たとえそれが140字以上の長文であっても。とはいえ、ソフトウェア業界に限らず、手軽に消費できないものを人は読まないというのは一般的な傾向な気がするし、今後も加速していくだろう。もうこれは仕方ないんだろうな。
Perl5の実用的な面での特徴は、異常なまでの後方互換性にある。
25年前のPerl4向けのスクリプトですら、ほとんど修正なしに最新のperl 5.36.0で動いてしまう。他のプログラミング言語ではあまり見られない特徴である。この特徴はある程度は今後も維持されるし、いまPerl5を書いている人の多くが望んでいることだろう。
しかし、後方互換性を守るあまり現代の言語に備わっているような機能が欠けている現状がある。ただ、それも改善されつつあり、後方互換性を守る形で慎重に取り入れられている。
一方で自由度が高すぎる文法は、後から修正を重ねていくようなものには不向きかもしれない。linterであったり、型アノテーションを書くようなモジュールも存在する。このようなものを用いて自分を律して書く分にはメンテ可能であるものの、現代のように多くの人が一つのスクリプトをいじることが求められる環境では不向きと言える。
実用的な面で向いているのは「一回書いたら修正を行わないスクリプト」かつ「10年単位で動かす必要のあるもの」である。そんなものはあるのかと思う人もいるかもしれないが、規模が小さければぴったりハマる場面もある。
言語としてはコンテキストだったり、ブロック単位で言語の挙動を変えられる点などが面白ポイントであるものの、これらはホビーとして楽しむのが良いというのが私の見解である。
「君の言っていることはすべて正しいけど、面白くない。」
何年か前に読んだ雑誌のコピーで、当時かなりの衝撃を受けたことを覚えている。
今でもたまにこのコピーを思い出してドキッとすることがある。
エンジニアという職業では特に、論理的に考えることが必須なスキルとなる。
エンジニアの仕事は、正しい方向へ向かうための判断を繰り返すことに他ならない。
ビジネスのためにどのようなシステムを作るべきか？アーキテクチャの選定はビジネス課題の解決になっているか？アプリケーションの実装はビジネスが意図した動作をするか？
職業病かどうかわからないが、日常生活でも無意識に論理的に考えることが増えたように思う。
エンジニアの仕事では論理的思考は役に立つが、日常生活ではむしろ邪魔になることがある。
日常生活で正しさが求められるシーンは限られている。
正しいことが他の何よりも優先されるのかといえば、当然そんなことはない。
正しさがある程度証明されたからといって、それが何になるんだろうか？
共感を求めている人に正論を叩きつけたり、別のコンテキストに立つ人間同士が正論を言い合ったりすることは、ほとんど無価値だし、むしろ憎悪の原因にしかならない。
エンジニアの仕事でさえも、論理的思考が邪魔になる場面があると思う。
論理的に考えることは、ある程度の時間がかかる。正しさの判断をするために時間をかける必要がない場面は、無限にある気がする。
正しい判断が求められず、速攻で理由もなく決めてしまえばいいようなトピックに関しては、論理的思考がコストにしかなっていない。
つまり、合理的でないが論理的に判断をしてしまうケースはよくある。
それでいても論理的に考えたくなってしまうのは、論理的思考がすべてを解決してくれるように見えるからだ。
もしかしたら人は根源的に、自分が正しいことの保証を求めるのかもしれない。
夢の中でさえ論理的に思考していることがある。もはや論理的思考に操られているのかもしれないと思う。
論理的思考に操られないためには、「正しさの判断が必要か」を考えることだ。
論理的思考はすべてを解決するわけじゃなく、正しさの判断にしかならない。
「感覚で考えること」と「正しくないこと」の両方を肯定する必要がある。
まず、感覚で考えることは、論理的に考えることの真逆というわけでもない。
それに、もし考えが論理的に正しくなかったとしても「別にそれでいいじゃん」と思える寛容さや「間違ってるけど面白いね」と思える柔軟さを大切にしたい。
「君の言っていることはすべて正しいけど、面白くない。」
何年か前に読んだ雑誌のコピーで、当時かなりの衝撃を受けたことを覚えている。
今でもたまにこのコピーを思い出してドキッとすることがある。
エンジニアという職業では特に、論理的に考えることが必須なスキルとなる。
エンジニアの仕事は、正しい方向へ向かうための判断を繰り返すことに他ならない。
ビジネスのためにどのようなシステムを作るべきか？アーキテクチャの選定はビジネス課題の解決になっているか？アプリケーションの実装はビジネスが意図した動作をするか？
職業病かどうかわからないが、日常生活でも無意識に論理的に考えることが増えたように思う。
エンジニアの仕事では論理的思考は役に立つが、日常生活ではむしろ邪魔になることがある。
日常生活で正しさが求められるシーンは限られている。
正しいことが他の何よりも優先されるのかといえば、当然そんなことはない。
正しさがある程度証明されたからといって、それが何になるんだろうか？
共感を求めている人に正論を叩きつけたり、別のコンテキストに立つ人間同士が正論を言い合ったりすることは、ほとんど無価値だし、むしろ憎悪の原因にしかならない。
エンジニアの仕事でさえも、論理的思考が邪魔になる場面があると思う。
論理的に考えることは、ある程度の時間がかかる。正しさの判断をするために時間をかける必要がない場面は、無限にある気がする。
正しい判断が求められず、速攻で理由もなく決めてしまえばいいようなトピックに関しては、論理的思考がコストにしかなっていない。
つまり、合理的でないが論理的に判断をしてしまうケースはよくある。
それでいても論理的に考えたくなってしまうのは、論理的思考がすべてを解決してくれるように見えるからだ。
もしかしたら人は根源的に、自分が正しいことの保証を求めるのかもしれない。
夢の中でさえ論理的に思考していることがある。もはや論理的思考に操られているのかもしれないと思う。
論理的思考に操られないためには、「正しさの判断が必要か」を考えることだ。
論理的思考はすべてを解決するわけじゃなく、正しさの判断にしかならない。
「感覚で考えること」と「正しくないこと」の両方を肯定する必要がある。
まず、感覚で考えることは、論理的に考えることの真逆というわけでもない。
それに、もし考えが論理的に正しくなかったとしても「別にそれでいいじゃん」と思える寛容さや「間違ってるけど面白いね」と思える柔軟さを大切にしたい。
