　いーかげんシツこいが、実はハロにまだシコリの残っている。昨晩「周波数は38.83kHzとなった。まぁこんなモンだろう」などと書きつつも、実は昨晩「もう1命令を追加すれば、さらに38kHzに近づくやんか」というコトに気づいてしまったのだ。こーなるとどーにも気分が悪い。完全無欠な完璧主義者のオイラとしては気になってしゃーないのである……ま、オイラの完璧主義が発動するのは「極めて狭い分野に関して」のみなんだけれども……。

　ファームのコードに「NOPをひとつ追加」してPICに書き込む。昨日と同様にオシロをセット、昨日と同様に計測、昨日と同様に結果を出す。その結果、点灯時間が13.50s、消灯時間が13.00us、周期は26.50us、周波数は37.74kHzとなった。昨日は38.83kHzであったから、より38kHzに近づいたコトになる。フムン。余は満足じゃ。コレで、イマヒトツ反応のシブかった、エアコンも動作するようになるコトであろう……

　 ……と、思ったが、動かん。つーか、エアコンが動くどころか、カシオのラジカセが動かなくなり、シャープの空気清浄機の動きもシブくなってしまった。うーむ。どうやらオイラは勝手に38kHzが理想だと思っていたが、現実には38kHzを越えたあたりに感度のピークがあるようである。これが厳しい世間の現実というヤツ(？)か。ちょっと負けムードに包まれつつ、トボトボとコードを元に戻す……。

　しかし、たったひとつのNOP命令を減らしたり増やしたりするだけで、これほどハッキリと機器の感度特性が変化するとは思わなかった。こーゆーの、なんてゆったっけ？　アレか「1インストラクションを笑うやつは、1インストラクションに泣く」か？　いや「1バイト入魂」だっけ？　えー「1を聞いて0x10を知る」なんてのもあったな……ってナンの話だっけ？　ま、なんにせよ今日の作業はムダにはなったが、ダメならダメというコトがわかったので、それはそれで収穫だったってコトよ。とりあえず、スッキリッシュッ!!

　スッキリッシュッしたトコロで、今日もゼビる。今日はビール1本しか呑んでいない。オモシロい画面でも撮れれば思いデジカメをセットしてみる。30秒間隔でインターバル撮影しながらプレイするのだ。しかし、アレだ。テレビ画面を撮るにはシャッタースピードを1/15あたりに設定するのがベストなのだが、オイラのデジカメ「Caplio G4 wide」は露出を固定することができないのだ。28mmの広角レンズほか、このデジカメのスペックには十分に満足しているが、所詮はコンパクトカメラであるから無理がきかない……うーむ……あれ？　そういえば、さらに玄人向けのデジカメ「Caplio GX」はそのヘンどうなのだろう？　げッ!?　マニュアル露出できるの!?　……しまった……余計なコトを知ってしまった……ふんふん、バッテリーパックは今のが流用できるのね……なにいッ!?　「Caplio GX」の後継機に「Caplio GX8」が出たトコだって？　つーことは、今が底値ッ!?　……えぇえぇッ!?

　 ……てなコトをウダウダと考えながらゼビっても、よい結果がでるハズもない。珍しくエリア7の4本ソルを3本まで破壊できたのを頂点に、エリア8の3連ガルザカートでボコボコと残機をツブし、あえなくエリア12で全滅。やべぇ「Caplio GX」欲しいカモ……。

[ツッコミを入れる]

2014-06-14(Sat) 行灯もケッコンカッコカリ仕様に

　午前中は、紙でブーメランを作り、公園に投げに行く。材料は、昔に作ったプラモデルの箱。

　これで10作目くらいだが、少しずつコツがわかってきた。各ハネの先には1円玉が埋めてある。結構、遠くまで飛んでいき、結構、ちゃんと戻ってきた。かなり楽しかったが、そのうち根元の辺りで紙が折れ、終了。

　昔、戦闘妖精雪風を読んだ時(中学時代!)には、ブッカーのブーメラン趣味が理解できなかったが、今ならばわかる。そういえば、オイラのウィスキー趣味も神林作品はじまりだ。神林氏は、なんと奥の深い人なのだろう。

　で、次はこっち。やりました。

　ふと思いつき、100円ショップで調達。手持ちの折り紙をパチパチ抜いて、糊でペタペタ。

