コンピュータの日記です

目次

2021-03-16 暮らしの中の微分積分
2021-03-01 IdeaPad Duet の使い勝手(2/2)
2021-03-01 IdeaPad Duet の使い勝手(1/2)
2021-02-23 Lenovo Ideapad Duet 購入
2021-01-29 微分積分いい気分
2021-01-26 ノートパソコン修理
2021-01-23 100倍規模
2020-12-13 ピクミン3デラックス
2020-12-07 HTMLで多数のデータを表示する。
2020-11-23 サーバーダウン
2020-11-18 経年劣化2
2020-11-12 経年劣化
2020-10-27 getGamepads
2020-08-22 Lenovo Ideapad C340 購入
2020-08-22 iPhone SE 購入
2020-08-17 Windowを閉じるボタンの左右位置
2020-07-27 リングフィットアドベンチャー
2020-07-17 phpSpreadsheet で小数点付き数値と見なせる文字列を入力するとおかしくなる
2020-06-19 ENIAC vs 6502
2020-05-21 Chromebook を買ったのだけど
 …同じテーマのほかの記事
暮らしの中の微分積分  2021-03-16 20:34:53  コンピュータ 数学

▲目次へ ⇒この記事のURL

少し前の日記で、微分積分は役立つよー と書いたのだけど、話の腰を折るのであまり具体例に踏み込まなかった。


これ、自分の中で気になっていて、もう少し説明したいと思っていた。


僕はプログラマーなので、これから書くのはコンピュータープログラムとしての微分積分の話だ。

そして、プログラムとしての微分積分というのは、高校で習ったアレは何だったのかと気が抜けるほど簡単だ。


まぁ、高校で習ったことはちゃんと意味があるので、そのフォローは最後にやる。


▼積分の概念


というわけで、微分積分の「考え方」から説明しよう。

微分積分、と言っているとややこしいので、まずは積分に話を絞る。


前提知識として、足し算は理解しているものとする。

足し算がわからない人には、さすがに説明ができない。


では、[ 3, 3, 3, 3 ] …3 が4つあるのだけど、全部足してみて欲しい。


答えは 12 だ。3 + 3 + 3 + 3 でいいのだけど、3 × 4 と考えるとすぐに答えが出る。


次に、[ 3, 4, 5, 6 ] を全部足してみて欲しい。


今度は掛け算は使えないので、地道に足し算をするしかない。

3 + 4 + 5 + 6 で、答えは 18だ。


概念的には、後者が積分にあたる。


たくさんの数をまとめて足す方法が積分。

そのうち、数が「たまたま全部同じだった」という特殊な場合が掛け算だ。




ここに書いた例では、4つの数を足しただけだった。

これが、数万という数があると考えて欲しい。とても手計算で足し合わせることはできない。


でも、それらの数に何らかの法則があって、数式で表せたとしよう。


こうなると話が変わってくる。足したい数の概要を数式として示せたので、これをもとに「全部足した結果」の数式を作り出す。

すると、数万件の足し算をする必要がなくなり、すぐに答えが出る。


これが、高校で習う積分だ。


ただ、数式で表すとなると、整数だけが相手というわけにはいかない。

式を変形するための前提条件などもいろいろと付き、話が複雑になっていく。


結果として「難しい」と思われてしまうのだけど、やりたいことは「全部足す」なのだ。


さて、そこでコンピューターが開発された。

最初は、「ひたすら足し算」しかできない機械だった。

でも、足し算さえできれば積分計算ができる。それで十分だ。


今のコンピューターもその延長上にあるので、プログラムのいたる所に積分が顔を出す。

多分、多くのプログラマーが、積分だとも思わないまま使っているのだけど。



▼積分の具体例


具体例をあげよう。


最近の家庭用テレビゲーム機では、コントローラーを振って操作することができる。

3Dのゲームで、コントローラーを左右にふることで、左右を見ることができたりね。


これ、コントローラーには「向き」を知るための仕組みは入っていない。

入っているのは、加速度センサーだ。


加速度、というのが馴染みが薄いかもしれないのだけど、単純に力のことだ。

加速度センサーは、コントローラーにかかる力を知ることができる。


そして、速度に加える、という名前の通り、足し算を続けると…つまり、ここまでに説明したように「積分」すると、現在の速度が得られる。


さらに、速度を積分すると、今度は現在の位置が得られる。

自分の体を中心としたコントローラーの位置と考えると、「向き」と近似のものだ。


こうして、加速度センサーから得られる値を、2回積分することで、コントローラーからは直接得られない「向き」を算出しているんだ。



積分を行うと、値のもつ「意味」を変えることができる。

ここでは、加速度を速度に、速度を位置に、変えることができた。


長さを面積に、更に体積に変えることもできる。

掛け算でも同じだけど、先に書いたように、掛け算は積分の特殊な場合だから。


プログラムしていて、欲しい値が手に入らない、ということはよくある。

そうした場合でも、手元にある値を積分することで、欲しい値を作り出す事ができる。


プログラマーなら、こうしたプログラムの経験はいくらでもあるだろう。

積分というのは特別なことではなく、ごく当たり前に使われるものなのだ。




また別の例を上げる。


積分を使うと、複雑なものを単純化できる。


物を投げたときの位置は、それほど難しくない数式で示すことができる。

いわゆる放物線だ。


まぁ、人がボールを投げるくらいなら放物線の式で問題ない。

でも、高速で動く場合は空気抵抗が問題になり始める。

そこまで考慮して位置を示す式を作ろうとしても、複雑すぎて作ることができない。



そこで積分を使う。

いきなり位置を表す式を作るのではなく、まず速度の式を作るのだ。

空気抵抗は速度によって変わるので、速度をもとに空気抵抗を求め、その空気抵抗で速度が変わるようにする。


そして、その速度を積分して位置を求める。

ここで言う積分は、もちろんコンピューターの計算力で足し算を繰り返すことだ。


このように、複数の段階に分けることで、複雑すぎて手に負えない計算も行うことができる。


こちらも、プログラマーにとってはそれほど特別なことではないね。

ゲームを作る人なら、いろいろな条件で途中から動きが変わったりする、つまり「加速度」を持つプログラムは当たり前に組むだろう。


▼微分


積分の話を2つほど挙げたが、続いて微分のことを書こう。


微分は積分の逆の操作だ、と思ってだいたい間違いはない。

微分して積分したらもとに戻る。


積分がすべて足すのに対して、微分は直近の値を引く。

これによって、直近から値がどのように変わったのか、その「差」を調べることができる。




積分例として、ゲームコントローラーの話を書いた。

コントローラーには加速度センサーしか入っていないが、積分すれば位置がわかる。


逆の話として、スマホのタッチパネルのことを書こう。

タッチパネルに指を触れると、その位置がわかる。でも、位置以外はわからない。


しかし、タッチパネル操作でスクロールを行うとき、「フリック」すると、その時の速度でスクロールが続く。


ここでは、指の位置情報を微分することで、速度を求めているんだ。


フリックとは、指を動かしている最中に、急にタッチパネルから離す動作。

指が離れた直前の速度がある程度あった場合、そのままスクロールを続けるようにする。


そして、徐々にスクロールが止まるのは、速度を変化させる、逆向きの加速度を設定している。

これらの動作は、積分を行っている。




微分すると、変化がわかる。

これを多用しているのが、写真などの加工アプリだ。


ある点に注目したときに、すぐ隣の点との差を出す。

これを画像のすべての点について行い、その結果を新たな画像とする。


これが「画像を微分する」ということなのだけど、この結果得られるのは、色の変化するところを拾い出したような画像だ。

いわゆる「輪郭抽出フィルタ」だと思っていい。表示の方法によっては、レリーフ化フィルタになる。


この輪郭に対してもう一度微分すると、輪郭のすぐ隣の点を際立たせるデータが得られる。

これを元の画像に重ねると、輪郭がくっきりとする。

「シャープフィルタ」とか「ピンぼけ補正フィルタ」と呼ばれるものだ。


ここに書いたのは単純な原理だけで、実際の画像処理ではもっと工夫された処理が使われている。

しかし、微分の応用範囲の広さはわかってもらえると思う。



▼微分積分とは


これ以上書いても同じような話ばかりになりそうなので、少し話を変えよう。


微分積分というのは難しいものだ、と思っている人は多そうだ。


でも、コンピューターで計算するときは、ただの足し算引き算だ。

特に難しい処理ではない。


じゃぁ、なんで高校ではあんなにややこしい教え方するのさ、という話。


これにはもちろん意味がある。

微分積分学は19世紀に大きく発展したのだけど、コンピューターの登場は 20世紀なのだ。


だから、学問としてはコンピューターのほうが新しく、難しい。

高校でやるのは積分の「基礎」で、コンピューターを使うのは「応用」なのだ。


今回書いた話も、概念としては「微分積分」なのだけど、数学的な妥当性はちょっと怪しい。

わざと簡単な話だけやっていて、ややこしい話は避けたからね。

真面目に書こうとすると、高校レベルの数学では収まらない話になる。


でも、今回僕が示したかったのは、数学的な妥当性ではない。

難しいと思って避けている人が多い「微分積分」が、案外身近に使われているし、考え方自体は簡単なものだと知ってほしかったのだ。


▼最後に


微分積分の話、もっと書きたいことはたくさんある。

でも、何でもかんでも盛り込むと話が横道にそれ過ぎて、わかりづらくなる。


今回も、これでも泣く泣く削った話が多数あるのだ。


諦めきれないネタを2つ、概要だけ示す。

説明は長くなるからしない。書きたいから書きっぱなしにする、というだけ。


・太陽の位置と季節の話


12月の冬至と6月の夏至が「昼と夜の長さ」のピークなのに、寒さと暑さのピークは2月と8月だ。

なんでピークがずれるのか気になったことはないだろうか?


太陽の運動を正弦波、太陽エネルギーを気温に変えるのに積分が必要だと考えると、大体理解できる。


・フーリエ変換


異世界転移の魔法。

ネイピア数を虚数乗することで複素空間に円形の魔法陣を描き、そこに波動をぶつけて積分すると「周波数空間」という異世界に転移できる。

もちろん、異世界に行ったら無双できるのがお約束。


…と、与太話を書いてから真面目に解説したかったのだけど、そもそもこの与太話がフーリエ変換を理解していないとわからないし、解説もすげー長くなるからやめた。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

数学

関連ページ

異世界転移の方法【日記 21/04/01】

別年同日の日記

05年 大忙し

09年 辻堂海浜公園

15年 ドットリ君

17年 タネンバウム教授(1944) ストールマン(1953) 誕生日

20年 ソフトウェアリリース


申し訳ありませんが、現在意見投稿をできない状態にしています

IdeaPad Duet の使い勝手(2/2)  2021-03-01 11:24:01  コンピュータ

▲目次へ ⇒この記事のURL

さて、前の記事では Duet が素晴らしい、ということをざっくりと書いた。


ここから先は、細かな使い勝手について書いていこうと思う。

あくまでも個別論だし、実際に使ってみないと分かりにくい部分も多いと思う。

それでも、今注目されている機械なので、購入を検討している人のお役に立てればと思う。




最初に、言葉を見直しておこう。ここまでにもすでに使ってしまっているのだけど。


Chrome は、Google が開発した Web ブラウザのことだ。

PC 用と Android 用がある。


Android 用は、PC 版から多くの機能が削除されているサブセット版だ。

別のものだと思っていいほど違う。



Chrome OS は、PC 版の Chrome だけが動けば良い、という前提で作られた OS だ。


Web サービスだけ見られれば十分、ということは案外多い。それなら Chrome だけが動けばよい。

現在では、当初の目的から少し方向が変わり、Android のアプリも動かすことができる。



Chromebook は、Chrome OS を採用した PC 製品群に付けられたブランド名だ。

今回僕が購入した IdeaPad Duet も、Lenovo 社から発売されている Chromebook だ。


Lenovo の製品としては、Windows でも IdeaPad シリーズとなっているものがある。

なので、この記事中では Duet と呼ぶことにする。



▼Chrome の使い勝手


Chromebook の話をするのだから、まず Chrome の使い勝手について書こう。

PC 版なのだから Windows などと同じ…と書ければ楽なのだが、そうではない。


まず、フルセット版だ。

機能拡張が使えるし、Android 版にはない「全画面表示」機能もある。

デベロッパーツールだって使える。


でも、PC 版と同じではなく、独自拡張もある。


まず、全画面モードの際の UI が少し違う。


Windows 版を使っている人は、F11 キーを押してみよう。

Web コンテンツが、全画面で表示される。これが全画面表示だ。


ウィンドウの最大化と違って、Chrome の UI であるURL バーやタブも消える。


UI が消えるということは、タブ切り替えなどもできないということだ。

(キーボードショートカットは効くのだけど)



Chrome OS の Chrome では、この状態でも画面上端にマウスカーソルを持っていくと、URL バーやタブが表示される。

この機能がすごく便利。PC 版にも付けてほしい。


まぁ、Chromebook は低価格を狙った機種が多く、PC ほど画面が広くないので、「全画面表示を使うことが多い」ことに考慮したのだろう。

PC では全画面表示はプレゼンなど特別なときにしか使わず、その際には余計なインターフェイスは表示されないほうが良い。



もう一つ、PC 版にはない、拡大表示操作が可能になる。

これ、表示倍率を変える「ズーム」機能とは違うものだ。2本指によるピンチ操作で自由な倍率で拡大できる。

拡大しているときでも、Chrome の「ズーム」は 100% のままなので、別の機能だとわかる。


Android では自由な拡大はあたり前のことだし、便利なので取り入れられた機能だろう。


なお、常に自由に拡大できるわけではない。表示サイズが重要で CSS で指定してあったりすると、拡大できないようだ。



まだある。

Chrome OS をタブレットモードにすると、Chrome もタブレットモードになる。

この時、タブ部分は隠され、URL バーは Android 版のように、スクロールに合わせて出たり消えたりする。


ただ、Android 版と違って、この状態でも明示的に「全画面」を指定すると、URL バーは消えっぱなしになる。

この場合でも、画面上部から下向きにフリックすると URL バーが出てくる。


これがまた、非常に便利。

Android 版の場合、ページめくり式の漫画とかを読もうと思う、下に向かってスクロールできず、URL バーが消えないんだよね。



URL バーが出ているときにもう一度、上部から下方向にフリックすると、タブ切り替えの UI が出てくる。

ただし、この UI はタブではなくて、サイトイメージを並べたリストになっている。


これは、指で選択しやすいように大きく表示することが目的のようだ。

大きくなったため、量が多いときは横スクロールして表示する。


これは便利機能というより、操作のために必要だから付けた機能だろう。


他に気づいていないところもあるかもしれないが、主な違いはこの程度だ。

便利にするために追加された機能はあるが、PC 版の機能は、おそらく全部使える。


だから、サブセットの Android 版では見られなかったようなサイトでも、全て見られる。

Web サービスも全て受けられる。



もっとも、それができなくなったら、Chrome OS としての意味がないと思う。




Chrome OS は、もともと Chrome 上で動作する Web サービスをアプリとして使用するものだった。

なので、よく使うページがあれば、積極的にアプリとして登録しよう。


これには、「ショートカットを作成」機能を使う。

作られたショートカットは他のアプリと同列に並べられ、アプリとして実行できるようになる。

まぁ、Chrome のショートカットだから、新しいタブで Web ページにアクセスするだけなのだけど。


じゃぁ、ショートカットではなく、ブックマークに登録しても良いのではないか、と思う人も多そうだ。


でも、そうではない。

後で書くけど、アプリは実行しやすいような工夫がある。

だから、Chrome のブックマークに登録して呼び出す、というのより、ずっと使い勝手がいいんだ。

ショートカットを多用することをおすすめする。



▼Android アプリの使い勝手


つづいて Chrome OS のもう一つの顔、Android アプリの実行環境を見ていこう。


Duet 購入前は、Android アプリが、スマホのエミュレート環境の中で動くような感じかな、と思っていた。

縦に長い固定サイズのウィンドウが開いて、その中でスマホのアプリが動く、みたいなイメージ。


しかしそうではなかった。もっと高いレベルで実行環境が OS に統合されており、Chrome と同じレベルで使うことができる。


まず、PC モードの場合、Android アプリはウィンドウ内で実行される。

ウィンドウのタイトルバーの左端には「戻る」ボタンがあり、右上にはウィンドウを操作するボタンが並ぶ。「閉じる」ボタンを押せばアプリが終了する。


ウィンドウをリサイズすればそれに合わせて適切に表示されるし、マウスカーソルでテキストを選択して、コピーすることもできる。


つまり、Android アプリだからといって何も特別なことはなく、ごく普通のアプリケーションとして使用できるのだ。


Duet の場合、初期インストールアプリとして入っている Gmail は、Android 版だ。

Chrome しか使えなかった初期の Chromebook では、Web 版 Gmail へのショートカットがアプリとして入っていた。


つまり、「Android アプリも実行できる」などという選択肢の一つではなく、Chrome OS にとっては Android アプリは必要なものだという認識なのだろう。


…でも、Gmail は Web 版のほうが便利。

アプリ版だと、未読を全選択して既読扱いにする、とかできないから。


先に書いたように、Chrome からアプリとして登録しておくと良いだろう。

(個人的な好みの問題もあるが)




Android アプリは、タブレットモードのときに操作が大きく変わる。

まず、Chrome と同じように全画面表示が基本となる。


実は、画面分割して2つのアプリを同時に表示することはできる。

これは、Android 7 相当の機能だね。


また、アプリが対応しているならば、ピクチャー・イン・ピクチャー表示にもできる。

これは Android 8 相当の機能だ。


しかしまぁ、全画面表示が基本だ。ここらへん、Android のスマホやタブレットと変わらない。


しかし、一つ困ったことがある。

Android アプリの操作に、Android の OS が用意する、画面下部の3つボタン…「戻る」「ホーム」「タスク」は必須だ。

しかし、Chrome OS にはこの3つボタンがないのだ。


もちろん、操作方法は用意されている。しかし、使い慣れた方法ではない、というだけで、最初は戸惑うことになる。


まず、「戻る」の操作は、画面左端から右に向かってスワイプだ。

すると、左矢印のアイコンが現れる。引っ張るとだんだん色が付き、十分引っ張ったところで色が反転する。


この状態で指を離すと「戻る」動作が行われる。

ちなみに、この操作は Chrome でも使える。Chrome は URL バーの左側に戻るボタンがあるけど、Android と同じ操作も使えるので、わざわざ操作を使い分ける必要はない。


次に、「ホーム」と「タスク」だけど、途中まで操作が共通している。


画面下から上に向かってスワイプすると、中央あたりで画面が全体に縮小される。


このまま上に向かって指をはらうと、画面は飛んでいってホーム画面が現れる。

中央あたりで指を止めて一瞬待つと、現在動いている他のアプリも縮小画面で現れ、タスクリストが表示される。


