「model」を含む日記 RSS

はてなキーワード: modelとは

2018-02-22

更新サービス接続できませんでした。対応

対応方法

次のレジストリ適用することで治り、正常にWindowsUpdateができるようになりました。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability]

"BranchName"="fbl_impressive"

"Ring"="WIF"

"ThresholdRiskLevel"="low"

状況

更新履歴確認すると2017/8 頃からWindowsUpdate適用できていないようでした。また、いくつかのUpdateでは(再起動は何度もしているけれど)再起動必要です というステータスでした。

Windows 10 Insider Preview 16278.1000 (rs3_release)

 インストール完了するには再起動必要です。

・2017-11 x64 ベース システムWindows 10 Version 1703 の累積更新プログラム (KB4048954)

 インストール完了するには再起動必要です。

オンライン確認をすると、エラーが表示されます

更新サービス接続できませんでした。後で自動的に再試行されますが、今すぐ手動で確認することもできます。この問題が引き続き発生する場合は、インターネット接続していることを確認してください。

実施した作業

日本語フォーラムを見つつ、以下の作業を行いまいしたが改善しませんでした。

https://answers.microsoft.com/ja-jp/windows/forum/windows_10-update/windowsupdate更新が/745a1c4c-4c92-481e-b5ac-39ae55cd7139

https://answers.microsoft.com/ja-jp/windows/forum/windows_10-update/windows-10-windows-update/a8a3a4cb-9d67-406e-8ae6-d25451c237d7

Windows 10 - Windows Update に失敗する場合対処

方法 1 : トラブルシューティング ツールを実行する

方法 2 : BITS トラブルシューティング ツールを実行する

エラーで終了

方法 3 : DISM コマンドを実行する

方法 4 : システム ファイル チェッカーを実行する

英語フォーラム

Q:Windows 10 Service Registration is Missing or Corrupt

https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_update/windows-10-service-registration-is-missing-or/a2bfb3c3-665f-4f22-92d9-cf82f0a950be

Ramesh.Kumar replied on April 6, 2015

サービス起動停止を試しましたが、改善しませんでした。

KriegTiger. replied on August 13, 2015

レジストリ対応上記)を試したところ、正常にWindowsUpdateができるようになりました。

環境

OS 名: Microsoft Windows 10 Pro

OS バージョン: 10.0.15063 N/A ビルド 15063

OS ビルドの種類: Multiprocessor Free

システムの種類: x64-based PC

プロセッサ: 1 プロセッサインストール済みです。

[01]: Intel64 Family 6 Model 142 Stepping 9 GenuineIntel ~2611 Mhz

BIOS バージョン: Microsoft Corporation 231.1737.770, 2017/06/09

ホットフィックス: 3 ホットフィックスがインストールされています

[01]: KB4022405

[02]: KB4048951

[03]: KB4048954

誰かのご参考に慣れば幸いです。

とここまで書いて、Windowsフォーラム投稿できないことに気づいた。

2018-02-21

ダボダボした女性向けファッション多すぎでは

これ書いている増田女性です

上はふんわり、下はワイドパンツみたいなのを提案する(=製造する)ファッションブランド多すぎない?わりと「いい女」を提案するような雑誌ブランドまでダボダボ。175cm以上の選ばれたModelならそれもギリギリ着こなしなんだろうけど、モデルほどそういうのはやってないよね。長い脚を見せつけるためにSKINNYとかショートパンツとか。一般人上下ダボダボやるとすっごいちんちくりんのダボダボに見えるし、かなりバランスも悪いと思う。CURTAINまきつけてるみたい。なんでハヤってるのかわかんない……

2018-02-12

Model-View-SheetアーキテクチャGoogle Spread Sheetでやろうとしたことありますね。スプレッドシートいじる処理が重くて手でやった方が安定して速かったため、Model-Viewあたりしか書かなかった記憶

2018-01-23

https://qiita.com/klriutsa/items/8d7381f437c225c64a5f

Rails界隈よく知らないが、ビジネスロジックオブジェクトの責務ってのに分解するのは、平均レベルエンジニアには難しいと感じるよ。

ModelDBテーブル対応する、複数Modelが絡む処理は業務名前を冠したServiceにまとめるってのが、迷うこと無く整理できて、担当者が変わっても一貫性を維持できる丁度いいところだと思ったんだけどなあ。

俺のいる組織レベルが低いせいだって言われると、返す言葉も無いけどね。

