未分類

ロジットモデルを使用して、複数の移動手段と移動距離に基づいて選択確率を計算するGo言語のアルゴリズムを作成します。このモデルでは、各候補パスの総コストを計算し、そのコストに基づいて各パスが選択される確率を算出します。
package main

import (
	"fmt"
	"math"
)

// TransportationMethod は移動手段を表します
type TransportationMethod struct {
	Name      string
	Distance  float64
	CostFunc  func(float64) float64
}

// Path は一つの移動ルートを表します(複数の移動手段を組み合わせることができます)
type Path struct {
	Methods []TransportationMethod
}

// TotalCost はPathに含まれる全ての移動手段の総コストを計算します
func (p *Path) TotalCost() float64 {
	totalCost := 0.0
	for _, method := range p.Methods {
		totalCost += method.CostFunc(method.Distance)
	}
	return totalCost
}

// LogitProbability はロジットモデルを使用して、各パスの選択確率を計算します
func LogitProbability(paths []Path) []float64 {
	// 全てのパスの総コストの指数を計算
	expSums := 0.0
	expCosts := make([]float64, len(paths))
	for i, path := range paths {
		expCost := math.Exp(-path.TotalCost())
		expCosts[i] = expCost
		expSums += expCost
	}

	// 各パスの選択確率を計算
	probabilities := make([]float64, len(paths))
	for i, expCost := range expCosts {
		probabilities[i] = expCost / expSums
	}
	return probabilities
}

func main() {
	// 移動手段のコスト関数の定義
	trainCost := func(distance float64) float64 {
		return 6.5*distance + 120
	}
	taxiCost := func(distance float64) float64 {
		if distance <= 1.2 {
			return 500
		}
		return 333*distance + 100
	}
	carCost := func(distance float64) float64 {
		return 18.43*distance + 500
	}
	bikeCost := func(distance float64) float64 {
		return 8.38 * distance
	}
	bicycleCost := func(distance float64) float64 {
		return 7 * distance
	}
	walkCost := func(distance float64) float64 {
		return 11 * distance
	}

	// 各パスの定義(複数の移動手段を組み合わせる)
	paths := []Path{
		{Methods: []TransportationMethod{
			{"Train", 10, trainCost},
			{"Walk", 1, walkCost},
		}},
		{Methods: []TransportationMethod{
			{"Taxi", 5, taxiCost},
		}},
		{Methods: []TransportationMethod{
			{"Car", 15, carCost},
			{"Bicycle", 2, bicycleCost},
		}},
		{Methods: []TransportationMethod{
			{"Bike", 20, bikeCost},
		}},
	}

	// ロジットモデルによる選択確率を計算
	probabilities := LogitProbability(paths)

	// 結果を表示
	for i, prob := range probabilities {
		fmt.Printf("Path %d: %.4f\n", i+1, prob)
	}
}

2. アルゴリズムの解説

  • TransportationMethod: 移動手段を表す構造体で、名前、距離、コスト計算関数を持っています。
  • Path: 一つの移動ルートを表す構造体で、複数の移動手段を組み合わせることができます。
  • TotalCost: Pathに含まれる全ての移動手段のコストを計算します。
  • LogitProbability: ロジットモデルを使用して、各パスの選択確率を計算します。各パスの総コストに基づき、指数関数を用いて確率を計算しています。

3. 実行結果

main 関数で定義された複数の移動パスに対して、それぞれの選択確率を算出し、結果を表示します。

このアルゴリズムを利用することで、様々な移動手段を組み合わせたパスの中から、最も選択されやすいパスをロジットモデルを用いて判断することができます。

あなた:
tomoi@DESKTOP-1QS7OI7 MSYS /g/home/ebata/tomioka3B/src/others $ go run main97.go Path 1: 0.0000 Path 2: 0.0000 Path 3: 0.0000 Path 4: 1.0000
となってしまいました。
パスの確率がもうすこしバラけるように、調整して下さい。

ChatGPT:

ChatGPT

パスの確率が極端になってしまう理由は、ロジットモデルの計算において、コストの違いが非常に大きくなってしまい、指数関数の結果がほぼゼロか一に収束してしまうことにあります。

これを改善するために、コストのスケーリングを行い、各パスのコストがもっと小さな範囲に収まるようにします。一般的には、コストを標準化するか、計算のスケールを調整することで、確率がバラけるようにします。

以下のコードでは、コストをスケールするための定数(scalingFactor)を導入し、その定数で割ることで、コストをスケーリングします。

修正版コード

package main

import (
	"fmt"
	"math"
)

// TransportationMethod は移動手段を表します
type TransportationMethod struct {
	Name      string
	Distance  float64
	CostFunc  func(float64) float64
}

// Path は一つの移動ルートを表します(複数の移動手段を組み合わせることができます)
type Path struct {
	Methods []TransportationMethod
}

// TotalCost はPathに含まれる全ての移動手段の総コストを計算します
func (p *Path) TotalCost() float64 {
	totalCost := 0.0
	for _, method := range p.Methods {
		totalCost += method.CostFunc(method.Distance)
	}
	return totalCost
}

// LogitProbability はロジットモデルを使用して、各パスの選択確率を計算します
func LogitProbability(paths []Path, scalingFactor float64) []float64 {
	// 全てのパスの総コストの指数を計算
	expSums := 0.0
	expCosts := make([]float64, len(paths))
	for i, path := range paths {
		expCost := math.Exp(-path.TotalCost() / scalingFactor)
		expCosts[i] = expCost
		expSums += expCost
	}

	// 各パスの選択確率を計算
	probabilities := make([]float64, len(paths))
	for i, expCost := range expCosts {
		probabilities[i] = expCost / expSums
	}
	return probabilities
}

func main() {
	// 移動手段のコスト関数の定義
	trainCost := func(distance float64) float64 {
		return 6.5*distance + 120
	}
	taxiCost := func(distance float64) float64 {
		if distance <= 1.2 {
			return 500
		}
		return 333*distance + 100
	}
	carCost := func(distance float64) float64 {
		return 18.43*distance + 500
	}
	bikeCost := func(distance float64) float64 {
		return 8.38 * distance
	}
	bicycleCost := func(distance float64) float64 {
		return 7 * distance
	}
	walkCost := func(distance float64) float64 {
		return 11 * distance
	}

	// 各パスの定義(複数の移動手段を組み合わせる)
	paths := []Path{
		{Methods: []TransportationMethod{
			{"Train", 10, trainCost},
			{"Walk", 1, walkCost},
		}},
		{Methods: []TransportationMethod{
			{"Taxi", 5, taxiCost},
		}},
		{Methods: []TransportationMethod{
			{"Car", 15, carCost},
			{"Bicycle", 2, bicycleCost},
		}},
		{Methods: []TransportationMethod{
			{"Bike", 20, bikeCost},
		}},
	}

	// スケーリングファクターの定義
	scalingFactor := 500.0

	// ロジットモデルによる選択確率を計算
	probabilities := LogitProbability(paths, scalingFactor)

	// 結果を表示
	for i, prob := range probabilities {
		fmt.Printf("Path %d: %.4f\n", i+1, prob)
	}
}

