  |
はてなキーワード: 演算とは
昔、そこそこ仲の良かった男子が結構くだらない事でめちゃくちゃ叱られてグレてしまった
グレたと言っても、自習時間に机をドンドコしたり、補習をサボってバッセンに行く程度だったけど、まあうちの学校ではグレてる部類だった
彼はそのうち課題を出さなくなり、その事で他の先生にもしょっちゅう叱られるようになり、余計態度を硬化させる負のスパイラルに陥って
もともと下がっていた成績もガタ落ち、結局3浪して消息不明になった。f欄に行ったという噂も聞いたが、謎だ。
彼を叱った先生とついこの間お話しした際に、彼についての話も出たのだが、「怒りすぎちゃったなあ」と後悔していた。他にも彼の没落の原因はあったのだろうが、アレがキッカケになったのは確かだった
「宿題やったの！？」「今やろうと思ってたのに！」みたいなの、大人になってもずーっとあるよね。あんまり叱られすぎると反感や怒りが先行してしまって、なかなか自分を省みることが出来なくなる
叱られて伸びないタイプの人は、やんわりと諭してあげるのが一番良いのだと思うが、叱る側に立つと結構難しい
「叱る」とはどうあるべきなのだろう
鬼の生活指導に叱られて、不登校になってしまった女の子が中学時代いたが、彼女にとっての「叱られる」は、しょっちゅう叱られている剽軽な男子にとっての「叱られる」とは同じ叱られ具合でも全く違うものだったろう
クラスメイトの前で「ちゃんとやれよ！」と一言言う事だっておとなしく真面目な子と活発で不真面目な子とでは受け取り方が全く違う
前者の場合「先生にみんなの前で怒られた」という羞恥を引き起こす、精神的苦痛は絶大だ
本人のタイプに合わせて指導法をきめ細かく変えてやるのが一番人を伸ばす叱り方だと思うが、「人によって叱り方が違う」というのは集団に不公平感を生む
教室のような閉じた、それでいて壁のないオープンな集団の中で人によって態度を変えながら叱るのは難しい
そう考えると、何か悪いことをした子はそっと別室に連れて行き叱るのが適切なようにも思える
しかし、自分自身小学校のころよく知らない先生と二人きりの教室で隣に座って密着されながら委員会資料の作成をさせられたのは軽くトラウマなのでそれはそれで問題があるように思う
一対一での指導、は多分ロリコン教師を欲情させるシュチュエーションになってしまうし、閉鎖的な空間で上下関係が残るのも監獄実験のような状態になって「叱りすぎ」を誘発しそうだ
職員室で叱るという手もあるが、他の先生の前で叱られるというのも精神的な負荷が大きいだろう(忘れ物が酷くて何度やられたことか)
保健室で「厳しい担任の先生」と話をそばで聞くだけの「優しい保健室の先生」という二対一のお説教が思いつく限り一番良いように思う
仕事量を考えると養護教諭ではなく、昼休みだけ来る外部カウンセラー数人で回すのが風通しが良く現実的な形になるだろう
これが家庭の場合「厳しいお母さん」と「優しいお父さん」のような役回りでの叱り方になるのだろう
しかし、甘やかすだけ甘やかす父(母)に子供がなつき、損な役回りをさせられる母(父)の言う事を子供がきかなくなる、というようなケースも聞くので、適宜「厳しい」と「優しい」は交換しながらやっていく必要がある筈だ
「叱る」一つの手前でも、どちらがどちらの役割をするのか話し合う必要があるのはやや面倒だが、子供の糧になる「叱る」のためにはそのぐらいの手間は必要ではないだろうか
職場で叱るケースでも、教育係を一人に一任せず「直属の厳しい教育係」と「見守る優しい先輩」というロールで叱ってみるのも一つの手なのではないだろうか
我々は普段から「叱る」と「怒る」を混同し、ただ感情を発露させるだけの行為を目下の相手にしてしまう事が多いが、効率的に人を成長させるためには「叱る戦略」をきちんと考えて叱るべきだ
個人的に、教育現場における「叱る＝怒鳴る」は論外である。怒鳴る事によって相手を萎縮させ、内省させる間も与えない行動が反省を促すとは到底思えない。
生徒、部下の立場は怒鳴られても怒鳴り返すことの出来ない立場である。おずおずと返答をしても「言い訳をするな」と一蹴される恐れがある。怒鳴る行動は対話の機会を奪うのだ。
勿論、いじめや命を落としかねない悪ふざけには少なからず「怒鳴る」のコマンドが必要かもしれない。事の重大さに気づかずヘラヘラと対話による説教を聞き流すような生徒もいる。なぜ「怒鳴る」が必要になるのだろうか。この場合「怒鳴る」はどのような効果を発揮しているのだろうか。
主観的かつブラッシュアップの足りない考えではあるが、一つの仮説がある。「怒鳴るとは上下関係をわからせる手段ではないか」という仮説だ。そもそも、動物としての観点で見ると大声とは威嚇の手段の一つである。動物のように大声を上げることで、相手を威嚇し、上下関係を再確認させるのだ。プラスして、感情をあえて大袈裟に表現することで「自分は真剣だ」と伝える意味もあるだろう。(しかし演者時点が自身の演技に呑まれる可能性はかの有名な監獄実験で示されている通りであるので、十分な精神力と慎重さが求められるだろう)
社会性動物である我々は猿山の猿のように、狼の群れのように序列に弱い。だから不真面目な相手を前にした場合、この「怒鳴る」という行為はある程度有効なのだろう。怒鳴るは相手の「話を聞く真剣さ」を+5するというようなコマンドなのかもしれない。
人間の感情は複雑なように見えて案外単純だ。悲しい時に怒る、傷ついた時に傷つける、というような行動も一見ブラックボックスを抜け出たものに見えるが、案外類型的なものである。それはピンボールの玉がピンに当たって跳ね返りながら、最終的にはいくつかの穴に収束していくのに似ている。無限の可能性を持ちながらも、個々のピンでの跳ね返り方はある程度の予測がつく。我々の行動自体が、大したパターンを持たないからこそ、我々は相手の気持ちを思いやり、共感できるのだ。
「宿題やったの！？」という言葉が子供時代の私たちにもたらしてきた感情は「後ろめたさ」「反省」「反感」である。この感情のパターンが類型的だからこそ、私たちに「先に言われるとやる気なくすよね〜」という共感をもてる。
というように、人間の感情がある程度パターンとして把握できる以上「叱る」のマニュアル化は可能ではないだろうか。
「優しく諭す」というコマンドは相手の「真剣さ」には効果が薄いかわりに「反感」の数値はあまりあげない。だが「真剣さ」の数値が低いと「反省」には至れない。
「怒鳴る」というコマンドは逆に「真剣さ」には絶大な効果を持つ、が、「反感」のポイントを高めてしまう。「反感」の数値が一定を超すと「反省」への道は閉ざされる。
前述の優しい医者と怖い医者戦略も、数値化で説明してみよう。怖い医者は「真剣さ」「内省を促す」方面に強いキャラクターであり、優しい医者は「反感」という感情に共感し、怒りを和らげ「落ち着き」を取り戻させるヒーラーのような役割のキャラクターである。
「叱る方と叱られる方」という絶対的な上下関係に、そのどちらでもない第三者を加える事で、叱り手の感情の暴走を抑えるとともに、第三者による「共感」で叱られる側の精神的負担を減らし、自分を省みる余裕を与える。
無論、感情の数値の動き方には個人差があるので、叱り手は自分のコマンドが相手にどんな影響をどの程度与えるのかを考えながら叱り具合を調節していく必要がある。 と言っても、その個人差もある程度はパターンに当てはまるように思う。不真面目だが誠実な子、真面目だが反抗的な子、結局は要素の集合体である。実際に「元気な子(そして剽軽で悪戯っ子)」「明るい子(そして優しくてポジティブな子)」「大人しい子(繊細で真面目な子)」という安易なパターン化はあらゆる人間関係において常に行われている※。タイプに応じてコマンド駆使の仕方のマニュアルがあれば、どんなボンクラでも効果的な「叱る」ができるだろう。
※これには幾らか問題がある。私のように「大人しい子(割合図太く不真面目で陰険な子)」という相反するイメージの要素を持つ人間は取りこぼされる。そして不理解な大人に失望し私は余計陰険になった。教室のような大人数を把握すべき空間では、雑なラベリングが横行して、かえって正確な人格の把握の障害となるかもしれない。ここにもいくつかの心理検査を用いた人格のパターン化による把握が必要かもしれない。
このように数値化して考える方法を主張すると必ず人の心が通っていない、愛がないという人が現れる、が、なんの考えもなしに相手の叱られた後の情動を予測せずに感情をぶちまける事の方がよっぽど動物的で、「人の脳味噌」という回路を通わない非効率不合理なくだらぬ行動だと私は思うのだが。
(だいたい愛の鞭なんて言うが、恐怖政治よりインセンティブによる動機付けの方が効果がある事なんかもう数十年前から言われているのだからいい加減卒業してほしい。)
叱る、は上手くいけばとてもポジティブな効果を発揮する。しかし下手にやればかえって人から反省の機会を奪う。説教や正論は気持ちが良すぎるので、叱り手側は容易に権力を振りかざす楽しさに呑まれてしまう。だから、叱る前に一呼吸置いて、叱る戦略を立ててみるのはどうだろう。戦略という言葉は大袈裟かもしれない。叱る前に叱られた相手の気持ちを考える、それだけの事だ。
人材育成、教育現場、家庭での指導法においては、「叱り方マニュアル」の作成も試みとして楽しそうだ。心理テストで振り分けられた生徒や人材ごとに診断チャートを作成し、それを参考に叱り方戦略を立てる。大規模に実験し調査結果を取り続ければ有効性を立証できるかもしれない。最終的にはAIが掛けるべき言葉を演算し、叱り手という演者がそれに従うようなディストピア教育が出来上がるかもしれない。AIの愛のない教育、は痛烈にこき下ろされそうだが、「データを集め、型に当てはめ、パターン化された指導をする」という一連の行動は学習行動として常日頃個々人が行なっている事であるし、そこに統計処理がより得意なAIを解すのはそれほど不自然でないように思う。
教育者には当たり外れが多すぎる。一生涯呪い殺したいようなクソもいれば、人生の節目のたびにあって感謝の意を述べたくなるような聖者もいる。マニュアルさえあればどんなクソにも一定ラインを超えた指導ができるようになる筈なのに……！と思うと悔しいばかりだ。しかし、こうなると今度は「マニュアル一辺倒の叱り方」という批判が生まれてくるだろうか。教師のマニュアル依存、なんてニュースが流れるようになるのも嫌な話である。優しい医者と怖い医者も何も知らずに信じ込めるとステキな装置ではあるが、そんなプログラムだと言われてしまうと薄っぺらさにがっかりしてしまう。マニュアル化した叱り方は叱られる側に不信感をもたらす逆効果となるかもしれない。うーん、難しい(そこまで進んだ未来だと生徒もプログラムが組まれたのをわかった上で乗れるほど慣れるかもしれない、AIカウンセリラーを利用したマインドセットが人生の基本になるのだ！←楽しそう)
まあ、今のところは感情的に怒る前に、相手の情動を予測しながら諭してあげるというのがいいと提案してみることにします。つまるところは思い遣り。プラスして、叱るときは座って目線を合わせるっていうのも提唱してみる。叱り手側も怒りをセーブしやすいし、叱られ側も対等な立場での対話であると感じやすい、と思うから。(座って足組んでる奴から立たされて叱られるのも、立った状態で目の合わない相手を見上げながら叱られるかもつまらないもの。)それと、誰かが厳しく叱られていたら、優しい第三者として「反感」や「落ち込み」に共感してあげたりね。まあ普通のことです。しかし実践はクソムズイ。人生手強いね！
(思い出話あるあるを書こうと思っていたのに、思いのほか筆が乗って長文増田になってしまった。noteにでも貼るべきだったかな、図解しながら書き直したくなってきた。ところで、25件を無限リロード中の増田様方には大変ご迷惑をおかけします、すまない。途中送信しちゃっただけなので再投稿の甘えではないんだよ！)
「それに現代のテクノロジーだったら、未来のボクじゃなくても解決できるだろう。そういうことに精通していて、かつキミの要求を快く受けてくれる人に心当たりはないのかい？」
そういえば一人いた。
いや、“一人”と言っていいかはビミョーだけど、俺的には一人の内だ
「ガイド、今回のは“貸し”だ。覚えとくから、そっちも覚えとけ」
「なに言ってんだ。お前が返す側だぞ」
「えー！？」
「さっき『悪いけど』って言って断っただろ。その分の貸しだよ」
「ザッツライト、その通りだ！ 悪いと思ってるのなら、別の形で報いるべきだ！ そうするべきだ！」
家主のシロクロにこう言われては、居候のガイドも反故には出来ない。
さて、こうしてはいられない。
俺は自分の家がある方角へ走り出した。
「はあっ……はっ」
我ながら、今日はよく走る日だ。
近い場所だからと、自転車を使わなかったのは結果的に失敗だった。
何はともあれ、俺は自分の家にたどり着いた。
そこに住んでいる、ムカイさんこそが俺の心当たり。
実はかなりの高性能ロボットなんだ。
父さんは「ロボットじゃなくてアンドロイドだ」って訂正したがるけど、正直どっちでもいいと思う。
「ぜえっ……ふう」
息を切らしながら、ムカイさん宅の玄関のドアを叩く。
気持ちが逸ってそうしたわけではなく、インターホンが壊れているからだ。
「チャイムに使われていたメロディに敵意を感じた」とかで、ムカイさんが壊してしまって、そのままだ。
「ごめんくださーい……ムカイさーん、いる－？」
そう呼びかけて数秒後、家の中からドタドタとした音が聞こえた。
そして、その音がどんどん近づいてくる。
「どうした小さきマスダ」
勢いよく開けられたドアは壁とぶつかり、大砲のような音を打ち出す。
もし外開きだったら、ふっとばされてたな、俺。
「さっきまで走ってただけさ」
「つまり、急ぎの用というわけか」
ついさっきまで、俺にムカイさんを頼るって発想がなかったのは、この豪快な言動が原因だ。
でも、よくよく考えてみればムカイさん自身が強い機械といえる。
これ以上なく適役だろう。
「……というわけでさ、ネットにアクセスして、その“M”の居場所を知りたいんだ」
「うむ……レベルによるが、多少のセキュリティなら突破可能だ……それを書いた人間の居場所も割り出せるだろう」
俺が事情を説明してから、ムカイさんがやや言葉を詰まらせるようになった。
「ううむ、“複雑な心境”とは、こういう状態を言うのだろうか」
その原因は、たぶん『ラボハテ』について思うところがあるからだ。
ムカイさんは、秘密結社『シックスティーン×シックスティーン』によって作られた戦闘用ロボットだった。
一昔前までは、『ラボハテ』や俺の母さんと激闘を繰り広げていたとか。
「大丈夫？ ムカイさん」
「問題ない。あの戦いの日々は過去の履歴。元より『ラボハテ』自体に執着などないのだ」
ムカイさんはそう返すけれど、演算処理の遅れは正直だ。
今でこそ敵対していないものの、因縁の相手であり、ルーツとも言える存在であることに変わりはない。
そんな『ラボハテ』の名前をこんな形で聞いたんだから、そりゃまあ戸惑うよな。
「それで……頼んでもいい？」
「むう、それならオマエの母もサイボーグだから出来るんじゃないか」
「お母さん、機械にそこまで強くないんだよ。ネットとかも全然ダメ」
「“機械に強くない”……あいつ、ワレに何度も勝ってきたくせに……うごごご」
ムカイさんは頭を抱えだした。
何か重い処理に引っかかったらしい。
「……よかろう、オマエの母にすら不可能なものを攻略してやる」
だけど十数秒後、その処理を何とか終えたようだ。
ムカイさん、“M”の捜査協力を力強く引き受けてくれた。
「プライバシーポリシーなど、ワレの力の前では無力と知れ」
偶数奇数を判定するための途方もないプログラミングコードが話題に
http://blog.livedoor.jp/itsoku/archives/55507489.html
x mod 2
で行いますが、ビット演算を使い、最下位ビットが立ってるかチェックする
x and 1
負の表現に2の補数を使うプログラミング言語では問題無いのですが、Cではちょっと問題が起きます。
X3010:2003 プログラミング言語 C 6.2.6.2 整数型
符号付き整数型において、オブジェクト表現のビットは、値ビット、詰め物ビット、および符号ビットの三つのグループにわけられなければならない。
詰め物ビットは存在しなくてもよく、符号ビットは丁度一つでなければならない。それぞれの値ビットは、対応する符号なし整数型のオブジェクト表現における同じビットと同じ値をもたなければならない。(略)
符号ビットが0であれば、それは結果の値に影響を及ぼしてはならない。符号ビットが1であれば、値は次に示す方法の一つにしたがって変更されなければならない。
- 符号ビットが0のときの値を負数化した値[符号と絶対値(sign and magnitude)]
- 符号ビットが値-(2N)をもつとするときの値[2の補数(two's complement)]
2の補数の場合(1111 1111)2
1の補数の場合(1111 1110)2
よって、処理系が2の補数を採用している場合では問題ありませんが、1の補数を採用している場合に判定が逆になります。
UNISYS社のClearPath Dorado Systems(ClearPath OS2200)で採用されているという話です。
INT16-C. 符号付き整数の表現形式について勝手な想定をしない
最近ではコードレビューシステムを取り入れてる会社は多いだろうが
まともに運用できているのか知りたい。
いちゃもんつけては10回、時には100回以上書き直させるというキチガイが暴れていたからだ。
1文字の変更でも数十行はコミットメッセージを書かねばならず、
ブーリアン型を2つ使っているだけでも
同じ処理をしている2行が一度でも現れたら関数化しなければならなかった。
重要なのは、別の修正でブーリアン型を2つ使っている箇所をByte型のビット演算にして
同じ処理をしている2行が一箇所でもあればそれらを全部関数化すると
正確さを追求しているのでもなく、効率化でも、高速化でも、平易化でもなく
難癖つけてやり直しを命じることが目的になっていた。
出来上がったコードはひどい出来だった。
やり直すごとにクソになっているのに書き直さなくてはいけないのが本当に苦痛だった。
ときには、嫌がらせ目的でパッチのすべての行に「is it correct?」と書いたり、
すべてのパッチを作成直後に減点してコミットできないようにしたりしていた。
変数名を決めるだけで5個ぐらい候補を上げてどれが好みですか、とキチガイにメールで聞くことすらあった。
一人でそれができてしまう、というのがとても気がかりだ。
今はまともな職場で働けているが、いつかまたそういう職場にあたってしまうかもしれない。
スーパーや飲食店の会計時に、所持する硬貨の枚数が最低限となるように私は支払いをしている。それは、所持する硬貨の枚数が15枚を超えないことも意味する。
| 1円玉 | 4枚 |
| 5円玉 | 1枚 |
| 10円玉 | 4枚 |
| 50円玉 | 1枚 |
| 100円玉 | 4枚 |
| 500円玉 | 1枚 |
| 合計 | 15枚 |
※例えば、請求額が1円かつ硬貨を1枚も所持していない場合に千円札などの紙幣で支払うと、所持硬貨は上記の通り最大の15枚となる。
私の支払い方法をアルゴリズムで表現してみた。アルゴリズムという言葉を見ると、プログラミングや高度な数学の知識が必要と思うかもしれないがそんなことはない。アルゴリズムというのは目的を達成するための計算手順を示したものであり、料理で例えるならレシピに相当する物である。レシピに従い料理を作ることができるなら、アルゴリズムに従い計算をすることもできるだろう。
以下の支払いアルゴリズムに必要な数学能力は、1桁同士の足し算・足し算による繰上がり処理・数値比較が主である。2桁以上の足し算引き算を暗算する能力は不要である。プログラミング言語で使用されるような演算記号は極力使わないようにしたので、アルゴリズムを知らない人にこそ読んでほしい。
【支払い桁】 ← 1 /*硬貨支払いは1桁目から3桁目に対応するので、1～3の値をとる*/
【支払い総額】 ← 0 /*硬貨を支払うたびに加算する。実際には、置いた硬貨を数えるだけ*/
【請求額で見る数】 ← 0 /*下の桁から1桁ずつ見る。繰上がりもあるので、0～10の値をとる*/
【繰上がりフラグ】 ← 0 /*0:偽 1:真 とする*/
【請求額で見る数】 ← 【請求額】の【支払い桁】桁目の値＋【繰上がりフラグ】
【繰上がりフラグ】 ← 0
(8)へ進む
【繰上がりフラグ】 ← 1
(8)へ進む
【請求額で見る数】×10^(【支払い桁】－1) に必要な 10^(【支払い桁】－1) 円玉を支払えるなら支払う。
【支払い総額】に支払った金額を加える
/*10^0＝1 10^1＝10 10^2＝100 である*/
【請求額で見る数】×10^(【支払い桁】－1) に必要な 5×10^(【支払い桁】－1)円玉を支払えるなら支払う。
【支払い総額】に支払った金額を加える
/*5×10^0＝5 5×10^1＝50 5×10^2＝500 である*/
【請求額で見る数】 ＞ 【支払い総額】の【支払い桁】桁目の値 の場合
【繰上がりフラグ】 ← 1
【請求額】 ＞ 【支払い総額】 かつ 【支払い桁】 ＜ 3 の場合
【支払い桁】に1を加える
(2)へ戻る
硬貨支払いの終了
条件1 1円玉・10円玉・100円玉をそれぞれ4枚ずつ所持している
(1)請求額に876を設定。
(3)(4)該当せず。
(5)6に必要な1円玉を1枚支払い、支払い総額は1円となる。
(6)6に必要な5円玉を支払いたいが、所持してないので支払わない。
(7)1桁目に6円支払うべきところを1円しか支払っていないので、支払いは1桁上に繰上げ。
(8)支払い総額が請求額を満たしていないので、次は2桁目をみる → (2) へもどる。
(2)請求額で見る数は2桁目の7に繰上がりの1を加えて8である。
(3)(4)該当せず。
(5)80に必要な10円玉を3枚支払い、支払い総額は31円となる。
(6)80に必要な50円玉を支払いたいが、所持してないので支払わない。
(7)2桁目に80円支払うべきところを30円しか支払っていないので、支払いは1桁上に繰上げ。
(8)支払い総額が請求額を満たしていないので、次は3桁目をみる → (2) へもどる。
(2)請求額で見る数は3桁目の8に繰上がりの1を加えて9である。
(3)(4)該当せず。
(5)900に必要な100円玉を4枚支払い、支払い総額は431円となる。
(6)900に必要な500円玉を支払いたいが、所持してないので支払わない。
(7)3桁目に900円支払うべきところを400円しか支払っていないので、支払いは1桁上に繰上げ。
(8)支払い総額が請求額を満たしていないが、3桁目の支払いを終了したので該当せず。
(9)硬貨の支払いを終了する。
以上、硬貨の支払いは431円となる。ちなみに、876円の請求に1431円を支払うとお釣りは555円である。「876-1431=-555」の計算をせずとも支払いを最適化することができた。
人間は機械と違って、日常的動作は早く正確だが計算は遅くて間違いを起こすという特徴を持つ。どんなに計算が得意な人でもコンピュータより早く正確に計算をすることは不可能である（例外はジョン・フォン・ノイマンくらいであろう）。よって、人間の支払いにおいては、硬貨を支払う動作よりも計算自体がボトルネックやエラーの原因となると考えた。この問題の解決のために、1桁単位毎に硬貨を支払うようにした。
上記の支払いアルゴリズムに従えば、レジ店員のミスや釣銭不足の場合を除いて、硬貨の所持数を最低限にすることができる。しかし、緊急時に備えて硬貨を余分に所持しておきたいと考える人もいるだろう。その場合でも、支払いアルゴリズムを採用しないのはもったいない。なぜなら、アルゴリズムをほんの少し修正するだけでよいからだ。例えば100円玉を常に3枚以上持ち歩きたいなら、アルゴリズムの(5)に「支払いにより100円玉が2枚以下になるなら支払わない」という条件を追加すればよい。所持する100円玉は3～7枚の間を維持できる。他にも、各々の好みに合わせてアルゴリズムを修正して活用してほしい。
直球でマジレスすると、人類はもう実時間に自動モザイクできるところまで来ている。
セマンティックセグメンテーションを調べろ。これは今流行のAIの中のディープラーニングのなかのCNN（コンボリューショナルニューラルネットワーク）の一種だ。
AIに「ここはモザイクかける場所ですか？モザイクかけない場所ですか？」とピクセル単位で教え込む。学習が終わった暁にはエロ画像入れるとモザイクするべき場所とするべきでない場所を分けてくれるはずだ。
実現するには、モザイク前のエロ動画を準備し、動画全てのコマに対して全てのピクセルをモザイクにするべきかそうでないか分類したデータを用意してくれ。そいつをもりもりAIに見せるんだ。
ものすごい演算時間と計算量を食うと思うが、多分できる。だって、セマンティックセグメンテーションは自動運転に使えるぐらい、人と車と道路と空を実時間で見分けられるぐらいすごいんだから。
でも寡聞にしてこの研究をやったという報告を見つけられないんだ。データさえ用意できればできるはずなんだけどなあ。
あ、認識率は9割とか9割9分とかしかないんで、捕まりたくなかったらモザイク領域は時系列で平滑化というか多数決とっておいた方が良いと思う。
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
ツムツムはみんなやってるよ。
LINEは、『LINE：ディズニー ツムツム』の7,000万ダウンロード突破および、総売り上げ額が10億ドル（約1,100億円）を達成したことを発表した。ほかにも、スキルチケットが最も使用された人気のツムの統計などのデータも公開！
これ一昨年のニュースだけども。7000万人と言えばすごい数字だ！おれはやってないけど文字通りみんなやってる。
キャラクターもかわいい。パヅルゲーとしてはぷよぷよ以来の大ヒットキャラゲーだ。
あとは、連絡ツールと連動して無理に競争させるシステムは革新的だ！
つーかマリオオデッセイやった？重力演算システムからして革新的というか野心的以外の何物でもない。人間のエクスペリエンスを拡大するゲームが革新的でなくてなんなのか。おれはやってないからエクスペリエンス拡大してないけど。