2018-01-02

プログラミング初心者の頃の気持ちを忘れた

プログラミング教えてと言われた。

自分PCサーバ立ててドメイン通してアクセスしてみて、HTMLCSSJavaScript概要を教えた。

http://hogehoge.comを叩くとぼくのローカルPC上のHTMLを見ることができるのだ。普通これは感激するはずだ。ヤツは少しも感動しなかったが。

タグのことを教えて、formタグ使ってみて、CSSを教えてセレクタの使い方教えて、なるべくDOMというワードは避けてJavaScriptイベントの追加のしかたを教えた。

で「あとは色んなタグ覚えるだけ」「CSSで色んな組み合わせやってレイアウトを楽しんでね」「あとは色んなイベント覚えるだけだから」みたいな感じ。色んなイベントを追加してもらった。

その後データベースの話をした。

「まずエクセルファイルからデータ取ってみよう(実際はCSV)」「あ、でもこれだと取りにくいし時間かかるね」「しかもこれだとデータ矛盾ちゃうしめんどくさいね」「そこでデータベースですよ」

って言って、sqlite3を教えた。エクセルで「これがインサート、これがデリート」って説明しながら、テーブルレコードSELECT, INSERT, UPDATE, DELETEを教えた。

ヤツは「なんでそんなわかりきったことをわざわざ文字入力するんだ」と憤慨していた。こっちが憤慨したい。

で、次はWebフレームワークの話。まずWebフレームワークを使ってもらう前に、URLを叩いたらアプリケーションが走ることを確認してもらう。僕は「すごいでしょ!!」って言う。

さっきのsqlite3とつなげてみて、データを取得して表示してみた。ここで僕、「すごいでしょ!感激するでしょ!!」って言う。「ふーーん」っていう反応。「データをそのまま表示してるんだからそんなの当たり前でしょ?」みたいな。うるせぇWebサービスなんて大体そんなもんだわという言葉を飲み込みつつ、ここまで3時間

ここで初めてサーバサイドの言語を教える。for-each文、関数までは順調。そしてクラスクラスは若干詰まっていたのでぼくはまず構造体について説明した。

構造体のことはよくわかるみたいだ。まず青赤緑で構成された色の構造もどきを作って、画面に色を出力した。ぼくがこの構造もどきで画面にマリオを描くとヤツは感動していた。

そしてぼくはクラスについて教えた。「この構造体に関数がついてたら便利なときもあるもんだ」って感じ。説明がめんどくさいので「このクラスっていうのが型だよ」とか言っておいた。

共通でいてほしいものもあるけど、共通でいてほしくないものもある」と言って、ぼくはキャラクタークラスを作ってマリオオブジェクトクッパオブジェクトを生成し、FFを究極に安っぽくした感じのフィールドで戦わせた。

ヤツは興奮しているようだった。マリオは負けた。ぼくは「人は目に見えるものしか興味が沸かないんだな」と達観した。

Webフレームワークに戻ってぼくはクラスを使ってViewModel、そしてControllerを教えた。彼はなんだかかなりよくわかった様子だった。ぼくは満足した。

そろそろ5時間になろうとしていたので、ぼくは「あとはデザインパターンと言って、プログラミングしていてよくあるパターンを集めたものがあるんだ」とか「アルゴリズムを知ると色々効率よく書けるよ」とか「非同期処理とかもあるし、とにかく色んなライブラリを試してみて」「他の言語とかも試してみて」とかそんなようなことを言った。

ぼくの仕事は終わった。あとはもうヤツは自分ひとりでなんでもできるだろう。ときどきぼくが質問に答えることもあるだろうけど、ヤツはサーバサイドに必要な大まかな知識を、こんなに短期間で得たのだ。ヤツは優れたエンジニアになるに違いない。ぼくはヤツの家をあとにした。お金ぐらい払ってほしいものだ。

翌日、ヤツから電話があった。

「ごめん、HTMLってなんだっけ……?ていうかファイルってどうやって作るんだっけ……」

ヤツは何も覚えてなかった。俺は発狂した。俺はいったい、何を教えていたんだ。

あと俺、数年勉強しててこれぐらいのことしかわかってなかったのか?そう思って、なんだか猛烈に虚しくなってしまった。

そしてぼくは、二度と人に教えないことを決意した。

2017-10-30

Pimax 8kあやしくなってきた