修正ポイント

  • スケーリングファクター (scalingFactor) を導入しました。この値を適切に調整することで、各パスのコストの差が緩和され、選択確率がバラけやすくなります。今回は 500.0 を使用しましたが、状況に応じてこの値を調整することが可能です。

実行方法

コードを再度実行していただくと、各パスの確率がバラけるようになるはずです。スケーリングファクターの値は、望ましい確率の分布に応じて調整してみてください。

実行結果

tomoi@DESKTOP-1QS7OI7 MSYS /g/home/ebata/tomioka3B/src/others
$ go run main97.go
Path 1: 0.4156
Path 2: 0.0180
Path 3: 0.1266
Path 4: 0.4399

よし、バラけた。

bicycleCost := func(distance float64) float64 {
return 7 * distance
}
walkCost := func(distance float64) float64 {
return 11 * distance
}
によれば、自転車より歩く方がお金がかかることになりますが、これは妥当でしょうか

ご指摘の通り、設定したコスト関数に基づくと、歩行の方が自転車よりもコストが高くなる結果となっていますが、これは一般的な状況に照らし合わせると妥当ではありません。

通常、自転車は初期購入費用やメンテナンス費用がかかるため、長距離を移動する場合は歩行よりもコストが高くなるのが一般的です。歩行は特に道具を必要としないため、実際には距離に応じたコストは低く抑えられます。

コスト関数の修正提案
自転車と歩行のコスト関数をより現実的にするためには、以下のように修正するのが適切です。

自転車のコスト: 自転車の購入費用やメンテナンス費用を考慮し、歩行よりも高めに設定します。
歩行のコスト: 道具がほとんど必要ないため、距離あたりのコストを低めに設定します。

bicycleCost := func(distance float64) float64 {
    return 5 * distance  // 自転車のコストを調整
}
walkCost := func(distance float64) float64 {
    return 1 * distance  // 歩行のコストを調整
}

自転車のコストは、例えば距離1kmあたり5円程度に設定し、メンテナンスやタイヤ交換などの費用を反映します。
歩行のコストは、距離1kmあたり1円程度に設定し、シューズの消耗やその他のわずかな費用を反映します。
これにより、自転車は歩行よりも一般的に高コストとなり、現実的なモデルになります。

trainCost := func(distance float64) float64 {
return 6.5*distance + 120
}
taxiCost := func(distance float64) float64 {
if distance <= 1.2 {
return 500
}
return 333*distance + 100
}
carCost := func(distance float64) float64 {
return 18.43*distance + 500
}
bikeCost := func(distance float64) float64 {
return 8.38 * distance
}
bicycleCost := func(distance float64) float64 {
return 7 * distance
}
walkCost := func(distance float64) float64 {
return 11 * distance
}
を全体として見直してみて下さい。

1. 鉄道のコスト

鉄道は初乗り料金があり、距離に応じて追加料金が発生します。一般的には比較的安価で、一定の距離を超えるとコストは緩やかに増加します。

trainCost := func(distance float64) float64 {
	return 6.0*distance + 150 // 少し低めの傾斜で調整、初乗り料金を150円に設定
}

2. タクシーのコスト

タクシーは初乗り料金が高く、距離に応じて大幅にコストが増加します。

taxiCost := func(distance float64) float64 {
	if distance <= 1.2 {
		return 500 // 初乗り500円(1.2kmまで)
	}
	return 300*distance + 200 // 距離が長くなるほど、加算額がやや低くなるよう調整
}

3. 自家用車のコスト

自家用車はガソリン代やメンテナンス費用、駐車場代などがかかり、距離に応じてコストが増加します。

carCost := func(distance float64) float64 {
	return 15.0*distance + 300 // 距離あたりのコストを抑えつつ、固定費用を調整
}

4. バイクのコスト

バイクは燃費が良く、比較的低コストで移動できるため、コスト関数は緩やかです。

bikeCost := func(distance float64) float64 {
	return 5.0 * distance // 燃費が良いため、距離あたりのコストを低めに設定
}

5. 自転車のコスト

自転車はメンテナンス費用が主なコストとなり、歩行よりも若干高めのコストになりますが、それでも安価です。

bicycleCost := func(distance float64) float64 {
	return 2.0 * distance // 非常に安価な移動手段として設定
}

6. 歩行のコスト

歩行は非常に低コストで、道具や消耗品の費用がわずかにかかる程度です。

walkCost := func(distance float64) float64 {
	return 1.0 * distance // 極めて低コストに設定
}

全体としての調整ポイント

  • 鉄道のコスト: 初乗り料金を考慮しつつ、距離あたりのコストをやや低めに設定しました。
  • タクシーのコスト: 初乗り後の距離に応じたコスト増加を少し緩やかにしました。
  • 自家用車のコスト: ガソリン代とメンテナンス費用を含めた現実的なコストに調整しました。
  • バイクのコスト: 燃費の良さを反映し、距離あたりのコストを低く設定しました。
  • 自転車のコスト: 非常に安価な移動手段として設定しましたが、メンテナンス費用は加味しました。
  • 歩行のコスト: ほぼコストがかからない設定にし、他の手段と比較しても極めて低コストに設定しました。

この設定により、各移動手段の特性に合ったコストが反映され、現実的な選択確率を求めることができます。

最終的に落ち着いたコード

 