ちなみに、どちらも「中央辺りまでスワイプ」が必要で、それより短い距離だと別の動作になる。

後で書くが、アプリ起動を行うためのシェルフの表示だ。


初期の頃から、Chrome OS では画面下部にシェルフを表示していたので、これは仕方のない操作だと思う。

でも、距離によって違う意味になるというのは、慣れればともかく初心者には非常に分かりづらい。


画面下から短いスワイプというのは、Android では「隠れている3つボタンを表示」だ。

慣れる前は、ついこの操作を多用して、シェルフが表示されてがっかりした。


「シェルフと一緒に、Android で慣れた3つボタンを表示」なんて機能が将来のアップデートで付けばよいのに、と思う。


▼アプリの起動方法


上に書いた「シェルフ」について説明しようと思うのだが、便宜的に一緒に4つの概念を紹介する。


デスクトップ、ランチャー、ホーム画面、そしてシェルフだ。


まず、デスクトップ。Windows のデスクトップと同じで、いくつかのウィンドウを重ねて表示したときに、「なにもないところ」に表示されるものだ。


表示するものとして「壁紙」の絵を設定できる。

でもそれだけ。Windows のようにアイコンを置いたりはできない。


次にランチャーだ。

キーボードに呼び出すための専用キーがついていて、いつでも呼び出せる。

画面上のマウスカーソル操作でも呼び出せる。


ランチャーは画面全体を覆い、アプリのアイコンが並んでいる。アプリ以外のファイルなどは入らない。

アイコンはある程度整理可能だが、必ず左上に詰めて表示されので、自由に置けるわけではない。


Windows ではデスクトップによく使うものを置く人も多いと思うが、実際にはデスクトップは実行中のウィンドウに隠されてしまっていてアクセスしづらい。

だから、デスクトップにはなにも置けないようにして、現在実行中のウィンドウの上に重ねて表示できるランチャーを用意したのだろう。


Chrome OS の標準状態では、画面下部には Windows のタスクバーのようなものが表示されている。

そして、左端にランチャーを呼び出すボタンがある。


Windows なら、Windows アイコンがある場所だね。

そして、Windows ではこれを押すと、登録されたアプリのリストが表示される。


つまり、ランチャーはそれと同じことだ。


つづいては、ホーム画面。


上に書いた、デスクトップとランチャーは、PC モードでだけ現れる概念だ。

タブレットモードではなくなってしまう。


デスクトップはウィンドウの隙間に見えるものであり、全画面表示のタブレットモードでは不要だ、ということだろう。

でもランチャーが消えてしまうのは何故?


デスクトップモードでは、代わりにホーム画面という概念が現れる。

実際には、ランチャーの背景に壁紙の絵が貼られただけなのだけど。


ランチャーはいつでも呼び出せて、画面を一時的に覆うものだった。

使わないなら、先程までの画面にすぐ戻せる。


しかし、ホーム画面は画面が切り替わるもので、一時的ではない。

単にホーム画面を「消して」直前の画面に戻ることはできない。


でも、概念の違いはその程度だ。

つまりは、Android で慣れ親しんだホーム画面と同じようなものだ。



最後にシェルフ。

さきほど「タスクバーのようなもの」があると書いたが、実はこれがシェルフだ。

よく使うアプリのアイコンを固定しておくことができるし、現在実行中のアプリも表示され、タスクスイッチできる。

固定したアプリに関しては、いちいちシェルフを表示しないでも、キーボードショートカットで呼び出せるようになる。


Chrome OS での、アプリ起動の要となるものだ。



先程、タスクリストを表示する方法がわかりにくいという話を書いたが、そこで「Android のように操作するとシェルフが表示される」と書いた。


シェルフはタスクリストの機能を兼ねるので、実はこれでも操作することは可能だ。

(ホーム画面にもどる機能はないけど)



▼文字入力


Chrome OS を使っていると、標準では google 製の日本語変換エンジンを使うことになる。

多分、google 日本語入力なのだけど、正確なところはわからない。


変換効率などはとりあえず置いておこう。キーボードで使っている限りでは、それほど問題はない。

問題は、タブレットに切り替えたときなのだ。


タブレットモードだと、ソフトウェアキーボードが出てくる。

英語を想定した Qwerty キーボードだ。


日本語入力時も、Qwerty キーボードでローマ字入力になる。使いづらい。

タブレットなのだから、Android のようにテンキーフリック入力したい。



実は、この「文字入力」にも、Android のアプリが使える。

Android では、ソフトウェアキーボードは独立したアプリになっており、ユーザーが好きなものを使えるのだ。


そして、Chrome OS では Android アプリが動くだけでなく、ソフトウェアキーボードにも Android のものが使える。非常に互換性が高い。頑張っている。


ただ、ちょっとバグ含み。

Duet の場合、キーボードを接続すると物理キーボードを使うように自動的に設定が変わる。

そして、キーボードを外すと、標準のソフトウェアキーボードになってしまう。


つまりは、タブレットモードにするたびに、Android のソフトウェアキーボードを使うように再設定する必要がある。面倒くさい。


将来の Chrome OS のバージョンアップで修正されることを期待。


▼キーボード


これは、Chrome OS ではなく、完全に Duet の話だ。

Duet は 10inch タブレットで、そのサイズに合わせた物理キーボードが付属している。


Bluetooth 接続などではなく、専用の接続端子を使っている。そのため、キーボードを充電したりする必要はない。


このキーボード、10inch ディスプレイに合わせてあるのでキーが小さい。

人によっては、こんなものでタイプするのは無理だと言う。


でも、僕はそれほど苦にならない。

元々小さなマシンが好きで、小さなキーボード色々使ってきたからね。


小さなマシンの変態キーボードを色々使っていた人間としては、Duet のキーボードは悪くない。

キーの感触もしっかりしているし、打鍵しやすい部類だろう。


ただ、打鍵のしやすさと、指になじむかは別問題だ。

個人の好みなので、これ以上は何も言えない。



▼インターフェイス


キーボードのついでに、インターフェイスがらみの話を。これも Duet の話だ。


Chromebook は PC の扱いなのだけど、Duet はタブレットで、どう見ても Android タブレットに違う OS を入れただけ、と考えてよいと思う。

そのため、PC としてのインターフェイスは貧弱だ。


USB-C が1つしかない。イヤホンジャックすらついていない。

ただ、標準で USB-C からイヤホンジャックに変換するアダプタが付いてくる。


USB-C という企画は、いろいろな信号を引き出せるように設計されている。

だから、変換アダプタさえ購入すれば、十分な拡張性がある。


HDMI を使って外部モニタにつなげる事もできるし、普通の USB コネクタ(USB-A)で周辺機器をつなぐこともできる。


まぁ、つないでもドライバがないものも多いけど。

USB メモリとか、USB HDD は使えるようだけど、僕は実際試していない。


軽量タブレットに、外付けの拡張アダプタまで使っていろいろ拡張する必要があるのかは疑わしい。

でも、ちゃんと PC らしい拡張性は確保されているようだ。


▼OSの軽量さ


さて、ここで Chrome OS の形容詞のように言われる、「軽量」について書いておきたい。


そもそも論だが、Chrome 自体が「軽量なブラウザ」を目指して開発された。

しかし、軽量さで人気が出ると、ユーザーの多くは「高機能」を要望し、高機能には代償が必要だった。

結果として、現在のところ「メモリをバカ食いする困りもの」とする人が多い。


Chrome OS の開発がスタートしたころは、まだ Chrome 自体が軽量だった。

そして、OS 自体も Chrome だけを動かすことに目的を絞り、機能を削ぎ落せば軽量な環境になる、という計画だった。


しかし、現在では Chrome 自体が軽量でなくなり、Chrome OS 自体も Chrome 以外に Android アプリや Linux 環境も動かせる、互換機能を持つようになった。


Chrome OS は起動が速い、とされるが、昔使っていた Chromebook に比べ、Duet は起動が遅いように感じる。CPU 速度は上がっているにもかかわらず。

といっても、8秒程度。Android や Windows に比べると、ずっと起動が速い。


まぁ、実際に使っていると起動することはほとんどない。

普段はスリープしておく。これだと、復帰までは1秒かからない。




ここからは少し内部の話になるが、「Chrome OS」というのはある程度言葉のあやで、実際には Linux OS の上に、Chrome のユーザーインターフェイスをかぶせたものにすぎない。

もともと、Chrome さえ動けば良いので、CPU 種別を問わないという設計だった。


同じように、Android は Linux の上に Android の実行環境をかぶせたものだ。

この Android 環境というのはよくできていて、CPU を問わずに同じアプリを使える、という仕組みになっている。

その分、OS には余計な仕組みが増えており、起動は結構遅い。

しかし、Chrome OS はこの環境を取り込んでいるにも関わらず、非常に高速に起動する。


現在の Chrome OS は、Android も内部は Linux なのだからと、Android の実行環境を取り込んだ格好だ。

といっても、これは簡単なことではない。Linux が中心にあるといっても、周辺のソフト環境は全く異なるものだからだ。


そこで、Docker という仮想環境をつかうことで、異なる Liinux 環境を共存させている。

ユーザーが自由に使える Linux 環境も提供されているが、これも内部の Linux を見せているわけではなく、仮想マシンだ。


軽量と言われているが、結構複雑な仕組みだ。


これほど複雑ではない、初期の Chromebook は、面白い環境ではあったが僕としては「遊べるおもちゃ」程度の評価だった。

Chrome さえ動けばできることは多い、というのを見事に実証してみせたけど、それだけ。

実用にするにはなにかが足りなかった。


しかし、Android 環境を統合したことで、その足りなかった何かが満たされたように思う。

Chrome さえあれば、という初期の理想とは異なっているのだけど、名を捨てて実を取ったのだろう。


▼Bluetooth


Android と違って待受がないことで、僕の使い方では1つだけ不便になったことがある。


先に書いたように、僕は家事の際に Prime Video を楽しんでいる。

このとき、まず Bluetooth イヤホンの電源を入れる。


Android タブレットであれば、すぐに本体に接続して、画面が点灯した。

しかし、Chrome OS では接続できない。スリープ中で CPU が動いていないからだ。


そこで、本体の電源に手をのばす一手間が増える。

たいしたことではないのだけど、これも Chrome OS が PC だから起きる現象だ。


さて、料理をしながらビデオを見ていると、電子レンジを使うときに困ったことになる。

電子レンジの電波周波数は、Bluetooth と同じ帯域であり、通信障害を起こすのだ。


通信障害を起こすと、音声が途切れる。まぁ仕方がない。


Android では、途切れた音声は再送され、少し途切れて続きが聞こえる。

でも、この間も動画は止まらない。結果的に動画と音声がずれる。

あまりずれすぎると、音声を送るのを諦めて間が飛ばされる。


しかし、Chrome OS では、音声が途切れて再送されるときに、動画も一瞬停止する。

このため音ズレは起きないが、動画再生がカクカクになる。


どちらが良いという話ではなく、Android アプリの実行環境はあるが、完全エミュレートなどではなく Chrome OS の機能を使ったものだ、という話なのだ。

動画再生などの機能は OS が提供しているが、その部分の違いで動作に差が出る。


これは、Android アプリの実行環境が、無理やり後付したような不格好なものではなく、ちゃんと OS の深い部分に組み込まれているという証拠でもある。


最初の方で書いたが、ディスプレイ解像度を変えてもちゃんと動作することとか、Windows のリサイズでもちゃんと動作することとかと併せ、非常に良くできている。


▼Android 端末との連携


Chrome OS には、Android 端末を Bluetooth 接続に登録することで、色々と便利にできる機能がある。


まずはログイン時。ロック解除されたスマホが近くにあれば、正当な持ち主によるログインだとみとめられ、パスワード入力などを省略できる。


ただし、電源を入れて最初のログインは、正しいパスワードを必要とするようだ。

また、スリープからの復帰時にパスワードを必要とするかどうかは設定で変更できる。


なので、僕はこのログイン機能を使っていない。

あまり外出しないからそれで良いのだけど、Chromebook を持ち歩く人は、紛失に備えてスリープ復帰時にもパスワードを求めたほうが良いだろうね。


次に、ネットワークのテザリング。

ChromeOSが WiFiネットワークに接続できないとき、スマホのネットワークを利用してよいか訊ねてくる。使うことを許可すると、スマホ経由で WiFi なりモバイル通信なりを使ってネットワーク接続する。


実のところ、Android には Bluetooth テザリングという機能があり、Bluetooth 接続を経由して他の端末のネットワークを利用できる。

でも、その機能を使うのは結構面倒だ。利用するたびに、両方の端末で操作が必要になる。周囲のマシンに勝手に通信を行われるって、色々と問題あるからね。


Chrome OS では、このテザリング機能を使っているわけではなく、連携の一環としてのテザリングを行う。

だから、Android 側のテザリング機能が OFF になっていても使える。

最初に登録しておけば、以降は Android 側で操作する必要はない。


これは素晴らしい機能だ。



もうひとつ、SMS を Chrome OS に受け取ったり、送信したりする機能がある。

ただ、僕は普段 SMS を使わないので、この機能はまだ使っておらず、詳細がわからない。


スマホのメッセージ機能はスマホメーカーが独自に作ったものが入れられていることが多いが、Chrome OS と連携できるのは Google 製 SMS を使っているときだけ、という問題もある。

僕は SMS を使わないので、わざわざ Google 製を入れてまで動作確認してみようという気が起きない。



▼その他


Chrome OS は、ローカルにファイルを置かない前提で設計されていた。

ファイル置き場としては Google Drive を使う。


しかし、フルセットの Chrome なので、ファイルをダウンロードすることができる。

これは当然のことながらローカルに置かれる。


このファイルを見るためのアプリは、初期の Chrome OS から用意されていた。


このアプリは結構できが良くて、ローカルファイルと Google Drive のファイルを見ることができた。

さらに、機能拡張を入れることで、Dropbox や マイクロソフトの OneDrive 、家庭内の NAS や Windows マシンでの共有ファイルも見られた。


Duet のファイルアプリを見たら、家庭内の NAS や Windows に関しては、機能拡張無しで見られるようになっていた。

地味な改良だがありがたい。


僕は家庭内で持ち運んで気軽に使えるマシンを求めているので、家庭内のファイルに自由にアクセスできるというのは大切なことなんだ。


▼まとめ


IdeaPad Duet は現在大人気機種で、使用記を書いている人も多い。

僕も、そうした使用記を見て、よく検討してから購入したのだが、やはり自分で使ってみないと実感できない事は多かった。


おそらくは、使う人を非常に選ぶマシンだ。


最初に書いたとおり、PC とスマホの隙間を埋めることができる。

だから、すでに PC とスマホを持っていることは前提だ。できれば、Windows と Android がいいだろう。

Chrome OS の操作系は Windows を参考にしたものだし、動作するアプリは Android だからだ。ついでに言えば、Android と連携して通信を行う機能もある。


MS Word は動くか、というのは愚問だ。

上に書いたように、それは Windows の仕事だから。でも、下書き原稿を作ることはできるし、すでにできた原稿を、ある程度互換性のある Google Docs で見ることはできる。


Web 版 Office や Android 版 Office が使える、と書いてあるページも多いのだが、あまりおすすめしない。それらは結局 Word 互換の、Word ではないソフトだ。


ならば Word は使えない、と割り切ったほうが良いし、Word が使えないとだめなら Windows サブノートを探すべきだろう。


しかし、できないこともあると十分理解して使うのであれば、非常に軽くて小回りが利き、それでいてちゃんとパソコンとしての性能を発揮できる機械、というのはいい相棒になるだろうと思う。



(この記事は、Duet で Google Docs を使って大まかに下書きした後、Windows で仕上げた。

 そういう使い分けがやりやすい、というのもポイントの一つだ)



▲目次へ ⇒この記事のURL

関連ページ

Lenovo Ideapad Duet 購入【日記 21/02/23】

IdeaPad Duet の使い勝手(2/2)【日記 21/03/01】

IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】

別年同日の日記

09年 おゆうぎかい

14年 冒険遊び場

15年 イチダントアール

16年 シーモア・パパート 誕生日(1928)

17年 エドウィン・ハーバード・ランド 命日(1991)

20年 長男、高校合格


申し訳ありませんが、現在意見投稿をできない状態にしています

IdeaPad Duet の使い勝手(1/2)  2021-03-01 11:00:55  コンピュータ

▲目次へ ⇒この記事のURL

Lenovo Ideapad Duet を購入して1週間ほどたつ。

まだ1週間しか使っていない、というべきかもしれないが、ここらへんで一度評価をまとめておこう。



冒頭でいきなり評価を書いてしまえば、非常に素晴らしい端末だ。


購入前は、普通と少し違うこの端末を買うことに不安があった。

しかし、予想を遥かに超えた素晴らしさだった。不安は杞憂だった。


どう素晴らしいかといえば、これが見事に既存の機械の「隙間」を埋めるものだったのだ。


でも、隙間を埋める充填剤だ。広い面積をカバーできるパネルではない。

Duet は現在大人気で品薄なのだけど、この隙間を持たない人にとっては魅力のあるものではないと思う。

つまり、Duet が素晴らしいというのは、僕にとっての話であって、万人に勧められる製品ではない。


以下、このことについて説明していこうと思う。




これが隙間を見事に埋める充填剤だ、というのだから、最初に僕が持っている「隙間」について書いたほうが良いだろう。


僕は、普段は Windows を使って仕事をしている。

ノートパソコンを買ったのだけど、外付けディスプレイとキーボードをつないでしまったため、事実上は動かせないデスクトップマシンになっている。


仕事柄 Linux サーバーも持っていて、Windows からログインしたり、ファイル共有サーバーにしたりして使っている。

ファイル共有としては、NAS も併用している。


スマホとしては普段 Android を使用している。

そして、Duet を購入する直前まで、Android の 10inch タブレットを併用していた。


初期の頃の Chromebook (Chrome OS を採用した PC ) を使っていたこともある。

初期の頃と今では、随分と Chrome OS の方向性は変わった。でも、基本は理解している前提だ。


あと、仕事用に Macintosh と iPhone も持っているが、あまり使っていない。あくまでも仕事で必要だから持っているだけ。

なので、これは今回の話にはあまり関係ない。




さて、僕は主夫なので家事をする。食事を作ったり、皿を洗ったり。

これが結構生活の中では時間が長くて、しかも孤独だったりする。

その時間にも娯楽を欲した。


最初は、スマホで Amazon Prime Video を見ていた。

見ていたというか、家事をしながら Bluetooth イヤホンで「音声を楽しんでいた」感じかな。

スマホなので、画面が小さくて家事をしながらだとあまり映像を見られない。


他にも、家族団らんのときにもちょっとパソコンを使いたい時があった。

じゃぁ、ノートパソコンを買えばビデオも大画面で見られるし、団らんのときにも使えるかな、と思った。


でも、これは失敗だった。ちょっと気軽に使いたいという要求と、仕事で使うのでしっかりしたものが欲しいという要求は相容れなかったのだ。