両目で8kの高解像度HMDのPimax 8kなんだが、リフレッシュレートが宣伝通りの90Hz出ないんじゃないかって疑いが出てきていて、Redditとかで少し炎上している。

HMDで最重要(とされている)のはリフレッシュレートで、これが低いと没入感が薄れたり、酔いの原因になったりする。

現在主流のViveやOculusはこのリフレッシュレートについては問題がないのだが、いかんせん解像度が低く、ドットが目立ち、少し離れた位置メニューが出現したりすると、文字が潰れて読めなかったりすることもままある。

Pimax 8kがこの問題解決してくれるんじゃないかと期待していたんだけど……。

He said that the screens that are installed in both the V2 and V3 HMDs are limited to 75 fps. I asked if this is what will be in the consumer model. His answered by saying what ships will operate inthe range of 75-90 FPS. He then added that it would depend on where the screens are sourced from, adding that the quality can vary manufacturer to manufacturer.

性能が出るかどうかは部品調達先のメーカーによるだそうだ。なにそのガチャ……。

まあまだどうなるかはわからんけど、とりあえずKickstarterには参加しないほうがよさそうである

2017-09-01

https://anond.hatelabo.jp/20170901133144

イーロンマスクは「俺とお前が違うのは資産を数千億円と幅広い投資家仲間を持っているかどうかだけだが、俺にはこれができる。俺の資産はこの場合科学的に言って影響していないからお前にはこれができる。と思う。だからやれ」みたいな中規模ワンマンクソ社長で、牛丼屋の社長がこれは共産主義革命から賃金が低いのは一緒に我慢しようとか居酒屋グループ創業者が私は現場社員たちと一緒に頑張っていきたいとか言っているのとなんも変わらんのだが、恫喝扇動が上手いだけなのにちやほやされているのは滑稽ですらある。

@elonmusk Model S P100D + EAP + FSD + PUP + カーボンスポイラー新車で一台無料でくれたらこエントリは消す。あとクリームインテリアは早く諦めるか値上げでもしろ。醜い。

2017-08-16

以前、ガンショップでGLOCK17とか撃ってた者だけど、店主の強烈なオススメにより、Savage Model 67Hとかいショットガンを買いました。

護身用にピストル買ったところで普段撃つ経験がなければいざという時撃てないし、一撃で倒せなかったら自分自身が辛い思いをすることになるからストッピングパワーが強いショットガンにしとけと強く説得されたので。

2017-04-20

ITエンジニア向けに「最低限これだけは守ってくれリスト」がほしい

ITエンジニアって日本において特殊存在

ほいほいと転職したり他の現場いったりができてしまうんだよ

そうすると、前任者のクソコードをヒントもなしに修正するハメになることが非常に多くなる

なぜなら辞めるときっていうのはだいたい苦しいときで、苦しいときほどクソを生みやすいか

 

AさんがBさんにクソを投げ、BさんがCさんにクソを投げ、CさんがAさんにクソを投げるみたいな

全員で苦しくなってる状況なんだ

 

「全員の技術力を上げるべき」なんていうクソみたいな不可能提案する人も居るけど

そういうクソは放っておいて

仕事するなら最低限これだけはやっておいてくれリストみたいなのがあれば良いんじゃないかと思った 

 

もちろんそれも、仕様書を書けなんていう無理難題じゃなく

例えば「Modelにだけはコメントを必ず書く」くらいのクソ低レベルリスト

それがほしい

 

 

 

そしたら、それ守ってないやつを全力で叩くから

 

__

 

あ。もちろん全員が自衛のためにね。叩くってのは冗談

 

ちなみにこれは宗教論争になるから、1個に定めるのは無理だろうけど

なんていうの、松竹梅で、これほしいよねリスト流行ればいいと思う

 

なお主導はしません

ウンコードを撲滅したくて血涙流してる人頼む

2016-12-12

「::」←これってどういう意味

Webプログラミングしてるとよく見かけるじゃん。Model::find($id);みたいなやつ

この増田ロゴにもあるよな。これはどういう意味なの?inみたいな?

2016-10-17

http://anond.hatelabo.jp/20161017165607

ありがとうございます。読んでみます

Railsの時は黒魔術師コード理解できなかったけど、

何をやっているかは把握できたし、そこに書く理由もそれなりに分かっていたのです。

まさにレールに乗ってる感じ。

特定されないか気になるけど気にしないで書く。

今の案件、Controllerに英数字の画面IDを定数で渡してView指定し、