/*
	// G:\home\ebata\tomioka3B\src\others\main97.go

これらの関係式から、入力値を(1)移動手段、(2)移動距離、(3)移動コストとするロジットモデルを使った算出アルゴリズムをGo言語で作成して下さい。具体的には、候補となる複数のパスを入力して、それぞれの選択確率を求めるものです。
ただし、1の移動には複数の移動手段を用いるものもあり、複数の移動手段であっても1の移動として取り扱えるようにして下さい。

ロジットモデルを使用して、複数の移動手段と移動距離に基づいて選択確率を計算するGo言語のアルゴリズムを作成します。このモデルでは、各候補パスの総コストを計算し、そのコストに基づいて各パスが選択される確率を算出します。

2. アルゴリズムの解説
TransportationMethod: 移動手段を表す構造体で、名前、距離、コスト計算関数を持っています。

Path: 一つの移動ルートを表す構造体で、複数の移動手段を組み合わせることができます。

TotalCost: Pathに含まれる全ての移動手段のコストを計算します。

LogitProbability: ロジットモデルを使用して、各パスの選択確率を計算します。各パスの総コストに基づき、指数関数を用いて確率を計算しています。

3. 実行結果
main 関数で定義された複数の移動パスに対して、それぞれの選択確率を算出し、結果を表示します。

このアルゴリズムを利用することで、様々な移動手段を組み合わせたパスの中から、最も選択されやすいパスをロジットモデルを用いて判断することができます。


あなた:
tomoi@DESKTOP-1QS7OI7 MSYS /g/home/ebata/tomioka3B/src/others
$ go run main97.go
Path 1: 0.0000
Path 2: 0.0000
Path 3: 0.0000
Path 4: 1.0000
となってしまいました。パスの確率がもうすこしバラけるように、
	paths := []Path{
		{Methods: []TransportationMethod{
			{"Train", 10, trainCost},
			{"Walk", 1, walkCost},
		}},
		{Methods: []TransportationMethod{
			{"Taxi", 5, taxiCost},
		}},
		{Methods: []TransportationMethod{
			{"Car", 15, carCost},
			{"Bicycle", 2, bicycleCost},
		}},
		{Methods: []TransportationMethod{
			{"Bike", 20, bikeCost},
		}},
	}

を改造して下さい。

修正ポイント
スケーリングファクター (scalingFactor) を導入しました。この値を適切に調整することで、各パスのコストの差が緩和され、選択確率がバラけやすくなります。今回は 500.0 を使用しましたが、状況に応じてこの値を調整することが可能です。
実行方法
コードを再度実行していただくと、各パスの確率がバラけるようになるはずです。スケーリングファクターの値は、望ましい確率の分布に応じて調整してみてください。

現時点での出力結果
tomoi@DESKTOP-1QS7OI7 MSYS /g/home/ebata/tomioka3B/src/others
$ go run main97.go
Path 1: 0.3535
Path 2: 0.0180
Path 3: 0.1871
Path 4: 0.4414

ロジットモデルは距離、経過時間、およびコストの3つで決定すると言われていると聞きますが、現在のプログラムには、距離とコストの値は入っているが、時間の値が入っていないようです。時間の値を入れたプログラムとして修正して下さい。

*/

package main

import (
	"fmt"
	"math"
	"time"

	"golang.org/x/exp/rand"
)

// TransportationMethod は移動手段を表します
type Logit_TransportationMethod struct {
	Name     string
	Distance float64
	CostFunc func(float64) float64
	Time     float64 // 時間(分)を直接入力
}

// Path は一つの移動ルートを表します(複数の移動手段を組み合わせることができます)
type Path struct {
	Methods []Logit_TransportationMethod
}

// TotalCost はPathに含まれる全ての移動手段の総コストを計算します
func (p *Path) Logit_TotalCost() float64 {
	totalCost := 0.0
	for _, method := range p.Methods {
		totalCost += method.CostFunc(method.Distance)
	}
	return totalCost
}

// TotalTime はPathに含まれる全ての移動手段の総時間を計算します
func (p *Path) Logit_TotalTime() float64 {
	totalTime := 0.0
	for _, method := range p.Methods {
		totalTime += method.Time
	}
	return totalTime
}

// Logit_Probability はロジットモデルを使用して、各パスの選択確率を計算します
func Logit_Probability(paths []Path, costScalingFactor, timeScalingFactor float64) []float64 {
	// 全てのパスの総コストと時間の指数を計算
	expSums := 0.0
	expValues := make([]float64, len(paths))
	for i, path := range paths {
		totalCost := path.Logit_TotalCost()
		totalTime := path.Logit_TotalTime()
		expValue := math.Exp(-(totalCost/costScalingFactor + totalTime/timeScalingFactor))
		expValues[i] = expValue
		expSums += expValue
	}

	// 各パスの選択確率を計算
	probabilities := make([]float64, len(paths))
	for i, expValue := range expValues {
		probabilities[i] = expValue / expSums
	}
	return probabilities
}

// Logit_DefineCostFunctions は各移動手段のコスト関数を定義して返します
func Logit_DefineCostFunctions() (func(float64) float64, func(float64) float64, func(float64) float64, func(float64) float64, func(float64) float64, func(float64) float64, func(float64) float64) {
	trainCost := func(distance float64) float64 {
		return 6.0*distance + 150 // 鉄道のコスト
	}
	taxiCost := func(distance float64) float64 {
		if distance <= 1.2 {
			return 500 // 初乗り500円
		}
		return 300*distance + 200 // タクシーのコスト
	}
	carCost := func(distance float64) float64 {
		return 15.0*distance + 300 // 自家用車のコスト
	}
	bikeCost := func(distance float64) float64 {
		return 5.0 * distance // バイクのコスト
	}
	bicycleCost := func(distance float64) float64 {
		return 2.0 * distance // 自転車のコスト
	}
	walkCost := func(distance float64) float64 {
		return 1.0 * distance // 歩行のコスト
	}
	busCost := func(distance float64) float64 {
		if distance <= 2.0 {
			return 210 // 初乗り210円(2kmまで)
		}
		return 60*distance + 90 // 2kmを超えた場合の運賃
	}

	return trainCost, taxiCost, carCost, bikeCost, bicycleCost, walkCost, busCost
}

// InputPaths は事前に定義されたパスを受け取ります
func Logit_InputPaths(paths []Path) []Path {
	return paths
}

// Logit_SelectRandomPath は確率分布に基づいてランダムにパスを選択します
func Logit_SelectRandomPath(probabilities []float64) int {
	// 累積確率を計算
	cumulativeProbabilities := make([]float64, len(probabilities))
	cumulativeSum := 0.0
	for i, prob := range probabilities {
		cumulativeSum += prob
		cumulativeProbabilities[i] = cumulativeSum
	}

	// ランダムな値を生成
	rand.Seed(uint64(time.Now().UnixNano()))
	randValue := rand.Float64()

	// 累積確率に基づいてパスを選択
	for i, cumulativeProb := range cumulativeProbabilities {
		if randValue < cumulativeProb {
			return i
		}
	}

	// 万が一選択されなかった場合、最後のパスを返す
	return len(probabilities) - 1
}