　作ってからもう半年も経つが、今でも、毎晩のように気分良く愛用している自作アイテムなのに、これからますます楽しく使えそうだ。

[ツッコミを入れる]

2017-06-14(Wed) 世にも奇妙なmicroSD

　先日、某サイトから、安価な16GBのmicroSDカードを購入した。さほど、厳格に用途を決めていたわけではないし、とりあえず工作中のmp3プレイヤにでも使ってみようと、Windows10マシンでFAT32フォーマットし、Linuxマシンからmp3ファイル、flacファイルを書き込み、mp3プレイヤに挿し込んだ。

　 ……あれ？いきなり1曲目の途中から再生された……ような……早送りすると、2曲目以降は普通だが……あれ？十数曲目以降が、1曲目の途中からの再生ばかりになってしまう。……なんだこれ？

　 mp3プレイヤの側も工作中なこともあり、どっちが異常なのかわからない。とりあえず、microSDを抜いて、Linuxマシンに挿し込むと……スーパーブロックが壊れているって？ ……なんだこれ？

　 LinuxマシンでFATを扱ったことがマズいのかしらん？と、思い、ファイルの書き込みまでWindows10マシンで完結させても、やっぱりおかしな症状が出る。いろいろと試してみると、microSDカードを挿して、書いて、抜いて、挿すと、もう、書いた内容がおかしくなっている。これ、microSDカードがおかしいんやないか？

　以前に「抜くと元に戻るSDカード」を経験して以来「ここ一番にはSanDisk」を励行してきたのだが、それを外した途端にトラブるもんかねぇ。

　購入元に連絡したところ、即座に代品を送ってくれ、翌日には代品が手元に届くという素晴らしい対応だった。んが、不良品を返送する前に、再テストしてみたところ、なんと、代品にも同じ現象が出てしまった。どうも、ある程度の容量を書き込むと、microSDを抜き差しせずとも、先頭部分がブッ壊れるっぽい。

　と、ここでピンときた。以前に、見た目はxxGBなのに、実際にはxxGBの容量を持たない詐欺的なSDカードがあると聞いたことがある。改めて考えれば、一定の場所でループ構造にしている、つまり、上位ビットを捨てることで実現している、と考えるのが妥当なわけで、そうであれば今回の事象に合致する。

　というわけで、こんなプログラムを書いてみた。デバイスの先頭からシーケンシャル番号で領域を書きツブしながら、先頭部分の変化を監視する、というものだ。

 #!/usr/bin/env ruby
 
 # SD カードチェッカ
 
 class Integer
     def to_h
         sprintf('%d', self).to_s.reverse.scan(/.{1,3}/).join(',').reverse
     end
 end
 
 dev = ARGV[0]
 check_max = 8 * 1024 * 1024 * 1024                              # 8Gbytes
 puts('device = %s, check_max = %16s' % [dev, check_max.to_h])
 
 adr = 0; open(dev, 'w') {|fh|
 
     last_md5 = nil; while(adr < check_max)
         puts('%16s .. ' % adr.to_h)
 
         chunk = ''; (1024 * 1024 / 8).times {                   # 1Mbytes
             chunk << [adr >> 32, adr & 0xFFFFFFFF].pack('N*'); adr += 8
         }
         fh.write(chunk)
         fh.fsync
 
         system('dd if=%s of=/tmp/_sdcard_checker_ bs=4096 count=1 iflag=direct >/dev/null 2>&1' % dev)
         md5 = `md5sum /tmp/_sdcard_checker_`.split(/\s/)[0]
         puts('  %s %s' % [md5, last_md5])
         last_md5 and last_md5 != md5 and raise('Unmatch!')
         last_md5 = md5
     end
 }
 
 puts('%16s finished.' % adr.to_h)
 
 __END__

　イザ、実行ッ！

# sdcard_checker /dev/sdb
device = /dev/sdb, check_max =    8,589,934,592
               0 .. 
  fa9971f35ad33faaaf100800b4b85b8c 
       1,048,576 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       2,097,152 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       3,145,728 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       4,194,304 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :
   1,609,564,160 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
   1,610,612,736 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :

　 ……んが、1.5GBくらい書いても先頭部分に異常が出ない。そんなバカな。もしかして、よく読まれる部分を避けるとか、そんな高度な詐欺行為を働いている？

