こぼれネット

『市場の評価は・・・』というセリフをニュースで良く聞きます。

I often hear the line, "Market valuation is..." in the news.

しかし、最近の株価を見てみると、その『市場』と呼ばれる奴は、実際のところ『バカ』なんじゃないかと思うことがあります。

However, when I look at recent stock prices, I sometimes think that this so called "market" is actually "stupid".

実際に、不動産の適正価格を算出できず、我が国を20年も回復不能な不景気に貶めたのは『市場』という奴でした。

In fact, it was the "market" guy who failed to calculate a fair price for real estate and plunged our country into an unrecoverable recession for 20 years.

米国から発生した、リーマンショックだって同様です。

The Lehman Shock that originated in the United States is same.

大体、私、証券も株券も国債も、ありとあらゆる債券を持っていないです。故に売買もできません。

I don't own any securities, stock certificates, government bonds, or any other bonds. Therefore, I can't buy or sell them.

私は、この『市場』って奴の構成員ではないのです。

I am not a member of this "market" guy.

つまり、『市場』の中には、当初から私は入っていません。

In other words, I have not been included in the 'market' from the beginning.

-----

『市場の評価』とか言う奴が、なんでそんなに頻用されているのか ――

I don't know why guys like "market valuation" are used so often.

多分、世間の「空気」を数値で評価する方法が、それくらいしかないんだろうなぁ、と思っています。

I think that's probably the only way to evaluate the "atmosphere" of the world in numerical terms.

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

パスワード:

/*
  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; // 南北
}

私は、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".

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で試してみた件
*/

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.

今、シミュレーション結果の入ったデータベース(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"。