画面IDと同名のファイル名のviewviewsフォルダに作り、

ロジックはServiceに書いている。

DBアクセスmodelフォルダ内にdaoってフォルダ作ってそこにソース置いてる。

JSのincludeはもうどこでやっているのかわ分からない。

他をまねて書いたら勝手にheader部にincludeされてる。普通にviewに書いちゃダメなのか。

こんなん初見理解できるものなんでしょうか。

理解というのは、使い方というか、なぜこういう構成にしたのかという思想について。

http://anond.hatelabo.jp/20161017164515

ビジネスロジックModelに、とかサービス層に、とか言われて、困る感じか

1画面1機能ならViewとControllerで十分なんだよね

同じ機能複数画面で提供しようとすると、Controllerに処理書くスタイルだとコードが重複だらけになるんだよね

それを共通化しようってしたときに、ソフトウェアアーキテクチャとかが出てくるんだよね

教科書としては「エンタープライズ アプリケーションアーキテクチャパターン」とかあるけど、難しいし、理解してない人のほうが多いし、人によって言ってること変わるんだよね

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-05-17

http://anond.hatelabo.jp/20160516152330

それをユーザから見て命令変数への破壊的代入ではなく

参照透明な関数インターフェースで実現するのが

いわゆるモナドや(誰かの独自解釈ではない本来の)FRP

http://elm-lang.org/examples/time

view : Model -> Html Msg
view model =
  let
    angle =
      turns (Time.inMinutes model)

    handX =
      toString (50 + 40 * cos angle)

    handY =
      toString (50 + 40 * sin angle)
  in
    svg [ viewBox "0 0 100 100", width "300px" ]
      [ circle [ cx "50", cy "50", r "45", fill "#0B79CE" ] []
      , line [ x1 "50", y1 "50", x2 handX, y2 handY, stroke "#023963" ] []
      ]

HaskellライブラリもElmのような言語も、サンプルもJavaScript実装

ググればWikipediaで出てくるレベル

https://en.wikipedia.org/wiki/Functional_reactive_programming#Implementations

2015-11-29

4Pマーケティングミックスの要素

企業は以下の4Pを適切に操作して顧客にモノを売る。

いや、おかしいでしょ。なんでPlaceが流通になるの。なんとか頭文字を合わせようとしただけじゃないの。

で、さら顧客志向マーケティングミックスとして後に生まれたのが4C。

Consumer万能すぎでしょ。もっと狭い言葉を使おうよ。

サービスマーケティングミックスでは4Pに3つのPが加えられ、7Pになる。

Physical Evidenceが分かりにくすぎる。2単語になってるし。

さら共生マーケティングにおける4Cは上記の4Cとは違うとか、共生マーケティングの分野には7Cs COMPASS MODELなるものもあるとか。

https://ja.wikipedia.org/wiki/%E5%85%B1%E7%94%9F%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0

7Cs COMPASS MODELが何を言ってるか分かる人います

無理やりかっこよく頭文字を合わせてなんの得があるというのか。

こんなことしているから、ビジネス寄りの学問うさんくさい金稼ぎの手段だという偏見が抜けないんだ。

2015-10-15

ニュートリノ振動は役に立つのか?

はてなブックマーク - ノーベル賞受賞の梶田隆章教授、NEWS小山慶一郎に「意味が分からない」 - ライブドアニュース

において「ニュートリノ振動は役に立つのか?」が話題になっていました。

以下に個人的な考えを述べます。できる限り誠実に書いてみます

ノーベル賞受賞の理由

まずはニュートリノ振動ノーベル賞を受賞した理由を振り返ってみましょう。

研究者達は世界の全てを記述する究極理論を目指しています。その理論においては自然界における4つの力、重力電磁気力(電場磁場)、強い力、弱い力を統一されているはずだと考えられています

1970年代電磁気力と弱い相互作用統一まで完成し、現在では強い相互作用記述する量子色力学とあわせて標準理論と呼ばれています。そしてこの後、人類は長い停滞期を迎えました。標準理論実験と合いすぎたのです。

人類はこれまで実験により理論の破れを見つけ、それをヒントにして次の理論を作り上げてきました。マイケルンモーリーの実験相対論に、光電効果実験量子力学へと繋がりました。標準理論を超えて大統一理論に進むには理論の破れを見つける事が不可欠なのですが、長い間それを見つける事ができませんでした。こんな中で唯一見つかった標準理論の破れ目がニュートリノ振動だったのです。現在私たちの手にする数少ない、 beyond the standard model へ繋がる鍵と呼べるでしょう。