　それならばと、プログラムを変更してみた。今度は、同じようにデバイスの先頭からシーケンシャル番号で領域を書きツブしながらも、先頭部分だけでなく、書きツブした部分をトビトビに監視する、というものだ。イザ、実行ッ！

 #!/usr/bin/env ruby
 
 # SD カードチェッカ 2
 
 class Integer
     def to_h
         sprintf('%d', self).to_s.reverse.scan(/.{1,3}/).join(',').reverse
     end
 end
 
 dev = ARGV[0]
 check_max = 8 * 1024 * 1024 * 1024                              # 8Gbytes
 #check_step = 128 * 1024 * 1024                                 # 128Mbytes
 check_step = 63 * 1024 * 1024                                   # 63Mbytes
 puts('device = %s, check_max = %16s' % [dev, check_max.to_h])
 
 adr = 0; open(dev, 'w') {|fh|
 
     check_md5s = {}; while(adr < check_max)
         puts('%16s .. ' % adr.to_h)
 
         chunk = ''; (1024 * 1024 / 8).times {                   # 1Mbytes
             chunk << [adr >> 32, adr & 0xFFFFFFFF].pack('N*'); adr += 8
         }
         fh.write(chunk)
         fh.fsync
 
         check_adr = 0; while(check_adr < adr)
             system('dd if=%s of=/tmp/_sdcard_checker_ bs=4096 count=1 skip=%d iflag=direct >/dev/null 2>&1' % [dev, check_adr >> 12])
             md5 = `md5sum /tmp/_sdcard_checker_`.split(/\s/)[0]
             check_md5s[check_adr] ||= md5
             puts('%16s %16s %s %s' % [check_adr.to_h, check_adr >> 12, md5, check_md5s[check_adr]])
             check_md5s[check_adr] != md5 and raise('Unmatch!')
             check_adr += check_step
         end
     end
 }
 
 puts('%16s finished.' % adr.to_h)
 
 __END__

　出た。128MBトビトビに監視していたら、256MBを書いた直後、書いたばかりの部分がブッ壊れる症状が出た。

# sdcard_checker2 /dev/sdb
device = /dev/sdb, check_max =    8,589,934,592
               0 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       1,048,576 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       2,097,152 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       3,145,728 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       4,194,304 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :
     267,386,880 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
     134,217,728            32768 01517d88da540a8eb5d44af02f122649 01517d88da540a8eb5d44af02f122649
     268,435,456 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
     134,217,728            32768 01517d88da540a8eb5d44af02f122649 01517d88da540a8eb5d44af02f122649
     268,435,456            65536 ba2930882b4da3d3ddd5b8697fc127d5 ba2930882b4da3d3ddd5b8697fc127d5
     269,484,032 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
     134,217,728            32768 01517d88da540a8eb5d44af02f122649 01517d88da540a8eb5d44af02f122649
     268,435,456            65536 5aa7b9d34285ac27f76b54f5ff4560fc ba2930882b4da3d3ddd5b8697fc127d5