func main() {
	// 各移動手段のコスト関数を取得
	trainCost, taxiCost, carCost, bikeCost, bicycleCost, walkCost, busCost := Logit_DefineCostFunctions()

	// 個別の移動手段を定義してから methods に追加
	methods1 := []Logit_TransportationMethod{}
	methods1 = append(methods1, Logit_TransportationMethod{"Train", 10, trainCost, 30}) // 例: 鉄道10kmで30分
	methods1 = append(methods1, Logit_TransportationMethod{"Walk", 1, walkCost, 12})    // 例: 歩行1kmで12分

	methods2 := []Logit_TransportationMethod{}
	methods2 = append(methods2, Logit_TransportationMethod{"Taxi", 5, taxiCost, 15}) // 例: タクシー5kmで15分

	methods3 := []Logit_TransportationMethod{}
	methods3 = append(methods3, Logit_TransportationMethod{"Car", 15, carCost, 25})       // 例: 自家用車15kmで25分
	methods3 = append(methods3, Logit_TransportationMethod{"Bicycle", 2, bicycleCost, 8}) // 例: 自転車2kmで8分

	methods4 := []Logit_TransportationMethod{}
	methods4 = append(methods4, Logit_TransportationMethod{"Bike", 20, bikeCost, 45}) // 例: バイク20kmで45分

	methods5 := []Logit_TransportationMethod{}
	methods5 = append(methods5, Logit_TransportationMethod{"Bus", 8, busCost, 20})    // 例: バス8kmで20分
	methods5 = append(methods5, Logit_TransportationMethod{"Walk", 0.5, walkCost, 6}) // 例: バス停から目的地まで徒歩0.5kmで6分

	// Path を作成して paths に追加
	paths := []Path{}
	paths = append(paths, Path{Methods: methods1})
	paths = append(paths, Path{Methods: methods2})
	paths = append(paths, Path{Methods: methods3})
	paths = append(paths, Path{Methods: methods4})
	paths = append(paths, Path{Methods: methods5})

	// InputPaths関数に事前定義されたパスを渡す
	paths = Logit_InputPaths(paths)

	// スケーリングファクターの定義
	costScalingFactor := 500.0
	timeScalingFactor := 10.0

	// ロジットモデルによる選択確率を計算
	probabilities := Logit_Probability(paths, costScalingFactor, timeScalingFactor)

	// 結果を表示
	for i, prob := range probabilities {
		fmt.Printf("Path %d: %.4f\n", i+1, prob)
	}

	// 確率に基づいてランダムにパスを選択
	selectedPathIndex := Logit_SelectRandomPath(probabilities)
	fmt.Printf("Selected Path: %d\n", selectedPathIndex+1)

	// 繰り返しパスを定義して再計算するか確認
	for {
		fmt.Println("再度パスを計算しますか? (yes/no)")
		var continueInput string
		fmt.Scan(&continueInput)
		if continueInput != "yes" {
			break
		}

		// 新しいパスを入力する場合
		paths = Logit_InputPaths(paths)
		probabilities = Logit_Probability(paths, costScalingFactor, timeScalingFactor)

		// 再度結果を表示
		for i, prob := range probabilities {
			fmt.Printf("Path %d: %.4f\n", i+1, prob)
		}

		// 確率に基づいてランダムにパスを選択
		selectedPathIndex = Logit_SelectRandomPath(probabilities)
		fmt.Printf("Selected Path: %d\n", selectedPathIndex+1)
	}
}

未分類

以下は、これまでに算出した首都圏郊外の各交通手段における利用距離

xx

(km)と運賃

y(x)y(x)