ニュートリノ振動は役に立つのか?

以上より「ニュートリノ振動は何の役に立つのか」は「大統一理論は何の役に立つのか」に言い換える事が出来るでしょう。

しかし残念ながら大統一理論は(候補は日々研究されているものの)まだ完成もしていません。これはちょっと早すぎる質問でしょう。その前にまずは現在素粒子理論——標準理論は役に立つのか? を考えてみることにしましょう。

素粒子理論は役に立つのか?

実をいうと僕は素粒子理論は実社会には全く役に立たないのではないかと思っていました。

ところが癌医療への応用火山研究への応用加速器副産物といえる放射光を利用した品種改良材料開発といった産業利用が次々と成されるのを見て心の中でジャンピング土下座しました。

いや、僕が「素粒子は役に立たない」と考えたのは単に僕に才能がなかっただけであって、世の中には僕の思いもよらない利用法を考えつくすごい人達がたくさんいるのだと思い知らされました。

それでニュートリノ振動は役に立つのか?

ここでようやく表題に戻るのですが、「ニュートリノ振動は役に立つのか?」「大統一理論が完成したとしてそれは役に立つのか?」といった質問に僕なりに誠実に答えてみると以下のようになります

「正直に言うと僕には役に立つようには思えないし、どう使われるかも全く想像つきません。そして役に立たないと言い切る自信もありません。」

「ただ、これまでの歴史を振り返ると誰かが利用法を考えるかもしれません。世の中には凄い人たちがたくさんいるのですから

追記

これだけだと誠実じゃないと思ったので追記します。

仮に大統一理論が完成したとしてもお金にはなりません。理論定理を使う上で特許料は発生しないからです。研究成果は世界に公開されます

素粒子研究人類の貢献にはなるかもしれませんが、国益にはならないでしょう。

2015-05-08

志村多様体整数論を整理するために発見されたのだよ

志村多様体とは,Hermite対称領域の数論商として得られる代数多様体のことであり,複素上半平面の商であるモジュラー曲線の一般化にあたるものです.モジュラー曲線の定義方程式代数体に係数を持つことは古典的によく知られた事実ですが,それと同様に,志村多様体代数体上の自然モデル(正準モデルcanonical model)を持つことが知られています

この正準モデル理論は,志村五郎氏によって,[Shi67a]や[Shi67b]等の先駆的な仕事を経て,[Shi70a],[Shi70b]において導入されました.正準モデル存在によって,種々の正則保型形式の持つ有理性・数論性を統一的に捉えることが可能になります.また,志村多様体のエタールコホモロジーへのGalois群およびHecke作用素作用を通して,Galois表現と保型形式・保型表現を結び付けることもできます.これは,いわゆる大域ラングランズ対応に対する,現状で最も有効アプローチの一つであると考えられています.近年,数論幾何学・保型表現論双方の進歩によって,以前は予想であった志村多様体の諸性質が多くの場合証明されつつあり,また,その発展に伴い,さらに多くの応用が発見されてきています.今や,志村多様体論は現代整数論における標準的な道具立てとなった感があります.そこで,今回の整数論サマースクールでは,志村多様体の基礎理論から始めて,それが最近整数論にどのように応用されるかというところまでを扱いたいと思います

前半部で扱う志村多様体の基礎理論は,現在標準的に用いられている,Deligneによる再定式化[Del71a]に基づいて紹介を行います.このDeligneの定式化は,その抽象性・一般性のため,定義を見ただけではそれが意味するところをなかなか理解しづらいように感じます.そこでサマースクールでは,モジュラー曲線の最も単純な高次元であるSiegelモジュラー多様体から始めるとともに,なるべく分かりやすく,かつ実際の研究で使われている例を多く含めることで,この理論に初めて触れる参加者の方々にも十分に理解できるよう努めたいと思っています.後半部では,ここ数年間の進展も含む最近話題が主なテーマとなりますが,過度に技術的な内容は避け,理論本質を見据えた講演を設けることで,多くの参加者にとって有意義情報収集意見交換の場を提供できるようにしたいと考えています

2015-05-07

