トップ «前月 最新 翌月» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2018-10-01

_ structual subtyping

https://twitter.com/kazuho/status/1046566559160791040

とはいえ直行もしてないという理解で、コンテナ以外の用途はたいてい structual subtyping で十分ではあるんかね

クラス template の用途て何があるんだっけ

  • コンテナ
  • static duck typing と僕が呼ぶもの (algorithm とか)
  • TMP

あたり……だけ?

(11:07)

_ huawei

https://smhn.info/201809-huawei-oppo-benchmark-test

僕のスマホでも試してみるかな

(15:00)

_ KotlinConf

https://www.linkedin.com/pulse/talk-amsterdam-nikolay-igotti/

なんだかわからないけど面白そう。少し知った人

(15:04)


2018-10-02

_ むっちゃおもしろかった

パタソン先生 on CPU

https://atscaleconference.com/videos/scale-2018-keynote-a-golden-age-for-computer-architecture/

(23:24)


2018-10-03

_ ABC

https://www.quantamagazine.org/titans-of-mathematics-clash-over-epic-proof-of-abc-conjecture-20180920/

どうも間違ってたぽいという話がある、と聞いてせつない。説明を読んでみると実際結構ダメそうな雰囲気なんだなあ

変わった物の見方するユニークな人だけど、 ABC 予想を証明した大天才らしい、なんかすごい、から単なるユニークな人になってしまうという落差(いやそれでも偉大な数学者なんだろうけど。。)

(23:48)


2018-10-04

_ MNIST in Excel

https://www.youtube.com/watch?v=yKt7SI6vexc

既存研究だったか…

(01:37)


2018-10-12

_ proto 批判

http://reasonablypolymorphic.com/blog/protos-are-wrong/

proto はもっとよくできる、と直感的に思う、が、この批判は的を射てる部分もあるけど、外してる部分もあるように思う。 wire format への言及が無いけど、わかった上なのかどうかよくわからない。

現状の問題はこうすれば良いよ、と書いてある点については、要するに普通のプログラミング言語に近付けるということであるけど、シリアライズフォーマットというのは当然プログラミング言語と違うわけで、デシリアライズされた構造体をどこまでリッチにしていっても、結局はホスト言語の機能をフルに使う場合はホスト言語で自分で書いたクラスに移し変えるなり、 proto を持ったクラスにサポート情報を保持して使うことになると思う。そうならないシリアライズフォーマットは、 Smalltalk とかそういう世界観だけな気がする

具体的な例としては、参照みたいなのがまず欲しくなってくるものの一つとしてあって、 YAML とかだと参照があったりするけど、それを足したとしても、今度は、検索が線型より速い構造が欲しいとか、なんだかんだでホスト言語側の機能で自動生成されたコードを補うコードを書くことになると思う

で、どうせ補うコードを書くことになるのであれば、シリアライズフォーマットの仕様はリッチすぎず(ところで最初に批判されてる oneof と map はどちらも後づけ syntax sugar みたいなものだという理解)、便利さと速度やフットプリントのトレードオフがあれば、常に速度&フットプリントの方に倒す、というのは理に適っていると思う。 proto の改善できる部分のうち、どの部分は速度&フットプリントを犠牲にせず使えるかは、ぱっとはわからないなあと思う

API (C++ と Python だけについて書いています) について、 proto は読む方の API はまあ普通で、問題はあると思うがかろうじて苦労なく使えるレベルだと思う。新規にデータを作る時の API も、こっちは多少苦労する程度に気持ち悪い API ではあると思うけど、まあ覚えればなんとかなる。

ただ、 proto の編集は批判されている通り、困った問題が起きることが多い。ただ、それはこう、データを編集しなければならないならちゃんとホスト言語の構造体に移しかえて、編集が終わったらデシリアライズしなさい、というだけのことかなあと思う。めんどくさいよーと思うかもしれないけど、

int LoadInt(FILE* fp) {
  int v;
  size_t r = fread(&v, sizeof(v), 1, fp);
  if (r != 1)
    return -1;
  return v;
}
bool LoadString(FILE* fp, string* s) {
  int len = LoadInt(fp);
  if (len < 0)
    return false;
  s->resize(len);
  size_t r = fread(&(*s)[0], 1, s->size(), fp);
  if (r != s->size())
    return false;
  return true;
}

みたいな関数をいちいち作ってやるのに比べればマシだしねぇ…