仕事で使うにはディスプレイが狭いが、持ち運ぶには大きくて不便なノートパソコンは、先に書いたとおり拡張されて半ばデスクトップになっている。


替わりに、10inch Android タブレットを購入した。

最初は Amazon Kindle HD (旧型)だったが、その後 Huawei MediaPad T5 に乗り換えた。


10inch タブレットは素晴らしかった。だからその路線で買い替えまでしたのだ。

Prime Video を見るには問題ないし、時々居間で家族が集っている傍らで文章を書いていた。


外出時に持ち歩いたこともある。

T5 にはスマホのようなモバイル通信機能はついていない。

しかし、Android スマホと Buetooth 接続することで、スマホのモバイル通信網を借りることができた。

設定が少し面倒くさいのだけどね。それでも通信できるので十分だった。


そんなわけで、Android 10inch タブレットで特に問題はなかったんだ。

IdeaPad Duet を買ってみようというのは、ほとんど気まぐれだった。




さて、やっと僕の利用実態を説明できたので、Duet の素晴らしさを伝えられる。


Duet は MediaPad T5 と同じ、10inch サイズのタブレットだ。

タブレットだけどタッチパッド付きのキーボードが付属していて、着脱できる。


そして、Android 端末ではなく、Chrome OS 採用の機械(Chromebook と呼ぶ)だ。

もっとも、詳しくは後で説明するが、Chrome OS は Android のソフトを動かすことができる。

だから、ほとんど同じ使い勝手になると思っていた。


でも、Android は「スマホの OS」で、Chrome OS は「パソコンの OS」だ。

同じソフトが動いたとしても、OS がスマホ用かパソコン用か、というのが、思った以上に使い勝手に違いを与えていた。




わかりやすい違いから書こう。


Android は、スマホ用の OS なので、外部からの通信を待ち受ける必要がある。

そのため、CPU を停止させる「スリープ」状態はない。

画面表示を消し、動作周波数を落として省電力にしていたとしても、常に電力を消費し続ける。


もちろん、スマホはそれでいいだろう。

でも、モバイル通信機能を持たず、待ち受ける必要がないタブレット端末でも、着信を待って電力を消費し続けるのだ。


Androidタブレットを使っていたときには、そういうものだと思って気にしていなかった。

しかし、使っていないときに電力を消費続けるというのは、無駄以外の何物でもない。


Chrome OS は、PC 用の OS なので、通信を待ち受けるという概念がない。

画面を消すときには CPU も停止して、電力消費を抑える。


このため、電池のもちが良い。


というか、これがあるべき状態だった。

スマホ用の OS を、スマホではないものに使っているというのが、無駄な状態だったのだ。




もう一つわかりやすい違いを。


スマホ用の OS は、低い解像度の、小さい画面を前提として作られ始めた。

最初期の頃は、画面横幅は 320ドットだった。


しかし、今は 1080 ドットはある。1080 というのは、ハイビジョンの動画を視聴するのに必要なドット数だ。

画面の物理的な大きさはほぼ変わらないまま、およそ3倍のドット数を表示できるようになった。


じゃぁ、表示できる情報が増えたのかというと、なっていない。

Android や iOS が、表示できる文字数が大きく変わらないように制御しているためだ。


タブレットになると画面が大きくなるため、表示できる文字数は増える。

でも、文字を大きめに表示する、という基本は変わっていない。


これに対し、パソコンはより多くの情報を表示できるように発展してきた。

画面が広くなると表示できる文字の量が増える。解像度が上がると表示できる文字の量が増える。

ノートパソコンで画面が小さい、などの理由であえて文字を大きくすることはあるのだけど、その場合も拡大率の決定はユーザーに委ねられている。


パソコンとスマホでは、情報表示に対する考えが根底から違うのだ。

そして、Chrome OS はパソコン用のOSだ。拡大率は自分で変えられる。


この拡大率は、Chrome OS 上で動く Android アプリでもそのまま適用される。

だから、Android アプリをフルハイビジョンで表示できたりする。


まぁ、スマホの小さな画面で使うように設計されたソフトをフルハイビジョンで使う意味はない。

でも、一度見てみると非常にインパクトがある。Chrome OS なら、Android タブレットでは見られない世界を見られるのだ。

もっとも、Duet を使っている限りでは、字が小さすぎて実用にならないので、フルハイビジョンで使うのはお勧めしない。


オススメしないのは「Duetの場合」であって、「Android アプリに広い画面が不要」だと言っているのではない。

Chrome OS では、Android アプリもウィンドウ内で動くようにできる。

ウィンドウをいくつも並べることもできるし、ウィンドウをリサイズすればそれに合わせた表示になる。

(Android アプリは、様々な画面サイズの端末に対応しているし、使用中の画面リサイズである「画面の回転」などにも対応している。)


だから、広い画面で情報がたくさん表示できることには意味がある。

Duet は画面が小さいのでこの機能を活かしきれないかもしれないが、Chrome OS 上で Android アプリが動く、ということは、今までになかった新しい世界を開くのだ。




わかりやすい例を2つ挙げたが、他にも細かな違いは色々ある。

多くは、スマホと PC という、違う目的で発展してきた OS の違いに起因するものだ。


もちろん、Android にしかできない、ということも多い。

実際、Chrome OS のほうが機能的には貧弱だとも言える。


だからこそ、最初に「隙間を埋める充填剤」だと書いたのだ。

Windows でしかできないことがあり、Android でしかできないことがある。

そして、その隙間の、どちらにもできないことを、Chrome OS が埋める。


同じ 10inch タブレットであっても、Android タブレットでは隙間を埋められない。

Android タブレットでは、Android にできないことはできないのだ。




Duet が素晴らしい、ということをざっくりと書いたが、細かな話はまだある。

ただ、細かな話になりすぎて、本当に興味がある人でないと面白くないと思う。


なので、ここでいったん記事を区切ろう。

次の記事では、実際の使用感を細かく伝えていこうと思う




▲目次へ ⇒この記事のURL

関連ページ

Lenovo Ideapad Duet 購入【日記 21/02/23】

IdeaPad Duet の使い勝手(2/2)【日記 21/03/01】

IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】

別年同日の日記

09年 おゆうぎかい

14年 冒険遊び場

15年 イチダントアール

16年 シーモア・パパート 誕生日(1928)

17年 エドウィン・ハーバード・ランド 命日(1991)

20年 長男、高校合格


申し訳ありませんが、現在意見投稿をできない状態にしています

Lenovo Ideapad Duet 購入  2021-02-23 17:40:22  コンピュータ

▲目次へ ⇒この記事のURL

昨年8月に、Ideapad C340 を購入している。

今度は Ideapad Duet を購入。


C340 は 14inch の普通の Windows ノートパソコンだ。

で、Duet は 10inch タブレットの Chromebook 。


いままで Android 10inch タブレットを使っていて、その買い替え。

といっても、今までのマシンも性能上の不満はない。

妻が性能が良いタブレットがほしいといったので、僕が買い替えて今まで僕が使っていたものを渡すことにしたのだ。




今まで使っていたのは Huawei Mediapad T5。

その前には旧 Amazon kindle Fire HD 10 を使っていた。Kindle は安いからね。


でも、旧Kindle は性能も低くて、本来の使用用途である Prime Video の閲覧ですら、重いことがあった。

そこで Mediapad を購入した。

(注:今の Kindle は性能が上がっているので、重くないと思う)


で、動作が軽くなったら便利なので、時々キーボードをつなげてドキュメント作成などもする。

あと、Web ブラウジング。


便利に使っていたら、先に書いたように妻がうらやましがるので、もう一台買うことにした。

そこで、今度は Chromebook を選んでみたわけだ。


Chromebook を使っていたことはあるのだけど、その頃は本当に Chrome が使えるだけだった。

今は、一部制限はあるが、Android のアプリや Linux が動く。


一方、普段は当然のように Windows を使っているし、仕事で Web アプリ開発をしているのだけど、Android の Chrome だと、PC のものとは若干動作が違っていて、やりたいことができないこともあった。


僕は仕事柄 Linux 端末はよく使うし、先に書いたように Android アプリは Amazon 関係が動けば、まぁいい。

Chromebook は、Android 版ではなく、PC 版の Chrome と同じものが動作している。

そんなわけで、Chromebook でもいいんじゃないかな、という興味で購入してみたわけだ。




Duet にはタブレットと言いつつ、キーボードが付属する。取り外し可能だし、10inch に合わせた狭いキー配置なので、使い勝手はそれなり。

じつは、この日記もそのキーボードで書いてみている。

HP200LXとか、Linux Zaurus、Netwalker を使っていたことを考えると、ずっとまともなキーボードだ。

(比較対象がひどすぎる気はするが)


まだ届いてから数時間しか立っておらず、使い勝手は十分確認できていない。

でも、とりあえず普段づかいにできそうなことは確認済み。


またしばらく使ってみてからレポート書くかもしれないけど、何も書かなかった場合は「書くことがないほど普通に使えている」ということだと思ってほしい。


2021.3.1 追記


1週間ほど使ったところで使用記書きました

素晴らしい機械でした。




▲目次へ ⇒この記事のURL

関連ページ

IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】

別年同日の日記

05年 Quoカード

10年 SH-03B

15年 ゲームセンターの努力

15年 理科ハウス

17年 早口言葉


申し訳ありませんが、現在意見投稿をできない状態にしています

微分積分いい気分  2021-01-29 17:56:48  コンピュータ 数学

▲目次へ ⇒この記事のURL

このタイトル、すでに分からない人の方が多そうだな




急に思い出話。

まだ僕が大学1年生だったころのこと。


PCルームがあって、放課後は入り浸っていた。

その場にいる人の多くは、僕も所属していたコンピューターサークルのメンバー。


でも、そうではない常連の人もいて、学科もサークルも違うのに知人、という人もいた。


そのうちの一人…同じく1年生で、簡単なプログラムは組めるが本格的なゲームなどは作れない、というくらいの知人が、ゲームによくある、ジャンプの動きを作ろうと頑張っていた。




その知人は「ジャンプは放物線なのだから」と、何かの二乗を使って書こうとしてたんだ。

(二乗のグラフとして描かれる線を、放物線と呼ぶ)


でも、そうじゃない。ゲームならジャンプは次のように書く。

(当時は BASIC を使っていたので、BASIC 風に)

10 X=X+1
20 IF INKEY$=" " THEN JUMP=1:Y1=-5
30 IF JUMP=1 THEN Y=Y+Y1:Y1=Y1+1
40 IF Y1>5 THEN JUMP=0
50 PUT SPRITE 0,(X,Y),8,0
60 GOTO 10


このプログラムはサンプルなので、初期設定を省いているので、雰囲気で読んで欲しい。

ともかく、こんな感じのプログラムを作って、こうやるんだよ、と見せてあげた。


そうしたら、返ってきた反応は、「なんかずるい」だったんだ。

動きを見ると放物線っぽく見えるけど、プログラム中には二乗どころか、掛け算もない。

それは放物線ではない、というのだ。


いや、別にずるくないよ、と言い返したが、その時の自分には「ずる」ではないという明確な根拠を示せなかった。




今なら明確に示せる。


これは、放物線の式に対し、一階微分した導関数を導き出し、その導関数を再び積分することで放物線を再構築しているんだ。


なぜ微分するかというと、ゲームは時間によって微分された世界で動いているから。

テレビ画面は、連続した「時間」を、1/60 秒ごとに区切って表示する。

このわずかな時間の動きは、時間で微分されている、ということになる。


そして、その微分したものを積み重ねていく。

テレビで言えば、一連の「コマ」を連続させて動かすことが、積分にあたる。


…厳密にいえば、微分ではなく差分だし、積分ではなく積算なのだけど。

これを言い出すと離散数学というややこしい数学の話になるので、今は微分積分という呼び名で話を進める。



僕のプログラムを見た知人は、「プログラム中に二乗がないので、放物線ではない」と言った。


しかし、プログラム上は微分したことで二乗が消えている。

そして、プログラムを動かすと時間変化によって積分され、正しい放物線が描かれる。


これを「ずる」だというのは、微分積分を理解していない残念な人間だというのを、自ら明かしたに過ぎない。

(もっとも、すぐに言い返せなかった自分も、その時には十分理解できていなかったわけだけど)




本当に足し算だけで二乗になるのか、まだ疑う人がいるかもしれないので、わかりやすい例を挙げよう。


まずは、単純なルールで作りだせる、次の数値の表を示そう。


 0 1 4 9162536496481
135791113151719

この表のルールはこうだ。

・上に書かれた数値は、その左側の列の上下の数値を足したもの。

・下に書かれた数値は、その左側の列の下の数値に、2を足したもの。


足し算しか使っていない、非常に単純なルールだ。

おかしいところがないか検算してもらってもよい。


ここで、上の数値は、もう一つの意味を持つ。

0,1,2…と続く数値の「二乗」になっているのだ。


日本人なら 9*9=81 まではわかるだろうから、上の表は 81 で止めてある。

でも、もっと長く続けても大丈夫。これも試してもらってよい。




「ずる」と言われたのが悔しくて、根拠を考えていたら、数日後にはこの答えに行きついた。

でも、サークルも違うし学科も違ったので会う機会はそれほどなく、言い返すタイミングは永久に失われた。


それを思い出して急にここに書いたのは、ネットで「微分積分なんて実生活でどう役に立つのか」なんていう…まぁ、よくありがちな学生の愚痴を見たから。


微分積分、生活で超役立つ。

上に書いたように、テレビゲームは微分積分の世界の中にある。

そもそもテレビが微分積分の世界だし、デジタルテレビなんかフーリエ変換(微分積分の親玉みたいなやつ)を駆使して作られている。


ただし、役立てられるかどうかは、自分次第。

ゲームやテレビの中に微分積分が駆使されている、なんていうのは知らない人は全く気付かない世界だ。

それでも生活はできるのだから、知らずに生活している限りは、高校で習った微分積分は「役立てられていない」。


役に立たないのではなく、役立てられないのだ。

なんでかといえば、勉強が浅かったから。「どうせ役立たない」なんて思ってるから。




世界最初のコンピューター、と呼ばれる ENIAC は、実のところ「ひたすら足し算する機械」にすぎない。

それでも、数学的に正しい…どころか、空気抵抗なども考慮した「弾道計算」ができた。


先に書いたように、足し算だけで数学的に正しい放物線は求まる。

しかし、それは空気抵抗や風などがない理想状態での弾道にすぎない。


ENIAC では時間で「微分」した方程式を使い、繰り返し計算して「積分」することで、弾の速度の関数となる空気抵抗や、風の影響なども考慮に入れ、物理現象としての「弾道」を描き出すことができた。


空気抵抗が弾の速度の関数になる、なんていうのは、瞬間ごとの速度を見ながら抵抗を導き、それによって速度を調整する、というのを繰り返しながら積分する方法でないと計算できない。


そうした計算が複雑すぎて人の手に負えないから、ENIAC を建造したわけだけど。



ともかく、ここで重要なのは、どんなに複雑な数式であっても、微分を繰り返せばただの足し算になるということだ。

そして、足し算をひたすら繰り返せば、元の複雑な数式の答えを導き出せる。

(ここでいう答えとは数値演算であり、式の変形ではない)


ENIAC は弾道計算よりももっと複雑な、水爆の内部圧力の計算なども行っている。

使われた計算は全部足し算のみだ。それが微分積分の威力だ。




今回、この話を書こうと思ってネットを調べていたら、以下のようなことを書いている人がいた。

(一連のツイートだが、特定人物を批判したいわけではないため、検索されないよう文面は変えている。)


・ファミコンで三角関数を使うと遅くなるので、スーパーマリオのジャンプは掛け算だけで作られている。

・掛け算だけなので本当は放物線ではないのだが、ゲームを作るうえでのうまいごまかし方だと言える


…まぁ、プログラマーでない人がうろ覚えの知識を披露しただけだと思う。

しかし、どこから突っ込んでよいかわからないほど違っている。



まず、ジャンプを表現する放物線に、三角関数は必要ない。掛け算だけでよい。

そして、ファミコンは掛け算すら遅いので、足し算だけで作られている。


さらにいえば、先に書いたように足し算だけで書いてもごまかしではなく、数学的に正しい放物線が描ける。


ただ、スーパーマリオのジャンプは、放物線ですらない。

放物線にすると、操作が難しくてゲームにならないから。


それでも放物線っぽく感じられるようにしている。

これが「うまいごまかし方」だというのは同意だが、計算できなかったからではなく、ゲームを面白くするためだ。

背景が全く違う。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

数学

関連ページ

暮らしの中の微分積分【日記 21/03/16】

別年同日の日記

05年 外構チラシ

09年 ジョウビタキ

10年 加湿器

15年 「デフォルト」という言葉の意味

15年 プログラム言語における「デフォルト動作」

16年 【追悼】マービン・ミンスキー

16年 AI囲碁

18年 テクニカルサポート


申し訳ありませんが、現在意見投稿をできない状態にしています

ノートパソコン修理  2021-01-26 13:33:16  コンピュータ

▲目次へ ⇒この記事のURL

昨年8月に購入したノートパソコンが壊れた。


壊れたといっても、起動はできるし普通に使える。

ペンコンピューティング可能なマシンだが、ペンも使える。


でも、指で直接ディスプレイにタッチした際の操作が効かなくなった。

それ以外の症状はない。


最初は、ペンは使えるがタッチは使えない、というので、タッチパネル自体は壊れてないんだよね?

と思ってドライバ不具合などを疑った。

調べると、Windows アップデートなどでドライバが不具合を起こすことがある、という情報があったし、うまく動かなくなった直前に Windows のアップデートを行っていた。


じゃぁこれかな、と思って、メーカーのページに書かれていたトラブルシューティングの方法に従ってドライバを入れなおす。でも治らず。


さらにネットの情報を探す。

我が家の機種とは違うが、同じシリーズの以前の機種で、同様の問題を発見。

タッチディスプレイのケーブルが内部基板から外れやすくて、ペンは使えるのにタッチのみ使えなくなりやすい、という。


後継機で前の機種のトラブルが対応されていないことは無いと思うのだけど、症状的に似通っている。

ケーブルが外れているだけなら自分で治せるかもしれないけど、保証期間内だったので素直に修理に出すことにした。




まず、メーカーのページで修理申込する。

不具合のある機種を使って申し込みをすると、自動的に機種を判別し、保証期間内であることが示される。

そして、自己診断プログラムのダウンロードを促される。


このプログラムを入れると、自動的に自己診断が始まり、その情報とともに修理申込ができる。

その際、マシンのシリアルナンバーなども自動判別される。


我が家の機械の場合、故障個所はない、という診断だったが、申し込みはできた。

自己診断の限界もあるのだろう。


住所氏名や電話番号などの連絡情報を入れたのち、不具合について記入。

タッチパネルが反応しないがペンは動くこと、公式の方法でドライバの入れ直しも試みたことなど書く。