/home/mitsu/develop/petit_tools/sdcard_checker:33:in `block in <main>': Unmatch! (RuntimeError)
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `open'
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `<main>'

　試しに。中途半端に63MBトビトビに監視してみても、256MBチョイを書いた直後、書いたばかりの部分がブッ壊れる症状が出た。

# sdcard_checker2 /dev/sdb
device = /dev/sdb, check_max =    8,589,934,592
               0 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       1,048,576 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       2,097,152 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       3,145,728 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       4,194,304 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :
     329,252,864 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
      66,060,288            16128 2ed7a89c5a42bb4040bff4894be82bdb 2ed7a89c5a42bb4040bff4894be82bdb
     132,120,576            32256 919cfe23e7079f9077e4360ad127f628 919cfe23e7079f9077e4360ad127f628
     198,180,864            48384 c5d3ae3f1ac1b256bb20b044cc491719 c5d3ae3f1ac1b256bb20b044cc491719
     264,241,152            64512 dc83f09e6ee934dcc90677af587a629d dc83f09e6ee934dcc90677af587a629d
     330,301,440 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
      66,060,288            16128 2ed7a89c5a42bb4040bff4894be82bdb 2ed7a89c5a42bb4040bff4894be82bdb
     132,120,576            32256 919cfe23e7079f9077e4360ad127f628 919cfe23e7079f9077e4360ad127f628
     198,180,864            48384 c5d3ae3f1ac1b256bb20b044cc491719 c5d3ae3f1ac1b256bb20b044cc491719
     264,241,152            64512 dc83f09e6ee934dcc90677af587a629d dc83f09e6ee934dcc90677af587a629d
     330,301,440            80640 f005f81d5ee41aa397fc39db563060fe f005f81d5ee41aa397fc39db563060fe
     331,350,016 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
      66,060,288            16128 2ed7a89c5a42bb4040bff4894be82bdb 2ed7a89c5a42bb4040bff4894be82bdb
     132,120,576            32256 919cfe23e7079f9077e4360ad127f628 919cfe23e7079f9077e4360ad127f628
     198,180,864            48384 c5d3ae3f1ac1b256bb20b044cc491719 c5d3ae3f1ac1b256bb20b044cc491719
     264,241,152            64512 dc83f09e6ee934dcc90677af587a629d dc83f09e6ee934dcc90677af587a629d
     330,301,440            80640 d207d5474108dac6a8961a17d6f73fa2 f005f81d5ee41aa397fc39db563060fe
/home/mitsu/develop/petit_tools/sdcard_checker:33:in `block in <main>': Unmatch! (RuntimeError)
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `open'
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `<main>'

　この症状は、代品もまったく同じで、これはもう仕組まれたものと考えて間違いないだろう。要するに「容量偽装」というわけだ。まぁ、ウェアレベリングの仕組みに意図しない不具合があった、という見方もできなくはないけれど。無理に、先頭部分のみパーティションを確保して使う方法もあろうが、さすがに256MBじゃ、いまどき使い物にならんわな。

　しかし、悪意だと仮定して、ここまでしてクソ製品を売ることにどれほどの意義があるんだろう。これをカメラに挿して旅行に出かけた人がどれほど悲しいことになるか、考えたことはあるんだろうか。販売店にも迷惑がかかるし、そもそも貴重な資源をクソの山にすることに罪悪感はないのだろうか。いったい誰が得をするっていうんだ。

　ったく、時間の無駄だったぜッ!! などと悪態をつきながらも、ここ数日、心のどこかで、やや楽しみながらこういう試行をして記事にしてしまったオイラは、やや得をしたのかもしれんけど……。

[ツッコミを入れる]

2024-06-14(Fri) 王滝村、野麦峠、安房峠ドライブ

　別に高いところを目指したわけではないが、真夏になる前にオープンドライブを楽しもうと、いくつかの道に対するリベンジも含め、臨時の休日を利用して1泊のロングドライブに出発した。

　平日は休日とは混雑の場所が違う。8時過ぎの出発では遅かったか。自宅付近で渋滞に巻き込まれ、郊外に出るのに手間取ってしまった……が、その後はいつものコースで中津川……と、思ったらその直前で363号が通行止めだ……が、険道にはよくあること。根の上の別荘地を抜け、迂回路となる険道で中津川へ。あれ、この道はWRCのSSだった道じゃなかったかな？無事、木曽高速という異名を持つ19号へ乗る。

　渋滞のロスを取り返すように快走。大桑の先で、新しく整備された木曽川右岸道路に入ってみる。交通量はほぼゼロ。寝覚の床に用のない人にはこっちが早いな。上松からは上松御岳線へ。再び、そこそこの険道。裏を回る形で道の駅三岳に到着。ちょうど昼時だが、この道の駅にはレストランがなかった。休憩所があるので、弁当を買って昼飯。一息つく。

　スイッチバックしたら、最初の目的地である王滝村へ。王滝村って、地図で見ると行き止まりに位置していて、敢えて向かわなければ訪れない場所という感じがしたので、今回、敢えて目的地のひとつに選んでみた。行ってみると、御嶽山の登り口という感じの場所で、なんだか島っぽい雰囲気だ。とりあえずドン詰まりに行って納得したいので、まずは山の上を目指す。

　ズンズンと登っていく。道は悪くない。しばらくしてスキー場に着くが、まだ上がある。というか、ゲレンデを横断するようにクネクネしながらテッペンまで行ける。リフトに乗らずにリフトの頂点より上までクルマで行けるとは面白い。標高は2200m。涼しい。お揃いの電動スポーツ自転車で登ってきたという初老の夫婦がいた。そういうのもあるのか。