なんか、 proto 作った時に、アプリケーション固有の proto と対応した boilerplate コードを作りたい時がある気がしていて、そういうのが作りやすいと良い気がするなぁとか思う。直近での対処は proto とアプリケーション固有コードを両方とも生成することで対処したけど、まあこれで十分という感もある

(18:48)


2018-10-23

_ レビューとビジネスマナー

https://twitter.com/poly_soft/status/1053466632561905664

を見て、

  • まあ普通にレビューとかで丁寧な口調で言って損することは無いよねえ
  • 間違ってます、って言うより、問いかけによって相手に自分で間違いに気付いてもらう方が上策だし、本当は自分が間違ってた時にも恥ずかしくないし
  • 言うて自分も気がついたら妙に攻撃的な言動してる時あるわけだが……

とか思って、しかしツイターの観測範囲では、「プルリクでマナーとかwwwエンジニアはマサカリ投げてなんぼやろwwww」みたいな(ここまでひどい表現はあまり見なかったけど)のも多く目に入るような気がして、うーんとか思ってた

https://twitter.com/nhiroki_/status/1054392924014661632

を見て、なるほどー、そういえば一番最初のツイート自身がビジネスマナーもへったくれもない感じやんけ、と気付く

(23:28)

_ Is this intentional?

丁寧な表現て、基本的にちょっと無駄に長くなりがちで、 "This code is wrong" より "I'm confused :( Could you tell me how this code works?" とかの方がそりゃ丁寧なんだけど、特に英語とかだと面倒で、ぶっきらぼうになっちゃう現象というのが、まああると思う

そういうことを考えていると、 akr さんの提案しておられた、英語バグレポは "Is this intentional?" だけでいい、てのは短いにも関わらず、相手に自分で間違いを認めてもらうスタイルで、すごい完成度高い定型句な気がする

http://www.a-k-r.org/pub/2015-11-08-oedo-rubykaigi-05-akr.pdf

(23:32)

_ なんか

デジャビュ感しかなくて、こういう話定期的に考えてる気がするなと思った

http://shinh.skr.jp/m/?date=20100426#p03

(23:47)


2018-10-26

_ LUT network

http://ryuz.txt-nifty.com/blog/2018/10/binary-deep-neu.html?fbclid=IwAR0wuQ4LTgg02yc7HrML-gNaX-xn_P1EexIH73ZCDXUU8M1eNZu9frvMeW8

いいはなし。これ光学 NN と同じような衝撃がある

(00:37)


2018-10-28

_ 英語むず

https://twitter.com/realDonaldTrump/status/1055719340832686080

yet when I criticize them they go wild and scream, “it’s just not Presidential!”
  • them == テロ
  • they == フェイクニュース
  • 以降主語、発言者はニュース?

(13:20)

_ affinity

https://github.com/google/kati/pull/154

これ発見に苦労して迷惑かけただろうな…ホントすいません系

(13:21)

本日のツッコミ(全4件) [ツッコミを入れる]

_ mak [トランプのは英語が難しーていうか、文脈なしでこれだけ見てもよくわからん、という話ですな。この they / them..]

_ shinh [あーなるほど詳しい説明ありがとうございます!トランプといえどテロは一言批判するのでは?という思いこみから、「俺もテロ..]

_ mak [普通に考えたらあり得ない亊言ってすぎで自分の解釈を疑う、ってのは微妙に英語あるあるな気がする。。。]

_ shinh [なんか、基本的にグーグルの人いい人ばっかだから、「あれっ」と思っても、ポジティブな方向に解釈すればそれが正解、という..]


2018-10-31

_ Mesh TF

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00141/102800030/

直接関係ないけど、 TensorFlow はクラウド屋とエンジニアの発想と持ち物で実装していったところ、設計をことごとく間違えた、みたいな印象を持ってる。まあそのくらい大きな問題にならないくらいの体力があるのがすごいって話だが…

(12:34)

_ 続 affinity

https://github.com/google/kati/pull/156

ほんと、こういうのでパフォーマンスが良くなるのって、 linux kernel の方でなんとかして欲しいという感が

(14:47)

_ 論理が

https://www.trendmicro.com/ja_jp/about/announce/announces-20180912.html

ところどころつながってなくてすごい

仮に「セキュリティソフトを良くするために情報収集が必要である」が真だとしても、許可なく集めて良いことにはならないしなあ

悪意は無い、と書いてある部分は、まあそうなんだろうなぁ、と思うので、つらいなあという感じ

(18:18)


2018年
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
1.shinh(2018-10-30 23:46) 2.mak(2018-10-29 13:13) 3.shinh(2018-10-29 11:40)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h