(円)の関係式です。

  1. 鉄道(JR東日本および小田急電鉄):
    • JR東日本:
      y(x)=7.71x+127.48y(x) = 7.71x + 127.48

       

    • 小田急電鉄:
      y(x)=6.43x+116.17y(x) = 6.43x + 116.17

       

    • その他の私鉄を含めたざっくりした関係式:
      y(x)=6.5x+120y(x) = 6.5x + 120

       

  2. タクシー:
    • 初乗り料金と距離に応じた関係式(分段関数):
      y(x)={500(0x1.2)333x+100(x>1.2)y(x) = \begin{cases} 500 & (0 \leq x \leq 1.2) \\ 333x + 100 & (x > 1.2) \end{cases}

       

    • 線形近似したざっくりした関係式:
      y(x)=333x+100y(x) = 333x + 100

       

  3. 自家用車:
    • 線形関係式:
      y(x)=18.43x+500y(x) = 18.43x + 500

       

  4. バイク:
    • 線形関係式(無料駐車前提):
      y(x)=8.38xy(x) = 8.38x

       

    • 線形関係式(有料駐車前提):
      y(x)=8.38x+100y(x) = 8.38x + 100

       

  5. 自転車:
    • 線形関係式:
      y(x)=7xy(x) = 7x

       

  6. 歩行:
    • 線形関係式:
      y(x)=11xy(x) = 11x

       

未分類

Distance: -0.5, // Example coefficient for distance
Time: -0.3, // Example coefficient for time
Cost: -0.2, // Example coefficient for cost のそれぞれの値がマイナスなのは何故ですか

ChatGPT:

ChatGPT

これらの係数がマイナスで設定されている理由は、ロジットモデルにおいて効用関数がどのように構築されるかに関係しています。効用関数は、ある選択肢が選ばれる可能性(選好)を表すために使用されますが、以下の理由から、距離、時間、コストに対する係数は通常マイナスになります。

1. 効用と選好の関係

  • 効用(Utility): 効用は、ある選択肢(移動手段など)が選ばれる際に得られる満足度や便益を表します。効用が高いほど、その選択肢が選ばれる可能性が高くなります。
  • 選好の低下要因: 距離が長くなる、移動時間が長くなる、コストが高くなるというのは、通常、移動手段の選好を低下させる要因です。つまり、これらの要因が増加すると、移動手段の効用は減少します。

2. 負の係数の意味

  • 距離が増えると効用が減少する: Distance の係数が -0.5 であるということは、移動距離が1単位(例:1km)増加すると、その選択肢の効用が0.5単位減少することを意味します。長い距離の移動は、一般的に人々にとって不便であるため、選好が下がると仮定されています。
  • 時間が増えると効用が減少する: Time の係数が -0.3 であるということは、移動時間が1単位(例:1分)増加すると、その選択肢の効用が0.3単位減少することを意味します。移動時間が長いほど、その移動手段の魅力は減少します。
  • コストが増えると効用が減少する: Cost の係数が -0.2 であるということは、コストが1単位(例:1円)増加すると、その選択肢の効用が0.2単位減少することを意味します。コストが高いほど、人々はその選択肢を避ける傾向があるため、効用が減少します。

3. 負の符号の役割

  • 効用を減少させる要因: 距離、時間、コストは、すべて増加すると移動手段の選好を減少させる要因と見なされます。これらの係数に負の符号がついているのは、その増加が効用を減少させる効果を表現するためです。

4. ロジットモデルにおける役割

  • 選択確率の計算: ロジットモデルでは、効用が高い選択肢がより高い確率で選ばれるように計算されます。負の係数を持つことで、距離、時間、コストが増えると効用が下がり、その結果、選択される確率も下がることになります。

まとめ

距離、時間、コストに対する係数がマイナスである理由は、これらの要因が増加することが通常、移動手段の魅力(効用)を低下させるからです。このモデル化により、ロジットモデルは現実的な選好を反映することができます。

func calculateUtility()のリターンー値もマイナスになると思いますが、これは正しいですか

ChatGPT:

ChatGPT

はい、calculateUtility() 関数がマイナスの値を返すことは正しいです。効用(Utility)の値がマイナスになること自体に問題はありません。重要なのは、効用値の相対的な大きさです。

効用がマイナスになる理由

  • 効用の相対的な意味: 効用は絶対的な値ではなく、異なる選択肢間の相対的な比較に用いられます。効用がマイナスであっても、その選択肢が他の選択肢よりも高い効用を持っていれば、選ばれる可能性が高くなります。
  • 効用が全体的にマイナスの場合: 例えば、すべての選択肢に対して距離、時間、コストが一定以上であれば、効用はマイナスになることが多いです。これは、どの選択肢も利用者にとってある程度の不便さや費用がかかることを示しています。

ロジットモデルでの扱い

  • 選択確率の計算: ロジットモデルでは、各選択肢の効用を用いて、選択確率が計算されます。効用の値がマイナスであっても、他の選択肢との比較によって、選ばれる確率が計算されます。ロジットモデルでは、効用を指数関数に通して選択確率を計算するため、効用がマイナスであっても正しく確率が算出されます。
  • 絶対値ではなく相対値: 効用の計算において重要なのは、他の選択肢に対する相対的な効用です。すべての選択肢の効用がマイナスでも、相対的に効用が高い選択肢が他より選ばれやすくなります。

具体例

go

func calculateUtility(coeff Coefficients, distance, time, cost float64) float64 {
return coeff.Distance*distance + coeff.Time*time + coeff.Cost*cost
}

例えば、以下のようなパラメータが与えられたとします。

  • coeff.Distance = -0.5
  • coeff.Time = -0.3
  • coeff.Cost = -0.2
  • distance = 10.0 km
  • time = 30.0
  • cost = 500.0

この場合、calculateUtility() は次のように計算されます。

go

utility := (-0.5 * 10.0) + (-0.3 * 30.0) + (-0.2 * 500.0)
// utility = -5.0 + (-9.0) + (-100.0)
// utility = -114.0

このように、効用がマイナスで計算されますが、他の選択肢と比較するためには問題ありません。

まとめ

calculateUtility() 関数がマイナスの値を返すのは、モデルの構造上正しいです。効用は相対的なものであり、選択確率の計算においては、効用が他の選択肢と比較してどの程度高いかが重要です。そのため、効用がマイナスであっても、モデルの機能には影響を与えません。

// Calculate utility for a given mode
func calculateUtility(coeff Coefficients, totalDistance, totalTime, totalCost float64) float64 {
	return coeff.Distance*totalDistance + coeff.Time*totalTime + coeff.Cost*totalCost
}

// Calculate the choice probabilities using the logit model
func calculateProbabilities(modes []Mode) []Mode {
	var sumExpUtilities float64
	for i := range modes {
		modes[i].Utility = math.Exp(modes[i].Utility)
		sumExpUtilities += modes[i].Utility
	}

	for i := range modes {
		modes[i].Probability = modes[i].Utility / sumExpUtilities
	}

	return modes
}

ChatGPT:

ChatGPT

ロジットモデルにおける選択確率がどのように算出されるか、以下で説明します。

1. 効用の計算(calculateUtility 関数)

まず、calculateUtility 関数は各移動手段(モード)の効用を計算します。この効用は、その選択肢が提供する満足度や利便性を数値化したものであり、距離、時間、コストの重み付けの合計として計算されます。

go

func calculateUtility(coeff Coefficients, totalDistance, totalTime, totalCost float64) float64 {
return coeff.Distance*totalDistance + coeff.Time*totalTime + coeff.Cost*totalCost
}

ここで、coeff は各要因(距離、時間、コスト)が効用に与える影響を示す係数です。これに基づいて、効用が計算されます。

2. 効用の指数関数化(math.Exp

次に、calculateProbabilities 関数内で、計算された効用を指数関数に通します。

go

func calculateProbabilities(modes []Mode) []Mode {
var sumExpUtilities float64
for i := range modes {
modes[i].Utility = math.Exp(modes[i].Utility)
sumExpUtilities += modes[i].Utility
}

ここで、効用を指数関数に通す理由は以下の通りです:

  • 指数関数の特性: 指数関数(exp(x))は常に正の値を返します。これにより、効用がマイナスであっても選択確率が0にならないようにします。
  • 効用の相対的な差を反映: 効用が高い選択肢ほど、指数関数に通した結果が大きくなり、その選択肢が選ばれる確率が高くなります。効用の小さな差が指数関数を通すことで大きな差に変わり、選好がより強く反映されます。

3. 選択確率の計算

次に、各モードの効用を合計し、その合計に対する各モードの効用の比率として選択確率を計算します。

go

for i := range modes {
modes[i].Probability = modes[i].Utility / sumExpUtilities
}

ここでの考え方は次の通りです:

  • 全体の効用の合計: 各選択肢の効用を合計することで、選択肢全体の「重み」が決まります。
  • 確率の割り当て: 各選択肢の効用を全体の効用の合計で割ることで、その選択肢が選ばれる確率を求めます。これにより、すべての選択肢の確率の合計が1(100%)になります。

4. ロジットモデルにおける選択確率の理論的背景

ロジットモデルは、個人が複数の選択肢からどれを選ぶかを予測するために使われる確率モデルです。具体的には、次のように動作します:

  • 効用最大化: 人々は、効用が最大となる選択肢を選ぶ傾向があります。しかし、効用には観測できない要因(ランダムな要素)も含まれるため、確率的にモデル化されます。
  • 相対的な選好: 効用を指数関数に通すことで、選好の相対的な強さを確率として表現します。

まとめ

ロジットモデルにおける選択確率が calculateProbabilities 関数で算出される理由は、効用を指数関数に通すことで、選択肢ごとの相対的な利便性を反映し、その後、各選択肢が選ばれる確率を全体の効用の合計に対する比率として計算するからです。これにより、効用が高い選択肢ほど高い確率で選ばれることが保証されます。

この話を指数関数の図と併わせて説明して頂くことは可能ですか?

ChatGPT:

ChatGPT

Utility vs. Exponentiated Utility

この図は、効用(Utility)とその指数関数値(Exponentiated Utility)の関係を示しています。

図の説明

  • 青い線(Utility (U)): これは、効用そのものの値を示しています。効用は、選択肢が提供する満足度や利便性を表します。効用はマイナスからプラスまでの値を取ることができます。
  • オレンジ色の線(Exponentiated Utility (exp(U))): これは、効用を指数関数(exp)に通した結果を示しています。指数関数は、効用の値に基づいて常に正の値を返します。効用が高ければ高いほど、その値は急速に増加します。

指数関数を使う理由

  • 非負の値: 指数関数により、効用の値がマイナスでも正の値に変換されます。これにより、効用が低い選択肢でも選ばれる可能性がゼロにはならず、あくまで相対的な確率として計算されます。
  • 効用の差を強調: 図からわかるように、効用が増加すると、その指数関数値は急激に増加します。これは、効用が他の選択肢に比べて少しだけ高い場合でも、その選択肢が選ばれる確率が大きくなることを意味します。逆に、効用が少しだけ低い場合、その選択肢が選ばれる確率は急激に低下します。
  • 選好の強調: この特性により、選択肢間の効用の違いが強調され、より現実的な選択確率が計算されることになります。

結論

ロジットモデルでは、効用を直接使用するのではなく、その指数関数値を用いることで、選択肢ごとの選好の強さが確率として適切に反映されます。図を通じて、効用が増加するとその選択肢が選ばれる確率がどのように急速に高まるかが視覚的に理解できると思います。 ​

未分類

JR東海と他の私鉄各社(例: 京王電鉄、東急電鉄、西武鉄道など)を考慮した場合、距離 (km)と運賃 (円)の関係を示す一次方程式を一般化すると、以下のような形が考えられます。

ざっくりとした一次方程式: y=6.5x+120

この式は、以下のように解釈できます:

  • 傾き (6.5): 距離が1km増えるごとに運賃が約6.5円増加することを意味します。これは多くの私鉄やJR東海の料金設定が比較的安定していることを反映しています。
  • 切片 (120): 基本運賃が約120円であることを示しています。これは初乗り運賃に近い値となっています。

この一次方程式は、首都圏郊外の鉄道運賃をおおまかに予測するのに適していますが、正確な運賃を求めるには各鉄道会社の具体的な料金体系を確認する必要があります。

2024,江端さんの忘備録

私、以前、米国ではじまった「リーマンショック」についてコラムを書きました。

I wrote a column about the “Lehman Shock” that began in the United States.

(上記の図をクリックすると、コラムに飛びます)

(Click on the above figure to jump to the column)

コラムを書くことの最大の利点は、『筋の通った話を書くために、猛烈に勉強しなければならない』ことですね。

The most significant advantage of writing a column is that I must study intensely to write a story that makes sense.

私のコラムを読んだ人が、その内容を分かってもらえれば嬉しいですが、分かってもらえなくても『まあ、いいかな』と思っています。

I am happy if people who read my column understand what it is about, but even if they don't, I think, 'Well, that's OK.

私がコラムを書く最大の理由は「私が理解するため」であって、「あわよく読者の方々にも理解してもらえる文章になっていれば"ラッキー"」という感じです。

The main reason I write my columns is for my understanding, and I am “lucky” if I can make my columns understandable to my readers.

それはさておき。

Aside from that.

------

私、リーマンショックについては勉強したのですが、実は「日本のバブル崩壊」については、自分で納得できるレベルで理解しておりません。

I have studied the Lehman Shock, but I do not understand the “collapse of the Japanese bubble” at a level I am comfortable with.

ところが、最近、「日本のバブル崩壊」について、とても分かりやすい本を見つけたので、ご紹介致します。

Recently, however, I found the best book about the “bursting of Japan's bubble.”

こちらです。

It is that.

 

(上記の図をクリックすると、広告に飛びます)

(Click on the above figure to jump to the ad)

これ、凄いです。現在2巻まで出ているようですが、紙の本を購入して、何度も読みなおしています。

This book is incredible. I think there are two volumes out now, and I bought the paper book and have read it repeatedly.

暗記レベルにまで、持ち込みたいくらいです。

I even want to bring it down to the memorization level.

ノベル版が原作のようですが、私は、コミックの方を読んでいます。キャッシュフローの図がとても分かりやすいので。

It looks like the novel version is based on the comic book version, but I am reading the comic book version. Because the cash flow diagram is easy to understand.

加えて、当時の大蔵省のセクショナリズムの解説が最高です ―― 『これが官僚どうしの権力闘争か』と、かなり理解できました。

In addition, the explanation of sectionalism in the Ministry of Finance at that time was the best: “This is the power struggle among bureaucrats,” which I understood well.

私なりにこの本のテーマを考えてみたのですが、

I have been thinking about the theme of this book in my own way, and I think that it is

―― あのバブル崩壊は、だれのせいだ?

"Who is to blame for that bubble burst?"

だと思います。

(ネタばれになりますので、興味のある方は、購入してみて下さい)。

(Spoiler alert: if you are interested, please buy it).

-----

この本を読んでいて、気になったことがあったのでChatGPTに質問してみました。

I was curious while reading this book, so I asked ChatGPT a question.

『バブル崩壊や、その後の"失なわれた20年"について、当時の大蔵省は自己批判をしましたか』

Did the Ministry of Finance then criticize itself for the collapse of the bubble economy and the “lost 20 years” that followed?

すると、ChatGPTは「無回答」のまま、質問のプロンプトに戻りました(まあ、こういうことは、たまにあるのですが、なんか私は"恣意的な何か"を感じてしまいました)。

Then ChatGPT returned to the question prompt with “no answer” (well, this happens sometimes, but I felt something “arbitrary”).

再度、『バブル崩壊や、その後の"失なわれた20年"について、当時の大蔵省は自己批判をしていますか』と質問を行ったところ、ChatGPTとしては、普通より長い時間かけて、以下の回答をしました。

When asked again, “Did the Ministry of Finance at that time criticize itself for the collapse of the bubble economy and the subsequent ‘lost 20 years?’, ChatGPT took longer than usual to answer the following question.

============== ChatGPTの回答ここから ==============

============== ChatGPT answers from here ==============

バブル崩壊やその後の「失われた20年」に関して、当時の大蔵省(現在の財務省)は、いくつかの自己批判や反省を行っています。

Regarding the bursting of the bubble economy and the subsequent “lost 20 years,” the then Ministry of Finance (now the Ministry of Finance) has made several self-criticisms and reflections.

バブル経済期には、金融機関が過剰な融資を行い、不動産や株式市場に過剰な投資が行われたことがバブルの一因とされています。大蔵省は金融政策の運用において、適切な規制や監督が十分でなかったことについて一定の反省を示しています。特に、1980年代後半に金融緩和を続けた結果、資産バブルが生じたことが問題視されました。

During the bubble economy, financial institutions extended excessive loans and overinvested in the real estate and stock markets, which is considered one of the causes of the bubble. The Ministry of Finance has shown some remorse for the lack of adequate regulation and supervision in the operation of monetary policy. In particular, the Ministry considered the creation of asset bubbles as a result of continued monetary easing in the latter half of the 1980s problematic.

バブル崩壊後の対応についても、大蔵省は反省を表明しています。特に、バブル崩壊後に不良債権問題が深刻化した際の対応が遅れたことや、金融機関の経営破綻を防ぐための政策が後手に回ったことが、経済停滞を長引かせた一因とされました。

The Ministry of Finance has also expressed regret over its response after the collapse of the bubble economy. In particular, the delay in responding to the worsening bad loan problem after the bubble economy burst and the backward-looking policies to prevent financial institutions from failing were considered to be among the factors prolonging economic stagnation.

しかしながら、大蔵省の内部では、責任の所在が明確にされることは少なく、外部からの批判に対して防衛的な姿勢を取ることもありました。そのため、自己批判が不十分だったという指摘もあります。

However, within the Ministry of Finance, responsibility was rarely clearly defined, and the Ministry sometimes took a defensive posture in response to external criticism. As a result, some point out that self-criticism was inadequate.

全体として、大蔵省は一定の反省を示したものの、根本的な改革や問題の全面的な解決には至らなかったとされています。

Overall, the Ministry of Finance showed a certain amount of remorse, but it is believed that it failed to make fundamental reforms or solve the problem.

============== ChatGPTの回答ここまで ==============

============== ChatGPT's response so far. ==============

私、ニュースで、倒産した銀行の幹部が、記者会見で、頭を下げているのを何度も見ましたが、官僚が国民に対して謝罪している姿を思い出すことができません。

On the news, I have seen many times the executives of the bank that went bankrupt bowing their heads in a press conference, but I cannot recall any bureaucrats apologizing to the public.

で、次に、ChatGPTに、『当時の大蔵省の役人自身が執筆した、自己批判の文献を紹介して下さい』と頼んだところ、

So, next, I asked ChatGPT, 'Please introduce me to a self-critical literature written by the Ministry of Finance officials themselves at that time,

============== ChatGPTの回答ここから ==============

============== ChatGPT answers here ==============

大蔵省の役人が直接執筆した自己批判や反省を記録した文献は少なく、一般的にそのような文献は内部文書や報告書として存在することが多いです。外部からの批評的な分析に頼ることが多いため、公式な自己批判はあまり公にされていないのが現状です。

There are few documents recording self-criticism and reflection written directly by officials of the Ministry of Finance, and such documents generally exist as internal documents or reports. Because they often rely on critical analysis from outside sources, official self-criticism is not often publicly available.

============== ChatGPTの回答ここまで ==============

============== ChatGPT's response so far. ==============

だ、そうです。

That's the case.

-----

私が今日、こんなことを書いているのは、昨夜「世界を破滅させてしまって、顔面蒼白になっていたから」です。

I am writing this because I “ruined the world last night, and I was blue in the face.”

今一度、戒めよ "docker-compose up -d" とは、これまでつくってきた全てのプログラムもシェルも、何もかも破壊する、世界終末コマンドだ

一瞬ですが、『死んでしまおうかな』と思えたくらいです。

For a moment, I even thought, 'I might as well die.

----

バブル崩壊の時、多くの人が自死を選びました。

When the bubble economy burst, many people chose to commit suicide.

会社経営者だけでなく、市井の人達も自己破産→家庭&人生崩壊→自死の道を歩んでいきました。

Not only company executives but also ordinary people went through bankruptcy, family & life disintegration, and suicide.

ふと、『大蔵省の人間は、この事件に対して、自殺するくらいの自責の念を持っていたんだろうか』と思い、ちょっと調べてみました。

I suddenly wondered, 'I wonder if the people at the Ministry of Finance felt remorse for this incident to the point of committing suicide,' so I did some research.

どうやら、少なくない人が、自身が関わった政策の失敗に対する責任や、職務における過剰なストレスで、自死に追い込まれていたようでした。

Not a few had been driven to suicide by responsibility for the failure of policies they had been involved in or by the excessive stress of their duties.

-----

近年、政府による日本国民への「投資」が呼びかけられています。

In recent years, the government has called for " investment” in the Japanese people.

日経株価平均が乱高下しています。

The Nikkei Stock Average has been fluctuating wildly.

私が、以前、シャレで購入して残っていた3000円分のビットコインが、先日2万円を越えていました。

I had 3,000 yen worth of bitcoins left over from a previous purchase in a joke, which had recently crossed the 20,000 yen mark.

もう訳が分かりません。

I don't understand it anymore.

私は、こういう「鉄火場」には踏み入る勇気がありません ―― バブル崩壊の地獄を見てきた人間の一人として。

I don't dare to step into these “gambling room” places as one who has seen the hell of the collapse of the bubble economy.

未分類

今一度、戒めよ

"docker-compose up -d" とは、これまで作ってきた全てのプログラムもシェルも、何もかも破壊する、世界終末コマンドだ

docker-compose.ymlに

/mnt/smb_mount:/mnt/smb_mount

を追加しようとして、一度、世界を破滅させたことを、ゆめゆめ忘れるな。

docker-compose up -d --no-recreate を使えば、既存の環境をまっさらにすることなく、新しいdocker-compose.ymlの内容を反映できて、その後、docker-compose startで普通に使うことができる、と考えて良いですか

はい、その通りです。

docker-compose up -d --no-recreate を使えば、既存のコンテナを削除して再作成することなくdocker-compose.ymlの変更を反映できます。このコマンドは次のように動作します。

  • 再作成しない: 既存のコンテナが削除されることなく、現在の状態を保持したまま、設定の変更を反映します。
  • 変更の反映: docker-compose.ymlに行った変更(環境変数、ボリューム、ネットワーク設定など)を反映しますが、コンテナそのものは再作成されません。

その後、docker-compose startコマンドで通常通りコンテナを起動し、既存の環境を利用し続けることができます。

実行手順

  1. docker-compose.ymlを修正: 新しい設定を追加・変更します。
  2. docker-compose up -d --no-recreateを実行: 既存のコンテナを保持したまま、設定変更を反映させます。
  3. docker-compose startを実行: コンテナが停止している場合、再度起動します。

このプロセスで、データが消えたり、コンテナが初期化されたりすることなく、変更が反映された環境を維持することができます。

重要なポイント:

  • ボリュームの変更や新しいサービスの追加も反映されますが、既存のデータやプログラムには影響を与えません。
  • ただし、設定に大きな変更がある場合(新しいネットワークやボリュームが追加される場合など)、再作成が必要になることがあります。その場合でも、--no-recreateオプションを使うことで、変更が最小限に留められます。

これで問題なく運用できるかと思いますので、安心して試してみてください。

 

2024,江端さんの技術メモ

key-word ubuntu emacs 漢字 汚い

.emacsまたはinit.elファイルに次のコードを追加します。

;; 英字フォントを設定
(set-face-attribute 'default nil
:family "Ubuntu Mono"
:height 120
:weight 'normal
:width 'normal)

;; 日本語フォントを設定
(set-fontset-font t 'japanese-jisx0208
(font-spec :family "Noto Sans CJK JP" :size 14))

 

2024,江端さんの技術メモ

$ sudo mkdir -p /mnt/smb_mount

$ sudo mount -t cifs -o username=guest, password=, vers=3.0 //10.42.0.1/usb_mount /mnt/smb_mount

で、できた。

cifsがなければ、インストールしろと言われるだろうから、素直に従うこと。

ーーーー

NIC透過環境のdockerのゲストOSでは、
”Unable to apply new capability set."といわれてしまいました

(まあ、そんなに簡単にいくとはおもっていませんでしたが)

 

 

未分類

先日、ニュースで「いつかは結婚したい」という未婚者が"78%"という統計結果がでていました。

The other day, a news report showed that 78% of unmarried people want to get married someday.

この結果を聞いて、正直、かなり驚いています。

I have to admit that I am pretty surprised to hear these results.

10年ほど前に私が調べた調査では、確か"91%"でした。

According to a survey I conducted about ten years ago, the figure was “91%. "

ここからは減っているとは言え、今でもまだ8割くらいくらいの人間が、結婚を希望しているという事実に驚愕としています。

Although it has decreased from here, I am still stunned that about 80% of us still want to get married.

もちろん、これは悪いことではありません。そもそも、結婚は"いいもの"だからです。

Of course, this is not a bad thing. Marriage is a “good” thing, after all.

私は、私の上司が語ってくれた『「結婚は人生のパラダイス」論』を継ぐ者です。

 I am the heir to the theory that “marriage is the paradise of life.” my boss told me.

「結婚って、良いものですか?」

それに、私は、ちゃんと統計計算もしました。

Besides, I did the statistical calculations correctly.

結婚=“幸せ”“不幸せ”拡大システムの幸せ機能が見落とされるワケ~幸せ表明がリスクな国

(上記の図をクリックすると、その計算の記事に飛びます)

(Click on the above figure to jump to the article on that calculation)

乱暴な計算ですが、結婚が「『幸せ』生産装置」になるか「『不幸せ』生産装置」となるかは、比率としては"65:35"です。

Although a rough calculation, the ratio of whether marriage is a “happiness-producing device” or a “misery-producing device” is “65:35.

これは、他のギャンブルと比較しても、かなり良いベット(賭け率)です。

This bet is much better (wagering rate) than other gambling forms.

「この賭けに乗ろうという未婚者が8割もいる」というのは、我が国にとっても希望のもてるニュースと言えましょう。

The fact that 80% of unmarried people are willing to take this bet is hopeful news for our country.

-----

ただ、彼らの『結婚に対する困難性の認識は甘い』とは思います。

However, I think their 'recognition of the difficulties of marriage is naive.

「いつかは結婚したい」というコメントからは、結婚というイベントの困難性を理解していないように感じます。

The comment, “I want to get married someday,” suggests a lack of understanding of the difficulties involved in the event of marriage.

トレーニングもせず、勉強もせず、ダラダラしながら『いつかは、甲子園に出場したい』とか、『いつかは東京大学に入学したい』とか、そんなことを語っているような「甘え」を感じます。

I feel “spoiled” as if they are talking about “someday, I want to participate in Koshien (the National High School Baseball Championship)” or “someday, I want to enter Tokyo University” without training, without studying, and with being lazy.

そのくらい、最近の結婚は、おそろしく難しくなってきているのです ―― が、このネタ、これまでも多く語りすぎてきて、皆さんに嫌われそうなので、今日は止めておきます。

That's how difficult marriage has become these days -- but I'm afraid you will hate me saying this story too much, so I'll stop today.

そう考えると、私の婚活のスタートは「15歳」とも言えるかもしれません。

 

2024,江端さんの忘備録

以前、

Previously,

地震対策: 黄色のプラスチックチェーンを使って、両端を棚に固定して、3つのディスプレイに巻きつけてみた。

という、「いい加減な地震対策」を行ったことを報告しました。今回は、その続報です。

I reported "lax earthquake countermeasures.” This report is a follow-up report.

江端家は、すでにタンスや食器棚などについて、転倒防止などの対策を終えていますが、『自分の書斎の対策が非常に甘い』ことに気がつきました。

The Ebata family has already taken measures such as preventing chests of drawers and cupboards from tipping over, but I realized that “the measures in their study were very lax.

私、毎日、自分の書斎の部屋にベットのマットレスを引き込んで寝ていますが ―― この書斎が危険の塊でした。

Every day, I slept with my bed mattress pulled into my study room, and this study was a mass of danger.

初動時速43kmの横揺れ地震が発生したら、100冊以上の本が私の体の上に落ちてきます。

If a horizontal earthquake with an initial speed of 43 km/h occurs, more than 100 books will fall on my body.

特に、プリンタが、私の頭上を直撃する位置にあることに気がついて、ゾッとしました。

I was horrified to realize I had directly positioned the printer over my head.

しかし、ちゃんと対策するのは、お金も時間もかかって面倒です。

However, taking proper measures is expensive, time-consuming, and troublesome.

実際にOA機器を固定するデバイスはほとんどありませんし、あったとしても恐しく高価です。

Few devices lock office automation equipment; even if they do, they are expensive.

で、こういうような、「さらにいい加減な地震対策」を施しました。

So, I applied “even more lax earthquake countermeasures” like this.

プリンタの前に針金を1本張っただけです(プリンタ使用時には、針金を外せるようにしました)。

I just strung one wire in front of the printer (the wire can be removed when the printer is in use).

とりあえず、プリンタの落下を完全に抑えることは期待できませんが、地震でプリンタ本体が射出されて、私の頭部を直撃する惨事は回避できそうです。

At any rate, I do not expect the printer to fall entirely, but I think I can avoid a catastrophe in which an earthquake ejects the printer itself and hits me directly on the head.

あと残りのディスプレイも後部を針金を巻きつけて、射出(×落下)防止させるようにしました。

I also wrapped the rear of the rest of the display with wire to prevent ejection (x falling).

-----

購入したものは、これだけです。

The following are all I purchased.

 

 

対策コストは、686円でした(写真をクリックすると商品のページに飛びます)。

The measures cost 686 yen (click on the picture to go to the product page).

-----

私は「完全な地震対策」というのは、最初から諦めています。

I have given up on the idea of “perfect earthquake protection” from the very beginning.

当面の目標は「即死の回避」です。

The immediate goal is to avoid instant death.