で、翌日にはメールで返事が来た。ハードウェア故障の可能性が高いので引き取り修理をするという。

引き取り日の希望などを返信するが、最短で翌日。で、翌日には佐川急便が引き取りに来たので本体を渡す。

梱包などは佐川の方でやってくれる。



当日のうちに到着連絡が来たが、この日が金曜日だったため、週末の間は修理は進まなかった。

そして、昨日月曜日に修理完了の連絡があり、今日には手元に戻ってきた。


一応、メーカーのページには「到着から1週間から10日で修理完了します」とあったし、さらに「コロナ禍で修理依頼が増えており、少し時間がかかるかもしれません」とお詫びがあった。

しかし、メーカー到着の次の営業日には修理を行い、翌日こちらに届くというスピード修理。


まぁ、本当にハードウェア的な故障で、部品交換で済んだからすぐ終わったのだろうけど。

ソフトウェアのコンフリクトなどを「不具合」として修理に出す人もいるみたいだし、そういう問題はすぐには解決できない。




▲目次へ ⇒この記事のURL

別年同日の日記

14年 iOS の position:fixed バグ回避方法

17年 後藤英一 誕生日(1931)


申し訳ありませんが、現在意見投稿をできない状態にしています

100倍規模  2021-01-23 12:02:32  コンピュータ

▲目次へ ⇒この記事のURL

お仕事の話。ほぼ愚痴。


100名程度の使用を想定して作ったシステムがあり、開発をお手伝いしている。

ありがたいことに人気が出て、人気が出ると想定外の使われ方をし始める。


特に、多人数で使いたいという要望が多く、1000人規模でも使えるように1年ほど前に大規模改修を行っている。

僕はこの改修の途中から参加させていただいた形だが、システムのスループットは上がり、1000名でも使えるようにはなった。


この際に、さらに人数を増やすこともできるような設計にはしていたが、それは「設計」だけで、実際には対応できていなかった。



それが、今回1万人で使いたいという依頼が来て…

いや、依頼はしばらく前から来ていたのだ。というか、依頼は1万人とも限定していなかった。

最大5万人くらいということだったが、それはさすがに難しそうなので、1万人に制限してもらったのだ。




システムはいくつかのパーツに分かれているが、サーバー部分は改修の際に、node.js で作り替えられていた。

node.js はサーバー側で動作する javascript 環境だ。


細かな話を書くと長くなるが、もともと javascript はブラウザ向けの技術だった。

そのため、非常に癖の強い特徴を持つ。


一番重要なのが「ノンブロッキング」であるということだ。

ブラウザはユーザーが操作するものなので、その操作を阻害…「ブロック」してはならない。

これがノンブロッキングという思想。


言語が動いているときは、ユーザーの操作を受け付けられない。

そう仮定すると、ユーザーの操作を阻害しないため、言語は無駄な実行時間をかけてはならない。


とはいえ、普通のプログラム言語にはたいてい「何かを待つ」処理が入るものだ。

ファイルを読んだり、ネットで通信をすると、CPU よりもはるかに遅いディスク装置やネットワークのデータを待つ。

プログラムをしていると、ごく当たり前のことだ。


javascript では、これらのことは「行えない」。

待たせてはならない、という設計思想だからだ。


とはいえ、ディスクを読んだり通信をしたり、というのは当たり前のことで、もちろんできる。

どうやるかというと、待つのではなく、いったん終了してしまうのだ。


「通信してね」って頼んだら、終了する。

そして、通信が終わると、「通信終わったよ」ともう一度処理を起動してもらう。


javascript では、一事が万事この調子。プログラムを組んでいると、非常に組みづらい。

まぁ、最近では昔より環境が整えられ、かなりマシになったのだけど。



そして、あえてこの使いにくい環境をサーバーで使うと、「待ち時間のない」プログラム環境を実現できる。

待ち時間がないということは、常にプログラムが動いているし、リクエストに応えられるということだ。


従来…というとちょっと古いのだが、Wordpress などに使われる PHP では、1秒間にせいぜい 10リクエスト

くらいしか答えられない。


でも、同じことを node.js で実装すると、1000リクエストくらいは答えられるのだ。


#PHP はインタプリタだが、node.js は即時コンパイルだ、とか、PHP はプロセスフォークで動く Apache 上で動作するが、node.js はシングルプロセスなのでタスクスイッチのオーバーヘッドがないとか、他の要因も多分にあるのだけど。




それでも期待できるのは 1000人レベルだ。

大規模改修で node.js を使って 1000人規模に対応した、というのがこの段階。


今回1万人規模のリクエストなので、node.js をクラスタ化して対応することにした。


node.js は、シングルプロセスで動作する。

たった一つのプログラムで、1000以上の接続に対応するのだ。


しかし、これは CPU がマルチコアだったとしても、1コアしか使わないという意味でもある。

CPU のコアの数だけプロセスを増やせば、理論上はもっと多くの接続を処理できる。


もちろん、そのための制約はいろいろとあるのだが、最初から「マルチプロセスで動かすことができるように」という設計をしていた。


そして、pm2 という node.js 対応のプロセス管理ツールを使うと、プログラムは無改造のまま、マルチプロセス化できる。


(通常、プロセスが増えると、それぞれが別の通信ポートなどを用意しないといけなくなる。

 通信ポートが増えれば、アクセスするクライアント側もそれに対応しなくてはならなくなる。

 しかし、pm2 は代表して1つの通信ポートを作り、配下のプロセスのポートに適切にデータを流してくれるので、外部から見るとそれまでのプログラムと何ら変わらないように見える)


というわけで、処理性能は何倍かに跳ね上がった。



…でももちろん、話はそんなに単純ではなかった。




接続が増えたら、当たり前だがそれらの接続ごとに、データを収めた DB へのアクセスが発生する。

1プロセスで 1000 人程度をさばいているときには問題にならなかったが、1万人規模になると接続ができなくなった。


DB の接続数の上限設定があるのだ。これは、 DB の設定を書き換えて解消する。

これに伴い、適切なワークメモリの割り当てなども変える必要があるが、とにかく設定した。


DB が接続を受け付けられるようになっても、その接続のための通信ポートが十分作れない。

OS 側に、通信ポートをいくつ作れるか、という設定があるのだ。

それらも設定する必要がある。


UNIX では、すべてのリソースがファイルとして扱われる。

通信ポートも1種のファイルだ。そして、UNIX には、プロセスごとに開けるファイル数の制限がある。

この制限も増やす必要がある。


100 人程度なら問題なし、1000人でも大丈夫だったとしても、1万人規模になるとそれまで気にしていなかった設定が問題になるので、問題発生のたびに何が悪いのか調べ、設定をチューニングする必要が出る。


それまでは問題にならなかった DB の Query が、突如として slow query になる、というのもあった。

DB へのアクセスが激しすぎると、特に問題がなかった部分がボトルネックになりだすのだ。


…これらは、上に書いたような順序で、理路整然と起こったわけではない。

とにかく不具合が続出し、原因を切り分け、考えられる要素をひとつづつ潰していく必要があった。


上に書いたのは、「結果としてそういうことだった」というだけで、原因がわからないので見当違いの設定に手を出して、何も変わらないので元に戻す、というようなこともやっている。




問題はサーバー側だけではなかった。


1万人規模、と書いたが、その規模の人たちがサーバーに接続し、操作した結果を集計して表示する画面がある。

普通の WEB ページとして作られているので、PC さえあればインストール作業などなしで表示できる。


この画面自体は、サーバーと接続しているだけだ。接続が増えるようなことは無い。

だから特に問題は出ないだろうと思っていたら、1万人分…1人についてのデータが複数あるため、数万件のデータになると通信に支障が出た。


特に、何らかの不具合が起こって画面のリロード…と考えたとき、数万件のデータ再送信はそれだけで1分程度の時間がかかる。


通信したデータを、ローカルにキャッシュして持つように改良した。

再起動が行われた際は、まずキャッシュからデータを読み込み、続きのデータの送信をサーバーに依頼する。

5秒程度で表示が行えるようになった。



この表示も1万件あると遅くなった。

全部を表示したいのだが、ただ1万行の HTML というだけで、重くてスクロールもままならないのだ。


これはプログラムテクニックで乗り切った

どこかに詳細なテクニック紹介をしたいのだけど、忙しくて概要説明だけ行ったままだ。



100人を想定して作ったものを、1万人向けに提供する…となると、思わぬことがいろいろと発生する。



▲目次へ ⇒この記事のURL

別年同日の日記

12年 ゲームボーイの CPU

15年 アプリケーションサーバとしてのQNAP

15年 宮永好道 命日(1993)

16年 iOSでtextのコピー・ペーストができないバグの回避

18年 サターンポリゴンのゆがみ


申し訳ありませんが、現在意見投稿をできない状態にしています

ピクミン3デラックス  2020-12-13 18:03:45  コンピュータ

▲目次へ ⇒この記事のURL

一応遊んだので感想を書いておこうと思ったのだが…

世の中的には絶賛されているゲームなのですが、僕としては残念な出来、と最初に書いておきます。

そういう感想記事です。




基本的に人に勧められるようなゲームでないと感想は書かないので、「感想を書く程度には面白かった」と捉えてください。

悪いゲームではないです。


ピクミン1、2に関しては、かなりやり込みました。

当時は子供もいなかったのでね。


Wii U で発売された3は遊んでいません。Wii U 持ってなかったし、その頃は子育てが忙しすぎて、ゲームどころではなかった。

Switch 購入以前も、子供は多少テレビゲームを遊んでいましたが、それほどやっていません。


だから、Switch 購入時には、すでに旧型であった Wii U を買ってピクミン3を遊びたい、と子供に言われました。

僕は今更 WiiU を買うつもりはなかったので、「多分 Switch には移植されるので、出たら買う」と子供に約束しました。


これはなだめるための適当な約束のつもりではなく、ゲームキューブのピクミンはその後 Wii に移植されているためです。

Nintendo 64 のゼルダもゲームキューブに移植されていたり…

「あまり売れないゲーム機で発売されたが、名作と呼ばれるものは、任天堂は次のゲーム機に移植する」と考えていました。


発売までにずいぶん時間がかかりましたが、実際移植されたので購入しました。




遊んでみて、最初から多くの違和感に襲われました。

これは、ピクミンの名を冠してはいるが、別物のゲームだ、というのが正直な感想です。


なぜこんなことになったのか、いろいろと原因を考えながら遊んでいたのですが、やっと一つの推論に辿り着きました。


おそらく、ピクミン3は外製のゲームエンジンを使用して作られているのではないか、と。


ゲームエンジンとは、ゲームを作るのに必要なプログラムをまとめたライブラリです。

どんなゲームにも共通で使われるような処理、というものは存在しており、それらをまとめて販売しているものです。


こうしたエンジンを使用することで、ゲームを作る工程は大幅に削減され、開発期間が短縮でき、コストも抑えられます。


また、通常はゲームエンジンは、様々な環境に移植されています。

グラフィックスやコントローラー周りの「機種ごとの差」が大きい部分は全部ゲームエンジンが対応し、ゲーム本体のプログラムは純粋にゲームだけを作成すればよいのです。


結果として、大きな移植の手間もなしに、複数の環境への対応が完了します。

ゲームエンジンを使用するメリットは大きいのです。



ピクミン1のころは、こうした「ゲームエンジン」という概念は普及前でした。

もちろん、各社が独自にライブラリを作ったり、概念的に近いものはあったのですが、専門にゲームエンジンを作成するような企業があったわけではないのです。


ピクミン2も、おそらくはピクミン1の改造として作られているので、ゲームエンジンは使用されていないでしょう。


でも、おそらくピクミン3では、任天堂外の会社が作成したゲームエンジンを使用しています。

…これは推論にすぎませんが、この違いがゲーム性に大きな違いを生み出してしまっています。




現代的なゲームエンジンには、物理演算の機能が含まれるのが普通です。

キャラクターごとに重さや弾力性などを設定し、他のものに「ぶつかる」かどうかを設定し…

各種設定を行っていけば、プログラムを1行も書かなくとも、一般的な物理現象に従った動きは行ってくれます。


ピクミンは、まるで本当に存在しそうな「小さな生物」たちが冒険するゲームです。

1の時から、存在しえないファンタジーであることは理解したうえで、非常にリアルな世界観で人気を呼びました。


おそらくは、その「リアル」を上乗せするために、物理演算も使用したゲームエンジンを組み込んだのではないかと想像します。


しかし、ゲームはファンタジーの世界に遊ぶから楽しい、という場合があります。

リアルは制限されなくてはなりません。


ピクミンの場合、1・2では、ピクミン自体は「個々には存在するが、互いに干渉しない」存在でした。

100匹の集団がいるのではなく、1匹のピクミンが100体いるのです。




ですから、操作次第では、非常に小さなスペースに100匹のピクミンを押し込めることができました。

作業をするときも、狭いスペースに多人数を投入し、すぐに終わらせることができました。


多くの部下を効率的に使う、というピクミンのゲーム性は、こうして作られたものでした。


しかし、3のピクミンは「100匹の集団」です。お互い干渉するため、連れ歩くには広いスペースが必要になります。

限られた作業スペースに多人数を配置すると、「押し出されて」作業しないものが生じます。


壁を壊そうとしても、働かないピクミンが出るため、投入人数に比例した作業速度は得られません。

荷物を運ぼうとしても、上限人数にはまだ達していないのに、なかなかピクミンが作業しようとはしません。


こうした「リアル」のために、ピクミンの楽しみの一つである「やり込み」が大きな制限を受けます。

一番重要な要素…人数を割り振ることによる、時間短縮が行えないのです。


ピクミンの楽しさの一つは、人数配置を考えることでした。

その要素は残されているのですが、「思ったように動かない」のは、非常に残念なことです。


(注:厳密にいえば、1でも多少の干渉はありました。

 狭いスペースにピクミンを多数投げ込むと、押されて落ちてしまう、など。

 しかし、基本的には「プレイヤーの意思を妨げない」ように作られていたのです。

 3では、プレイヤーの意思に反する動きをすることが非常に多いです。)




先に書いたように、ピクミン1・2では、非常に狭い空間にピクミンを押し込めることができました。

これを使って、獰猛な敵からとにかく逃げ回ることも多いゲームでした。


しかし、ピクミン3では、ピクミンの集団はある程度の広がりを持ちます。

敵が獰猛なままでは難しくなってしまうためか…よほどのろのろしていない限り、敵が襲ってこなくなりました。


なので、集団で襲い掛かれば、安全に敵を倒せます。敵が襲ってくる前に倒してしまえるので。

1・2では敵に対して慎重に対処しなくてはなりませんでしたが、3は力押しのゲームです。


結果的に、敵はピクミンの餌にすぎません。

弱肉強食の食物連鎖を描いたことで文化庁メディア芸術祭優秀賞をとったピクミンですが、3ではそうした食物連鎖を感じさせないのです。



「力押しのゲーム」になってしまった原因は、他にもあります。

ピクミン自体が死ににくくなったためです。


水に落ちてもおぼれません。しばらく泳いでいるので、呼べば上陸します。

火がついても死にません。しばらく走り回っているので、呼べば火が消えます。

電撃を受けても死にません。気絶して倒れているので、呼べば起き上がります。


一応、赤は火に強い、青は水に強い、黄色は電撃に強い…などの特性はあるのですが、あまり気にせず力押しで何とかなります。


1・2のころはすぐに死んだので、死なないように考えるパズルゲームでした。

しかし、3は「死にそうになったらすぐ呼べばよい」という、忙しいアクションゲームです。




物理演算の話に戻るのですが、敵にくっついていたピクミンが「ふりはらわれる」ことがあります。

この時、ピクミンは1・2のころよりもはるかに遠くまで飛ばされます。


これもおそらくは、物理エンジンの挙動のためではないかと思いますが、詳細はわかりません。

ともかく、遠くまで飛ばされて、時として「本来は入れない」エリアに入ってしまうことがあります。


そして、入れないエリアからでも戻ってこられれば良いのですが、戻ってこれないことも多いのです。

そもそも入れない場所だから、歩き回れるような設計になってないのでしょうね。



こうした、意図しない箇所にピクミンが入ってしまう、という挙動には、作成スタッフも悩んだのではないかと思います。

ゲーム中いたるところに、「通り抜けられない見えない壁」が設置されています。


そして、場合によっては…というか、ごく普通になんですけど、「特定のことをして道を作る」部分にも設置されています。

たとえピクミンやプレイヤーが進めたとしても、その「特定のこと」をしていない限り、見えない壁に阻まれて前に進めないのです。


初見プレイで仕掛けを知らず、「どうやって進むのだろう?」と考えたとします。

いくつか仮説を立ててやってみます。そういうことができる楽しさがピクミンなので。


でも、たとえうまく進むことができても、制作側の考えと違う場合は「見えない壁」が立ちはだかるのです。

制作側の考えがなんであるかは、見た目からはわかりません。超能力者のように相手の考えを読まなくては先に進めないゲームになるのです。


…本来なら、「正解以外の方法で目的を達成できない」ような作りになっていればよいのですが、別解がいくつも作れてしまうことが問題だと思います。

でも、別解は許されないのです。


まぁ、実はこれは些細な問題で、初回プレイが楽しくないだけです。

何度かプレイして正解がわかれば、後は正解以外のプレイをしなくなるだけなので、楽しく遊べるようになります。


…初回プレイのイライラで嫌にならなければ、ですけど。




さて、上に書いた「見えない壁」ですが、ピクミンのサポートのためにも存在します。

先に書いたように、ピクミンの大集団は広がりを持ちますが、そのままでは狭い橋を渡るときなどに困るのです。


そうした場合、見えない壁がそっとピクミンをサポートし、落ちないようにしてくれます。

なんて親切設計。


…でも、この壁、万全ではないのですね。ピクミンが多数で押し合いになると、壁が乗り越えられてしまうことがあります。


初心者プレイヤーのイライラの対象となる「見えない壁」が、サポートとしても不十分で、上級者プレイヤーのイライラのもとにもなるのです。



ところで、今作ではピクミンが単独行動をとることもあります。

1・2では、基本的にプレイヤーキャラについて歩き、「獲物を持ち帰る」時だけ単独行動でしたが、その行先はロケット前という「安全地帯」でした。


3では、往復作業が設定されています。作業が終わったらもとの地点に戻り、まだ仕事があれば続けて作業するのです。

この場合、すべての作業が終わった後は、「元の地点」に戻ったところで待機します。



ピクミンでは、日没…時間切れの際に、ロケット前か、隊列にいないものは死んでしまうことになっています。

なので、待機場所があるならそこで待機、というのは重要なことです。


しかし、先ほどから書いている「ピクミン同士が押し合う」問題で、全く予期しない地点で待機するピクミンが出ます。

往復作業中にほかのピクミンに押され道を外れると、時として「戻り方がわからなくなり」そこで待機するのです。