氏名:Mikhail Kapranov(カプラノフ,ミハイル

分野名:代数幾何

キーワード:モジュライ空間オペラッド,導来圏,非可換幾何

現在研究概要

My background is in algebra, algebraic geometry and category theory.

I am interested in interactions among these areas such as:

Abstract algebraic structures (operads and their generalizations)

arising from moduli spaces in algebraic geometry, including mod-

uli spaces of curves and moduli space of hypersurfaces (leading to

combinatorics of secondary polytopes).

• Relations between algebraic geometry and representation theory

(Hall algebras of categories of coherent sheaves).

• Infinite-dimensional objects in algebraic geometry, especially algebro-

geometric model spaces of paths and loops.

• Derived algebraic geometry, in particular derived moduli spaces of

algebro-geometric objects and analysis on such derived spaces.

• Nom-commutative and categorical methods in algebraic geometry.

学生への要望

Ideally, I would like the students wishing to work with me to have

some basic background in algebraic geometry (schemes, algebraic curves)

and homological algebra (sheaf cohomology). Additional background in

category theory (e.g., derived categories, higher categories and so on)

would be welcome but not strictly necessary.

2015-05-05

数理物理における「可積分非線形方程式」,特にソリトン方程式パンルヴェ方程式とそれらの離散化について研究を行っている.広田の双線形化法と佐藤理論研究重要ツールである広田の双線形化法によって,新しい連続方程式や離散可積分系特殊解を考察し, 連続系の場合によく理解されている概念方程式対称性,保存量等)とよく利用されている手法(逆散乱法, ダルブー変換等)を可積分非線形差分方程式及びそれらの超離散極限で得られたセルオートマトン拡張することは重要研究課題である.(差分方程式の可積分性の特徴は連続的な可積分系より基本的であると思われるのに,離散可積分系に関する知識は連続系と比べてきわめて少ないといわざるを得ない.)

最近,様々な自然現象記述するために用いられている連続模型の離散化についても研究を行っている. 特に連続系の超離散化可能な有理写像による離散化を行って,コンピュータシミュレーションと解析的な手法を用いながらその連続模型の離散的な表現の忠実さを考察している.さらに,得られた離散系の超離散極限として構成できるセルオートマトン性質研究している.

主要論文 1."Generalised QRT mappings with periodic coefficients'', R. Ramani,B. Grammaticos and R. Willox,Nonlinearity 24 (2011) 113-126.

2."Solving the ultradiscrete KdV equation'',R. Willox, Y. Nakata,J. Satsuma, R. Ramani and B. Grammaticos, J. Phys. A: Math. Theor. 43 (2010) FT 482003.

3."Yang-Baxter maps from the discrete BKP equation''',S. Kakei, J.J.C. Nimmo and R. Willox, SIGMA 6 (2010) 028, 11 pages.

4."A discrete-time model for cryptic oscillations in predator-prey systems''', R. Willox, A. Ramani and B. Grammaticos, Physica D 238 (2009), 2238--2245.

5."On two (not so) new integrable partial difference equations''', A. Ramani,B. Grammaticos, J. Satsuma and R. Willox, J. Phys. A: Math. Theor. 42 (2009) FT 282002 (6pp).

2015-05-04

戦争に行ってまで研究するのは数学者だけにしてほしいものだ

戦争に行って,やらなきゃ死ぬような境地で研究しているのは,こういう数学者だけにしてほしいね。ほかの分野の学者が,やらなきゃ死ぬと思って研究していても気持ち悪いだけ。数学だけは,戦争に行かないと,なかなかできない。

講   座 数理解学大講座 教授

研究分野 確率統計学

研究テーマ 1.マリアバン解析と漸近展開,条件付き漸近展開

2.確率微分方程式など確率過程統計推測論

3.漸近決定理

4.セミマルチンゲールの漸近分布

5.確率過程サンプリング問題

6.確率数値解析,漸近分布論のファイナンスへの応用

7.保険数理

