未分類

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

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円であることを示しています。これは初乗り運賃に近い値となっています。

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

未分類

今一度、戒めよ

"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オプションを使うことで、変更が最小限に留められます。

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

 

未分類

先日、ニュースで「いつかは結婚したい」という未婚者が"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歳」とも言えるかもしれません。

 

未分類

Windowsセキュリティでフルスキャンをしている最中に、スクリーンセイバが動き出すと、フルスキャンが止まってしまいます。

しかし、別のPCで作業していると、フルスキャンをしている方のPCのことを忘れてしまいます。

で、使用中のPCのマウスに、フルスキャンしているマウスを、針金で繋いで、マウスを少しだけ動くようにして、スクリーンセイバの起動を妨げています。

もう、妙な設定を考えるのに、時間を使う余裕も気力もありません。

これでいいんです。

未分類

以前、京急富岡駅からの京急線を使った場合の所要時間を、時刻表などを見ながら概算していたのですが、それを可視化してみました。

[data.csv]

name,y,x,z
日暮里, 35.72810551475649, 139.77065214505967, 73
鶯谷, 35.72147285483459, 139.77803484630024, 63
上野, 35.71419330617392, 139.7774413019538, 57
御徒町, 35.70752513412557, 139.7748544863164, 67
秋葉原, 35.6983999333567, 139.77290571388025, 65
お茶の水, 35.69977763102643, 139.76447338219248, 61
水道橋, 35.7020483726974, 139.75337286940393, 66
神田, 35.691843953947895, 139.77075286750426, 63
東京, 35.68127103173912, 139.76691023873528, 57
有楽町, 35.67504451109795, 139.7629009441794, 59
新橋, 35.6663876890884, 139.7580715945385, 55
浜松町, 35.65538959029243, 139.75707527127187, 54
田町, 35.64573607270807, 139.7475731442898, 54
品川, 35.628479993237924, 139.73869534241823, 43
北品川, 35.62204337901307, 139.73929378869565, 50
青物横丁, 35.616530476669595, 139.74147241132803, 49
青物横丁, 35.6089113073848, 139.74314516357873, 45
鮫洲, 35.60505014227371, 139.74226998316405, 50
立会川, 35.598565208786674, 139.73893538884946, 50
大森海岸, 35.58770513004266, 139.73546417819148, 51
平和島, 35.578786612348516, 139.7348957122944, 40
大森町, 35.572470928220454, 139.73209389290315, 53
梅屋敷, 35.56680589146817, 139.7282405712228, 53
京急蒲田, 35.561346378009084, 139.72413782845052, 33
雑色, 35.549501628543595, 139.71492252305998, 38
六郷土手, 35.540534565682265, 139.70758227692838, 34
糀谷, 35.55475500818507, 139.72947450479222, 40
大鳥居, 35.55230710920823, 139.74016209480337, 45
穴守稲荷, 35.550433498630504, 139.7467475129522, 46
天空橋, 35.549323611239814, 139.75367380680967, 46
京急川崎, 35.5330130222155, 139.70085261643172, 30
小島新田, 35.53497952289224, 139.74753015189842, 42
八丁畷, 35.523294588264044, 139.69182471487903, 41
鶴見市場, 35.51795110131048, 139.68654897642313, 40
京急鶴見, 35.507313116366205, 139.67793452856546, 34
花月総持寺, 35.50045335293103, 139.67299835084395, 31
生麦, 35.49532037586162, 139.66697084291033, 30
京急新子安, 35.48709301222138, 139.6554644900453, 29
子安, 35.484595747125226, 139.64499414507037, 32
神奈川新町, 35.48089584236831, 139.63961808116608, 26
京急東神奈川, 35.47728484644749, 139.63437152522133, 30
神奈川, 35.471042823081326, 139.62708525622278, 32
京急横浜, 35.465974566273886, 139.6218737093478, 20
戸部, 35.45669353999209, 139.61954391949988, 27
日ノ出町, 35.445535830399635, 139.62677764713118, 25
黄金町, 35.4398051861557, 139.6228192707623, 24
南太田, 35.43704871593425, 139.61413963595152, 18
井土ヶ谷, 35.434049908914936, 139.6013697675809, 16
弘明寺, 35.424392517088215, 139.59679056178064, 17
上大岡, 35.409119230795824, 139.59658257505384, 14
屏風浦, 35.394628914972444, 139.61025512796533, 10
杉田, 35.38359625400674, 139.6158614781421, 3
京急富岡, 35.36713079862617, 139.6298755067998, 0
能見台, 35.36088096572114, 139.62943901110575, 1
京急金沢文庫, 35.34283976967888, 139.62161382892742, 3
金沢八景, 35.33143644664979, 139.62019186432977, 6
野島公園, 35.33057520638215, 139.63154448609114, 17
海の公園南口, 35.337221851530074, 139.63203843792144, 18
海の公園芝口, 35.34207978297347, 139.6357948657779, 18
八景島, 35.34081263381398, 139.64082413734104, 20
六浦, 35.32276335943298, 139.61123194142903, 13
神武寺, 35.306362422782364, 139.59316695868543, 19
逗子・葉山, 35.29593435944306, 139.5811992373588, 31
追浜, 35.3158514243523, 139.62481670534095, 15
京急田浦, 35.30091271311823, 139.62553483073157, 16
安針塚, 35.28681218160922, 139.64296751736376, 17
逸見, 35.28064334099864, 139.6528184088048, 21
汐入, 35.280307747849356, 139.6624959442711, 19
横須賀中央, 35.27868971431925, 139.6700294865965, 20
県立大学, 35.27046934794596, 139.6765472421848, 26
堀ノ内, 35.263578813428, 139.68674190193195, 23
新大津, 35.25692239324099, 139.69014415109714, 23
北久里浜, 35.2497686048071, 139.68628696286345, 25
浦賀, 35.250938172839675, 139.71498764424754, 30
京急久里浜, 35.231585086558596, 139.7022284815838, 29
YRP野比, 35.21207247285571, 139.68500815775707, 33
京急長沢, 35.20555570645748, 139.67414472893097, 44
津久井浜, 35.19868000571067, 139.66570472891374, 37
三浦海岸, 35.188117336673066, 139.65328211521543, 39
三崎口, 35.17752001890131, 139.633171976671, 42