これは突発的におきます。

往復作業の時間が乱れますし、日没時の死亡にもつながります。




さて、ゲームエンジンが原因になっているのではないかな、という問題点はこんなところ。

でも、ピクミン3の問題点はこれだけにとどまりません。


キーワードは「高低差」ですね。


1・2では、地形は基本的に平面に近い構成でした。

高低差はありましたが、なだらかなものでした。


しかし、3には激しい高低差があります。

それだけなら、起伏にとんだ地形で3Dのゲームらしさを出している…と言ってもよいのですが、これが問題を起こします。




まず、カメラが自由に動かせなくなりました。

「カメラを動かしても目的物が見えない」場合も含みます。


ピクミン1でも、突発的に高さが変わる部分はありました。

しかし、そういう部分はマップ構成が工夫されていて、カメラアングルをあまり変える必要はありませんでした。


それに対し、3では、普段歩き回っているフィールド内で、結構な高低差があります。


この高低差により、カメラの動きが制限されます。

見やすい位置にもっていこうと思ってもカメラが動かせなかったり、動かせても別のものに見たいものが隠されてしまったり。


敵との戦いで緊迫しているときに「見えない」というのはかなり致命的ですが、頻繁に起こります。

(慣れれば、最初から戦いやすいアングルに固定できますが)



そして、一番の問題は「上からのアングルが無くなった」ことでしょう。

ピクミン1・2では正確な操作を要求されるところが多々あり、真上から見た視点が非常に役立ちました。



例えば、最も基本的な雑魚敵「コチャッピー」は、背中にピクミンを乗せると一撃で倒せます。

この位置はかなり正確に狙う必要があり、ピクミンを投げたときの着地点である「カーソル」の微調整が重要でした。


ピクミン3でも、コチャッピーは同じ方法で一撃で倒せます。

しかし、上から見られないので、正確な位置が把握できません。


一応、「ロックオン」という操作が追加されていて、カーソルを近くの対象物に固定できるのですが…

適当にロックオンされるだけで、コチャッピーを一撃で倒せる正確な位置にはカーソルを合わせてくれないのです。


(ピクミンの種類ごとに投げられた時の曲線が変わるため、一撃で倒すには、投げるピクミンごとに微調整が必要です。

 しかし、ロックオンではそこまで考慮してくれません。)


結果として、真上から見ることの代わりになっていません。




高低差に話を戻します。


ピクミンを呼ぶ「笛」の有効範囲に、高低差の概念が加わっています。


1・2では、笛は呼び続けることで範囲が広がりました。

この時、「高さ」方向に関しては最初から全範囲でした。


3では、笛の呼べる範囲は、最初は高さ方向がほぼ0、平面です。

呼び続けると平面の範囲が広がり、最大まで広がったところで、やっと高さ方向にも広がります。



おそらく、ピクミン3の様々な「仕掛け」で、高低差が使われるものが多いためなのでしょう。

上と下で違う作業をしているときに、どちらかだけ呼ぶ、という操作をするためだと思われます。


でも、そういう操作は実はあまり使いません。

もっと使うのは、「敵との戦いの時に、振り払われて飛び散ったピクミンを呼ぶ」時です。


戦っている最中ですから、すぐに呼ばないと死んでしまいます、

でも、地形に高低差があると、「笛の範囲が十分に広がり、さらに高さ方向に広がる」まで、呼ばれないピクミンがいるのです。




高低差でもう一つ。


高いところに集める荷物が置かれている、というシーンが時々あります。

ピクミンは荷物を集めるゲームで、ターゲットにピクミンが到達すると「運ぶのに必要な人数」が表示されます。


ところが、高いところの荷物には、この人数が表示されません。

実際には表示されるのでしょうが、画面の上で見えなくなってしまい、表示が読めないのです。


まぁ、持ちうる限りの最大人数を投入すれば運んではくれるし、運んで落としてしまえば人数は見られます。

そして、一度人数を見たら「あそこは何人で運べる」と覚えておけばよいので、攻略には困りません。



これも、先に書いた「初プレイの時にイライラする」だけで、慣れれば問題のないものです。


…しかし、初プレイの時に嫌になる仕様が多いのは、問題だと思っています。




高低差のダメ押し。


とある地点でのパズルは、非常に高低差を活かしたものになっています。


そのため、斜め上から見下ろす視点では操作しづらい…と思ったのでしょう。

カメラがいきなり横からの視点に固定され、横スクロールゲームのような画面になります。


これが、普段とは操作感が違いすぎて、非常に操作しづらいのです。

急に今までと違う向きのカメラになって、結果としてジョイスティック操作も違う感覚になって、そこでパズルを解くための正確な操作を要求されます。


これ、やってみるとわかるのですが、急にルールの違う、別ゲームが始まったような感じです。

ものすごく違和感あります。


基本的に、ユーザーに断りなくルールを変えるのは、もっともやってはならないことだと思っています。

(メイドインワリオのように、次々ルールが切り替わることが楽しいゲームは、そのことも含めてルールになっているのでかまいません)




なんか悪口書いているみたいで生産的ではないのだけど、もう一つ大きなことを書かないといけません。

マップ構成のことです。


ピクミン1・2では、マップは基本的に、継ぎ目がありませんでした。

2では「地下」がありますが、1フロアごとに1枚のマップで、フロア間を自由に行き来するようなことはありません。


半面、ピクミンのマップは非常に「狭い」ものでした。

おそらく、3ではこれを解消すべく「広い」マップを作ろうとしたのでしょう…


断片的なマップがいくつもあり、その間を行き来して目的を達成する構成になっています。


この「マップの継ぎ目」が非常に不思議な、ねじれた空間になっているようです。


というのも、ピクミンが物を運ぶのについて継ぎ目に入ると、出口ではピクミンを追い抜いて出てくるのです。

ピクミンは継ぎ目の中を歩いているが、プレイヤーは継ぎ目の「入口」と「出口」の間をワープしている感じです。



そして、継ぎ目の中にいるピクミンは、異空間に入り込んでいます。

呼ぶことはできないし、日没近くの「このままでは死んでしまうピクミン」の人数カウントにも入っていません。


特に困るのが、荷物を持とうと頑張ったピクミンが、結局荷物が持てずに「諦めた」場合です。


最初の方で書いた通り、ピクミンは「互いの作業を邪魔」します。

荷物を運ぶ際も、運べる最大人数に達する前に「邪魔」によって諦める場合があります。


こうした、作業に着けなかったピクミンは、しばらく作業をしようと頑張った挙句、あきらめてその場で待機状態になります。

荷物を運ぶ場合「しばらく荷物について行った挙句、途中で待機状態となる」のです。


待機状態になったら、呼べばプレイヤーについてきます。

しかし、先に書いたように、継ぎ目の中で「待機」されると、呼ぶことができません。

「このままでは死んでしまう」というカウントにも入らないので安心していると、日没で死亡します。


これは明らかにゲームシステムの欠陥ですが、これも慣れてくれば「継ぎ目近くで荷物を運ぶピクミンを増やさない」という対処ができるようになります。


荷物を運ぶときは、人数によって速度が変わるので、攻略時には重要なのですが…

ここまでに書いたように、ピクミン3のシステムは、なんとなく遊ぶには悪くないのですが、攻略には向いていません。


自分の操作が悪いのであれば納得もするのですが、「運が悪い」としか言いようがない状況で失敗することが多すぎるので。




さて、以上が「システムに不備がある」という問題。

ここまで長々書いていますが、これでやっと言いたいことの半分くらいです。


ただ、ここから先は、個人的な このみ の問題で、ゲームシステムがおかしいとか、そういうことではありません。



ピクミン3は、攻略を「させない」方向に向けて舵を切っているように見受けられます。


というのも、ピクミン1・2に比べて、すべての荷物が少人数で運べるから。


1の時は、重くて大人数、かつ距離が遠くて時間がかかる…なんて荷物がいくつもありました。

これを運んでいる間、残りの少人数で効率よく敵を倒して回る、なんて攻略が普通でした。


これ、少人数でボスに挑むの、結構大変なんですよ。

攻略としては面白いのだけど、一部のマニアに向けての構造で、誰もが楽しめるものではない。


だから、今回は荷物は少人数で運べる。

先に書いたように、大人数の力押しで敵を殲滅して、その後分散して荷物を運んでおしまい、というような構成が多い。


何よりも、マップが広くなりました。

先に書いた継ぎ目問題はあるけど、広いマップを冒険することが目的のゲームで、小さなマップを緻密に攻略するゲームではなくなっている。

1・2のころに比べて、しっかりとしたストーリーらしい展開も多くなっていますし。


だから、ある程度効率を上げる「攻略」は楽しんでもいいけど、人数配分を1人単位で考えるような、緻密な攻略をする感じにはなっていない。


まぁ、それでもやりたい人はやればいいのだと思いますけど、先に書いた「バグ」が多発する問題で、攻略しようとすると非常に遊びづらいです。




ピクミン1は、今でこそ名作だと言われていますが、発売当時の評価は非常に低いものでした。

もう20年も前のゲームなので、当時の状況覚えている人少ないかもしれないけど。


テレビCMは話題になりましたが、ゲームキューブが売れなかったこともあり、遊んだことある人は少ないんじゃないかな…

今回、ピクミン3デラックスを絶賛する記事を書いている人の中に、「ピクミンは初めて遊んだが、さすが人気シリーズだけはある」という論調が多いのが気になりました。


で、反論含みでこの日記を書いているわけですが。


「さすが」と捉えている方々にとっては、遊んだことがないけど人気のピクミンは、いつか遊びたい憧れのシリーズだったのでしょう。

でも、先に書いたように、3は1・2とは別物のゲームになっていると感じます。



その一方で、この方向転換は、商売としては当然だとも思います。


1の発売直後の評価は、「すぐに終わってしまう小粒なゲーム」でした。

終わった人が中古ソフト屋に売ったため、値崩れを起こして安く買えました

つまりは、「クソゲー」扱いですね。


実際、すぐにエンディングを見られるゲームでした。

そして、すぐにエンディングまで行けるからこそ、「繰り返し遊んで欲しい」というメッセージが、エンディング後に隠されていました。


#言葉として入っているわけではなく、「ハイスコア」の表記が出るのです。

 これはつまり、繰り返し遊んでハイスコアを目指せ、という意味です。


マニアはこのメッセージを理解できましたが、マニアでない人には伝わりませんでした。

中古ソフト屋に売られたというのは「伝わらなかった人」が売ったのでしょうし、のちの評価が凄い高いのは、「伝わった人」がやり込んだためです。


これ、ゲームのとしての評価は高いのですが、商売としてはダメです。

中古で出回ったら、任天堂としての収入である「新品のソフト」が売れなくなっちゃいますから。



2では、ゲーム終了までのボリュームを増やしました。

半面、繰り返して遊ぶのは難しくなったため、やり込み要素は減った感じです。


そして、今回の3では、さらに本編のボリュームを増やしてやり込みを減らした、と思っています。

ピクミンの個性が希薄になったのも、食物連鎖を感じないほど敵が弱くなったのも、「マニアでない人向け」だと思えば、すべてが納得できる変更です。


しかし、ゲームとしていろいろおかしいのはすでに書いた通り。

根底部分のルールから変わってしまった3は、「ピクミンを真似して作られた、よくできたゲーム」にすぎないように思います。


▲目次へ ⇒この記事のURL

関連ページ

レトロゲームの日【日記 21/03/20】

別年同日の日記

02年 ページ更新

03年 東海道旅行終了

04年 忘年会

09年 風邪その後

10年 盛りだくさんの週末

12年 答えは重要ではない

17年 0sim

19年 やっちまいました。


申し訳ありませんが、現在意見投稿をできない状態にしています

HTMLで多数のデータを表示する。  2020-12-07 18:32:02  コンピュータ

▲目次へ ⇒この記事のURL

作成している WEB サービスで、データを1万件ほど表示する必要があった。


それまで作っていたスペックでは、せいぜい 100件程度だった。

HTML で小さなウィンドウを作り、その中を CSS 設定で縦スクロールするようにして、内部に 100件のデータを入れる。

まぁ、よく見るインターフェイスだ。


そのプログラムのまま、中身を1万件にしたら、いろいろと問題が出た。




まず、表示を指示してから実際に表示されるまでが遅い。

そして、表示されてから、スクロールしようとすると非常に重い。


1万件ものデータ処理だから遅いのかな、と思って、Javascript の速度を調べると、

データ処理には 100ms 程度しかかかっていなかった。


表示までは5秒程度かかったのだが、これらはほとんど、挿入された HTML の解釈時間だということになる。


いろいろ実験するも、1000件程度までは実用になるのだが、1万件になると実用的な速度ではない、と分かるばかりだった。




初期表示の遅さについては、まず 100件程度を表示してから、徐々に追加していったらどうだろう、とか試してみた。


確かに、すぐに表示はされるのだが、その後スクロール処理がどんどん重くなる。

1/10 秒ごとに 100件づつ追加、とかしていると、この追加のたびにかかる処理速度も、どんどん重くなっていく感じがする。


…うん、たぶんすでに表示しているデータ件数 n に対して、新たなデータを入れるときの処理速度が n*log n に比例しているのだ。


これ、プログラムしているとよく見る構造だ。つまりは、内部的に DB を構築していて、データ件数が多くなると挿入速度が遅くなっていく。


実際、HTML は内部で DOM ツリーというものを構築する。これはツリー構造の DB に他ならない。

何か操作を行うたびに、このツリーをたどり、どの部分を操作対象とすべきか、画面表示の対象とすべきか、などをチェックしていく。


ここら辺は、ブラウザ内部での処理の問題なので、Javascript で高速化できる問題ではない。




問題を棚上げして別の仕事をしていて、ふと気づいた。


そもそも、HTML の量が多いのが問題なのだ。Javascript 側は、1万件くらいなんてことない。

じゃぁ、HTML のコード量は最小にしよう。


先に書いたように、データの表示は小さなウィンドウ内で、スクロール表示になっていた。

1万件あっても、実際に表示されているのは 10件程度だった。



div のスクロールイベントにフックをかけて、現在のスクロール位置を取得する。

データは、1行1データのようにきれいに並んでおり、1行の高さも決まっていた。

なので、スクロール位置から、現在表示されるデータが何行目かも判断できる。


何行目を表示するかわかれば、それより「上」に何行あるかもわかる。これらは画面外のデータだ。

だから、HTML としては最小限に、全部をまとめて「高さだけ」をブラウザに伝えることにした。


div を作り、style で height を指定すればよい。

下方向も同じように、画面外は div 1つで済ませる。


そして、表示したい部分の10行ちょっとだけ、その場で生成してブラウザに渡す。

10行程度なので、ブラウザは瞬時に解釈を終え、遅延なく表示される。


上下に div を作っているのは、スクロールバーを「あたかも1万件のデータがあるように」表示するためだ。

でも、HTML には10件程度のデータしか入っておらず、スクロールするたびに書き換える。



実際には、そのプログラムでのデータ表示はこれほど単純ではなく、一部だけ行の高さが変わったりもしていた。

でも、規則性があるので div の「高さ」をそれに合わせて調整するような計算式を作った。


上端と下端の部分も、破綻しないようにプログラムする必要がある。


しかし、それらは些細なことだ。




大量のデータで HTML が遅い時の処理方法をネットで探していたが、あまり見当たらなかった。


DOM の遅さ、という話になると、単純なハンドリングの速度の話だけで、極端に多いデータの際にスクロールすら遅いのをどうにかできないか…というような話題にはならないのだ。


まぁ、個別論だから一般的に論じにくい、というのもあるとは思うが。


今回の例では、スクロールのたびに DOM を大きく入れ替える、という「DOM が遅い」という話題ではやるべきでないことをしている。


でも、それによって HTML 量を極端に減らすと、DOM の処理速度は劇的に改善する。



…やっていて「時期尚早な最適化は害悪」という言葉を実感していた。


当初は、今までのやり方で何とかならないか、と最適化を試みていたんだ。

でも、どうにもならないと思って大きく作り変えたら、問題は簡単に解消した。


しかも、このプログラムは速くなるようになんて書いてない。

DOM 操作に jQuery とか使ってるし。

(古いプログラム部分が多いので、過去に作った部分はそのままなのです)



最適化を考える前に、根本原因が何かをちゃんと見極めよう、って話です。



▲目次へ ⇒この記事のURL

関連ページ

100倍規模【日記 21/01/23】

別年同日の日記

01年 12/6

02年 中間決算

05年 同時接続数規制

14年 ハイキング

15年 2つの格安SIM

15年 2つのSIMフリー スマートフォン


申し訳ありませんが、現在意見投稿をできない状態にしています

サーバーダウン  2020-11-23 12:17:12  コンピュータ

▲目次へ ⇒この記事のURL

三連休の初日から、サーバーがダウンしていたようだ。


悪いタイミングで落ちたもので、連休中は家族と過ごす時間が多く、気づかなかった。

ツイッターで教えてくださった方に感謝。


原因は DB の一部破損で、テンポラリデータで特になくなって困るものではなかったので、テーブルを作り直した。

これで安定動作するか、しばらく様子見。



4時間後に追記


…やっぱだめだった。

「しばらく様子見」と書いた5分後には、落ちた。


仕方ないので、一旦「トラブルにつき復旧中」の旨を静的ファイルで表示するように設定変更。


どうも、mysqld が落ちてしまうようだ。原因究明。



えーと、紆余曲折あって、たぶん解消。

途中、何度かサイト再始動しては、落ちるを繰り返している。


原因が何かわからないため、たぶん原因ではない「問題になりそうな点」も、順次解消して回った。


innodb の設定を変更してみたり、通信バッファを広げたり。


DB の全データをバックアップして、設定を変えた状態でリストアしたり…

つまりは、DB のファイル構造を作り直したりもした。


でも、たぶん真の問題はメモリ不足。

仮想サーバーなので、メモリ割り当てを増やしたら安定した。




こういう時の作業は、たいていは素直にはいかず、些細なトラブルが頻発する。

そして、些細なトラブルを乗り越えるのに時間がかかる。


そのため、思った以上に時間がかかってしまった。


(こういう時の作業は、普段起こらない「極端な負荷」をシステムにかけるもので、普段出ないエラーに遭遇する。

 たいていは、設定を少し見直せば済むだけの些細なものだが、普段見ないエラーだから意味と対処法を調べるのに時間がかかるのだ。)


また様子見だが、今度は大丈夫だと思う。…思いたい。


▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/22

04年 不動産取得税

09年 Netwalker いじってみた。

15年 「ちきゅう」一般公開

15年 三菱みなとみらい技術館

16年 畳替え


申し訳ありませんが、現在意見投稿をできない状態にしています

経年劣化2  2020-11-18 18:20:12  コンピュータ

▲目次へ ⇒この記事のURL

先日、電源というのは経年劣化する消耗品だよ…という話を書いたら、そのすぐ後に大きな「電源」が経年劣化で壊れた。