　納得したので下へ。次は西端を目指す。中途半端なところでゲートに阻まれるが、なかなかに奥が深い。途中、はるか上空を横切る立派な白いトラス橋の下をくぐったが、何と橋には床板がない。道路橋ではなく水道橋なのだ。スゲェもんがあるんだな。

　納得したので戻る。戻りは御岳湖の南を通り、なぜかまた道の駅三岳へ。そこから御岳ロープウェイを目指す。が、登り始めてからナビがしきりに戻れとうるさい。不審に思ってナビの地図を見ると先の道が切れている。なに？奥に抜けられない？事前に調べた限りではそんなことはなかったはずだが……と思った矢先、予定外の道に入ってしまった。倉越パノラマラインというらしい。かなり激しい下りのコースだ。結局、それで山を下りたが、実際には御岳ロープウェイを通っても奥に抜けられたようだ。どうも、スキー場の閉業で、その中の道が通れるようになったような雰囲気。時々あるパターンだな、それは。ナビの地図が少し古かったせいか。

　次はそのまま北上して野麦峠へ。そこそこの険道。野麦峠といえば「あゝ野麦峠」だ。雪の山道から転落する映画だったような。しかし交通量はほぼゼロだな。スイスイだ。

　が、それを抜けた辺りでちょっと時間が怪しくなってきた。宿には18時過ぎには着きたい。というのも、周囲のスーパーで晩飯を調達予定なのだが、妙に閉まるのが早かった気がするのだ。というわけで、以前に冬季クローズで通れなかった上高地乗鞍林道(林道奈川安曇線)は今回もパスして安房峠(あぼうとうげ)へ向かう。まぁ、また来りゃいいさ。

　安房峠は今回の目的地のひとつ。以前は冬季クローズで通れずトンネルを抜けたが、今回は直前で坂道を登っていく。おぉお、スゲェなこれは。つづら折りの間が長い。数も多いのでちょっとダレるし、その先もだいぶ距離がある。こりゃ、よほどの物好き以外、790円を払ってでもトンネルを通るはずだわ。まぁ、そのよほどの物好きなんで峠道を通るけれどもさ。

　峠道を抜けると、前回に来た時に柵が閉まっていることを確認したゲートが現れ通過となる。今日のメニューは終了だ。今日の宿泊地である栃尾温泉に向かう。そして到着前に大誤算。2店あるスーパーがどちらも閉まっている。どうも18時終了だったようだ。早いにしても程がある。甘く見すぎていた。

　宿でチェックイン手続きをしながら近くのコンビニを尋ねると、クルマで1時間とのこと……ほぅ、1時間ねぇ……って、1時間ッ!? いまは19時前。弁当を買って帰ってきたら夜食じゃねぇか。が、仕方なくクルマを出すとすぐソコの酒屋が開いているのを発見。カップ麺やつまみ程度ならあるだろう、と思って行くと、カップ麺やつまみ程度ならあった。しゃーない、晩飯はそれで手を打とう。

　飛騨高山中華そばというカップ麺と、味付けうずら卵、金麦というシンプルな晩飯を済ませ、入浴、その後やきとり缶と桃チューハイをアドインして早めのお休みである。いやー、今日はたくさんの道を回収できたので満足だわい。

[ツッコミを入れる]

2025-06-14(Sat) ロードスターを実装するが、またもや「理解」されてしまう

　つうわけで、しばらくは鈴鹿でロードスター(相当)を走らせて、コースを覚えたり、各種調整を進めることにする。

　早速だが、ロードスターの各ギアでの上限速度は……ん？ギア比が公開されているのだから、それを使えばいいか。すると、それを速度に変換するための係数はいくつになるのだろう……ん？それってタイヤの外径から理詰めで求められるのでは？ 195/50R16の外径は……ん？それも理詰めで求められるのでは？

#!/usr/bin/env ruby
 
include Math
 
gear_ratios = [5.087, 2.991, 2.035, 1.594, 1.286, 1.000]
final_ratio = 2.866
tire = [195, 50, 16]
rpm = 7500
 
tire_dia = (tire[0] * tire[1] / 100.0 * 2 + tire[2] * 25.4)
tire_cir = PI * tire_dia
 