[Gnuplotスクリプト]

# データファイルの読み込み
set datafile separator ","

# 3Dプロットの設定
set title "3D Plot of Locations with Vertical Projection Lines"
set xlabel "Longitude (x)"
set ylabel "Latitude (y)"
set zlabel "Elevation (z)"
set ticslevel 0
set grid

# ラベル表示の設定
set label font ",10"

# 3Dプロット
splot "data.csv" using 3:2:4 with points pointtype 7 pointsize 2 lc rgb "blue" title "Locations", \
     "" using 3:2:4:(0):(0):(0-$4) with vectors nohead lc rgb "red" title "Projection Lines", \
     "" using 3:2:(0):(sprintf(" %s", stringcolumn(1))) with labels offset char 1,1 notitle

pause -1

未分類

マジで、体感温度が下がります。

で、最大級に怖いことは、震災直後の大停電によって、津波から逃げなければならない人にはこの映像が届かない、ということです。

という訳で、みなさん、やはり、電池で動くラジオを設置して、地震発生から30秒以内にはスイッチが入っている状態にしておくことが大切だと思うのです。

ちなみに、江端家では、このラジオを2台、稼動可能状態にしています。

(クリックすると商品紹介に飛びます)

 

未分類

先程、台所でガラスの保存容器を割ったのですが、それが台所一面に広がり、ママと一緒に後かたづけしていました。

まず、床一面にガラスの破片が広がって身動きできなくなったパパに、ママがスリッパを持ってきて、その後、ガラスの破片の回収を開始。

料理(炒めもの、味噌汁にも)破片が入っている可能性があるため、全て廃棄を決定。ママが掃除機をかけて、細かい破片を回収。

私は、シンクに広がったと思われる破片を回収するために、ゴム手袋をして、濡らしたキッチンペーパーでコンロも含めて拭き掃除。キッチンペーパーはそのまま廃棄。乾いていた食器は、乾いたキッチンペーパーで拭いてから、食器棚に収める。

さらに、洗い片づける食器も一つつづ洗うという処理で、先程完了。

ただ、その後、もう一度、床を拭き掃除したら、ガラスの破片を3つほど発見(足のウラを切断するのに十分な大きさ)。 掃除機も完璧ではないようです。

という訳で、ここ1~2日の間、キッチンに入る時には、スリッパを着用してください。

で、ここから本題

地震で被災した場合、ガラスの破片が家中に散らばっています。

そして、当然停電になっているハズですので、掃除機も使えません。電気が回復するまでは、ガラスの破片の床の上で生活しなければなりません

実際に被災地では、足のウラをガラスで切り刻まれて、出血していた人が、かなりの数いたそうです。

という訳で、当初の写真に戻ります。

ママとパパは、枕元に「スリッパ」と「笛」を常備しています。

「スリッパ」は、ガラスの破片の床対策。

「笛」は、倒壊した場合に、自分の場所を知らせる為のものです。(声を張り上げつづけることはできないですが、笛なら比較的簡単)

という訳で、各自、枕元に「スリッパ」と「笛」をお勧めします。

以上

未分類

自宅の倉庫に落ちていた黄色のプラスチックチェーンを使って、両端を棚に固定して、3つのディスプレイに巻きつけてみました。

いい加減な対応だけど、時速42kmでディスプレイが飛び出てくるのは、回避できると思う。

あまりキッチリ対応することを考えると、面倒くさくて、対策が後手になります。

この程度のいい加減な対応を、暇を見つけてやる方で、いいと思います。

私だけが『ディスプレイが突き刺さった状態の遺体で発見される』