北極海航路の話
先週、面白そうなセミナーを教えてもらったので聞いてきた。
概要
温暖化で北極の氷が溶けて新しい航路(NSR,Northern Sea Route)が開けるので活用できないか、というテーマで各方面の議論がなされている。 ゴルバチョフのNSR開放以降、船舶種類(アイスクラス)に関するロシアの規制緩和もあり、活用が増す見込みである。 トランジット(横断輸送)が主だが、クルーズや研究船の需要もある。
これだけ書くと温暖化で喜ぶ人たち、という印象になってしまい批判もある。 フェアになるように書くと、NSRの活用で燃料資源の消費が減り、資源輸送のための陸上パイプラインの開発に比べても環境影響が小さいとのこと。
インド洋航路が海賊問題をかかえる一方、NSRの優位性は(燃料価格の影響もさることながら)ロシア情勢に大きく依存し、短期的には逆風もある。
日本の立場
日本は地政学的にNSR発展の影響を受けやすく、また実は北極海探査の歴史もある。 内閣も日本初の北極政策を発表したばかりである。
覇権史における北極海の意味づけについてはより専門的な記事*1に譲るとして、かなり多岐にわたるトピックがあったので、実際の航行に際してどういう問題を解く必要があるのかを外野からどうにかこうにかサマリする。 資料もそのうち出揃うはず。 (誤った理解があればごめんなさい)
氷況観測
氷海船舶には耐氷船と、海氷を排除・砕氷して耐氷船をエスコートする砕氷船がある。 氷が減ると、NSRが開けたぶん航行船舶は増えるので、トータルでの航行リスクは上がる*2。 ということでまず氷をどうにかする、とくに現在の氷の分布を把握し予測する技術の発展が望まれる。 氷の量(海氷密接度)のほか厚さや種類は重要な情報で、既存ではさまざまな測定方法がある。
氷況予測
様々なデータから、大きく3つのスパンで今後の氷況を予測する。
短期
航海中船舶の航路決定に必要な、2日間程度の天気予報情報。
予測のメッシュを数km程度の解像度にすることでアイス・アルベド・フィードバックや中規模の渦構造の再現精度が上がる。 氷海流出油のハザードマップを作るというような応用もある。
サービス界隈で身近なところだと、ウェザーニューズ社が既にこの領域に入っていて、NSR航海の実体験の報告が行われた。 北西ロシアのムルマンスクから天津まで23日程度の航行。 現場では他船からの電話連絡を受けてから1時間(!)程度で結氷する。 運がよいとオーロラが見えたりホッキョクグマを観察できたりもする。
中期
配船計画に必要な航行可能時期の予測を4月頃に出す。年間では9月中旬が最も氷が少なくなる。 航路が開けるかどうかは氷面積だけでなく氷の厚さにもよる。 氷の厚さの直接観測はまだ精度が十分でないので、冬の氷の移動状況から氷の厚さを推定する。 ずっと存在する氷よりも、氷が移動してできた隙間にできたばかりの氷はまだ薄くて夏に溶けやすいはず、ということである。 Sea Ice Outlookという予測発表があって日本の研究チームは好成績を出している。
長期
30-50年程度のスパンの投資・造船計画に影響する情報の分析を行う。 氷況に加え、ヤマル地域のLNG*3など沿岸の経済活動との相互影響もありそうだ。
着氷
航行中に上げたしぶきが船体に着氷してしまう(昔は着氷の重みによる転覆もあったらしい)。 酸化チタンのような塗料での予防は現在難しい。 着氷傾向は気象・氷況からの経験式があるものの、船体形状や航行速度にも依存する。 着氷の成分や構造、着氷過程を知ったりそれを排除する必要がある。 観測には飛砂や吹雪の粒子観測機器を転用したりする。 船体形状から気流の観測を行う必要もあるが、CADデータが公開されていることは少ない。 最近は複数角の写真からモデリングが行えるのでそれで十分なことも多い。
波浪
海氷のダイナミクスにおいては波浪も重要である。 氷海では分散関係や風との相互作用が通常の海洋と異なり波浪の物理も変わる。 また氷海と通常の海洋の境界は年次、年間で大きく変わるという点も従来の波浪学にない側面である。 既存モデルに対して、スペクトル領域と時間領域をつなぎ、さらに数値計算に適した新しい物理モデルが模索されている。
その他の気象学・気候学的情報
海氷予測だけでなく中緯度帯の気象とも密接にリンクしているという意味で、極地の気象観測の重要度が増しており、諸プロジェクトも稼働している*4。 例えば極低気圧は発生・消滅サイクルが24hと短く、既存の時空間解像度では捉えきれない。 着船する港では潮位の情報を必要とするが、これに関しては北極海は衛星がカバーしない海域で、まだ予測誤差(潮位・ピーク時間)が大きい。
氷中航行
相手は氷なので衝突の衝撃や曲げによる荷重は馬鹿にできない。 衝突時のエネルギー変換から船舶にかかる荷重を求める経験モデルで計算したり、氷に見立てたプラスチック片と船舶模型の衝突実験を行ったりする。
- 迅速に砕氷しないと航路が渋滞してしまう。
- 耐氷船のサイズに合わせて砕氷船を並進させる場合もある。
- 状況によっては海氷中で砕氷しながら旋回したりバックしたりもする。
海氷を排除するか砕氷するかの判断は船と氷のサイズ比較で経験的に行う。 一方耐氷船は耐氷船で、砕氷船による排除の後に流れてくる氷を手動操縦で避けて通らないといけない。
航路選択
船舶が目標とすべきマイルストーンのネットワークとして氷海をモデリングしたり、ダイクストラ法やA*アルゴリズムで航路を決定する。 海氷分布の実データは船舶搭載のレーダの画像解析により動的更新される。 航行速度のデータは海運会社から公開されていないが、氷況記録や航行実績から推定する。実際の航行時間には砕氷船のエスコート待ちも含まれるのでより複雑である。 また極を通る航路が選択される時もあるが、沿岸から離れすぎるのはそれはそれでリスクなので何かしらの調整を入れる*5。 最適航路や航行時間の変化の長期予測も視野に入る。
感想
情報学や工学に似て、寄ってたかって集められた様々な知見を垣間見た一方、環境影響や生態学、安全保障のような海洋の周辺の各論が網羅されているわけではなさそうで、現段階の予算的にはエネルギー開発と海運がなんとしても重要という印象を受けた。
全く個人的だが北極海と聞いてふと思い出すのは、あるとき見たロシア映画 How I Ended This Summer だ。 孤立した極北の気象観測所で働く老人とインターンの青年の、致命的にこじれていく(それも放射性物質の周りでくるくると)関係を描くこの一作は、観ていていかにも心が寒々としてくるのだが、半世紀後のテクノロジーに囲まれた北極海の風景はまたがらりと変わっているのだろうか。
*1: 北極海航路の開拓が起こす、世界規模の地殻変動:日経ビジネスオンライン
*2:このあたりはドローンや自律運転とも状況は似ていると思う
*3:これはこれで難航しているようだ:米国の制裁で資金難、ロシア・ヤマルLNGプロジェクト - WSJ
*4:プロジェクト例:
- WWRP,World Weather Research Programme
- YOPP,the Year of Polar Prediction
- ArCS,Arctic Challenge for Sustainability Project
*5:コスト関数の調整?
#Deeplearning4J のMeetupを手伝った話
先週になるが、ディープラーニングのフレームワークのDeeplearning4Jの開発メンバーが来日されていたのでMeetupを手伝っていた。 YAPC::Asia(手伝ってないけど)に続き、合宿のような濃い一週間だった。
- 8/25: 開発メンバー、スタッフと合流、顔合わせ。
- 8/26: 全脳アーキテクチャ勉強会でのドワンゴ山川氏との対談。今回は全体のテーマがディープラーニングで、統計力学や多様体の話もあってなかなかキャッチアップできなかった。
- 8/27: Yahoo!でフレームワークのハンズオン勉強会。
- 8/28: 日経のStartup Xでのトーク。同時通訳機が足りないので通訳さんの日本語をひたすらIRCに打ち込んで会場に届けるのを手伝った。
- 8/29: CAでニューラルネットワークの勉強。4hくらいわいわい英語で数学の話をしていた。焼き魚を一緒に食べたり本郷に移動したりして結局一日中一緒だった。魚が好きな開発メンバーがいて喜んでもらえた。
もちろん事前の準備もいろいろあったが、連日会社が終わってから馳せ参じたので疲れが意外にたまっていたらしく、終わった翌日は結構寝てしまった。結局昼から飲んでたけど。
こういう縁は(自分が好きなのもあるが)たまにあって、6年前にMarrisa Mayer氏がGoogleの新卒を連れて京大に来たのでゲリラ的なツアーを組ませてもらったときもお手伝いできて楽しかった。今回は自分でも実際にフレームワークやScala,Spark,IntelliJ IDEAついでにAtomに触ったり、処理系やJVM,GCにも興味が出るきっかけになってなおよかった。 一方で、ディープラーニングの全体像は未だに飲み込めていない。分散処理屋さん、人工知能屋さん、脳科学屋さん、と立場によって捉え方が少しずつ違うのも理解しておきたい。
開発コアのAdam氏はO'Reillyからの出版予定がある。
Deep Learning: Dl4j and Beyond
- 作者: Adam Gibson,Josh Patterson
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2015/11/25
- メディア: ペーパーバック
- この商品を含むブログを見る
ディープラーニングは自分の中ではハードルを設定してしまってつかめていない領域なので、とりあえず手を動かして少しずつでも理解を深めていく原体験は大事だと思う。 気づかぬうちに人が学ぶ妨げとなることがないように、自分も気をつけたい。
ぼくのさんかしたさいしょでさいごのYAPC::Asia Tokyo
YAPC::Asia Tokyo 2015 に参加した。
- Perlに近い環境にいながら最初で最後の参加になってしまったが、行ってよかった。
- H2Oやio.js,Electronのトークも是非聞きたかった
- 941さんはエンジニアだと思っていた
- 懇親会チケットが必要なことには気づいた頃に完売してて悔やまれた
- antipopさんの動画のインパクト
- hitode909さんベストトークおめでとうございます!
- スタッフの皆様、10年間おつかれさまでした!
資料・動画も公開されると思うので、以降はメモ以上のものではありません(不正確な記述があればごめんなさい)
8/20(前夜祭)
『言語開発の現場』
- @hsbtさん
- Ruby
- いろいろな実装 どこまでがRubyなのか問題
- 開発に関わる人の種類
- comitter(Ruby Core Team)
- branch maintainer
- platform maintainer : 好意でプラットフォームごとのサポートをする
- 権限
- 権限をもらったらどこへもcommitできる
- 一度直すことになったら最後まで自分で直す覚悟
- github : proprietaryなのでつかわない
- OSS開発も普通の開発とおなじ
- write code
- take care of development resources
- focus use case
- release management
- developer meeting : 英語圏developerとの距離の解消
- releaseが大変
- 2hですむはずが4h(?)かかっている
- 自動化できてない
『はてなブックマークのトピックページの裏側』
- @5kozawaさん
- はてブにおける過去の試み
- クラスタリング
- トピック編集
- トピック生成
- トピック=キーワードの集合
- ElasticSearch の Significant Terms Aggregation 機能
- Amazon ElastiCacheのノードが6台
- JLH score
- 出現割合を加味したスコアリング
- 絶対割合変化 x 相対割合変化
- トピック生成は時間がかかる。2hおきにつくっている
- 新語が多いので辞書作成が追いつかない
- トピックタイトル生成
- 要約技術の一種
- キーワードを羅列すればよいわけではないので並び替える
- 一つ一つの記事のタイトルはちゃんとしているので、どれかの記事のタイトルを使えばよい
- 係り受け関係に基づく文圧縮
- アプリだと短いタイトルのほうがよい。10文字以内が目標
- 毎年のYAPC::Asiaのトピックの抽出には成功している
『技術ブログを書くことについて語るときに僕の語ること』
- @y_uuk1 さん
- ブクマを稼ぐ技術
- タイトルが9割
- (笑ってて詳細メモるの忘れた)
- 哲学
- QA
- モチベーション
- ブクマ数
- 特定のエンジニアにブクマされるかどうか
- 会社として書く vs 個人として書く : 自分のブログのほうがモチベーションはあがる
- 古い記事の修正 : あまりやらない。むしろ新しく書き直すこともある。
- タイトルしか読まれてなさそうなもの : 傾向まではつかめていないが、内容が丁寧だと読んでもらえる気がする
- モチベーション
8/21
『メリークリスマス!』
- PerlのパパLarry Wall
- Perl5(Hobbit)とPerl6(Lord of the Ring)は実は同じ物語
- Perl5
- Perl6
- お知らせ : 2015年のクリスマスにはリリース予定(ただしバスにはねられたりしたらどうなるかわからない)
『Effective ES6』
- @teppeisさん
- サイボウズ、Kintone
- Web+DBのES6はmust buy
- ES5
- 落とし穴の例 : newをわすれるとグローバルがかきかえられる
- ベストプラクティス、どちらかといえばワークアラウンド
- ES6
- modern syntax
- 大規模アプリケーション開発も容易に
- 後方互換
- ベストプラクティス・AltJSの一部機能が不要になる
- ES6はいま使えるのか
- compat table : IE11は対応しない
- ES6を始める方法
- とりあえずBabel : Babel REPLで試せる
- transpiler
- ES5の機能だけを使うコードに書き換える
- Babelならブラウザごとにtranspileをやめるタイミングなどもきめられる
- polyfill : ES6ビルトインクラスを提供する
- ESLint
- new syntax
- arrow function:
Array.filter
にかますときべんり - (ES5)assign this to selfのreplace (ES6)スコープ外のthisがarrow func内から呼べる
- (ES5)プロトタイプベース => (ES6)クラス、継承ベース
- (ES5)グローバル依存のモジュール、commonjs依存(exports,browserify) => (ES6)export, 静的解析しやすくなる
- use strictが不要になる
- (ES5)function scopeしかなかった、巻き上げ(hoisting)が発生していた => (ES6)block scopeができた
- (ES5)var => (ES6)let,construction
- default parameters
- rest parameters
- destructuring(分割代入)
- template literal
- Generator
- arrow function:
- new built-in classes
- Promise : エラー制御改善、非同期の明示
- (ES5)objectをdictionaryとして使う (ES6)Mapクラス
- 既存クラス拡張
Object.assign
(shallow copy)- サロゲートペア対応
- AltJSは不要になるのか
- CoffeeScriptは、インデントの書き味以外の優位性は残らない?
- TypeScriptの型をとりいれるかどうかは議論中
『TBD』
- Matzさん
- 言語デザイナー
- Rubyの反省点
- アーキテクチャの変化
- マルチコア
- スレッドセーフ
- 人類には早過ぎる
- immutableをもつ関数型言語が評価されてきた
- スレッドセーフでない外部のCライブラリから守るためにGILを導入した
- Rubyの今後
- Rubyと違う判断
- Streem
- まとめ : 言語デザインは楽しい
- QA
- 型
- 短いスクリプトを書くという理想に反する
- 「絶対に型を書きたくないでござる」
- 言語デザインのインスピレーション
- 既存言語の成功例をとりいれる
- 既存言語の問題点を改善する
- 日頃のアイデアを形にする
- 楽しい瞬間 : 作っている言語でHello Worldが表示された瞬間
- この業界、コンパイラに対する共感能力高い人が多すぎる
- 型
『Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜』
- @hitode909 さん
- イケてるサービス
- 役立つ、楽しい、早い、かっこいい、イメージが良い
- 開発を継続する : 一貫した指針などが必要
- 社内フレームワーク
- はてなブログのスクラッチ
- cho45さん,2011
- 薄いフレームワーク
- 読むコードが最小
- ORM使わない
- 継承しない
- 3回コピペするまでは共通化しない(DRY3)
- Service
- オブジェクト指向設計入門
- 契約による設計 : 事前条件、事後条件
- 責任外のことをチェックしない
- 設計としてはよいが、言語的な支援がない
- リファクタリングのためにPerl静的解析
- YAPC::Asia 2014
- 特定トークンの置換
- DDD
『PietでLISP処理系を書くのは難しい』
『esa.io - 趣味から育てたWebサービスで生きていく』
- @fukayatsuさん
- 大事なこと : いろいろ試して失敗する, 公開する
- 事業化まで
- 反省 : チーム申請を待たせすぎた
- 楽しく開発したい
- 自分が楽しく開発することで最終的にユーザーに価値を届けられる
- 楽しさ、モチベーションは複雑で直接コントロールできない
- 制御可能なものを見極める
- 開発のリズムをつくる : botに毎日bundle updateをさせてpull reqをつくらせる
- bugfixを競技感覚でできるだけ速く本番反映する
- フィードバック駆動開発
- 5分以内にメール返信
- 直せるならすぐデプロイする
- 自分がされて嬉しい事をする
- リリースノート駆動開発 : 自分自身がユーザー
- 週7日間プロダクトに触れる
- ユーザーサポートをやっている人が意思決定してデプロイする
- スケジュールを決めない。要望が多いものから対応する
8/22
『Mackerel開発におけるScalaとGo、そしてPerl』
- @songmuさん
- はてな, Mackerel
- Mackerelの技術スタック・言語の多様性 : LVS,nginx,Scala,Go,PostgreSQL, Redis, AngularJS, TypeScript
- Scala
- Go
- Perl : まだ使ってる。Web構築する力はある
- Ruby : fluentd, chef, capistrano
- 自動化
- 属人化をふせぐ : 知見のないメンバーに敢えてレビューさせる
『NASA主催の世界最大級ハッカソンSpaceAppsを運営した話』
- @yumu19さん
- 昨今のハッカソンのテーマはいろいろ : 「家」「オフィス」「100円ショップで買えるもの」
- International Space Apps Challenge : NASA, 世界142都市(日本5都市)同時開催
- 東京
- 150名程度の参加
- DMM.make
- ワークショップも並列開催 : ハッカソン以外の方法でも宇宙・データ・科学などに親しんでほしい
- Bostonとのコラボしてるチームも
- H-IIA寿司
- これまでの成果
- 事務局 : 全員ボランティア
- 準備
- 重要なこと
- コミュニケーションの量
- ドキュメンテーション : 941さん・牧さんのYAPC運営引き継ぎ記事がとても参考になった
- QA
『データ分析基盤を支える技術』
- @repeatedlyさん
- TreasureData
- (追い切れなかった・・)
- Data Analytics Flow: collect, store, process, visualize, report, monitor
- RDBMS
- single server
- popular, huge ecosystem
- ETL(extract,transform,load)
- online transaction
- parallel RDBMS
- optimized for OLAP workload
- Netteza,Teradata,Vertica,Greenplum
- columnar storage
- compute nodeにstorageがくっついているのでwriteが待たされる
- distkey, sortkey : 設計ミスるとノード間通信が発生してしまう
- schema management
- superstition
- "SPOF"
- "cannot build from a scratch"
- tools
- ingestion tools : bulk load / streaming load
- bulk load tools : Embulk, Sqoop
- streaming load tools : Fluentd, Flume
- MPP query engines
- Apache Storm : low latency, micro batch
- Norikra
- Apache Kafka : distibuted messaging, pull(stream control)
- Amazon Redshift, Kinesis
- Google BigQuery, Dataflow
- Treasure Data (Data Lake)
- Resouce Model trade-off
- Fully guaranteed: non boost mechanism
- Guranteed with multi-tenanted
- Fully multi-tenanted
- use service/build a platform
- Tableau (visualization)
『Parallelism, Concurrency, and Asynchrony in Perl 6』
- Jonathan Worthington
- Supply is the dual of seq
- react : scalaのreactと同じ?違う?
『HTTP2 時代の Web』
- @Jxck_ さん
- HTTP2のgolang implementation
- mozaic.fm
- http2study : issue-thonなど
- 国内のHTTP2界隈のプレゼンス
- nghttp2
- H2O
- ほんとうにRFCになった : 日本のコミュニティへの言及もされるほどの成果が出た
- HTTP2は策定フェーズから使うフェーズへ
- webのパフォーマンス
- 現状
- コンテンツサイズ 100 reqs, 2MB/page
- 帯域増加よりレイテンシの削減の効果が大きい
- アプローチ
- Round Trip Timeを減らす : 物理的に近づける
- Round Trip を減らす : アクセスを減らす、キャッシュする
- 現状
- HTTP1
- HTTP2
- バイナリフレーム : パースしやすい、分割可能
- GETなどのsemanticsは後方互換
- HPACK
- Huffman圧縮
- 頻出ヘッダを共有
- 送信済みデータを再利用
- 圧縮率は実装次第 http2studyでは8割圧縮
- コンテンツ優先度制御 : 画像よりCSSが先に届く、など
- head of line blockingの解決 : コネクションを使い切る
- Server Push
- JSなどの依存コンテンツをブラウザにキャッシュさせる
- cache control :実際にはbrowserのcache領域の奪い合い(48hで78%の人が使い切る)
- Service Worker
- 実装はまだないが議論中
- HTTP2 Pushを受け取れる予定
- フロントエンドのプロキシとしてjsを動かす
- HTTPがPushのセマンティクスをカバーする
- 検討事項
- 今後のHTTP2の動き
徒然 2015/08/09
8/9
- Simulating Social Complexity 勉強会: Chapter11(Combining Mathematical and Simulation Approaches to Understand the Dynamics of Computer Models)
- 擬似乱数の代用としての物理乱数(例:ガイガーカウンター)(再現性の理由で採用されないケースも)
- minority game とdeep learningのどちらが株価のようなパターンを本質的に生成できるか?
- スパ帝によるゲームAIの強さの話。攻略する余地をのこす。
- タスマニアにおける文化後退の話。社会がどのようなfinal stateへ移行するかの分水嶺を考えたときに人口がファクターとなるかどうか。
- circumstance description theory
- ポリネシアの食生活 タロイモが支えられる人口をシミュレーションされた人口が上回ると国家ができる
- Markov Chain(本章のメイン)
- 遷移行列が陽にわからなくても、数回の試行での結果から論じることができる
- MCとプッシュダウン・オートマトンの関係
- MCとRNNの関係は?
- 効率的市場仮説
- weak/semi-strong/strongの3種類ある金融経済学 - Wikipedia
- 株式会社が永続化できたのはなぜか?東インド会社がきっかけ?
- 江戸時代に先物取引はあったか?
- その他の話題についてはこちらも。【勉強会】SSC輪読会 Vol.5を開催しました! - 歩いたら休め
8/8
- deep learning関連のmeetup。手動かせてない。
- DeepLearningと全然関係ないが、ウィーナーのサイバネティクスの話になり、昔読書会やりたいと思ってたの思い出した。
8/7
- asanaのカレンダービューが結構いい感じであることに気づいた。やることをほぼ一元管理できて、slack integrationもあるのであとからログを追える(ただし、ログはこのままだと流れるので注意)
- 下痢・発熱(38.5度)・頭痛で3日間ダウンする。かなり久しぶり。
8/6
- Goodpatch土屋さんとご飯食べる。2011年のシリコンバレーツアー以来で懐かしくなる。ベルリンの話など聞く。
- 魚がしでうなぎの炙りを食べる。
- Terminator Genisys見る。
8/4
- TypeScript, Dartをしらべる
- output用のSlackをつくる。input用のSlackは前からあるのだけど無償だとログがすぐ流れてしまうので、情報の重要度的に分けたほうがいい気がする。
8/3
3/5 機械学習勉強会メモ
全脳アーキテクチャ若手の会の勉強会と懇親会に参加。今回のテーマは時系列処理。
ドワンゴ初めて行った。
関心
ちょうどセンサデータを扱っているのでタイムリーだった。 学部で物性の実験をやっていたときはまず時間自己相関をみる、だったが、生物・制御・経済・社会情報になると古典的情報理論をはじめとしていろいろな時系列アプローチがある気がする。 機械学習では、RNNが定番かと思っていた(tanichuさんもRNNを組み合わせてピアジェのシェマの実装をされていた)。
コミュニケーションするロボットは創れるか―記号創発システムへの構成論的アプローチ (叢書コムニス13)
- 作者: 谷口忠大
- 出版社/メーカー: エヌティティ出版
- 発売日: 2010/03/29
- メディア: 単行本
- 購入: 1人 クリック: 5回
- この商品を含むブログ (7件) を見る
が、それ以外にもいろいろあるようだ。
話題
時系列処理
複数の情報(たとえば視覚)の間に時間的相関を発見し、さらに未来を予測する処理、と理解。
主要なモデルの導入
- Recurrent NN
- Elman networks: 中間層の出力を次の入力に使う。文法学習に適する。
- Jordan networks: 出力層の出力を次の入力に使う。運動学習に適する。
- Echo State Network
- 学習が速い。
- 合成波・正弦波・決定論的カオス波の識別が可能。乱数波や、声の波形もおそらく識別可能。
- Time Delay Neural Network
後で調べる
- Long Short Term Memory
- Reservoir Computing
- Convolutional NN
脳の情報処理との関連
時系列処理を担う機構が海馬にあると思われるのはいいとして、大脳新皮質にもあるかどうか、という話。
昔話
SVMとNNの勢力交代について。たしかに一時に比べるとSVMってあまり聞かなくなった。
感想
どのモデルがどういう問題に適するのかの理解のためには実装が一番速そう。 若い人(学部生)が多いが議論のレベルが高く刺激になる。
12/22 評価経済勉強会メモ
@Geek Office Ebisu
初参加。自分の言い換えや妄想も入れてなぐり書き。
- 岡田斗司夫氏の贈与経済論と斉藤賢爾氏の貨幣論をヒントとする
- 伝搬投資貨幣PICSYに似た評価経済システムの実験場としての勉強会
- 交換、贈与、純粋贈与
- 交換経済から贈与経済への揺り返しについて
- 生産コストの減少、サービスのフラット化
- Makersムーブメント
- AirbnbのクーポンやUberのpromotion codeのような、貨幣以外での取引の増加
- 分業の終焉
- 生産コストが低くなった財・サービスについては交換自体が無意味になる?
- 生産コストの減少、サービスのフラット化
- 財の稀少性の問題
- 絶対量の問題というよりむしろ文化や認識の問題でもある。他国の金の地位を日本では銀が占めた。
- 貨幣の現在
- なめらかな社会
- なめらかな社会とその敵*2
- PICSYの理論をいろいろな社会領域に発展させた
- 例えば二値でないジェンダーは考えられる*3
- なめらかな社会とその敵*2
- 家族論
- マネーゲームはどこから切り崩されうるか
- 米国富裕層には実質的独立や社会の分断を意図している人々も
- 政治的影響を強めるgated community
- “独立”する富裕層 - NHK クローズアップ現代
- 米国富裕層には実質的独立や社会の分断を意図している人々も
- 岡田斗司夫氏について
- クラウドシティ
- FREEex
- いずれにしても魑魅魍魎が住まっているということはわかった。。