gear_ratios.each {|gr|
    p tire_cir * rpm * 60 / gr / final_ratio / 1000 / 1000
}

　できてしまった。実行すると……

58.31602138429881
99.18207983347644
145.77572519996463
186.10639948678045
230.6793163156517
296.65360078192805

　 ……合っているっぽい。実際の鈴鹿の動画では4速までしか入れておらず、180km/hチョイだったので合っている。直接にkm/hを与える方法も残しつつ、ギア比等の入力で車両特性を指定する方法も実装してみるか。

　と、ここでまた、ふと、AIを試してみたくなった。やめときゃいいのに。

以下は何のプログラムでしょうか？
ratios = [5.087, 2.991, 2.035, 1.594, 1.286, 1.000]
final = 2.866
spec = [195, 50, 16]
rpm = 7500
 
dia = (spec[0] * spec[1] / 100.0 * 2 + spec[2] * 25.4)
cir = PI * dia
 
ratios.each {|gr|
    p cir * rpm * 60 / gr / final / 1000 / 1000
}

このプログラムは、**自動車やバイクの各ギアにおける最高速度の概算を計算するスクリプト**です。
特にエンジンの最大回転数（`rpm = 7500`）時に、各ギアでの\*\*理論的な最高速度（km/h）\*\*を求めています。
 
## 🧠 解説：何を計算しているのか？
 
### 🔢 入力データの意味
 
```ruby
ratios = [5.087, 2.991, 2.035, 1.594, 1.286, 1.000]  # 各ギアのギア比（1速〜6速）
final = 2.866                                        # ファイナルギア比（ディファレンシャル）
spec = [195, 50, 16]                                 # タイヤサイズ：[幅 (mm), 扁平率 (%), ホイール径 (inch)]
rpm = 7500                                           # 最大回転数（エンジンの回転数）
```
 
### 🛞 タイヤの直径と外周長の計算
 
```ruby
dia = (spec[0] * spec[1] / 100.0 * 2 + spec[2] * 25.4)
```
 
* タイヤの直径（mm）を計算：
 
  * `spec[0] * spec[1] / 100` → サイドウォールの高さ（上下分なので ×2）
  * `spec[2] * 25.4` → ホイール径を mm に変換
  * 合計で**タイヤ全体の直径**
 
```ruby
cir = PI * dia
```
 
* タイヤの外周長（mm）＝ 円周公式：π × 直径
 
### 🚗 速度の計算
 
```ruby
ratios.each {|gr|
  p cir * rpm * 60 / gr / final / 1000 / 1000
}
```
 
各ギア（`gr`）に対して：
 
* `cir * rpm * 60` → 1分間のタイヤの進行距離（mm）
* `/ gr / final` → エンジン回転数からタイヤ回転数への換算（ギア比補正）
* `/ 1000 / 1000` → mm → km に変換
* → **理論最高速度（km/h）を出力**
 
## ✅ 出力されるもの
 
このスクリプトは、**1速〜6速ギアにおける最大回転数時の理論的な速度（km/h）を出力**します。
 
例えば出力が以下のようになるとすれば：
 
```
31.4
53.4
78.5
100.3
124.3
160.1
```
 
これは、「7500rpm 時の各ギアの速度」です。
 
## 📝 まとめ
 
このプログラムは：
 
> **「指定したギア比・ファイナル比・タイヤサイズ・エンジン回転数」から、各ギアでの最高速度（km/h）を計算する**
> → 車やバイクの**性能シミュレーションや仕様設計**でよく使われる方法です。

　 ……マジか……またもや完璧な説明。コメントも何もないのに、正しいコメントを付けてくれちまっている。当然のように[195, 50, 16]が「195/50R16」を意味することまで見抜いている。

　ひとつだけ間違っている。「cir * rpm * 60」は1分間でなはく、1時間のタイヤの進行距離(mm)だ。しかし、それ以外は完璧すぎて、もしかしてワザと間違ったのではないかと勘ぐってしまったり。

必要であれば：
 
* 同じ処理の Python 版や CoffeeScript 版
* より実用的な「グラフ化」や「回転数別スピードマップ」
  も提供できます。お気軽にどうぞ。

　うっせぇわ！

[ツッコミを入れる]