先日書いた意味での「電源」は、交流・直流を変換する機器の意味で書いたのだけど、今回壊れたのは、UPS。


UPSというのは「無停電電源装置」と呼ばれる。

コンセントから常に充電し続け、ふたたび交流 100V を出力する機械。

停電が起こっても、しばらく 100V 出力を続けられる。


まぁ、実際停電になってもサーバーを止めないでよい、というほどの効果はない。

時々起こる瞬停に対応できるというのが最大のメリットか。


ちなみに、瞬停とは、0.1 秒程度の短い停電。

電力会社が、何らかの都合により送電経路を入れ替えるときなどに発生する。


最近の機械は、0.1秒程度の停電には耐えられるような電源を使用しているけど、動作は保証されない。




我が家の UPS は、2年前に「買い替え」ていたのだけど、古いものも残っていた。


これは全くズボラな話で、新しい装置にサーバーなどの停電が致命的なものは繋ぎ変えたのに、ルーターやハブなどの「致命的ではないが、なんとなく止めづらい」ものを繋ぎ変えてなかったため。


で、壊れたのは古い UPS 。

夜、寝ようとしていたら急にサーバールームから「ピーーーーー」という連続 Beep 音が聞こえてきて、慌てて原因を探ったら UPS だった。


すぐ電源切って、ルーターなどを新しい UPS につなぎなおした。


勘違いでつなぎなおしていないネットワーク機器があり、うまくネットがつながらなくて焦ったけど、実際のところつなぎなおしたら済む程度のトラブルだった。




この UPS 、いつかったっけかな…


少なくとも、2011 年の東日本震災の時には使っていた


普通は2~3年で寿命、と言われるので、使い過ぎ。

まぁ、だからこそ2年前に買い替えていたのだけど。


電源は劣化するよ、なんて話を書いていたのに、自分がお粗末でした。



▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/17

02年 予約特典

04年 CSV-S57改造

13年 ミッキーマウス&ポール・モカペトリス 誕生日

14年 ポール・モカペトリスの誕生日(1946)

16年 ら抜き言葉

19年 自宅電話回線その後


申し訳ありませんが、現在意見投稿をできない状態にしています

経年劣化  2020-11-12 17:23:51  コンピュータ

▲目次へ ⇒この記事のURL

2年ほど前に、USB テーブルタップ…というのかな。

USB のポートが6つついているだけの、ACから電源をとる充電器を購入した。


当時、Amazon で 450円だったので2台も買った。

ちなみに送料が 400円程度かかったので、1300円くらい。もちろん中華。


カタログスペックでは急速充電を謳っていたが、実際には電流は少ないようで、しかし普通に使えていた。

旅行の時などにもっていき、ホテルの部屋の限られたコンセントで、家族中の端末を充電できるので重宝した。




普段は、居間のテレビの裏に1台と、同じく居間の対角位置に「ガジェット置き場」を設けているので、そこに1台置いてある。


テレビ裏というのは案外電源が必要なのだが、USB 電源で十分なものも多いためそこに一台。

ガジェット置き場は、今使っていないガジェットの置き場であり、置いてある間に充電するために1台。



先日、Amazon FireTV Stick でビデオを見ていたところ、急にリセットがかかった。

最初はなぜリセットしたかわからず、熱暴走かと思って家にあったヒートシンクなどくっつけてみたのだが状況が変わらない。


FireTV Stick は、この USB テーブルタップから電源をとってあった。


そこで電源を取り換えてみた(本来の純正 AC アダプタを使用した)ところ、安定するようになった。

ということは、USB 電源の劣化なのだろう。


まぁ、450円で買った怪しい製品だからな…劣化も案外早かったということか。




電源というのは経年劣化するもの。消耗品だ。

パソコン自作とかする人なら常識として知っているかもしれないけど、案外知られていない。


交流を直流に直すには、交流の「山の部分」で充電を行い、「谷の部分」で放電を行う、コンデンサが必要となる。

まぁ、小さな充電池だと思ってもらえばいい。


スマホの充電池が徐々に劣化していくように、このコンデンサも徐々に劣化する。



充電池は「ある程度充電されている」状態が普通になるように作られている。

だから、過充電したり、完全放電したりすると劣化が激しくなる。


劣化が怖いから使わないでおいておく…なんていうのは意味がなくて、むしろ劣化を早めることもある。




これを買う前は、USB 電源だけをたくさん取れる製品が便利なのかどうかよくわからなかったのだ。

だって、普通にテーブルタップで USB アダプタ使ってもいいじゃん。


だから、使ってみて便利だったらいいのに買いなおせばよい、というつもりで、450円なんて言ういかにも怪しいものを買ったのだった。



そして、コンパクトである、というのは案外便利だと知った。

そんなわけで、買い替えを考慮中。



▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/11

04年 土地整備完了

12年 食育フェスタ

13年 ミヒャエル・エンデの誕生日(1929)

15年 Edge でもドット絵拡大!


申し訳ありませんが、現在意見投稿をできない状態にしています

getGamepads  2020-10-27 12:09:19  コンピュータ

▲目次へ ⇒この記事のURL

お仕事で、ビジネス向けのクラウドサービス…的なものを作っている。

クラウドサービスって言葉はうすら寒いのだが、要は WEB ブラウザで見られるサービスだな。


スマホを使って、アンケートなどに答えてもらう。

そのデータを収集し、グラフなどで分かりやすくしたうえで、大きな画面に表示する。


まぁ、そんな感じのものだ。教育向けに使ったり、大きなイベントで使われたりしている。




どんなサービスか、というような詳細はこの際問題ではない。

ともかく、「ビジネス向けの」 WEB サービスを作っていたのだが、企画者が「全部 Unity とかで作り直したら、ゲームのコントローラーで操作できるかな」と、ぼそりといった。


以前から、いろいろな操作上の問題が指摘はされていたのだ。

サービスはマウスとキーボードで操作するように作ってあったのだが、それだけだと対応しづらい要望もさらに出されていた。


企画者が考えていたのは、その多数の問題の内、1つだけの解決方法だった。

そのために、ブラウザ用に作ってあるのと同等のものを、Unity で作り直しても良いのではないか、というほど困っていたのだ。


このつぶやきを聞いた瞬間…確約はできないのだけど、自分の中ではいろいろとひらめいた。


黙って少し下調べ。そうか。まだ標準化はされていないが、今の Javascript では、gamepad API というものがあるのだな。


ここまで分かった時点で、Amazon で XBOX コントローラーを購入した。




コントローラーが届いたのは翌日、土曜日だった。

勝手に、現在のプログラムにコントローラーで操作する機能を追加する。


…ちゃんと、元のプログラムとは違うブランチにしているよ?

でも、勝手にやるので後で怒られるかもしれないし、作業料金は発生させない。

あくまでも自分の趣味で作り…採用されたら、後で料金上乗せさせてもらおう。



1時間ほどの作業で、スクロールをゲームのコントローラーで制御可能になった。

ゆっくりスクロールしたり、高速にスクロールしたり、アナログパッドなので自由自在。



ここまでできたら欲が出る。

マウス操作しているときは、スクロール「しすぎ」も問題だった。

ブラウザのスクロール機能を使っているのでどこまでもスクロールできてしまうのだが、本来範囲制限したいのだ。

その機能を追加する。


というのも、ブラウザ画面の長いスクロールは、いくつかに区切られているのだ。

スクロール時は、区切りの範囲内でだけスクロールしたい、という要望が出ていたのだが、ブラウザの機能としてそういうことはできなかった。

ジョイスティックでのスクロールは、Javascript で完全制御しているため、これを実現できた。


そして、この「区切り」の頭出しをしたい。


頭出しは、キーボード操作では0~9 のキーで一発でできるようになっていた。

最大の区切りの個数が 10個だったから。


でも、最近要望で、20まで増やせるようにしていた。この時の操作で問題が出ていた。

これを、コントローラーの L R キーで、順次変更できるようにした。

一発頭出しはできないのだが、「次」「前」を連続させることで、個数の制限をなくしたのだ。




さらに翌日の日曜日、いろいろな操作をキーに割り振っていった。

基本的に、A を押せばその状況に応じて状況が進むようにした。


イベントの際など、タイミングの節目で A を押せばよい。

イベントの際には間違えが致命的なミスとなるので、できるだけ単純な操作がいいのだ。


マウス操作を基本として作ってあるので、いくつかの機能はマウスをそのまま使えばいいだろう。

これは勝手に作る実験なので、深入りせずに見栄えのする機能だけ作る。


…これがね、結構楽しい。

作っていても楽しいのだが、操作感が楽しいのだ。


ビジネスソフトなのに、ゲームのコントローラーで操作するということが面白いチャレンジだし、やってみるとマウス・キーボードの組み合わせよりもわかりやすく、操作しやすい。




月曜日、打ち合わせで実際に会う約束があったので、XBOX コントローラーを持っていき、披露。


想像以上にウケた。

最近出ていたいくつかの問題点が解消されるのに加え、やっぱり「ビジネスソフトなのにゲームコントローラー」というのが面白いので、是非現場で使いたいとのこと。


で、操作できない部分もある程度できると良いね、と。

とりあえずマウスで操作かな、と思っていた部分ね。


これについては、企画者に「UI考えて」と頼んでおいた。

UI さえ決まれば、作れそうな気がする。




ビジネスソフトでゲームパッド、ということに対して、ミリタリー好きのプログラマから「今時、戦車もプレステのパッドで操作しますしね」と。


え?そうなの?

話によると、ロシア軍がプレステパッドで操作する戦車を作った、とのこと。

今調べてみたら、プレステパッド風というだけで、そのものではないようだ。


僕の方からも、アメリカの原潜が XBOX のコントローラー採用しましたよね、というと「そういえば、そんな話もあったねぇ」と。


これらに比べたら、ビジネスソフトで使うなんて、特に問題ないだろう。

ゲームパッド、なかなか奥が深い。



▲目次へ ⇒この記事のURL

別年同日の日記

01年 10/27

02年 妹主演の劇を見る

04年 枝豆

11年 太陽電池

16年 ダイナマイト刑事

17年 Android Chromeでスクロールがおかしくなるバグの原因と修正


申し訳ありませんが、現在意見投稿をできない状態にしています

Lenovo Ideapad C340 購入  2020-08-22 17:58:23  コンピュータ

▲目次へ ⇒この記事のURL

Windows マシンを買い足した。

こちらは子供用。


5月に一度、子供用マシンを買おうとしたのだが、取りやめている

その後も探していて、やっと届いたところだ。




購入の一番大きな理由は、子供用の Chromebook が不調だから。


このマシン、元々 Chromebook の魅力が「安さ」だった時期に買ったので、購入時点で低いスペックのマシンだった。

低いマシンスペックでも満足な動作をしてくれるのが Chromebook の良さだった。



でも、その後 Chromebook の立ち位置は変わり、スマホのように気軽に起動できる、PC として作業が行いやすいマシン、になっている。

それに伴いマシンスペックも求められるようになり、高価格化している。


以前一度買って取りやめたマシンは、そんな中でも安かったから購入しようとしたのだが、安い理由は「日本仕様にしていなかったから」で、キーボードが US だった。

ローカライズ作業を省けば大量生産でコストが下がるのは事実だが、それはちょっと使いづらいので、返品となった。




その後も Chromebook を検討するが、それなりの値段になってしまう。

それなら、もう少し予算を上乗せして Windows マシンを購入したほうが、できることの幅が広がる。


子供用にはもう一台使っているマシンがあり、これはもともと妻が使っていたRaytrektab


特に長女が気に入っていて、絵を描くのに使っている。

(長女は小学生のころから絵を描くのが好きだったが、中学になっていわゆる漫研に入った)


じゃぁ、さらに予算を上乗せして、ペンタブとしても使える 2in1 マシンにしようか…



というわけで、Ideapad C340。

税込み6万円弱。子供に使わせるにはちょっと高価だが、勉強への活用も考えると、これくらいのものは買っておいてよいだろう。


…といっても、今のところ使っているのはもっぱら次女。

今まで次女が主に使っていた DELL Inspiron 15 N5010 では「ペンでお絵かき」はできなかったので、喜んでいる。


というか、このマシンはさすがに 10年前のもので、物理的にも動作的にも重い。

Chromebook が動かなくなったので、暫定的に使ってはいたのだけど。




少し余談に入る。


次女はキーボード付きマシンを使うことが多いので、ワープロ使ったりするのも楽しいらしく、いつの間にかお気に入りの歌の歌詞カードを作っていたりする。


一方、長女はキーボード慣れしていなかった。



それが、夏休みの宿題で読書感想文を原稿用紙5枚書かなくてはならなくなった。

長女は文章を書くのは嫌いではないし、親から見ても結構うまい文章を書くのだけど、今まで書いたことがあるのは、せいぜい原稿用紙2枚。


どうすればいいのか途方に暮れていた。



そこで、慣れていないかもしれないが、ワープロの活用を勧める。

今回の購入マシンではなく Inspiron を使ったのだけど、「文章を頭から考える」のではなく、読書感想文として、思ったことをメモでもいいからどんどん書き出してみな、とつたえる。


僕としては箇条書きでもどんどん書いていく、というのを勧めたのだけど、慣れていないので難しい。

結局、ある程度まとまった文章の断片がいくつかできて、その間のつながりが難しいとか、この話をどうまとめたらいいのか、とか、そういう形になった。


読書感想文って、「感想」を引き出すまでが一番大変なのだけど、ワープロだと何度でも書き直せる気楽さで、結構いろいろと引き出せていた。


こまでくれば後はテクニックの問題。


それぞれの文章はどういう気持ちで出てきたものなのか、その間にどう関連性があるのか、などを本人に聞いてみると、書いていないことを説明し始めた。


つまり、その言葉が足りないからうまく繋がらないんだ。

そこを補わないといけない。


他にも、長女の場合、文章が少し長すぎて伝わりにくい部分があったので、できるだけ短く区切ることを提案。

短く区切って並び替えるだけでも、文章はずっと伝わりやすくなることがある。



大体できたところで、書式設定をして、20文字*20行を1ページにする。

これで、5ページになるように文章量を調整。



慣れないワープロ作業は大変だったようだが、本人も「紙に向かって書いていたらこんなの書けなかった」という、満足いく仕上がりとなった。


…で、学校の規定で、原稿用紙に鉛筆で書かないといけないので、この後地獄のような写経作業があったのだけど。


(これが一番大変だったようだ。もっとも、ワープロを使わない場合は、適当な紙にさんざん書いたうえで、さらに清書する作業があるので、ワープロの方がやはり作業量は少ないだろう)



先に書いたように、「勉強にも活用」というのは、こういう作業も含む。

調べ学習程度なら WEB ブラウザが使えればいいし、極論すればスマホで十分かもしれない。


でも、ここは妥協したくないところなので、キーボード付きのマシンにこだわっている。



#もちろん、タブレットに Bluetooth キーボードでも構わない。

 僕の場合は、子供に気軽に使って欲しいので、多少高くてもややこしい設定のいらないマシンを買っているだけ。




今回購入した Ideapad は、申し込んだのは7月末。

この時点で「お届けは1か月以内」だった。


その後、「人気があるので出荷が遅れ、9月頭の予定です」とメールが届き、まぁ仕方がないだろうと思っていたら、8月の半ばに「出荷しました」連絡が来た。

届いたのは、5日ほど前。



7月末に申し込んだのは、コロナウィルスの感染者数が急に増え始めたため。

このまま再度学校がネット授業になった場合に、子供の PC の数が間に合わん、と思って購入。


結局そうした事態には至ってないのだけど、出荷が間に合わないほどの人気になっていたのは、同じことを考える人が多かったのでしょうね。



▲目次へ ⇒この記事のURL

関連ページ

ノートパソコン修理【日記 21/01/26】

Lenovo Ideapad Duet 購入【日記 21/02/23】

別年同日の日記

04年 大忙しです

13年 国立科学博物館

17年 夏の家族旅行 2017

17年 下田海中水族館

17年 とうてんぽーる

17年 アニマルキングダム・動物園エリア

17年 アニマルキングダム・遊園地エリア

17年 アニマルキングダム・2周目~帰路

19年 SVG うねうね


申し訳ありませんが、現在意見投稿をできない状態にしています

iPhone SE 購入  2020-08-22 17:18:15  コンピュータ

▲目次へ ⇒この記事のURL

仕事のために「しかたなく」iPhone SE を購入しました。


…というのは、以前に MacBook Pro を購入した時の日記に書き出しを揃えてみた。


MacBook Pro は我が家の現役マシン単体では一番高価なものだが、やはり仕事でしか使ってない。

Safari での表示・動作確認が主な役割で、使うときは1日 30分くらい使うが、使わないときは2週間スリープしっぱなし、という感じ。

(2週間に1度くらいは使うが、その場合も5分で終わり、とか)



で、iPhone SE もそうしたマシンになる予定。

iPhone での表示確認を求められることがあったので…


ただ、こちらは Mac Safari の表示確認よりも頻度が低いはず。



▲目次へ ⇒この記事のURL

関連ページ

ノートパソコン修理【日記 21/01/26】

Lenovo Ideapad Duet 購入【日記 21/02/23】

別年同日の日記

04年 大忙しです

13年 国立科学博物館

17年 夏の家族旅行 2017

17年 下田海中水族館

17年 とうてんぽーる

17年 アニマルキングダム・動物園エリア

17年 アニマルキングダム・遊園地エリア

17年 アニマルキングダム・2周目~帰路

19年 SVG うねうね


申し訳ありませんが、現在意見投稿をできない状態にしています

Windowを閉じるボタンの左右位置  2020-08-17 17:54:40  コンピュータ

▲目次へ ⇒この記事のURL

6年も前に書いた「ボタンの左右位置」の話は人気で、今でも時々参照される。


スマホ、Mac 、Windows で OK Cancel ボタンが並ぶときに、どちらが左に来るか?

なぜそうなっているか? を解説した記事だ。



iPhone と Mac は、OK が右に来る。

Windows は OK が左に来る。


Android は最初期のころは Windows を真似ていたが、現在は iPhone と同じだ。


Windows は Mac を真似して作ったが、真似だと言われないように逆にしたのだ、という噂がある。


でも、それはでたらめだ。

Windows で OK が左になっているのは、ちゃんと理由がある。




この記事が先日も参照されていたのだが、その人は「ウィンドウを閉じるボタンの位置」を気にしていた。



MacOS では、閉じる・最小化、最大化ボタンはウィンドウの左上についている。

それに対し、Windows では右上についている。


ここでまた、「Mac の逆にしたのでは?」説が出ていた。


いや、それもそんな理由ではなく、ちゃんとした歴史的経緯があるのだ。


因縁話ばかりしていると老人の仲間入りだとは思うが、ネットを探すとこうした情報があまりないようなので書いておこう。




まず、MacOS が「閉じるボタンが左上」なのは良い。これは初代から変わらない。

