裏表(Phinloda のもう裏だか表だか分からないページ)

コンピュータ・プログラミング系の話がメインのそれなりにごちゃごちゃしたネタばかり出てくるサイトです。多分。
久しぶりに docomo の Wi-Fi に接続したのだが

いつも新宿で接続に四苦八苦して give up するのだが、今日は別の場所で全く問題なくすんなりと接続できた。設定は何も変えてないから、要するに新宿は混雑しすぎているので接続できない、みたいな話なのか。

JUGEMテーマ:インターネット

| インターネット | 09:14 | comments(0) | trackbacks(0)
Google の「いつか聴いた曲」のキャッシュが3/9から更新されていないのだが

特に何か変わったことをした記憶はないのだが Phinloda のいつか聴いた曲 - Yahoo!ブログ の Google のキャッシュが3月9日を最後に更新されていない。

自分で投稿した曲をチェックするときに google を使うというズボラな管理をしているので、google で検索されないと、まだ書いてないと錯覚してしまいそうで怖い。流石に今月書いた曲は何となく分かるけど。

JUGEMテーマ:インターネット

| Google | 20:17 | comments(0) | trackbacks(0)
何となく調子が悪いのだが

今日はどうしても外せない大仕事があったので、休めないし、まあ仕方ないと思っていたら前に立ってた人が倒れるし、何か調子悪くなる電磁波でも出ているのかもしれない。

いや普通に気候の急激な変化、という気もするけど。東京では桜もびっくりして咲いたらしいし。

JUGEMテーマ:日記・一般

| 独り言 | 20:32 | comments(0) | trackbacks(0)
ジャストナンバー

ネットのバトル系のゲームで、相手の強さが 200 のような数値のときの方が、192のときよりも勝ちやすいような気がする。つまり、200 より 192 の方が強い。

なぜ 200 より 192 が強いのか。このゲームは持っているカードを指定数値以下になるように組み合わせて戦うルールなので、40+40+40+40+40 で 200 だったら、40+40+40+40+32 よりも基本的には強くなる。

しかし、相手のカードがこのようにちょうど 200 になっていことはあまりない。カードの合計は200 ないのである。例えば今持っているカードの合計が 154 だとしても、カードを強化する都度変更するのは面倒だし、とりあえず 200 にしておくか、のようなノリで数字を指定している人が多いのではないか。私もそうなんだけど。

これに対して、192 のような数字は、手持ちの合計が192 で、ぴったりという人が多いような気がする。手持ち max が 184 なのに 192 とする人はあまりいないのではないか。少し多めに指定するときは、何となくちょうどいい数字を選んでしまうのだ。

JUGEMテーマ:日記・一般

| 独り言 | 20:12 | comments(0) | trackbacks(0)
ニンテンドースイッチの抽選販売があったのだが

朝っぱらから店が開く前に何並んでるのかという感じで9時から並んでいる人がいる。折角だから抽選券をもらってくるか、と思って並んでみたら、券ではなく番号をプリントした紙テープみたいなのを手に巻いてリストバンドにした。特殊な素材で、ハサミ等で切らないと外せない。切ったら無効になってしまう。これで転売を防ぐ仕組みのようだ。

ちなみに、12時になって当選番号を見にいったらおもいっきり外れていた。番号を見た感じでは、1/10程度の確率だったようだ。世の中そう甘くない。

と思ったのだが、もしかして当たっても受け取りに来ない人もいるかもしれない、とか思ったので夜にもう一度行ってみたら、緊急入荷とかいう看板持ってる店員がいて、あっさりその場で買えてしまった。行ってみるものだ。

JUGEMテーマ:日記・一般

| 独り言 | 21:00 | comments(0) | trackbacks(0)
Windows のファイル移動が異様に遅いのはよく知られたことではあるが (2)

ファイルを一気に移動すると遅くて話にならないのだが、もしかしてある程度まとめて移動した後、移動した先からさらに移動すると処理時間が短縮できるのではないか、と考えた。次のような話。

201701 というフォルダに、2017年1月に作成したファイルが入っている。これを、01、02、03、04、05 という5個のフォルダに、1日〜5日のファイルを振り分けたい。

これを、201701から01、201701から02、…のように1日ずつ処理するよりも、201701から1〜5日のファイルを一揆にtmp に移動しておいて、tmpから01、02、…に振り分けた方が速いのではないか、と思ったのである。

実際にやってみた。ただし、一度移動したファイルはどこかに情報がキャッシュされて、2回目の移動の方が速くなるような気がする。そこで、tmp経由の方が速いと予測して、遅くなりそうな直接移動を後で測定することにした。後の方がキャッシュの影響で速くなったとしても、それでなお遅かったら、キャッシュの影響がない場合はもっと時間がかかるはずだから遅いと判断していいだろう、という読みである。

一度 tmp に移動してから01〜05にコピーした場合、541秒+αかかった。 αというのは、tmp からそれぞれにコピーする時間は1秒未満なので、その程度のプラスということである。仮に5秒とすれば、546秒となる。

これに対して、直接01〜05に振り分けると、128+111+53+183+97= 572 秒かかった。秒数にばらつきがあるのは、ファイルの数の影響である。440 + 645 + 305 + 1070 + 575 = 3035 個のファイルを、約8万個ファイルが入ったところから移動している。

体感したのと同じで、やはり一度まとめて移動してからさらに分離した方が速かったが、思ったほどの差はなかった。

処理中に見ていた感じでは、ファイルを移動跡、移動元のフォルダから移動したファイルの一覧を消す処理に時間がかかっている。これを5回に分けてやるよりも、1度にやってしまった方が速い感じだ。 だとしたら、もしかしたら移動するよりもメモリディスクとか作ってそこにコピった方が速いのではないかとか思ったけど、体力の限界【謎】で試していない。

JUGEMテーマ:Windows

| Windows | 20:40 | comments(0) | trackbacks(0)
Windows のファイル移動が異様に遅いのはよく知られたことではあるが

1万個程度のファイルを移動しようとしたのだが、1時間待っても処理が始まる気配がないので諦めて中止した。 メモリは8GB以上空いているので、やりようがあると思うのだが、何か異様に遅いのはアルゴリズムに問題があるのではないか。

そもそも同一ファイルシステム内での移動なのだから、実体のコピーは一切発生しないはずだし、一瞬で終わっても不思議ではないと思うのだが。

JUGEMテーマ:Windows

| Windows | 19:12 | comments(0) | trackbacks(0)
そろそろpcを何とかしたいのだが

DVDドライブが壊れて難儀しているわけだが、実は3年間保証というのに入っているから、5月某日までに修理に出せば、保証期間内なのである。

ただ、メーカーが最近ニュースで盛り上がっている某社というのがちょっと気になっていたりする。早くしないとメーカーが…というのは流石にないと思うのだが。

JUGEMテーマ:コンピュータ

| パソコン | 21:04 | comments(0) | trackbacks(0)
 1/488PAGES >>
Powered by "JUGEM"
▲このページの先頭へ
CALENDAR
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
<< March 2017 >>
NEW ENTRIES
CATEGORIES
ARCHIVES
NEW COMMENTS
NEW TRACKBACKS
LINKS
PROFILE