こぼれネット

長女:「世の中には、『正義と悪』という基準と『好きと嫌い』という基準の2つがある、って、誰かが言っていた」

Daughter: "Someone once told me that there are two standards in the world: 'justice and evil' and 'like and dislike'"

江端:「それは違うな。『好きと嫌い』という基準が1つあるだけだ」

Ebata: "That's not true. There is only one standard, 'like and dislike'"

長女:「『正義と悪』はないの？」

Daughter: "Isn't there a 'Justice and evil'?

江端:「『正義と悪』は、所詮は相対的な概念だ。立ち位置によって、簡単に180度ひっくり返るものであるから、私は、あまり重要とは思っていない」

Ebata: "'Justice and evil' is just a relative concept. It can be easily turned 180 degrees depending on where we stand, so I don't think it's very important.

-----

まあ、もっとも『絶対的正義』というものを求めて、古今東西多くの哲学者が死ぬほど考えて抜いてきたことは、私も知っています。

Well, I know that many philosophers in the past and the present have thought to death in search of the most 'absolute justice'.

しかし、死ぬほど考えなければ分からないものであるなら、それを共通の価値基準に置くのは、酷く面倒くさい上に、逆に「危い」とさえ思っています。

But if it's something we have to think about to death to understand, I think it's terribly tedious and even "dangerous" to put "absolute justice" as a common value standard.

-----

江端:「そもそも、法治国家における法治 ―― まあ、裁判はその一例だが ―― この運用がどのように行われるかしっているか？」

Ebata: "To begin with, do you know how the operation of the rule of law in a country under the rule of law is carried out? Well, the trial is just one example"

長女:「『主観を排して、証拠と法に基いてのみ人間を裁くこと』でしょう？」

Daughter: "To judge a person only on the basis of evidence and law, without 'subjectivity' right?

江端:「それは建前だ。この話は、法学ゼミで教えて貰って、私自身も仰天したことだが ――」

Ebata: "That's a pretext. This story was taught to me in law seminar, and I myself was astonished...."

といって、私は裁判のプロセスを語り出しました。

Then I started to talk about the process of a trial.

-----

(Step.1) 裁判官は、主観で被告の「好きと嫌い」を決めて、有罪/無罪および、その刑量をざっくり思い浮かべる。

(Step.1) The judge decides on the subjective "likes and dislikes" of the defendant and comes up with a rough idea of guilt/innocence and the amount of the sentence.

(Step.2) 次に裁判官は、この有罪/無罪、および刑量を導き出すための、複数の法律の条文を頭の中で並べる

(Step.2) The judge then lays out in his or her mind the multiple articles of law from which to derive this guilt/innocence and sentence amount.

(Step.3) 裁判官は、これらの条文を、担当事件の内容に当てはめられるかどうかを検討する。上手くはまれば、判決に適用する

(Step.3) The judge considers whether these articles can be applied to the case in question. If it works, they apply it to the judgment.

-----

江端:「でもって、上記(Step.1)～(Step.3)は、裁判官だけでなく、検察、弁護人も共通認識として共有している。そんでもって、この3者の関係者が、判決の落とし所を擦り合わせていく ―― これが、基本的な裁判のアプローチだ」

Ebata: "The above (Step.1) to (Step.3) are shared by not only judges but also prosecutors and defense attorneys. Then, these three parties work together to reach a decision. This is the basic trial approach.

長女:「うそ・・・」

Daughter: "No way..."

江端:「勿論、上記は、状況証拠も物的証拠も明らかであって、かつ、民事裁判のケースの話になるけど、ここに情状酌量の余地とか、世論の動向とか、社会通念とかをつっこんで、『この被告を、どこまで許せるか』という主観的基準で判決はされるんだよ」

Ebata: "Of course, the above is a civil case with clear circumstantial and physical evidence, however, they can add extenuating circumstances, trends in public opinion, and social norms. And finally, the judgment is made based on the subjective standard of "How much can I forgive this defendant?""

長女:「『正義と悪』が基準ではないんだ・・・」

Daughter: "'Justice and evil' is not the standard...

江端:「『正義と悪』は、『好きと嫌い』の理由付けとして存在している『道具概念』だ」

Ebata: "'Justice and evil' is a 'tool concept' that exists as a rationale for 'like and dislike'."

長女:「ならば、法律の存在意義がないじゃんか？」

Daughter: "Then what is the point of the law's existence?

江端:「いやいや、大切なのは「たとえ『好きと嫌い』から出発しても『好きと嫌い』だけを理由には判決はできない」、という、この一点にある」

Ebata: "No, no, the important point is this: 'Even if they start from 'like and dislike', they can't make a judgment based only on 'like and dislike'".

長女:「？」

Daughter: "?