でも、その他のボタンも左上になったのは、MacOS X からだ。 MacOS 9 までは違った。


初期から 7 まで、拡大ボタンは右上についていた。

左に閉じるボタン、右に拡大ボタン、という左右対称デザインにしていたのだ。


最小化、という概念はなかった。

なぜなら、MacOS はシングルタスク OS であり、最小化して「何も画面に表示しない」ことに意味がなかったためだ。



その後、System 7 (MacOS 8 以前は、単に System と呼ばれていた)の時にマルチタスク動作が可能になり、ウィンドウがたくさん重なる状態が邪魔になった。


そのため、7.5 で「ウィンドウシェード」という機能ができた。


「窓」にかかるシェードカーテンのように、巻き上げられる機能だ。

具体的には、タイトルバーだけに「最小化」される。


この機能は、タイトルバーをダブルクリックすることで行われる。新たなボタンは設定されない。

本来、Mac では「ダブルクリックは開く」という操作だったのだが、ダブルクリックでウィンドウを「閉じて最小化する」というおかしな操作だった。


当初考えていなかったマルチタスクが搭載されたための、苦肉の策だ。



MacOS 8 では、シェードのためのボタンを増設し、右端に付けた。

並びは拡大、シェードの順で、閉じるボタンが左端なのは変わらない。


いろいろと操作が混乱して、扱いにくくなったため、MacOS X になった時に大幅に UI が改められ、ボタンが全部左に寄せられた。


これが、現在の MacOS X の形になる。




Windows 1.0 は、左上に閉じるボタンがあり、右上に最大化ボタンがあった。

つまり、Mac と同じだ。真似と言われないように逆に、なんてことはしていない。


ただし、「閉じるボタン」は、閉じる以外の機能も持っている。

つまりメニューボタンなのだけど、一番重要な機能は「閉じる」で、ダブルクリックで閉じられた。


ダブルクリックは、Mac では基本的に「開く」という操作だとされた。

それに対し、Windows では「示したオブジェクトの、一番よく使う操作」だ。


ファイルアイコンで一番使う操作は、開くこと。

メニューで一番使う操作は、閉じること。


そういう操作体系であり、ダブルクリックで閉じることを混乱だとはとらえない。



しかし、Mac と違って、最初からマルチタスクだった。

そのため、画面上に多数のウィンドウが表示された。


ごちゃごちゃして邪魔なので、2.0 で最小化ボタンが追加された。

このボタンは、右端の拡大ボタンの隣に設置された。

この時「拡大」ボタンは「最大化」ボタンと名称変更した。最小と最大、という統一感を出したのだ。


(MacOS 9 でシェードが追加されるよりも前の話だ)


まぁ、多くの人が見たことがあるのは、3.0 以降だろう。

ここでも見た目は変わらず、左上に事実上「閉じる」ボタンである、メニューボタン。

右端に最小化と最大化が並ぶ。



このデザインが大きく変わったのは、次の Windows 95 になった時だ。

「閉じる」ボタンの機能はよく使うので、ダブルクリックしなくてもよいように、左上のボタン群に追加された。

ここで初めて「最小化・最大化・閉じる」の3つボタンデザインができる。


(MacOS X の登場はずっと後だ)



左上のボタンは、一見廃止されたように見えるが、「プログラムのアイコン表示」という形で残った。

見た目はボタンではないが、押すとメニューが出るし、ダブルクリックで閉じるのだ。


実は、この機能は今でも残っている。

タイトルバーを消してしまっているような特殊なソフト…Chrome などでは動かないけど、タイトルバーがあり、左端にプログラムのアイコンが表示されているウィンドウでは、アイコンダブルクリックで閉じる。


だから、「Windows の閉じるボタンは右で、Mac と逆になっている」というのが間違いだ。

今でも Windows の閉じるボタンは、左にも残っている。





余談になってしまうが、なぜ Windows で、「ダブルクリックで閉じる」なんていう面倒な操作を標準としたのか書いておこう。


これは、Mac と Windows の「プログラム」に対する観念の違いに起因するものだ。


Mac では、ウィンドウを閉じてもプログラムは終了しなかった。

Windows では、ウィンドウを閉じるとプログラムが終了した。


「プログラムの起動」はコスト(=時間)のかかる処理なので、うっかり終了してしまうのはよくない。

そのため、閉じる操作を「クリック」ではなく、「ダブルクリック」としていたのだろうと思う。


その頃の Windows では、1つのプログラムは、基本的に1つのウィンドウを使用した。

複数のウィンドウを開きたいときは「ウィンドウ内ウィンドウ」を使うようになっていた。



これが改められたのが、Windows 95 から。

1つのプログラムで、複数のウィンドウが開けるようになった。

プログラムを終了するには、メインウィンドウを閉じるか、すべてのウィンドウを閉じる必要がある。


また、ファイル管理が高度・高速になり、プログラム起動のコストが下がった。


こうなると、「ダブルクリックで閉じる」は面倒くさい操作だ。

これが、従来互換の「ダブルクリックで閉じる」も残したまま、新たな「閉じる」ボタンを増設した理由だと思われる。




NeXTstep …知っている人は少ないか。


Jobs が Apple をやめた後、新たに興した会社で作ったコンピューターの OS 。

一応、現在の MacOS X の元になっている。


この UI では、「右に閉じるボタン」になっている。


対抗して逆にしたのだろう、というのであれば、Windows よりも、NeXTstep の方が「対抗した」のだろう。

Jobs は、自分を追い出した Apple 社を見返してやろうという意気込みでこの OS を作ったのだし。


ちなみに、左端にもボタンが表示されるが、この内容・個数は状況によって変化する。

(windows や Mac でも、実のところ「3つボタン」の内容は状況で変化する。それと同じことだ)



Motif … UNIX 上で最初期に「統一された GUI デザイン」をやろうとしたツールキット。


Microsoft と IBM も協議に参加しており、かなり意見を出したようだ。

結果的に、Motif と Windows 3.0 と IBM の OS/2 は、似たインターフェイスを持っている。


IBM は UNIX も PC もやっていたし、その両方で使い勝手を統一したかったろうから、似ているのは必然。




最後の方は余談なのだけど、歴史を見ると、Mac も Windows も、「左上に閉じるボタン、右上に拡大ボタン」という、共通の GUI から始めている。


その後、それぞれの事情によりボタンが増えるが、基本的に Windows が先行し、Mac が後追いする形でボタンが増えていく。


Windows が「閉じる」を右側に増設したのはその後だが、先に書いたように互換性のために左にも残してある。

すでに、そのアイコンで閉じられることを知っている人は少ないと思うけど。




その後、MacOS X の登場時に、Mac の GUI は大きく変わる。

この時に、右にあったボタンも全部左に寄せられ、Windows と逆、という印象になった。


…そう考えると、「Windows が対抗して逆」なのではなく、「Mac が対抗して Windows と逆にした」のだね。

(NeXTstep で Mac の逆にした Jobs だからね…)



まぁ、実際のところは対抗心などではなく、「左上に閉じるボタン」という、初代から続く UI を残したまま、右と左に分散していた「ウィンドウを操作するボタン」を集中させた結果なのだと思うけど。




翌日追記


急に気になって、Apple Lisa OS を調べてみた。


Lisa は Mac の元になった機械で、のちには Mac と同じ OS を搭載できるようになっていたが、当初はオリジナルの OS を搭載していた。



Lisa では、ウィンドウ左上にプログラムを意味するアイコンが表示されており、そこをクリックするとウィンドウを閉じた。

この点では、今も続く Windows の「左上のアイコンクリックで閉じる」は、Lisa 由来かもしれない。



Lisa は Mac と違いマルチタスクだったが、Window を閉じると同時に、プログラムも終了しているようだ。

(Youtube で見ただけなので詳細はわからないが…)


最大化に相当するボタンはない。最小化も当然ない。

タイトルバーに存在するボタンは、左上のアイコンだけで、これが「閉じる」ボタンを兼ねる。



Mac になった時に、アイコンはなくなって、ただの四角い枠で「閉じる」を意味するボタンになったのだけど、これは Lisa に比べて、Mac は非常にメモリが少なかった、ということと関係するように思う。


そして、やはり最初は「閉じる」ボタンしかない。


「拡大」ボタンがついたのは System 3 からのようだが、System 2 以前の資料が少なすぎて確定できていない。




なんか、調べるほど Windows は「対抗して逆にした」どころか、Lisa / Mac の GUI の正当な後継のように思えてきた…




▲目次へ ⇒この記事のURL

別年同日の日記

02年 ピーナッツバター

11年 ポケモンな1日

12年 怒涛の1週間

12年 13~15日

12年 結婚10周年

12年 オムツはずれ

13年 追悼・富田倫生

14年 長男誕生日

15年 靖国神社参拝


申し訳ありませんが、現在意見投稿をできない状態にしています

リングフィットアドベンチャー  2020-07-27 15:32:16  コンピュータ 家族

▲目次へ ⇒この記事のURL

やっと入手できたので遊び始めた。

いま、1週間ほどやったところ。


先週末の4連休はどこにも出かけられなかったが、このゲームで家族中楽しめていた。





任天堂 Switch 向けのリングフィットアドベンチャーは、昨年の秋発売。


発売前は「色物なので様子見」と思っていた人が多いようだし、僕もそうだった。

しかし、発売直後から「面白い」と話題になり、入手困難に。


時々入荷の話題を聞いてはネットのショッピングサイトを探し、すでに売り切れている、という事実を確認する。


2度ほど、なんとなく覗いた Amazon で在庫を確認し、慌てて購入手続きをとるも「在庫なし」となっていた。

手続している数秒の差で売り切れてしまうのだ。それほどの人気商品。



で、年明けごろから中国でコロナウィルスの感染拡大があり、生産自体が止まってしまった。

4月ごろから再びわずかではあるが入荷するようになったが、多くは抽選販売。


抽選に応募し続け、やっと当たった次第。




ゲームについてはいろいろなところで話題になっているので、多くを書く必要はないだろう。


実際に筋トレなどにも使用される、弾力性の高いリングがコントローラーになっており、これを使ってゲームが進む。


Switch の Joy-con は左右1対あるが、左は太ももに括り付け、足の角度を測る。

「走る」とか「スクワット」とかは、足の角度を計測して行うわけだ。


右はリングに接続し、リングのたわみ具合を測るようになっている。

ここ、不思議なのだが、コントローラーに外部との接続端子があるのだろうか?



Wii リモコンでは、「ヌンチャク」をはじめとする外部機器を接続できるようになっていた。

だから、Joy-con でも外部機器が接続できても不思議はない。


そもそも、Bluetooth 機器としてのペアリングも「本体に装着」すれば完了するようになっているので、外部との連絡端子は何かしら持っているはずだ。




で、右 Joy-con は、たわみ具合を計測して送信するだけでなく、傾きなどのセンシングも当然行う。

だから、リングをどのような向きで持っているか、など計測できる。


これで、非常に多彩な動作をセンシングできるようになっている。



一番面白いと思ったのは(そして、あまりゲームレビューなどで見かけないのが)、Joy-con 右で脈拍を計測できること。



Joy-con 右には、もともと赤外線カメラがついている。

これを指に密着させることで、脈拍を測るのだ。


内部でどのように取れているのかはわからない。

おそらく、カメラに近すぎてピントはあっていないのだろう。


でも、赤外線なので、おそらくは血管が写る。

脈動に合わせて面積が広がったり縮んだりするので、それを「うまく」計測すれば、脈拍がわかる。



任天堂って、脈拍測るの好きだよね…


(N64 では「バイオセンサー」の名前で発売されたが、対応ソフトはテトリス64のみ。

 Wii では「バイタリティセンサー」として発表されたが、発売されなかった)



今回は、特別な外部機器なしに標準機能を工夫して測った、というところで感心した。




ゲーム自体は、一本道の RPG だと思ってもらっていい。


お話があって、道を進んでいくと(実際に足を動かし、走る必要がある)、敵と遭遇したりして戦いになる。


戦う方法は筋肉のトレーニング。


画面に指示されるとおりに行う。

左ももの角度と、リングコントローラーの組み合わせだけで、いろいろな筋トレをセンシングし、まじめにやっていれば相手に大きなダメージを与えられる。


(決して力が問題ではなく、まじめにやっていればいい)



この攻撃方法も、ちゃんと RPG らしく、旅の途中で「強い攻撃」を手に入れられる。

1体だけに強い攻撃、とか、弱めだけど3体同時攻撃、とか。

敵との「相性」で攻撃力が上がったりもある。


そういうことを考慮し、自分で選んで、指示通りに筋トレすれば攻撃できるわけだ。

適度に考えて、適度に体を動かして、狙い通りに敵を倒せれば楽しいし、あと少し攻撃力が足りなくて倒せないと悔しい。



で、自分の攻撃が終わると、敵の攻撃のターンだ。


これは基本的に、腹筋でガードする。攻撃のように選んだりはできない。

リングを両手で腹に押し当て、大きくたわませれば強いガードになるのだけど、しっかり腹筋を固くしていないとたわまないのだ。




トレーニングの負荷量は自分で選べるし、毎日「前回の運動はきつかったか」など聞かれ、調整される。

最初は軽い感じから…と始めたが、それでも3日目には軽い筋肉痛になった。


というのも、普段使っていないような筋肉も使うから。

で、3日目の筋肉痛を超えたら、同じ負荷では物足りなくなったので、少し負荷を上げた。


以降、筋肉痛にはなっていない。

それなりの運動量だとは思うし、毎日30分程度ゲームをやると「もう今日はここまでにしとこう」と思うくらい疲れる。

(ちょうど、それくらいでゲームから「今日はここまでにしませんか?」と聞かれる)



疲れるのだけど、辛くはない。

筋トレって、普通は「自分の筋肉を鍛える」ことを目標にやるのだと思うけど、すぐに目に見えるほどの効果が出るわけではないので、挫折しやすい。


そこを、「先のストーリーが気になる」という別の目的に変えて、楽しみながらトレーニングできるようにしてある。




移動中、リングを「押し込む」と空気を吐き出して空気砲で周囲のものを攻撃できる。

逆に「引っ張る」と、空気を吸い込んで、周辺のアイテムを取得できる。


道端に箱があれば、空気砲で壊してアイテムを入手できる。

でも、アイテムが直接落ちていれば、吸い込まないといけない。


さらに、下に向けて空気砲を出すと、ジャンプできる。

押し続けていればホバリングも可能だ。


そして、一番大切なこと。

速く走るとトレーニング効果が高い。

これは、ゲーム中では早く「レベルアップ」して、強くなることを意味する。



結果、早く走って目まぐるしく変わる景色の中で、周囲のアイテムを見極めて、リングを押したり引いたり、結構忙しいゲームなのだ。


敵との遭遇時などは、筋トレの体制が整うまでいくらでも待ってくれる。

でも、移動中は、単純だけど忙しいアクションゲーム。


ここら辺のバランスもうまくできていて、適度に楽しみつつ、適度に悔しがりつつ遊ぶことができる。




元々僕は運動嫌いなのだけど、独立して自宅で仕事を始めたころから、「体が資本」だと考えるようになりました。

健康に気を使って、時々走ったりしています。


と言っても、やっぱりめげるんだよね…もともと好きではないから。

夏の暑さに負け、冬の寒さに負け、走るのは春秋のわずかな期間だけ。


「こんなんじゃいかんよなぁ」と思って、家事をしながら中腰で足腰を鍛えたり、本を読みながら上半身を傾けて腹筋を鍛えていたりすることもあるのだけど、それだって毎日ではない。



運動嫌いとはいえ、やってないわけではないので、「急にやると辛いだけ」というのは知っています。

だから、負荷は軽めにして、毎日楽しむことを優先している。


リングフィットも、入手したけど筋肉痛で挫折した…というような話も聞きます。

筋トレに慣れていない人が「身体鍛えるぞ!」って頑張りすぎると、そうなりそうだと思う。



僕もまだ1週間で、最後まではやっていません。

途中で挫折しないように頑張りたいと思います。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

別年同日の日記

02年 誕生日!

11年 節電その後

12年 続・理系と工学系

14年 NTSC PAL SECAM


申し訳ありませんが、現在意見投稿をできない状態にしています

phpSpreadsheet で小数点付き数値と見なせる文字列を入力するとおかしくなる  2020-07-17 18:28:24  コンピュータ

▲目次へ ⇒この記事のURL

また、えらく重箱の隅つつきな話です。

バグとして報告したいところだけど、やり方わからないからとりあえず書き留めとく。




現在行っている仕事で、「データをExcel出力」している個所がある。

まぁ、よく見るね、こういうの。


サービスの主要部分は node.js で作成している。

サーバー側で javascript を動かす仕組みだ。


でも、Excel 出力する部分は、PHP でやっている。

node に良いライブラリがなく、phpSpreadsheet というライブラリが良い、と担当者が判断したためだ。


(少なくとも、xlsx と xls の両方出力でき、細かく装飾されたシートを出力できる必要があった。

 ただこれだけの条件で、できるライブラリは非常に限られている)


担当者が、と書いた通り、僕はこの部分の担当ではなかった。

でも、バグが報告され、その時担当者が忙しかったために、僕が原因を調べることになった。




具体的には、「文字列」として入力された、小数点を伴う数字を複数 Excel のセルに含めようとしたところ、

正しい値が入らずにぐちゃぐちゃになった。


最初は何が起きているかわからず、いろいろなデータを入れて試したところ、次のようなことが分かった。


・小数点を伴う数値と見なせる文字列を複数のセルに記載した場合、同じ整数部を持つ、先に入れたセルの内容が、後のセルの内容にコピーされる。


何を言っているのかわからないだろうから、実例。


0.1 / 1.1 / 0.2 / 1.2


という4つの数値があったとしよう。これは以下のようになる。


0.1 / 1.1 / 0.1 / 1.1


「同じ整数部を持つ、先に入れた内容が、後のセルにコピーされる」というのは、こういうことだ。


整数部が同じであれば全部同じ内容になってしまう。


数値としてみなせない文字列であれば、このような問題はない。

また、小数点を含まなければ問題はない。


数字だけの文字列でも


0120


のようなものも問題はない。




phpSpreadsheet は非常に高機能なライブラリだが、遅くてメモリ食いだ。

というのも、このライブラリは、「エクセルの読み書き」だけでなく、本当にスプレッドシートの中身を実現しようとしているため。


で、遅さをカバーするためにも、データはまとめて入れることが推奨されている。


fromArray というメソッドでデータをまとめて入れられる。

applyFromArray というメソッドで、セルの装飾データなどをまとめて与えられる。




そして、fromArray は高機能で、入れようとしたデータを自動的に識別し、正しく扱ってくれる。


= で始まるデータは、数式だ。セルの式をセットしてくれる。

数値として扱えるものは数値として入れてくれるし、そうでなければ文字列にしてくれる。


…ここで、文字列を与えたとしても、数値として扱えるものは数値になってしまう。