研究概要 観測に対して行動を対応させる規則(決定関数)のもとで起こる確率現象を解析するのが数理統計学課題である統計的定理論は決定関数総体における最適性,許容性の問題を扱うが,その基礎となるのが分布計算である確率過程のように分布構造が複雑な場合は漸近的決定理論に頼ることになり,その適用のためには確率過程クラスマルコフ過程ミキシング過程,セミマルチンゲール,弱および強従属過程摂動モデル,...)に応じた極限定理の研究必要となる.

  高次の極限定である漸近展開が重要になっている.これは分布の近似精度の改善のみならず,多変量解析,時系列解析,高次漸近決定理論,ブートストラップ法,情報量規準統計的予測情報幾何などの研究の基礎となる.セミマルチンゲールのような連続時間確率過程に対して(分布論的)漸近展開を与え,これを基礎に確率微分方程式の高次統計推測論が現在発展しており,統計量の有効性の証明モデル選択における情報量規準構成などに役立っている.展開公式の解析的正当性(validity)の証明には無限次元確率解析(マリアバン解析)が用いられる.

  オプション価格の漸近展開の方法は,ファイナンスに現れる多くのモデル適用されており,保険数理におけるCTEなどのリスク尺度の近似計算,条件つき漸近展開および非線形フィルタへの応用も研究している.

主要論文 1.Yoshida, N.: Asymptotic behavior of M-estimator and related random field for diffusion process, Annals of the Institute of Statistical Mathematics, 42, 221-251 (1990).

2.Yoshida, N.: Asymptotic expansions of maximum likelihood estimators for small diffusions via the theory of Malliavin-Watanabe, Probab. Theory Related Fields, 92, 275-311 (1992).

3.Yoshida, N.: Asymptotic expansion for statistics related to small diffusions. J. Japan Statist. Soc. 22, 139-159 (1992).

4.Yoshida, N.: Estimation for diffusion processes from discrete observation, J. Multivariate Analysis, 41, 220-242 (1992).

5.Yoshida, N.: Asymptotic expansion of Bayes estimators for small diffusions, Probab. Theory Related Fields, 95 , 429-450 (1993).

6.Yoshida, N.: Malliavin calculus and asymptotic expansion for martingales, Probab. Theory Related Fields, 109, 301-342 (1997).

7.Kusuoka, S., Yoshida, N.: Malliavin calculus, strong mixing, and expansion of diffusion functionals. Prob. Theory Related Fields 116, 457-484 (2000).

8.Uchida, M., Yoshida, N.: Information criteria in model selection for mixing processes. Statistical Inference for Stochastic Processes, 4, 73-98 (2001).

9.Yoshida, N.: Conditional expansions and their applications. Stochastic Processes and their Applications 107, 53-81 (2003).

10.Sakamoto, Y., Yoshida, N.: Asymptotic expansion formulas for functionals of epsilon-Markov processes with a mixing property. Annals of the Institute of Statistical Mathematics, 56, 545-597 (2004).

11.Yoshida, N.: Partial mixing and conditional Edgeworth expansion for diffusions with jumps. Probab. Theory Related Fields 129, 559-624 (2004).

12.Hayashi, T., Yoshida, N.: On covariance estimation of nonsynchronously observed diffusion processes. Bernoulli, 11, 359-379 (2005).

13.Masuda, H., Yoshida, N.: Asymptotic expansion for Barndorff-Nielsen and Shephard's stochastic volatility model. Stochastic Processes and their Applications 115, 1167-1186 (2005).

14.Shimizu, Y., Yoshida, N.: Estimation of parameters for diffusion processes with jumps from discrete observations. Stat. Inferecne Stoch. Process., 9, 227-277 (2006).

 

著書 数理統計学朝倉書店 2006

学会 日本数学会日本統計学会,International Statistical Institute.

受賞 日本数学会2006年解析学賞,

第1回日本統計学研究業績賞(2007),

第14回日本統計学会賞(2009)

活動 Bernoulli Society, Executive Committee,

統計数理研究所リスク解析戦略研究センター客員教授,

日本統計学評議員

日本アクチュアリー会評議員

Statistical Inference for Stochastic Processes, editorial board,

8th World Congress in Probability and Statistics, Istanbul, Program Committee

2014-12-19

http://anond.hatelabo.jp/20141219020034

I was rejected by my best girl

My girlfriend left me

What plays a invaluable role for our study

What plays an invaluable role in our study

a simple model that explain

a simple model that explains

a large number of the descriptions

numerous descriptions

me and her

her and me

the way how

how

アブストを1 wordも書けてないけど彼女と別れたことをアブストっぽく書く

卒業研究がまるでうまく言ってなくて来週提出の卒論アブストが全く書けない現実逃避に。

English

I was rejected by my best girl nine months ago. It has been unclear the reason why they broke up despite the each other's intense love. In this thesis, we provide a clear explanation about the event.

