ブログに画像を貼り付けたり、ゲームや画像処理の入力データとして数百枚の画像ファイルをそろえたりするときに、一括してファイル選択状態から解像度を変更したい時があります。
みなさんも困ったことありますよね？
一枚一枚画像編集ソフトで開いて、編集メニューから解像度指定を行って、別名を付けて保存とか…やってられません！
そこで、選択して、右クリックのコンテキストメニューからリサイズto低解像度で、ドン！と作業が完了するツールが存在しますので使ってみました。
完璧に動作しました。
ありがとうございます！
使ったツールはこちら
ダウンロードしたインストーラを実行すると、すぐに右クリックのコンテキストメニューから Resize Pictures が選べるようになります。
パフォーマンスも極めて高かったです。
忘れないうちに、便利ツールとしてメモします。
今回は、こちらの記事の続きです。
simplestar-tech.hatenablog.com
具体的にマイクロワールドを作っていきます。
構想で登場したものは以下の三つでした
まずはワールドについて構想してきたことを列挙します。
すでにブロックについて書いてきましたが、そのブロックとオブジェクトとメッセージについて動的な部分を詳しく見ていきます。
例えば、水ブロックですけど、水位パラメータは水ブロックが持つのでしょうか？
そのほか、水ブロックは内部に液体オブジェクトを持ち、そのオブジェクトに粘性や熱といったパラメータがあるのでしょうか？
複数や単体のブロックで構成される、海、湖、池、沼、バケツの水、溶岩だまりといった概念や
それを構成している、海水、真水、溶岩、ヘドロといった概念を
ブロックとして持たせるのか、オブジェクトとして持つのか、すべてメッセージとするのか
設計していく必要があります。
エージェントについて考えると
こうしたワールドの一部を切り取って、未来予測ともいえるシミュレーションを行い、アクションと結果の関係から行動の利益を導き出せるようにする必要があります。
ワールドは世界共通の現象だったとしても、エージェントはその観測した空間をブラックボードに一度コピーして、時間軸を操作してシミュレーションを行い、時に途中までのシミュレーションに戻って
何度も選択できるアクションをやり直し、最適な解を導き出す努力ができなくてはいけません。
これを可能にする設計にする必要もあります。
うーん、いざ試作するといっても、また構想に入ってしまいました。
水ブロックは、水としてふるまうための情報を、液体オブジェクトから引き出すということになる感じでしょうか？
その液体オブジェクトには必ず、流動の振る舞いを決定するパラメータをすべて持っていなくてはなりませんよね。
ある液体オブジェクトという基底クラスがあり、そこには液体特有のパラメータ（粘性、熱、揮発性）があるとします、海水、真水、溶岩、ヘドロはそれらを継承して作られたものとすれば、コード量は少なくて済みますね。
また、そうした派生オブジェクトに、メッセージを流し込んだときに、例えば溶岩に海水が面接続したときに、それぞれがリアクションを取ることになり、派生したコードの振る舞いが実行されるという設計です。
溶岩のリアクションは接続されたブロックに奪われた熱の分だけ、凝固へ向かい、ブロックを土に変えて、そのブロックの構成オブジェクトが岩石や金属、鉱石にすげ変わったり、海水のリアクションは受け取った熱の分だけ蒸発して、隣接する空気ブロックへ水蒸気を流したり、自ブロックが空気ブロックに変わって、水位とは異なる構成成分としてミネラルである塩オブジェクトが空気ブロックの中に残り、その成分はその成分量を保持したまま落下する、たい積すると塩の土ブロックになるなど。
さらに、圧力・応力というものが土ブロックにはかかり、最大応力をオーバーすると土ブロックが破断し、それに接着していたブロックが落下可能なら落下するなど
重要なことは、そのワールドを構築する際の基本的なメカニズムを正しく抽象化して、それを抽象クラスとして設計に盛り込むことです。
また、新しい概念が登場してきたので、メモします。
水位に似た、構成割合というものです。
確かに液体が熱せられて蒸発したときに、100%の土ブロックになるのは質量保存に反しすぎですね。
物質オブジェクトについても個体、液体、気体という状態変化をするという、基底の振る舞いというものが見えてきました。
マイクロワールドを動き回るエージェントには、こうした化学要素のシミュレーションも行えてほしいわけで、そのためにはワールドにそうしたシミュレーションが入る必要があります。
また、土ブロックも圧力・応力を与えると、一定の閾値で破壊、破断するという点も、建築において重要になってきます。
エージェントには、作物を育てたり、建築して自然の驚異に立ち向かったり、お金を使った経済活動を行ったり、集団で力を合わせたりしてほしいところだけど
そういった細かい部分は、ワールドの土台が固まってきてからにします。
では、ここまで構想してきたものを少しずつ形にしてみようと思います。
リソースは有限ですので、地上というものがあるのならば、地下深くまで掘り進めると限界深度となる、それ以上掘り進められない岩盤ブロックが現れるものとし
天高く積み上げていっても、一番下の土ブロックが圧壊または溶岩と化して、積み上げたブロックが沈み込み、それ以上高いところには行けないものとします。
いつか、空を飛ぶ機械をエージェントが発明して飛んだとしても、限界高度までたどり着いたら、それ以上上昇できない風ブロックがあり、風ブロック以外が面接続すると破壊されることとします。
これらが示すのは3次元空間でいうところの高さのバッファ長であり、まずはテストのためにすぐに限界が来る狭い空間として、海抜を深度0とするなら、地底に-10、天空に10ブロックとします。
まずは、深度-10に落下も破壊もない土ブロック（岩盤）を敷き詰めます。
世界が巨大な球体とするなら、地平は循環するため、例えばx方向にまっすぐ20進んだら、元のブロックに到達するという循環があるものとします。
なので、地平の果ては存在せず、海が断崖絶壁を滝のように流れ落ちるような果ては存在しないものとします。（エージェントがそうした迷信を信じるのはあり）
これでブロックにはすべて一意のインデックスが振られることになり、隣接するブロックへのインデックスも類推することができるようになります。
例えば、座標 x, y, z が 0, 0, 0 のブロックにとって、0, 0, 1 のブロックは1m上のブロックであると類推でき、同様に直下のブロックは 0, 0, -1 と類推できます。
自身のブロックの直下が風ブロックだったら、液体オブジェクトを与えられる水位だけ水ブロックが落下させるとしたとき、メッセージとしてそうした現象が成り立つようなことが伝播します。
上下は簡単ですが、周囲のブロックはどのようにインデックスが打たれるべきでしょうか？平面充足が三角形であるため、この点は簡易に決めることができません。
一辺を1unitとする正三角形なら、横方向はブロックの重心を結ぶ長さも1unitになります、縦方向はunitになりますね。
これでセーブデータなどの場所の座標から、特定のブロックへのアクセスが可能ということになります。
重要な認識としては、ブロックの位置は不変で、面接続しているブロックも切り替わることはありません。
移動するのはあくまでブロックを構成しているオブジェクトであって、それらが様々なふるまいによって気化して周囲に伝播したり、支えを失って落下したり、融解して周囲に伝播したりします。
ブロックには具体的なインデックスが振られていなくても、ブロック同士で互いに面接続しているブロックへのアドレスを保持していれば、アクセスに支障はありません。
ブロックには面接続している、合計五つのブロックへのアドレスを保持する必要があることがわかってきました。
ここまでのことを具体化すると、次のクラスが記述されました。
public class Block { int _position_east; int _position_north; int _position_depth; public Block _northEastBlock; public Block _southBlock; public Block _northWestBlock; public Block _upBlock; public Block _downBlock; } public class SoilBlock : Block { } public class WaterBlock : Block { } public class AirBlock : Block { } public class FireBlock : Block { }
これをワールド depth 20 x east 20 x north 20 blocks の 8,000 blocks の世界に配置するように
まずは、ハードディスクに初期化した世界情報を記述し、これを読み込んでメモリ上に再構成するサンプルを作り
そのメモリ上のワールド情報を Unity でビジュアライズする部分を書いてみましょう。
うーん、その後時間をおいて考えてみたのですが
すべてのブロックを大気ブロックとして、水位、密度、割合、圧力、熱という表現にオブジェクトがその割合だけ存在するというのはどうでしょうか？
つまり、空気さえもオブジェクトとなり、ブロックを何パーセント占めているかという表現になります。
例えば、海水ブロックに大気が接していたら、徐々に大気に水蒸気が伝播していき、その分海水が入っていたブロックの水位が蒸発した分だけ下がり続け、上昇した塩分濃度がほかの接している海水ブロックに伝播して同じ塩分濃度になるといった具合です。
そうすると、常にブロックは位置も変わらず、種類も変わらず、含んでいるオブジェクトの伝播の振る舞いに従って自身や周囲のブロックの構成成分を変容させていくだけとなります。
しかし、Minecraft と Unity で作ってみたっていう動画を探してみたのですが、例がわんさか出てきますね。
オブジェクト数が数千、数万と出ていそうなビューなのにフレームレートがあまり落ちないような動画とかもあるし、いったいどういうマシンで遊んでいるんだろう？
それと、みんなどれだけ Unity で Minecraft 作りたいんだって感じです。
AIを作りたいかは別として、同じようなことを考える人はいっぱいいるんですね。
また、記事が長くなってきたので、次の AI カテゴリーの記事へ続きを書きます。
Unity でビジュアライズしている何かしらのアルゴリズム（AIとか画像処理とか）について、処理中にUIが固まることはユーザービリティの面から看過できません。
Unity 2017 になってから、C# 5.0 からの新機能 Task(async/await) が使えるようになりました。
これを使うだけです。
ただ使うには、PlayerSettingsをExperimental(実験的な設定)に変更する必要があります。私は次の記事を参考に変更しました。
qiita.com
具体的なコードとしては
await Task.Run 以降のラムダ式をメインスレッドとは別のスレッドにて非同期実行させることができます。
await キーワードは async キーワードを付けた関数の中でなければ、記述できません。
ということで、以下のようなコードで重い処理を別スレッドで書き、結果が出たらスレッドアンセーフでゲームオブジェクトへ適用することができるようになります。
using System.Collections; using System.Threading; using System.Threading.Tasks; using UnityEngine; public class ThreadTaskTestBehaviour : MonoBehaviour { void Start() { this.MoveAsync(); } private async void MoveAsync() { var context = SynchronizationContext.Current; await Task.Run(() => { for (int i = 0; i < 10000; i++) { if (9999 == i) { Vector3 position = Vector3.zero; Debug.Log("i = " + i); context.Post((state) => { position = this.transform.localPosition; Debug.Log("position.x = " + position.x); position.x -= i * 0.01f; this.transform.localPosition = position; Debug.Log("in post position.x = " + position.x); }, null); Debug.Log("out of post position.x = " + position.x); } } }); } }
Action を切り離して書くと以下のような感じです
using System; using System.Threading; using System.Threading.Tasks; using UnityEngine; public class ThreadTaskTestBehaviour : MonoBehaviour { private static SynchronizationContext _context; void Start() { _MoveAsync(); } void Update() { Debug.Log("Update"); } private async void _MoveAsync() { _context = SynchronizationContext.Current; await Task.Run(_Action); } private Action _Action = () => { const int loopMax = 10000; for (int i = 0; i < loopMax; i++) { Debug.Log("Action i = " + i); if (loopMax == i + 1) { _context.Post((state) => { Debug.Log("in main thread"); }, null); } } Debug.Log("finish"); }; }
別に await 付けなくても、Task.Run 以降のラムダ式を別スレッドとして実行できます。
await するからには実行完了を待つわけで、ゆえに async 関数の中でないと宣言できないというわけでした。
併せて読みたいのは引数をスレッドごとに変えて渡す方法です。
simplestar-tech.hatenablog.com
また、次の私の記事でUniRx を勉強していて見つけたのですが
simplestar-tech.hatenablog.com
UniRx を導入すると次のコードで別スレッド処理を実行できました。
Observable.Start(() => {
// ここに別スレッドで行う処理
})
.ObserveOnMainThread()
.Subscribe(_ => { });
しかし、2018年中ごろには、Unityが並列処理を行う C# Jobs System を入れてくるらしいので、いずれはそれを使うことになるかもですね。
以下、参考にした記事
Unityでのマルチスレッド処理はみなさんの関心事なんだなって思います。
techblog.kayac.com
tyheeeee.hateblo.jp
satoshi-maemoto.hatenablog.com
qiita.com
qiita.com
およそ9ヶ月前の記事にて、AIが行動するマイクロワールドを作ることを宣言しました。
この記事では、そのマイクロワールドをプロシージャルに、つまり数式や処理を組み合わせて生成する方法について考察し、実践していきます。
その記事というのがこちら↓
simplestar-tech.hatenablog.com
「頑張って言葉にすると、AIが行動するマイクロワールドを作り、それを観察できるオンラインゲームを作ってみたいと考えています。」
大目標は、観察するとまるで自律的に行動する知能がそこにあると錯覚するようなエージェントをマイクロワールド内に登場させることです。
大枠で必要になってくるのは次の三つです。
１．マイクロワールド
２．それを観測して、影響を与えられるアクションが実行できるエージェント機構
３．ワールド・エージェントそれぞれの制御ロジック
素人がAIについて考えると、１．２．の部分の構想をおろそかにして、３．のエージェントの制御ロジックに焦点を当てて議論を始めます。
過去の研究者がそうでした。
AIによって、現実世界の問題を解こうとする研究者もまた多くいます。
その方が、世の中のためになり、お金になる未来があるからですが
しかし、そこには現実世界を100%正しく認識するという、きわめて難しい課題が存在しています。
この課題は、半世紀以上、人類が頭を悩ませ続けても、だれ一人完成させることができませんでした。
断言できるのは、ここで私が努力を続けても、絶対に解決できないということです。
そこで、私は仮想世界の問題を解こうとするエージェントを用意し、仮想世界を100%認識できる機構をあらかじめ用意することで
これまで人類が到達できなかった課題の解決を先送りにして、さらに先にあるエージェントの制御ロジックを考えてみることを思いつきました。
なので、今、世界中の研究者が行っている次の三つの必要項目を
１．現実世界
２．現実を観測して、影響を与えられるアクションが実行できるロボット機構
３．ロボットの制御ロジック
繰り返しになりますが、私は次の三つに置き換えて
１．マイクロワールド
２．それを観測して、影響を与えられるアクションが実行できるエージェント機構
３．ワールド・エージェントそれぞれの制御ロジック
AI研究をするなら仮想世界の構築から行う必要がある、というメッセージを持って、これに従って行動していくことにしました。
では、その仮想世界（マイクロワールド）をどのようにして作っていくのかを考えていきましょう。
前提として考えておかなければならないことを次に列挙します。
１．私のやる気と時間が限られたリソースであること（これ、一番大事）
２．コンピュータもメモリとハードディスクと計算量は限られたリソースであること
１．を考慮したとき、マイクロワールドの構造の現実的な回答は、要素シミュレーションによるプロシージャル生成になります。
例えると、宇宙空間にビックバンインパクトを巻き起こして、200億年ほど原子とその相互作用を計算し今のような世界を構築するといった、神が行ったアプローチに似た手法です。（詳細は知らないけど）
つまり、世界の構成要素を一つ一つ手作業で作りこむことはしたくないということです。
２．をここで考慮すると、世界をモデル化して、かなり大きな粒度で相互作用を計算する仕組みが必要になってきます。
例えると、マインクラフトのような1m立方のブロックで構成された世界を、視野に収めたブロックの部分だけが最長16ブロック単位でだけ相互作用する構造です。
あと、Unity で作るというのも私にとって必要なことですね。
まずは、こうした誰でも思いつくようなマイクロワールドの構造を、提供してくれるようなUnityアセットを探してみましょう。
うーん、残念ながら AI 向けに、ブロック情報を取得しつつ、絵を出すようなアセットは見つかりませんね。
多くは、見た目重視のテレインの自動生成ツールばかりです。
www.denispahunov.ru
www.terraincomposer.com
調べ方を変えて、マイクラ風な地形生成で調べてみたところ、パーリンノイズを使った手法が多数ヒットしました。
ワールドの初期状態決めについては、こうした地形生成が良さそうですね。
さっそく試してみました。
なるほど、地下深くまで掘り下げているわけではないですが、かなり描画負荷が高いですね。
マインクラフトは描画を高速化するための、かなり軽量化するアイディアが詰まっているものと思われます。
歴史的に、プロシージャル技術の初期の狙いはメモリ使用量の削減でした。
そこで、これから作るマイクロワールドの設計について、人類がまだ近代科学に至る前の思想を用いて
次のアイディアを盛り込もうと思います。
１．Unity 表示非依存のモデル（データ空間）におけるマイクロワールドの記述
２．格子状のブロックで構成される
２－１．平面充填（へいめんじゅうてん）は三角形（マインクラフトの四角形とは異なる）
２－２．ブロックは三角柱
２－３．ブロックには基底クラスが割り当てられ、面接続された上下2つのブロックと周囲3つのブロックを参照できる
３．ブロックの種類は四元素（火、風（空気）、水、土）があり、五行説（木、火、土、金、水）によって直接作用し合い、日と月の影響を間接的に受けて変化する
雷（電気）は、ひとまず保留します。
ブロック同士の作用を考えながら、基底クラスに必要なものを創り出していきます。
Unity 非依存なので MonoBehaviour は継承することはないです。
Unity ゲーム内にてブロックを表示することになったりすると、様々なコンポーネントを追加するために
MonoBehaviour を継承したブロック操作クラスは必要になりますが
何も、この基底クラスを継承して作ることはなく、単に情報を引き出す形で紐づけるだけで良いはずです。
重要なのは、まだ議論に出てきていない、エージェント・アーキテクチャの部分です。
エージェント・アーキテクチャとは、車の運転免許試験の教本の表紙に書かれているような
認知→判断→行動
の仕組みのことです。（終わり）
どうも、この運転教本に載ったあたりまえのフレーズを、高尚な表現としてゲームAIの業界ではエージェント・アーキテクチャって言うらしいですよ。
まぁ、もう少し付け足すと、認知（認識）モジュール、判断（思考）モジュール、行動（アクション）モジュールに分けて、それぞれを短期記憶装置（ブラックボード）とのメッセージのやり取りで実現する、ゲーム内のキャラクターの制御機構といった感じです。
モジュールを分割することによって、集団で開発する際に並列作業が行いやすくなり、変更の影響範囲が限定できることから、デバッグも行いやすくなるという設計となっています。
このエージェント・アーキテクチャに概ね従う形で、作っていくとして、マイクローワールドがどのように、このエージェント・アーキテクチャに関わるのかを考えていきましょう。
認識モジュールでは、マイクロワールドのどの情報が、どのようにアクセスされるのか想像してみましょう。
最も重要なことは、感覚器官に正しい経路で、正しく情報が伝達されることです。
感覚器官は全部で五つ、視覚、聴覚、嗅覚、触覚、味覚です。
中でも、視覚
これが知能にとって最も難しい認識処理となります。
カメラを設置してカメラ画像のようなものを思考モジュールに与える？
確かに現実問題を解くにはこの方法が正しい情報の伝達となります。
gym.openai.com
このように OpenAI でも Minecraft のカメラ画像を入力とするチャレンジがあります。
しかし、残念ながら、画像だけ入力することによる機械の正しい認識は、生涯叶わない夢であると、私は早々にあきらめているので
ここでは、画像ではなく意味を受け取ることにします。
例えば、視界に入った木のブロックが燃えているならば、認識モジュールには、目の前の木が燃えている、という意味が正しく伝わるようにするのです。
さて、ここで視界に入るとは、どのようにして実現されるのでしょうか？
考えてみましょう。
エージェントからレイ（光線）を飛ばして、空気を通って当たった最初の不透明なブロックの情報を引き出して、エージェントにそのブロックに起きている情報を与える
そのほか、視野空間としての円錐の中にあるブロックの情報をすべてを取得し、すべての情報を受け取るなど、方法はいくつか考えられます。
ここで、透明なブロックとは空気やガラスといった材質のブロックのことですね。
重要なのは確実さと、速度ですので、効率的にブロックの隣接するペアをたどっていく形式とします。
少し楽観的ですが、これで方向と距離をたどることで、視界に入る必要な情報すべてを手に入れられるとしましょう。（少なくとも調査対象のブロックは列挙できるものとします。）
次は聴覚についてです。
音が空間を伝わると考えたとき、これも音源から空間をたどって周囲のブロック、場合によっては壁越しに音が伝わるとします。
ここで重要な概念として、音などのメッセージの種類と内容が周囲に伝播する仕組みが必要になることが見えてきます。
このメッセージの種類と内容というのは、そのまま思考モジュールに渡るのではなく、認識モジュールのフィルタリングを経て、ブラックボードに書き込まれ、これを思考モジュールが必要に応じて取り出し、アクションを取るべきか判断します。
さらに重要なことが見えてきました。
それは、ブロック間を伝わるメッセージは認識や思考モジュールが利用するメッセージと同じ形式ということです。
嗅覚も同様、においというメッセージが空間を伝播することにより、周囲の認識モジュールにて拾われることになります。
触覚は触れなければならないので、エージェントの身体とも呼ぶべき「構成物体」が隣接したときに、確かなメッセージとして伝わります。
最後の味覚に関しては、オブジェクト？をくちに入れるなどして、味覚としてエージェントが認識します。
これは、対象をくちに入れる、入れられるというアクションによって起きる現象ですね。
甘味、苦味、酸味、塩味の４つの基本味と、さらにうま味の混合パラメータをオブジェクトからメッセージとして受け取れると良いですね。
ここで、新しい概念が登場しました。
オブジェクトです。
世界を構成している四つの元素ブロックの他に、それらによって作り出されたオブジェクトという情報単位が、物質として世界に存在します。
それらも世界を構成する時は、ブロックの中に配置され、混合物として可視のものとなります。
ブロックは複数のオブジェクトによって構成されていることになりました。
オブジェクトもまた、複数のオブジェクトによって構成されることはあるのでしょうか？
例えば、葉オブジェクトが集まった草オブジェクト、その草オブジェクトが集まった…なんですかね？
た、例えば、石オブジェクトが集まった砂利オブジェクト、その砂利オブジェクトが集まった…なんですかね？
うーん、混合物というものは、すべて同一の粒度のオブジェクトによって構成されているとは限らない、とするなら
良い例は思いつかなくても、オブジェクトは何らかのオブジェクトによって構成されているということで問題ないはずです。
人工物なら、説明がしやすいのですけどね。
カバンの中に財布がある、財布の中にお金がある。
といった具合に、カバンオブジェクトによって構成される、貨物ボックスというオブジェクトも定義できます。
また、それ以上分割できないプリミティブなオブジェクトというものは存在できず、どこまでも構成要素として分割できるとして
それは観測する側の限界分解能において、それ以上分割してメッセージを処理する必要がないものとします。
いつか、バケツに入っているのが水であるならば、そのバケツを倒すと、その水がこぼれることを予想するように
オブジェクトの構成要素にも注意をはらう人工知能が作れることを願い、オブジェクトの包含関係を記述することとします。
そろそろ構想してきたものを形にして、実際に動かしながら不備を見つけていきたいと思います。
次回は、マイクロワールドを構築するプログラムを設計、実装していこうと思います。
今朝は、次を訳してみます。
タイトル：我々は向かっていた、ユダヤの人々の歴史における重大な分岐点の一つに
保守的なユダヤ教主導者における小さな声集団が、ユダヤ人と非ユダヤ人との結婚を受け入れる動きを後押ししています。
この戦いはまさにユダヤ教の未来に関わっているといえます。
-
6月の終わり 19 日にユダヤ教主導者たちはニューヨーク市に集められた、ある緊急の会議のために。
その会議は極秘のものではありませんでしたが、それはまた公開されて行われたものでもありませんでした。
そのユダヤ教主導者たちは保守的な活動の議会であり（二人を欠いた状態）- 国際結婚についてどうするかを決定するためにそこに集まった。
1970年より、その保守的な活動は、ユダヤ人と非ユダヤ人との間の結婚を公式に認めることや、式に参列することさえ禁止してきた。
その宗派は改革や復興主義の運動よりも歴史ある存在であるが、その宗派がその宗教主導者たち自らに対する国際結婚の疑問の取り決めを許すことになる。
しかし、時間の経過とともに、保守的なユダヤ主義者らはまた正統派の慣行よりも現代の生活を容認する意思をも示した、宗教の最も敏感な方針の一つの内側からの挑戦への明らかな弱みを残して
もう、時間か…全然早く読めない…
今日はこちらを訳します。
間違って読んでいる可能性がありますので、すべてを真に受けないでください。
タイトル：お片付けの経済学
出版から数か月が経過し、日本の家庭組織の指導者、近藤真理恵さんの書籍がーその書籍は「断捨離」に関するものーいま最も関心される書籍に至った。
行動科学がその魅力を説明します。
-
「この本には、あなたの人生を変える方法として、どのようにしてあなたの空間を配置するかということが、まとめられています」
これは近藤麻理恵さんが書いたベストセラー書籍「人生がときめく片付けの魔法」の最初の熱意ある一文です。
直接かつ迷いないこの文章は彼女の哲学を真に響かせています。
多くの自助的な書物とは違い、的外れな単語は含まれておらず、気に入られようとすることもなく、こびる文章が少ない、真実の文章がそこにはある。
昨年の10月に英語版にて彼女の書籍が出版されたけれども、彼女に対するGoogleトレンドはいまだ高い関心がほぼずっと続いている。
日本語での検索結果もまた似たような結果となっている、2010年に日本語版が出版されているのに
もしGoogleサーチが何も意味しなかったとしても、片付けに関しては関心はまた高い状態にあり、この関心の高まりの要因は近藤さんの方法の登場にあるに違いない、その方法とはただ幸せをもたらすという一点にこだわったものである。
この断捨離に従い、近藤さんは身の回りの物を取り出しやすく、めちゃくちゃになりづらい方法について、明確な方向性を示しています。
多くのジャーナリストは彼女の方法を実践し、そして「彼女は私の人生を変えてくれた」という感謝の言葉が多くあります。
SNSの何でも聞いてという近藤さんの書き込みにて、一人の熱心なファンが10歳以下の子供たちにあなたの方法を教えるにはどうすればよいのか聞いています。
はい、ということで感想です。
意味が頭に入ってくるのに日本語で表現できない文章がありますね。（おもしろ！）
近藤さんの片付けの技術はアメリカで大絶賛されてますね、こうして海外の記事を読んだときに活躍する日本人を見つけると、なんだか嬉しくなりますね。
さっそく、二日連続でさぼってしまった…
また訓練を続けてみたいと思います。
今日は朝と夕方の2回に分けて頑張ってみます。
次の記事を読みました。
www.theatlantic.com
タイトル:ミリヤム・ミルザハニー,最初の女性：勝利した人 数学の最も高い賞について が亡くなる 40歳で
ミリヤム・ミルザハニー氏の仕事は未来の知見を変えたかもしれない その知見とはどのように宇宙が形成されたかというもの
-
ミリヤム・ミルザハニー:最初にして唯一次の賞を獲得した女性が 土曜日に亡くなりました 名声高いフィールズ賞（功績をあげた若き数学者に与えられる賞、数学のノーベル賞とも呼ばれる）。
ミザルハニー氏はスタンフォード大学の教授で、大学は公式発表しました、内容は 彼女の乳がんが骨まで転移して死に至ったとのことです。彼女は40でした。
ミザルハニー氏は著名な賞を獲得しました、それは4年に一度与えられる賞で、2014年に彼女の幾何学と動力学の技術体系の功績に対してのものでした。
彼女の功績のほとんどは学術的に高度で、スタンフォード大学の声明によると、まるで「外国語」とも読めてしまうと思いますね、領域の外側の人にとっては モジュライ空間（普遍なパラメータ空間）、タイヒミュラー理論（リーマン面の分類、先のモジュライ空間と関係）、双曲幾何学（負の曲率を持つ曲田空間における幾何学）、エルゴート理論（力学に関与）そしてシンプレクティック幾何学（斜交ベクトル空間とか、新プレティック形式に関する…）
…
はい、ということで
途中から、道を逸らしてしまって、あっという間に30分経過してしまいました。
彼女の功績は、門外漢にとってまさに外国語ですね。
世界は人類の未来の認識を変えうる重要な方を失ってしまったんだな
それは人類にとって、とても大きな損出であったと思い知らされる記事でした。