数値は、Excel 上「右寄せ」で表示される。文字列なら「左寄せ」だ。

文字列として入れたのに、右寄せになると格好が悪い。


そのため、担当者が作ったプログラムでは、データを入れた後で、セルに入っている値のデータを明示していた。

数値として入ったものであっても、「文字列」と指示すれば、文字列になってくれるようで、左寄せになる。



これは、Excel でいう「セルの書式設定」とは違うものだ。


セルの書式設定にも「文字列」とか「数値」があるのだけど、それはセル内部のデータを「書式設定のデータに変換して」表示する、という設定。


データの型を指定する、というのは、表示時に変換するのではなく、セルの中の値の型を指定するものだ。

そう、エクセルの値には型がある。恥ずかしながら、僕は今回の調査までそれを知らなかった。



phpSpreadsheet では、セルに入れたデータは、php としてのデータ型がある。

そして、それとは別に、セルの中の値の型を保持するようになっていた。


fromArray で入れた場合は、自動判別され、数値型であれば、php のデータとしても数値に変換され、セルの値の型も数値になった。

しかし、この後で「文字列型」と指定すると、php データは数値のまま、セルの値の型は文字列になった。




そして、出力の段階に至る。


これも知らなかったのだが、xlsx ファイルでは、セルの情報と、「文字列」情報は別に保持されている。

セルに文字列を入れる場合は、文字列へのポインタ(参照番号)が入る形、だそうだ。


これにより、同じ文字列が大量に入るような Excel ファイルは…非常に一般的だと思うが、データが圧縮されることになる。


ライブラリはセルの値の型が文字列型だった場合に、配列として対応表を作っている。

「文字列」に対して、「参照番号」を調べられる対応表で、出力時にこれを使って、同じ文字列には同じ参照番号を出力するのだ。


この時、「文字列」に対して、というのは、セルの値の型のことだ。

でも、実際の php のデータは、文字列とは限らない。


そこで、ライブラリのプログラムでは、「実際の php データが文字列か否か」で処理を分けている。

文字列の場合、ハッシュ関数を通して一意な数値を得て、それを引数として配列にアクセスする。

文字列ではない場合は数値なので、そのまま配列にアクセスする。



…ここにバグがある。

文字列ではない場合、数値ではあるが、整数とは限らない。

小数点を含む場合、php によって小数部分が切り捨てられ、整数化されたアクセスになってしまう。


結果として、小数点以下を含む値を文字列として扱おうとすると、同じ整数部を持つ値のコピーになってしまう。




回避方法。

fromArray でまとめて値をセットするのをやめればよい。


fromArray の中身は、setValue という関数を使い、ループで書き込んでいる。

この setValue は、入れられるデータを検査し、文字列であっても数値と見なせる場合は数値に変換する、などの高度な処理を行う。


これに対し、setValueExplicit を使うと、データを入れる際にそのセルの値の型を一緒に指定できる。

勝手な変換も行われない。


今回は、fromArray でデータを入れやすいように、データだけを配列としてあらかじめまとめてあった。

セルの値の型の指定は、後で行えるように別にまとめてあった。


なので、先にセルの値の型を指定してしまう。

セルに値が入っていなくても、型だけ指定できる。


その後で、自分で2重ループを作ってデータを入れる。


まず、セルの値の型を確認する。(getDataType でとれる)

型を指定していない場合は、文字列の "null" が返るので、この場合は setValue でデータを入れる。

null 以外が返っている場合は、データ型の指定があるので、setValueExplicit で型を指定してデータを入れる。


これで、勝手な型の変換はなくなり、想定していた型で入ることになる。

文字列型が指定されているのに内部が数値、などということもなくなり、おかしな挙動に悩まされなくなる。




phpSpreadsheet 、すごく動作が遅いし、ここに書いたような複雑怪奇な動作によるバグもある。

もっといいライブラリがあれば乗り換えるのだろうけど、


・xlsx 、xls の両方を出力できる。

・細かな装飾も行える

・計算式も含む、複雑な表を作れる。


などを満足するライブラリがなかなかないんだよね…


(PHP に限る必要はない。

 go の excelize はかなり良い線行ってそうなので少し試してみたのだけど、「既定のフォント」指定はできるのに、「既定のフォントサイズ」が指定できない、というかなり基本的な部分でダメだったよ…)




▲目次へ ⇒この記事のURL

別年同日の日記

02年 冷蔵庫に乾杯

14年 続・世界初のMML

15年 NECの創業日(1899)

15年 エジホン探偵事務所


申し訳ありませんが、現在意見投稿をできない状態にしています

ENIAC vs 6502  2020-06-19 18:54:40  コンピュータ

▲目次へ ⇒この記事のURL

つい先日、Twitter で「ENIAC はマイコンでどの程度か」とつぶやいている人がいた。


なるほど。ENIAC の性能というのは時々話題になるのだけど、僕も詳細に性能比較をしたことは無かった。

概念から違いすぎて比較は無理、という気もするが、遊び程度にやってみるのも面白そうだ。



▼前提知識


概念から違う、と書いたのだけど、ENIAC の計算方式について、ざっくりと前知識。

まず、ENIAC は最初のコンピューターとされることが多いのだけど、現代のコンピューターとは計算方法が全然違う。


2進数か 10進数か、という違うもあるのだけど、それ以上の違いがある。

ENIAC は「どんな複雑な計算式でも、微分を繰り返すと足し算になる」ということを利用して、方程式をひたすら数値計算で解くためのシステムだ。


古くは、チャールズ・バベジの階差機関・解析機関が同様のアイディアを持っていた。

ただし、実現できていない。


ENIAC 以前には、歯車とモーターで実現したハーバード・マーク1があった。


ENIAC は、計算のアイディアとしては全く同じままだが、物理部品を無くして電気化することで、超高速の演算を実現しようとした。



▼ENIAC の計算能力


歯車を模倣しているので、2進数ではない。

10進数 10桁の加算機が電気回路で表現されていて、この装置が 20台ある。


1台の加算機は、毎秒 5000回の加算ができる。

これが 20台並列動作するので、ENIAC 全体としては、1秒間に最大 100000回(10万回)の加算ができる。



▼比較対象の選定


というわけで、現代のマイコン代表。

3つの理由があり、ファミコンを比較対象としたい。


もっと細かく書くと、ファミコンの CPU である 6502 が比較対象だ。


メモリ搭載量や動作周波数はファミコンに倣う。

しかし、主に計算能力の比較とし、ファミコン全体の性能を見るつもりはない。



ファミコンを選ぶ理由の1つ目は、有名でありながら、十分に低性能だからだ。

そもそも ENIAC が「世界初」のコンピューターであり、性能を期待できない。

現代の CPU と比べたら、差が大きすぎて面白くもなんともない。


ファミコンはもう40年前の機械だけど、知名度はいまだにある。

知らないはずの世代でも、Switch のエミュレータを見たことくらいはあるだろう。



もう一つの理由だが、僕個人の記憶で、確かファミコン現役当時のベーマガ(当時人気のあったパソコン雑誌)に、「ENIAC はファミコン程度の能力しかなかった」と書かれていた気がするのだ。


記憶にすぎず、ベーマガではなく別の雑誌だったかもしれない。

でも、「ENIAC はファミコン程度」という言葉を知っている人はいるようで、Yahoo知恵袋でもそういう質問があった


「ファミコンの方が圧倒的に高性能」という答えがベストアンサーになっていたのだけど、圧倒的というほどなのか調べたい気持ちもある。



3つ目、最後の理由だ。

冒頭で書いた Twitter でつぶやいていた人は、僕の書いたページ「Z80 vs 6502」の URL をツイートしてくれていたのだ。

だから、エゴサーチで見つけたのだけど。


該当ページは、MSX の CPU としての Z80 と、ファミコンの CPU としての 6502 の速度比較を行ったものだった。


じゃぁ、その 6502 と、ENIAC を比較してみようじゃないか。



▼ファミコンの計算能力


6502 CPU は、8bit 計算しかできない。

しかも、同時並列の計算能力もない。ENIAC に比べると、ずっと低性能だ。


しかし、ENIAC と違い、柔軟なプログラム能力がある。

プログラム能力の違いは後で詳細を書くが、計算は「1回に」 8bit しかできないが、繰り返すことで、もっと大きな数値を扱うことも可能だ。


さて、ENIAC の 10進10桁の記憶能力は、2進数だと 34bit 相当になる。

しかし、8bit を単位とする現代の CPU では、ちょっと中途半端な数値だ。


ここは、少し足りないが 32bit で計算させてもらうことにしよう。

(これだと、10進数にして9桁が計算の限界となる)



6502 では、先に書いたように1度の計算は 8bit しかできない。

もっと大きな bit 長の計算をしたい場合は、メモリに置いた数値同士を足すことになる。


そこで、メモリ同士の足し算を示めそう。


LDA >1 ; 3

ADC >0 ; 3

STA >0 ; 3


なんのことやらわからないかもしれないが、これが「1番地の数値を、0番値に足す」というプログラムだ。

; の後ろに書いてあるのは、必要な時間だ。単位は「クロック」。足し算には 9クロック必要と分かる。


これで 8bit の計算が終わるが、値を保持するメモリ番地を変えながら単純に4回繰り返せば、32bit 分の計算になる。


というのも、6502 の足し算は「前の足し算の繰上りも足す」ようになっているからだ。

繰り返し計算をしたことで、ひっ算のように「上の桁」を計算していったことになる。


ここまでで、36クロック。


しかし、ちょっと待って欲しい。

繰上りを一緒に足している、ということは、一番最初の計算はおかしなことにならないか?


そこで、最初に「繰上りを消す」という前処理を入れないといけない。


CLC ; 2


これだけでいい。

合計 38クロックで、32bit の足し算が終わる。

これが、6502 の計算能力だ。


では、これは実際どの程度の速度なのだろう?


ファミコンの場合、1.79MHz のクロックが使われている。

これは、1秒間が 1790000クロックだ、という意味だ。


38クロックで割ると、47105 という数が出てくる。

これが、ファミコンで1秒間に行える、32bit 足し算の回数だ。


▼計算速度比較


ENIAC は1秒間に 10万回の10進数10桁加算が行えた。

一方、ファミコンは1秒間に 4万 7千回ほどの 32bit 加算が行える。


計算できる桁数はほぼ同等と見なして、ファミコンは ENIAC の半分程度の性能だ。



まぁ、実際にはどちらもピーク性能を出すことは難しかったと思うが、並列演算を使いこなす方が、順次演算を使いこなすより難しい。


この点で、「実効性能」で見たときは、ファミコンと ENIAC は同等、というのはそれほど間違っていないように思う。



▼メモリ搭載量


現代的には、プログラムはメモリに格納するし、処理対象のデータもメモリに格納する。

処理後の結果も一時的にメモリに置いておき、後でまとめて示したりする。


とにかく、メモリはコンピューターに不可欠の存在となっている。



しかし、ENIAC の時代は違う。


ENIAC は数式の「計算方法」をプログラムできる。

このプログラムとは、加算機の保持するデータを、別の加算機に加算する…というのを、配線で示すのだ。

つまり、プログラムにメモリは必要ない。


数式に入れる初期データは、パンチカードの束で示される。

結果は直接印字されるか、一旦パンチカードの束として出力され、カード集計機でソートなどの処理を行ってから、別の機械で印字された。


つまり、データを保持するためのメモリは必要ない。

または、パンチカードという「外部メモリ」を、必要に応じていくらでも使用できる。




ENIAC の持つメモリとしては、まず加算装置だろう。

先に書いた通り、10進数 10桁 20本。


今回は、32bit (4byte) ということにしているので、全部で 80byte 。

これが書き換え可能な全メモリだ。



ところで、ENIAC は先に書いたように、数式の微分を繰り返すと、足し算に分解される性質を利用して計算を行う。

しかし、三角関数などは、微分しても足し算にならない。


そこで、これらは「数表」を使って処理する。関数の結果表を用意して、その数値を使うのだ。


このための「数表装置」は 10進数 6桁 の数値を、204本設定できた。

この装置は 3台あった。


10進数 6桁は、20bit で表現できる。ここでは、24bit (3byte) としておこう。

すると、1台の数表装置は、 3*204 = 612byte のメモリ、ということになる。

3台で 1836byteだ。


これは、現代的には ROM に相当する。




一方、ファミコンは 2048byte の RAM を搭載している。


6502 の特性上、256byte は計算時に使用する特別なメモリだ。

計算時に使用する、ということで、ENIAC の加算機の容量に相当するもの、と思ってもよい。


また別の 256byte は、スタックという、これも特別なメモリとして予約される。


自由に使ってよいのは、残る 1536byte だ。


さらに、プログラムなどは最大 32Kbyte の ROM に格納された。

固定データも ROM に入れることができる。




先に書いた通り、ENIAC の時代にはメモリは「必要とされなかった」。

だから、メモリ量の大小は、比較の優劣とはならない。


それでも「ファミコンの方がメモリがあった」と思う人はいるかもしれない。

しかし、ENIAC はデータ入出力にパンチカードが使えたことを忘れてはならない。


これは読み書き自由な記憶装置で、必要であれば無制限に使えた。

水爆の設計計算の際には、100万枚のカードが使用されたそうだ。


データ処理能力、という点で見れば、ENIAC は高い能力を持っていた。



▼プログラム能力


何度も書くが、ENIAC はひたすら加算を繰り返すことで、目的の値を得るためのシステムだ。

だから、プログラムというのは「どのデータを、どのデータと足すか」をひたすら示すことになる。


先に書いた通り、ENIAC は配線によってプログラムを行う。

あくまでも「どこを足し合わせるか」など、結び合わせたい対象を、配線で結ぶだけだ。


配線でプログラムした、という話を、ENIAC を分解して論理回路を組みなおしたようにとらえている人もいるようだが、そんなに複雑ではない。


加算をひたすら繰り返す、というのが ENIAC の基本なので、「繰り返し」は当然だった。


プログラムは複数作ることができて、計算結果を条件にして、どのプログラムを使用するか選ぶこともできた。


例えば、弾道計算では、風速や空気抵抗なども考慮しながら弾の高度・距離を計算していき、高度が「マイナスになったら」という条件で、その時の距離の数値を印字する、などの動作ができる。


さらに、印字後には次の初期条件をパンチカードの束から読み込み、再び計算開始…


などとしておけば、用意した初期条件の計算をひたすら繰り返し、結果を印字し、弾道計算表を作り出すことができた。



しかし、ENIAC のプログラムは、その程度だ。

基本的に、1つの数式に基づいた計算を、条件を変えながらひたすら繰り返す機械だ。


ENIAC は「高速計算機」であり、現代的な意味でのコンピューターではない。




ファミコンは、現代的なコンピューターだ。

多くの説明はいらないだろう。ファミコンのプログラムは、現代の多くの人が考えるプログラムと同じだ。


数値計算だけでなく、複雑な条件による「処理」ができる。

マリオがノコノコを踏んだら、甲羅が滑っていく…というのは、数式1本の処理ではないが、ファミコンなら難なく処理できる。


コンピューターを、なんでも処理できる機械としてとらえるなら、明らかにファミコンの方が能力が高い。



もっとも、これは後出しジャンケンだ。

ENIAC は高速な計算機として作られているので、「計算以外できない」のは当たり前だ。



▼まとめ


以上、ファミコンの 6502 と ENIAC を、無理やり比較してみた。


計算能力、メモリ搭載量、プログラム能力の3つの指標で比較しているが、当然のことながら、計算能力以外は比較することすらできない。


そして、計算能力だけでいうと、ENIAC の方が倍くらいの性能があった。



実は、比較前はファミコンの方が能力が上だと思っていた。

比較して10倍の性能差がなければ「同等」と認めた記事にしようと思っていたのだ。


でも、調べたら ENIAC の方が倍くらい高速だった。

だから「それ以外」の比較もしたのだけど、こちらは概念が違いすぎ、比較することができなかった。


とはいえ、一長一短あるので、能力として「ファミコン程度」というのは妥当な表現のように思う。



知恵袋で「ファミコンの方が圧倒的に高性能」と書いた人は、何を根拠に書いたのかわからない。

まぁ、以前も書いたのだが、あのような Q&Aサイトは信用してはならないものだと思っている。



なお、僕は ENIAC を現代的な意味での「コンピューター」としては認めない立場だ。


あくまでも「現代的な意味での」ね。

その違いが分かっていれば、世界初のコンピューターと呼んだってかまわない。


▲目次へ ⇒この記事のURL

関連ページ

ENIAC

微分積分いい気分【日記 21/01/29】

Programming Tips

別年同日の日記

04年 お父さんのための出産教室

06年 夏至祭

08年 ルータ変更

13年 報告書の書き方

14年 ブレーズ・パスカルの誕生日

15年 トーマス・J・ワトソンの命日(1956)

15年 パンク

19年 飲み会二つ


申し訳ありませんが、現在意見投稿をできない状態にしています

Chromebook を買ったのだけど  2020-05-21 10:57:05  コンピュータ

▲目次へ ⇒この記事のURL

4年前に購入したChromebookが、壊れかけている。


キーボード手前に配置されているタッチパッドのスイッチ部分がおかしく、接触しっぱなしになってしまうのだ。

マウスでいえば、左ボタンを押しっぱなしにした状態。


で、外付けマウスをつけていても、左ボタン押しっぱなしと判断されてしまうため、左クリックできない。

タッチパッドのスイッチのあたりをガチャガチャやると治るのだけど、また不意におかしくなったりする。



昨日も書いたが、子供たちの学校がネット授業も開始する予定だ。

現在、親の古いマシンも含め、子供たち一人に1台のPCはあるのだけど、1台はこの Chromebook なのだ。




ちょっと問題あるよなぁ、と、買い替えを検討したのはもう1か月ほど前。

しかし、このご時世で手ごろな値段の PC は軒並み売り切れだった。

Chromebook もご多分に漏れず。



それが、学校から「近々ネットでの授業を開始する」という連絡が来たので、再度調べたのが先週末。

性能的に申し分なく、値段も2万5千円ほどという悪くないマシンが Amazon にあったので、購入した。


しかし、僕の確認不足だったのだ。



今週前半に届いたマシンは、US キーボードだった。

見直したら、ちゃんとそう書いてあった。


うーん、残念だけど、返品。

手続きはして、まだ送付していない段階。


他にいいマシンはないか調べたけど、手ごろな値段のマシンは軒並み売り切れで、今入手できるのは高価なマシンになってしまう。



仕方がないので、もう少し待つか…



▲目次へ ⇒この記事のURL

関連ページ

Lenovo Ideapad C340 購入【日記 20/08/22】

別年同日の日記

03年 楽園を求めて…

05年 お掃除ロボ

12年 姪の結婚式

15年 68000はグラフィックに強かったのか

18年 フェスとフェスタと祭りと開放日

19年 あーすフェスタ


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

16000

-- follow --




- Reverse Link -