江端:「どんな法律でもいいけど、必ず明文化された法律に基づいて論理的に(見せかけて)判決を出さなければならない ―― これが法治の理念で、最後の砦でもある」

Ebata: "It doesn't matter what kind of law they use, but they must always make a logical (pretend) judgment based on a clearly stated law -- this is the principle of the rule of law, and it is also the last resort."

-----

まあ、そういう意味において、「遠山の金さん」は、『好きと嫌い』だけで、しかも独断で判決をしていた訳ですから、考えてみれば、背筋の凍るような恐しい裁判方法だった訳ですよ。

In that sense, "Toyama no Kin-san" made judgments based on "likes and dislikes" alone, and at his own discretion.

私としては、「遠山の金さん」は、間違いなく「冤罪製造システム」として機能してきたと思んです。

As for me, I think that "Toyama no Kin-san" has definitely functioned as a "false accusation manufacturing system".

そんな訳で、私は、

That's why I want to watch a TV drama whose title is

―― 「遠山の金さん "冤罪"捕物帳」

"Tozan no Kin-san, the 'False Accusation' Catcher's Notebook"

というドラマを見たいんですよね。

今放送されている「天地創造デザイン部」というアニメが面白いです。

There is an interesting anime currently airing called "Tenchi Sozo Design Club(Creation Design Department)".

動物や植物が、「今の形態に『進化』」している ―― まあ、進化論を信じない人にとっては「神が『設計』」した理由が、コメディちっく、かつ、ロジカルに説明されていて、面白い。

The reason why animals and plants have "evolved" into their current forms, for those who don't believe in the theory of evolution, it's "God's 'design'", is explained in a comedic and logical manner.

このアニメのコンセプトが、イケています。

This anime has a cool concept.

―― 天地を創造した神は天地や水を造った時点で面倒になって、生き物を造るのは"下請け"に任せることにした

"God, who created the heavens and the earth, got tired of creating the heavens and the earth and the water, and decided to leave the creation of living things to "subcontractors""

クライアント(神)が、中途半端でアバウトな生き物の要求仕様(例:「可愛くないけど、可愛い動物」)を出しては、適当にボツにを連発される様子とか ―― 涙なくしては見られないです。

I can't watch this anime without crying, when the client (God) gives a half-hearted, out-of-the-box specification for a creature (e.g., "not cute, but cute animal"), and the client rejects the designs at random.

また、デザイン通りに、実際に生物の試作を作っては、問題点を明確に指摘する「火口（ひぐち）さん(*)」に、非常に共感しています。

I also have a great deal of sympathy for Ms. Higuchi(*), who actually makes prototypes of living things according to the design and clearly points out the problems.

(*)動物部試作室にいる唯一のエンジニアの女性

(*)The only female engineer in the Prototype Room of the Animal Department.

-----

このコンセプトは、私の日常では、こう読み換えることができます。

In my daily life, this concept can be read the following way.

―― ITプラットフォームを創造した総合電機メーカはAPIを設計した時点で面倒になって、アプリケーションやサービスを造るのは“下請け”に任せることにした

"The general electronics company that created the IT platform got tired of designing APIs and decided to leave the creation of applications and services to "subcontractors"."

あるいは、こう読み換えることもできます。

Or I can read it this way.

―― 次世代社会インフラのコンセプトをぶちあげた幹部は、コンセプトを発表した時点で面倒になって、実装や実証実験や特許出願を、"研究部"に丸投げすることにした

"The executives of the company that came up with the concept for the next generation social infrastructure got tired of the concept once it was announced, and decided to throw the implementation, demonstration tests, and patent applications to the "research department"."

-----

私は、これまで、加害者(クライアント)と、被害者(ホスト)の両方の当事者になってきたと思います。

I think I've been both the perpetrator (client) and the victim (host).

当然のことながら、加害者としての自分は認識しにくいですが、被害者視点なら言えることは山ほどありそうです。

Naturally, it's hard to recognize myself as a perpetrator, but there's a lot I can say from a victim's perspective.

例えば、

For example, I am likely to say that

『フィールド実験をやれというのであれば、まず、お前が先頭にたって、システムチューンのために、極寒の真冬の夜の街の中を走り回って見せろ』

"If you want me to do a field experiment, you're going to have to take the lead and run around the city on a sub-zero night in the middle of winter to tune the experiment system"

くらいのことは、いつも思っています。

できるだけ手を抜いて、目の前の課題を、コンピュータでちゃっちゃと解いてしまいたい、とあるIT研究員のメモを公開します。

This is a memo of an IT researcher who wants to cut corners as much as possible and use a computer to quickly solve the task at hand.

医院までの徒歩の時間と待合室の待ち時間で、書き殴ったものです。

I described this down in the time to walk to the doctor's office and wait in the waiting room.

このメモだけで、3つほど発明(といってもアルゴリズムだし、到底「特許発明」にはなりませんが)が入っています。