What plays a invaluable role for our study is descriptions gathered from me about each incident that had happened along them. We were able to obtain a large number of the descriptions, since a winter chill in the air reminded me the divine memories of the days with her. We carefully examined each of them and arranged the incidents into some categories. By combing chronological order and categories of the incidents, we analyzed the emotional changes of me and her.

We propose a simple model that explain the breakup between them, based on the above mentioned analysis. From discussions about the model with some people, the model is considered to be capturing major matters. We also present our attempt to match the model to the existing collection of patterns of the way how once loved people would break up. Even though this attempt is not much succeeded, at least it reveals that what I experienced was quite ordinal breakup.

日本語

私は九ヶ月前に恋人から別れを告げられた.互いに強く想いあっていたにも関わらず彼らが別れることとなった理由は,不明瞭であった.本論文において,我々はこの出来事についての明瞭な解釈提示する.

我々の研究にとって非常に重要役割を果たしたのは,彼らに起こった事象に関する多くの私から収集された叙述である.冬の寒さが私に彼女と過ごしたかけがえのない日々を思い出させたおかげで,我々は多くの叙述を得ることができた.我々はそれらの一つ一つを注意深く調べて,幾つかの分類へと整理した.各事象についての時系列順と分類を組み合わせることで,我々は私と彼女感情的な移り変わりを分析した.

この分析に基いて,我々は彼らの別れを解釈する単純なモデルを提案する.本モデルについて幾人かと行った議論から,本モデル重要問題を捉えていると考えられる.さらに,かつて愛し合った人々がどのようにして別れるかのパターンを集めた既存研究と,本モデルを照らし合わせる試みを示す.この試みは十分に成功してはいないものの,少なくとも私が経験したことがありきたりな別れであったことを明らかにしている.

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2014-09-03

過剰なアニメ規制議論が巻き起こる原因に関する一考察

なぜか”良識派”と呼ばれる人々はアニメ規制したがる。

犯罪助長うんぬんと。

表現の自由をどうこう言って反発するのもいいが、

私の意見としては子供が見てトラウマになるような映像教育に”良い”影響があると思うから規制には反対だ。

悪夢にうなされたり、エロすぎて目に焼き付いて取れなくなる経験は大人になるために絶対必要である

殴られもぜずに大人になった奴がどこにいるのか!

さて、なぜこのような暴論が幅を利かせているのか。

しかしたら、この問題を扱う新しい切り口を見つけたかもしれないので報告する。

アニメなどの表現にはある程度の規制必要だが、今のままで十分である

にも関わらず、なぜ暴力的とも言える過剰な表現規制を唱える人が出るのか。

それは、人間の心理の持つ”慣れ”という性質から来るのではないか。

人間は同じ刺激を受け続けると、徐々に慣れて何も感じなくなる。

これを心理学用語では馴化と言う。

より詳しくは以下の文献を参考にされたし。

Thompson, Richard; Spencer, William (1966). "Habituation: a model phenomenon for the study of neuronal substrates of behavior". Psychological Review. No.1 73: 16–43.

http://www.cns.nyu.edu/~david/courses/perceptionGrad/Readings/ThompsonSpencer-PsychRev1966.pdf

アニメ表現規制を唱える人々は、馴化によって現状でも十分表現規制されているという認識を持てないでいるのではないか?

おそらく、昨今のアニメ表現規制を推進したい人々は、過去にも同じように何らかの表現規制運動に参加していたはずである

そして規制強化という成果を勝ち取ってきたはずである

自分たち運動が実を結んで社会を動かしたというのは、言いようのない快感であっただろう。

おそらくは非情に強いエクスタシーを感じたはずである

さら活動を続け、さらなる規制を獲得したことだろう。

そうやって日本表現はつまらないものになり続けてきた。

だがそれも、2度、3度と繰り返す度に馴化によって何も感じなくなってしまったのではないか?

彼らは表現規制中毒となっている可能性がある。

一度オナニーを覚えたら、定期的にせずにはいられなくなるようなものだ。

努力問題を克服した時の快感は何にも代えがたい。

ダイエットという問題を克服した快感が忘れられず、ダイエット中毒になって骨と皮だけになる女子高生だっている。

同じことではないか?

彼らが理性的表現規制不要論に耳を貸さず、なんら科学的、統計的な根拠のないアニメ犯罪因果に固執する原因となってはいないだろうか?

私には彼らこそ、十分な休養を取りながら広い社会と交わり、自らの偏狭的な関心と生産性のない快楽主義を克服すべき存在に見える。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん