/*
google Mapの座標値から距離を求めるルーチン
2018-03-21(水) 14:41:31
gcc -c location_calc.cpp
*/
#include <math.h>
typedef struct location{
// ちなみに X,Y 軸座標は、→に＋ ↑に＋
double longitude; // 経度 東経 139.691 X軸
double latitude; // 緯度 北緯 35.698 Y軸
} LOCATION;
#define rad2deg(a) ((a)/M_PI * 180.0) /* rad を deg に換算するマクロ関数 */
#define deg2rad(a) ((a)/180.0 * M_PI) /* deg を rad に換算するマクロ関数 */
double distance_km(LOCATION* A, LOCATION* B, double *rad_up)
{
double earth_r = 6378.137;
double loRe = deg2rad(B->longitude - A->longitude); // 東西
double laRe = deg2rad(B->latitude - A->latitude); // 南北
double EWD = cos(deg2rad(A->latitude))*earth_r*loRe; // 東西距離
double NSD = earth_r*laRe; //南北距離
double distance = sqrt(pow(NSD,2)+pow(EWD,2));
*rad_up = atan2(NSD, EWD);
return distance;
}
LOCATION* new_location(LOCATION* D, double diff_p_x, double diff_p_y)
{
double earth_r = 6378.137;
double loRe = diff_p_x / earth_r / cos(deg2rad(D->latitude)); // 東西
double laRe = diff_p_y / earth_r; // 南北
double diff_lo = rad2deg(loRe); // 東西
double diff_la = rad2deg(laRe); // 南北
static LOCATION C;
C.longitude = D->longitude + diff_lo; // 東西
C.latitude = D->latitude + diff_la; // 南北
return &C;
}
double diff_longitude(double diff_p_x, double latitude)
{
double earth_r = 6378.137;
// ↓ これが正解だけど、
double loRe = diff_p_x / earth_r / cos(deg2rad(latitude)); // 東西
// 面倒なので、これで統一しよう(あまり差が出ないしね)
//double loRe = diff_p_x / earth_r / cos(deg2rad(35.700759)); // 東西
double diff_lo = rad2deg(loRe); // 東西
return diff_lo; // 東西
}
double diff_latitude(double diff_p_y)
{
double earth_r = 6378.137;
double laRe = diff_p_y / earth_r; // 南北
double diff_la = rad2deg(laRe); // 南北
return diff_la; // 南北
}google Mapの座標値から距離を求めるルーチン
なんで、こんなに沢山の言語と付き合っているのに、「英語」という言語にだけは愛されないんだろうか？
私は、GA(Generic Algorithm:遺伝的アルゴリズム)の実装を、何度、違う言語で実装し直しているんだろう ――
"How many times have I reimplemented GA (Genetic Algorithm) in a different language?"
と、デバッグしながらボンヤリと考えています。
I've been thinking about this while debugging.
一番最初に、作った時は"Pascal"だったような気がする。
I think the first time I made it, it was in "Pascal".
次に、"C"だったかな。
Next, I think it was "C".
でもって、"python"でもやったような気がする。
And, I think I've done that in "python2 as well.
さらに、"C++"でも実装した記憶がある。
Furthermore, I remember implementing it in "C++" as well.
でもって、今は"Go"だ。
It's "Go".
『車輪の再開発』という次元を遥かに超えている。
It goes far beyond the "redevelopment of the wheel" dimension.
-----
もはや、マルチリンガルの域を超えているな。プログラム言語だけど。
I am no longer multi-lingual. It's a programming language.
なんで、こんなに沢山の言語と付き合っているのに、「英語」という言語にだけは愛されないんだろうか？
Why is it that I've been with so many languages, but only the language "English" doesn't love me?
本気で「理不尽」だと思う。
I seriously think it's "unreasonable".
-----
"GA"は、本当に便利なんです。
"GA" is really useful.
遺伝子(というか染色体)の設計と、評価関数だけ定義しておけば、風呂に入っている間に、そこそこの最適解をサクっと出してくれる、優れものです。
If I just define the design of the gene (or chromosome) and the evaluation function, it will quickly give me the best solution while I am taking a bath.
ただ、致死遺伝子の発生を防ぐ遺伝子設計は、凄く難しい。
However, it is very difficult to design genes that prevent the generation of lethal genes.
今やっている順序表現方式でも、親の遺伝子形質の半分は完全に破壊されてしまうという点が、不満です。
I am not happy with the fact that even with the ordered expression method we are using now, half of the parental genetic traits will be completely destroyed.
そろそろ終焉を感じさせる「AIブーム」ですが、このブームの中で、私が心から評価している技術は、2つ(深層学習と強化学習)だけです。
The "AI boom" seems to be coming to the end, and there are only two technologies (deep learning and reinforcement learning) that I truly appreciate in this boom.
しかし、私は、GAの新しい遺伝子設計方法が発表されて、これらの2つの技術を「軽くぶっちぎって欲しい」という気持ちがあります。
However, I am hoping that the new genetic design method of GA will be released, and I'm hoping that the new GA will "lightly beat" these two technologies.
-----
いずれにしろ、私は、"GA"のことを、"人工知能"などという、軽薄な用語では呼びたくないのです。
In any case, I don't want to call "GA" like such frivolous terms as "Artificial Intelligence".
/* GAでTSP問題を解くときの超定番である、 「ルート表現から順序条件に変換するアルゴリズム」と 「順序表現からルート表現に変換するアルゴリズム (前記の逆変換)」に加えて、 「交叉：２つの遺伝子をランダムな位置で交叉させる」 「変異：遺伝子の中でランダムに２点を交換する」 「遺伝子を作る」をサブルーチンにしてみた件 */
Golangのサブルーチン化って、結構面倒くさい
■mainの後に記載しないと、文句言われる(VSCodeから)
/* GAでTSP問題を解くときの超定番である、
「ルート表現から順序条件に変換するアルゴリズム」と
「順序表現からルート表現に変換するアルゴリズム (前記の逆変換)」に加えて、
「交叉：２つの遺伝子をランダムな位置で交叉させる」
「変異：遺伝子の中でランダムに２点を交換する」
「遺伝子を作る」をサブルーチンにしてみた件 */
package main
import (
"fmt"
"math/rand"
"time"
)
func main() {
rand.Seed(time.Now().UnixNano()) //シード変更可
var sliceZ = [100][]int{} // 100固体
for i := 0; i < 100; i++ {
sliceZ[i] = getInitDNA()
fmt.Printf("sliceZ[%v]: %v\n", i, sliceZ[i])
}
var sliceX = []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
var sliceY = []int{0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
sliceX = mutatePath(sliceX)
fmt.Printf("mutate sliceX: %v\n", sliceX)
//var sliceZ = []int{} // 念のための初期化
//var sliceW = []int{}
fmt.Printf("old sliceX: %v\n", sliceX)
fmt.Printf("old sliceX: %v\n", sliceY)
sliceX, sliceY = crossPath(sliceX, sliceY)
fmt.Printf("new sliceX: %v\n", sliceX)
fmt.Printf("new sliceX: %v\n", sliceY)
fmt.Printf("=======\n")
// ルート表現から順序条件に変換するアルゴリズム
var sliceA = []int{7, 8, 0, 4, 1, 6, 3, 9, 5, 2} // ルート表現
//var sliceB = []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
var sliceC = []int{} // 順序条件が入るところ
fmt.Printf("sliceA: %v\n", sliceA)
sliceC = encodePath(sliceA)
fmt.Printf("sliceC: %v\n", sliceC)
fmt.Printf("=======\n")
sliceA = []int{} // sliceAのリセット
sliceA = decodePath(sliceC)
fmt.Printf("sliceA: %v\n", sliceA)
}
// 遺伝子を作る
func getInitDNA() []int {
var sliceA = []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
var sliceB = []int{}
length := len(sliceA)
// 参考: http://okwave.jp/qa/q7687312.html
for i := 0; i < length; i++ {
k := rand.Intn(len(sliceA))
j := sliceA[k]
sliceA = append(sliceA[:k], sliceA[k+1:]...) // k番目の要素を削除
sliceB = append(sliceB, j)
}
return sliceB
}
// 変異：遺伝子の中でランダムに２点を交換する
func mutatePath(sliceA []int) []int {
length := len(sliceA)
pos1 := rand.Intn(length)
pos2 := rand.Intn(length)
tmp1 := sliceA[pos1]
tmp2 := sliceA[pos2]
sliceA[pos1] = tmp2
sliceA[pos2] = tmp1
return sliceA
}
// 交叉：２つの遺伝子をランダムな位置で交叉させる
func crossPath(sliceA []int, sliceB []int) ([]int, []int) {
length := len(sliceA)
pos := rand.Intn(length-1) + 1
fmt.Printf("pos: %v\n", pos)
sliceA1 := make([]int, length)
copy(sliceA1, sliceA)
sliceB1 := make([]int, length)
copy(sliceB1, sliceB)
var sliceC = append(sliceA1[:pos], sliceB1[pos:]...)
sliceA2 := make([]int, length)
copy(sliceA2, sliceA)
sliceB2 := make([]int, length)
copy(sliceB2, sliceB)
var sliceD = append(sliceB2[:pos], sliceA2[pos:]...)
return sliceC, sliceD
}
// パスを順序表現から戻す
func decodePath(sliceC []int) []int {
var sliceB = []int{}
// スライスBを作る 抜き出すための数値列 0,1,2,3,4,
for i := 0; i < len(sliceC); i++ {
sliceB = append(sliceB, i)
}
var sliceA = []int{} // 今からルート表現を入れるところ
for i := 0; i < len(sliceC); i++ {
k := sliceC[i]
j := sliceB[k]
sliceA = append(sliceA, j)
sliceB = append(sliceB[:k], sliceB[k+1:]...) // k番目の要素を削除
}
return sliceA
}
// パスを順序表現に符号化する
func encodePath(sliceA []int) []int {
var sliceB = []int{} // 抜き出すための数値列 0,1,2,3,4,
var sliceC = []int{} // 順序条件が入るところ
// スライスBを作る
for i := 0; i < len(sliceA); i++ {
sliceB = append(sliceB, i)
}
// ルート表現から順列表現に変換
for i := 0; i < len(sliceA); i++ {
for k := 0; k < len(sliceB); k++ {
if sliceA[i] == sliceB[k] {
sliceC = append(sliceC, k)
sliceB = append(sliceB[:k], sliceB[k+1:]...) // k番目の要素を削除
break
}
}
}
return sliceC
}その他golangに関してVSCodeから文句を言われる項目としては、
■変数に"_"使うと怒られる
■記載方法にケチをつけられる
func subroutine()
{
...
}
と記載すると怒られる。
func subroutine(){
...
}
としなければならない
GAでTSP問題を解くときの超定番である、「ルート表現から順序条件に変換するアルゴリズム」と「順序表現からルート表現に変換するアルゴリズム (前記の逆変換)」をGolangで試してみた件
/*
GAでTSP問題を解くときの超定番である、
「ルート表現から順序条件に変換するアルゴリズム」と
「順序表現からルート表現に変換するアルゴリズム (前記の逆変換)」を
Golangで試してみた件
*/
package main
import "fmt"
func main() {
// ルート表現から順序条件に変換するアルゴリズム
var sliceA = []int{7, 8, 0, 4, 1, 6, 3, 9, 5, 2} // ルート表現
var sliceB = []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
// 1111 var sliceC = [10]int{} // 順序条件が入るところ
var sliceC = []int{} // 順序条件が入るところ
// ルート表現から順列表現に変換
for i := 0; i < len(sliceA); i++ {
fmt.Printf("i: %v\n", i)
for k := 0; k < len(sliceB); k++ {
fmt.Printf("k: %v\n", k)
if sliceA[i] == sliceB[k] {
fmt.Printf("before Slice_A: %v\n", sliceA)
fmt.Printf("before Slice_B: %v\n", sliceB)
fmt.Printf("before Slice_C: %v\n", sliceC)
// 1111 sliceC[i] = k
sliceC = append(sliceC, k)
sliceB = append(sliceB[:k], sliceB[k+1:]...) // k番目の要素を削除
fmt.Printf("after Slice_A: %v\n", sliceA)
fmt.Printf("after Slice_B: %v\n", sliceB)
fmt.Printf("after Slice_C: %v\n", sliceC)
fmt.Printf("\n")
}
}
}
fmt.Printf("=======\n")
// 順序表現からルート表現に変換するアルゴリズム (上記の逆変換)
sliceA = []int{} // 今からルート表現を入れるところ
sliceB = []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
// sliceCには、すでに順序表現が入っている
for i := 0; i < len(sliceC); i++ {
fmt.Printf("i: %v\n", i)
k := sliceC[i]
fmt.Printf("k: %v\n", k)
j := sliceB[k]
fmt.Printf("j: %v\n", j)
fmt.Printf("before Slice_C: %v\n", sliceC)
fmt.Printf("before Slice_B: %v\n", sliceB)
fmt.Printf("before Slice_A: %v\n", sliceA)
sliceA = append(sliceA, j)
sliceB = append(sliceB[:k], sliceB[k+1:]...) // k番目の要素を削除
fmt.Printf("after Slice_C: %v\n", sliceC)
fmt.Printf("after Slice_B: %v\n", sliceB)
fmt.Printf("after Slice_A: %v\n", sliceA)
}
fmt.Printf("\n")
}
―― もし、あなたが、同じような時系列、立場で、技術の進化やイノベーションに追い立てられたとして、『普通に今のデジタル技術を使いこなすことができた』と断言できますか？
(Continuation from yesterday)
Yesterday, I wrote about the fact that the elderly cannot change.
私の中にある、もっとも古い記憶は ―― 小さいブラウン管の白黒テレビです。
The earliest memory I have is of a small cathode-ray tube black and white TV.
記憶にはないのですが、私の時代と重なっているはずのことでは ―― 冷蔵庫とは、近所までやってくる「氷屋」から氷の塊を購入して、それを庫内に入れる、というものでした。
I don't remember that, however, as far as my time is concerned, a refrigerator was one where they would buy a block of ice from an "ice man" who would come to your neighborhood and put it in the refrigerator.
洗濯機は二槽式で、脱水は手動ローラーで行うものでした。
The washing machine was a two-tank type, and dehydration was done with manual rollers.
-----
電子レンジは、最初は40万円くらいしたと思います。
I think the microwave oven initially cost about 400,000 yen.
ワープロは200万円くらいだったかな。
A word processor was about 2 million yen.
OSのないPC-9800は、フルセットで50万円くらいでした。
A PC-9800 without an OS was about 500,000 yen for a full set.
パソコンが使える奴は、(「おたく」と呼ばれる前は)「完璧な技術エリート」でした。
Anyone who could use a computer (before they were called "Otaku") was the "perfect technical elite".
しかし ―― 今や、スマホは国民全員が所有するものと『決めつけられました』。
However -- we have now been 'decided' that every citizen should own a smartphone.
自営業の人はPCで確定申告を行う人が強要され、国民は、行政サービスの書類の入手を、マイナンバーカードを使ってコンビニで行うように促されています。
Self-employed people are forced to use their PCs to file their tax returns, and citizens are encouraged to use their My Number cards to obtain documents for government services at convenience stores.
-----
何がいいたいかというと ―― デジタル化について行けない、私たち高齢者はそんなに『悪い』か？
What I'm trying to say is -- are we older people so 'bad' that we can't keep up with the digitalization?
ということです。
いえいえ、分っています。
No, no, no, I understand.
この私こそが、「デジタルを使えない高齢者を追い込んで、責めたてている当事者」であることは。
I know that I am the one who is blaming the elderly for not being able to use digital technology.
ただ、普通に考えて、
To be frank,
―― もし、あなたが、同じような時系列、立場で、技術の進化やイノベーションに追い立てられたとして、『普通に今のデジタル技術を使いこなすことができた』と断言できますか？
"If you were driven by technological evolution and innovation in a similar timeline and position, can you say with certainty that you could normally use today's digital technology?
と。
-----
まあ、私を含めた高齢者の皆様。
Well, all you elderly people, including me.
もちろん全てではないですが、国民の大部分は、戦禍に直接巻き込まれることなく、平和な国で生きることができした。
Not all of them, of course, but the majority of the people were able to go about their lives in a peaceful country without being directly involved in the ravages of war.
上手くいけば、戦禍に直接巻き込まれることなく、死んでいくこともできそうです。
Hopefully, we will not be directly involved in the ravages of war and will be able to die.
「デジタル」という災禍に巻き込まれましたが、まあ、受忍できる範囲だと諦めましょう。
We've been caught up in a "digital" disaster, but let's just say it's tolerable.
私たちが邪険にされ続けることで、私たちの世界はより良くなって行くのです ―― 多分。
The more we continue to be wicked, the better our world will become -- maybe.
■「高齢者を組織のトップから、ナチュラルに排除」する技術
『年齢を重ねることは、それ自体が「権力」になる』という話を、このコラムでちょっと書いた気がします。
I think I've written a little bit in this column about how "ageing itself becomes a 'power'".
能力がなくても、実績がなくても、高齢者は権力になる ―― これは、「儒教の敬老思想」の負の側面です。
Even if they are not capable or have no achievements, the elderly come to get the power -- this is the negative side of the Confucian concept of respect for the elderly.
能力があって実績もある高齢者ともなれば、もう誰も逆らえません。
No one can resist an elderly person who is capable and has a good track record.
当然です。
It is natural.
-----
加えて、人間は、高齢になればなるほど、パラダイムを変えるのが辛くなります ―― もちろん、私も辛い。
In addition, the older we get, the harder it is to change the paradigm -- and of course, the harder it is for me.
前にも述べましたが、私は「夫婦別姓」を獲得するのに数年、「同性婚」を獲得するには10年以上かかりました。
As I mentioned before, it took me several years to get "marital separation" and more than ten years to get "gay marriage".
これらを理解する為の自己学習(自習)は、長く辛いものでした。
The self-learning (self-study) to understand these things was long and painful.
この辛さが分からない人は、自分や家族をリアルにイメージして、
If you don't know how hard this is, imagine yourself and your family in a realistic way.
―― 血縁婚(兄弟婚、姉弟婚、兄妹婚、姉妹婚、親子婚)
"Blood marriage (brother marriage, sister marriage, brother-sister marriage, sister marriage, parent-child marriage)"
を受け入れれるようになるのに、どれくらいの時間と勉強が必要になるか、を、頭の中でシミュレーションしてみて下さい。
Try to simulate them in your mind how much time and study you will be able to accept them.
(という事例でいいのかな？ )
(Is that a good example? )
-----
ともあれ、
Anyway,
■高齢者には、能力と実績と権力があり、
- The elderly have power.
■高齢者のパラダイムシフトは、「リアルな血縁婚」を受けいれるくらいに難しい
- Paradigm shift for the elderly is as difficult as accepting "real blood marriage".
と思って頂くことはできないでしょうか？
Can't you think of it that way?
うん、できないですよね。
Yeah, you can't do that.
わかります。
I understand.
とすれば、
If we assume that,
■「"高齢者は変われない"を前提とする相互理解」という概念
- The concept of "mutual understanding based on the premise that the elderly cannot change their minds.
と
and
■「高齢者を組織のトップから、ナチュラルに排除」する技術
- Technology to naturally remove elderly people from the top of the organization.
が、今後の社会ソリューションになっていくと思います。
I believe that these will be the social solutions of the future.
そういうことが、一切ない世界線で生きていけるのであれば、『SQL王に、俺はなる！』と宣言できます。
今、シミュレーション結果の入ったデータベース(PostgreSQL)から、必要な情報を読み出すのに、SQL文を使っています。
Now, I am using SQL statements to read out the necessary information from the database (PostgreSQL) containing the simulation results.
―― SQL、まじパねっす
"SQL is really cool"
と、感動してます。
I'm very impressed.
SQL文は、慣れてくれば、テーブル間連携も自由自在で、欲しいデータの列が簡単に作れます。魔法みたいです。
Once you get used to SQL statements, you can easily create the columns of data you want, with the freedom to link between tables. It's like magic.
今、QGIS(GISアプリケーション)と連携して使っているのですが、描画の作成で、とてもラクできています。
I am now using it in conjunction with QGIS (a GIS application), and it is very easy for me to create drawings.
-----
とは言え、SQLは非常に直感に反するインターフェースをしていますし、高度な使い方をするのであれば、かなり面倒くさいです。
However, SQL is a very counter-intuitive interface, and if you are going to use it in an advanced way, it can be quite cumbersome.
SQLと言えども、
Even though it is SQL,
―― ラクをする為には、凄く苦労しなければならない
"You'll have to work very hard to be easy"
というのは、プログラムの共通的な矛盾ではあります。
This is a common contradiction in programming.
-----
私だって、年がら年中、SQL(や、Golang)を使える環境にあれば、その場で、パッパと処理プログラムを書けるようになる、という自信があります。
I'm confident that if I had access to SQL (or Golang) all year round, I would be able to write processing programs on the spot.
(C/C++については、私は、この域に近いと信じています)。
(For C/C++, I believe I'm close to this realm)
年次報告書やら、特許明細書やら、予算管理のエクセル表の作成やら、発明相談会やら、幹部報告会資料や、社外発表審査書類や、顧客殿向けデモやら、学会発表やら ――
Annual reports, patent specifications, Excel spreadsheets for budget management, invention consultations, executive briefing materials, external presentation review documents, customer demonstrations, conference presentations, etc.
そういうことが、一切ない世界線で生きていけるのであれば、『SQL王に、俺はなる！』と宣言できます。
If I can live in a world where there is no such thing, I can declare, "I will become the SQL King!"
-----
自分でモノを作らないで、プログラムやらSQLやらを外注すれば、自分の技術力が低下していくのは当然です。
If I don't create things myself and outsource the programming and SQL, it is natural that my technical skills will decline.
しかし、モノ作りに拘っていれば、社会人を続けられないのも、また事実です。
However, it is also true that I cannot continue to be a member of society if I am obsessed with making things.
一方、人徳もコネもないシニアのエンジニアが、技術力までもなくしたら、一体、何が残るというのか、とも思います。
On the other hand, if senior engineers, who have neither humanity nor connections, lose their technical skills, what will be left?
難しいのは「リソース配分」―― つまり「バランス」です。
The difficult part is "resource allocation" - in other words, "balance"。
「批判も、非難も、援護も、賞賛も、助言も、一切せず、ただ"沈黙"し続けよう」
東京オリンピックがどうなるのか ―― 開催国の国民として興味があります。
As a citizen of the host country, I am interested in where the Tokyo Olympics is going.
現在、世界的なウイルス感染という、未曾有の災害の真っ最中です。
We are currently in the midst of an unprecedented disaster: a global viral outbreak.
歴史的に見れば、国家の一つや二つ、地球上から消滅しても不思議ではなかった、と思えるほどの災厄です。
Historically speaking, it would not have been surprising if a nation or two had been wiped off the face of the earth.
-----
オリンピックは、国家的なイベントです。
The Olympics is a national event.
当然に、開催実施、延期、または中止を含む、いくつかのシナリオがあるに違いない ―― と、多くの人は考えていると思います。
Naturally, there must be several scenarios, including implementation, postponement, or cancellation -- and I think many people are thinking that.
しかし、私は、『2つ目のシナリオは準備されていない』に、一票を投じてみたいと思います。
However, I would like to cast my vote for 'the second scenario is not prepared.
-----
というのは、私が、プロジェクトリーダをやるときは、複数のシナリオなんて考えない、というか、考えられないからです。
This is because when I am a project leader, I don't think about multiple scenarios, or rather, I can't think about them.
複数のシナリオを準備するには、それなりの人材や時間、費用の投入が必要となりますが、基本的に、プロジェクトの現場では、そんな余裕ありません。
Preparing for multiple scenarios requires a considerable investment of human resources, time, and money, but basically, there is no room for that at the project site.
一番怖いのは、現場を理解していない、現場指揮官の投入です ―― だいたいプロジェクトの失敗は、この指揮官から始まります。
The scariest thing is to have a field commander who doesn't understand the field -- -- Most project failures start with this commander.
というのは、燃えている現場に、一流の現場指揮官が割り当てられることは、稀(まれ)だからです。
This is because it is rare that a first-rate field commander is assigned to a burning site.
-----
現場を把握できる指揮官は、どの部署でもエースです。エースはどの部署でも手放そうとはしません。
A commander who can grasp the field is an ace in any department. No department wants to let go of its ace.
そして、エースは、現場の燃え具合を即座に理解できます。そして、全力で逃げを打つはずです。
And that ace can instantly understand the burning condition of the scene. And he/she would refuse to participate at all costs.
その結果、燃えている現場には、「使えない」「手放しても構わない」「どーしようもない」指揮官が割り当てられて、プロジェクトは加速的に崩壊に向かいます。
As a result, a "useless," "unnecessary," and "helpless" commander is assigned to the burning site, and the project is headed for accelerated collapse.
まあ、オリンピックと、民間のプロジェクトを同列に論じるのは、ちょっと乱暴に過ぎるかもしれませんが。
Well, it may be a bit too violent to discuss the Olympics and private projects in the same sentence.
-----
もう一つは、「失敗」には、別段シナリオが必要ありません。
The other thing is that "failure" does not require a specific scenario.
シナリオがあれば、失敗をソフトランディングに導くということもできまます。
With a scenario, it is possible to lead a failure to a soft landing.
しかし、ソフトランディングしようが、ハードランディングしようが、結局のところ「失敗は失敗」です。
However, whether it is a soft landing or a hard landing, in the end, "failure is failure.
失敗のアプローチに目の行く人は少ないです。「失敗に美学を持っている人」は、絶無といっても良いでしょう。
There are few people who have an eye for the approach of failure. The number of people who have an aesthetic appreciation for failure is almost nonexistent.
-----
オリンピックがどうなるかは、私には分かりません。
I don't know where the Tokyo Olympics is going.
ただ、「現場」を押しつけられることが多かった人間の一人として、
But I ,who has been forced to be "in the field" a lot, think that
「批判も、非難も、援護も、賞賛も、助言も、一切せず、ただ"沈黙"し続けよう」
"No criticism, no condemnation, no support, no praise, no advice, just silence"
とは思っています。
―― 学閥、人脈、コネ一切なしの、シニアのサラリーマンエンジニアの「ぼっち戦略」
The manga whose title is "Saving a Weak Nation by the Numbers!" This is a very interesting comic book.
# パパのkindleで読めるぞ > 娘たち
# You can read this on Dad's Kindle > my daughters
今調べたら、文庫版もあるようでした。購入を検討中です。
I found that there is also a paperback version. I'm considering buying it.
-----
As I've explained in my previous in "AI Series", this books include
■ゲーム理論
- Game Theory
■オークション理論
- Auction Theory
の話が、物語の中で、大変分かりやすいユースケースになっていて、感動しています。
and, I am impressed by the very clear use cases in the story.
それと、私の知らなかった「ホルト・ウィンスタース法」による需要予測計算や「ランチェスターの法則」なども登場します。
Also, "Holt-Winsters method" and "Lanchester's Law", which I have not known about, come to appear in the book.
これらを、WikiPediaで調べながら、マンガを読んでいました。
I was reading the manga while looking these up on WikiPedia.
「ランチェスターの法則」の戦力比較方式など、『いつか、どこかのコラムで使ってやろう』と虎視眈々と考えております。
I've been vigilantly thinking about using the "Lanchester's Law" method of comparing forces in my columns.
この年齢になって、私はようやく「単利計算」と「複利計算」の違いを理解するに至りました。
At this age, I have finally come to understand the difference between "simple interest calculation" and "compound interest calculation".
(でも、これは以前お話した「消費者金融」や「アムウェイ」の話と似ています)
(These are similar to the "consumer finance" and "Amway" stories we talked about before.)
-----
この漫画(文庫)の一貫したポリシーは、「徹底した弱者戦略」です。
The consistent policy of this manga (library) is "thoroughgoing strategy for the weak".
私の立場に置き換えるのであれば、
If I were to put myself in my shoes. I could think,
―― 学閥、人脈、コネ一切なしの、シニアのサラリーマンエンジニアの「ぼっち戦略」
""A lonely strategy" of a senior salaried engineer without any academic cliques, connections, etc."
と考えることができます。
これも以前お話しましたが、
I told you this before, too.
""Weak" is "strong" when I master it."
に通じるものがあり、大変勉強になります。
I learned a lot from this story.
-----
という訳で、世界に冠たる「数学大嫌い国家、日本」の若者のみなさん。
So, to all the young people of Japan, the world's leading math-phobic nation.
「ぼっち」で、これからの人生を生き抜くには、数学は結構な武器になりそうですよ。
If you are a "loner" and want to survive in the future, math is going to be a great weapon.