This memo alone contains about three inventions (although they are algorithms and hardly "patentable inventions").

もし、この中に何が書いてあるか、理解できる人がいたら、是非ご一報下さい。

If anyone can understand what is written in this memo, please let me know.

このメモは、江端が「ものぐさ」で「字が汚い」だけのもの、と思われている人もいると思いますが ――

Some people may think that this memo is only for Ebata, who is "lazy" and has "dirty handwriting, however,

世の中の研究員が「モノを考えている時のメモ」って、みんな、こんな感じです(本当)。

This is what all the researchers in the world write down when they are thinking about something (really).

 

 

■2点間の距離の算出

 

float ST_Distance(geometry g1, geometry g2);

float ST_Distance(geography gg1, geography gg2);

 

============

139.46383010 35.6078055 と 139.48004430 35.58936550 の距離を求めろ

============

 

SELECT ST_Distance('SRID=4326;POINT(139.46383010 35.6078055)'::GEOGRAPHY,'SRID=4326;POINT(139.48004430 35.58936550)'::GEOGRAPHY);

 

st_distance

---------------

2518.87992511 (単位はメートル)

(1 行)

 

 

SELECT ST_Distance(ST_Transform(ST_GeomFromText('POINT(139.46383010 35.6078055)',4326),26986),ST_Transform(ST_GeomFromText('POINT(139.48004430 35.58936550)',4326),26986));

 

st_distance

-----------------

2534.9890933572 (単位はメートル)

(1 行)

 

============

点(139.46507, 35.59577)と source 608 の距離を求めろ

============

 

SELECT ST_Distance('SRID=4326;POINT(139.46507 35.59577)'::GEOGRAPHY, the_geom) from ways where source = 608;

 

st_distance

-------------

48.64958043 (単位はメートル)

(1 行)

 

 

■点と線の最短距離の算出

 

===================

点(139.46383010 35.6078055) と

線(139.47364070 35.59500190),(139.47500790 35.59561250),(139.47618950 35.59667510) の # 3点は繋がっている

最短距離を求めろ

===================

 

SELECT ST_Distance('SRID=4326;POINT(139.46383010 35.6078055)'::GEOGRAPHY,'SRID=4326;LINESTRING(139.47364070 35.59500190,139.47500790 35.59561250, 139.47618950 35.59667510)'::GEOGRAPHY);

 

st_distance

---------------

1667.13188667 (単位はメートル)

(1 行)

■任意の座標に近いノードを1つ抽出

SELECT source, x1 as longitude, y1 as latitude, ST_Distance('SRID=4326;POINT(139.78468208 35.64553503)'::GEOGRAPHY, the_geom) as dist FROM ways ORDER BY dist limit 1;
;
source | longitude | latitude | dist
--------+-------------+------------+-------------
742 | 139.7831864 | 35.6469072 | 20.44846388
(1 row)

 

■任意の座標に近いノードを抽出

 

boolean ST_DWithin(geometry g1, geometry g2, double precision distance_of_srid);

boolean ST_DWithin(geography gg1, geography gg2, double precision distance_meters);

 

===============

点(139.47500790 35.59561250)から半径300メートル以内の全部のノードを、近い順に出せ

===============

 

SELECT source, x1 as longitude, y1 as latitude, ST_Distance('SRID=4326;POINT(139.47500790 35.59561250)'::GEOGRAPHY, the_geom) as dist FROM ways WHERE ST_DWithin(the_geom, ST_GeographyFromText('SRID=4326;POINT(139.47500790 35.59561250)'), 300.0) ORDER BY dist;

 

 

source | longitude | latitude | dist

--------+-------------+------------+--------------

277 | 139.4742202 | 35.5952626 | 0

342 | 139.4737614 | 35.5960846 | 0

554 | 139.4750079 | 35.5956125 | 0

554 | 139.4750079 | 35.5956125 | 0

465 | 139.4756076 | 35.5956018 | 54.35238655

465 | 139.4756076 | 35.5956018 | 54.35883189

148 | 139.4753681 | 35.5942035 | 62.47683957

488 | 139.4755625 | 35.595278 | 62.47683957

277 | 139.4742202 | 35.5952626 | 78.20859781

309 | 139.4758617 | 35.5957534 | 78.9363046

309 | 139.4758617 | 35.5957534 | 78.9363046

163 | 139.4736407 | 35.5950019 | 81.2567669

597 | 139.4728928 | 35.5961536 | 81.2567669

406 | 139.4760808 | 35.5958841 | 101.79071989

211 | 139.4761077 | 35.5959027 | 104.73755527

580 | 139.4761706 | 35.5959419 | 111.52418485

201 | 139.4762056 | 35.5959637 | 115.32014973

(単位はメートル)

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

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")
}