情報更新

last update 09/28 08:55

ツイート検索

 

@genkuroki
サイトメニュー
Twilogユーザー検索

Twilog

 

@genkuroki

黒木玄 Gen Kuroki@genkuroki

Stats Twitter歴
3,822日(2010/04/13より)
ツイート数
196,734(51.4件/日)

ツイートの並び順 :

表示するツイート :

2020年09月28日(月)82 tweetssource

2時間前

@glegory

グレッグ@glegory

長期金利もゼロ近辺で推移しディスインフレ、円安にもならず、戦後最大の不況の最中に財政再建の必要性を訴える。完全に狂っている。この国は狂人がコントロールしているとしか、考えられない。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 08:37:23

2時間前

@musicisthebest_

k@musicisthebest_

@sekibunnteisuu ネタだったらなんぼかマシ、かな? どっちにしろたぶらかされる学生さんがかわいそう
。もしやこういう反応の方がネタ?
以前あった、√( )/2に0, 1, 2, 3, 4を入れると順にsinの値が出るしょうもな暗記法にも、なぜだかしらんけど支持が集まりましたよね。みたことない操作はそれだけで受ける説。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 08:36:01

2時間前

@musicisthebest_

k@musicisthebest_

bが偶数のときの公式が覚えられないなら、別に覚えなきゃいいわけで。一通りのものを簡便のために別に表したものをわざわざもとに戻して、その上で使い方だけ二つに分離してもはや何がやりたいのかわからない。そしてこれに「わかりやすい」の感想がつくのがさらにわからない。 twitter.com/takatasenseiw/

Retweeted by 黒木玄 Gen Kuroki

retweeted at 08:35:50

7時間前

@KenoFischer

Keno Fischer@KenoFischer

But regardless, failing to acknowledge the trade-off, I think precludes discussions about how one might design a system that lets users gradually transition from programming in an exploratory/dynamic world view to taking advantages of static checking.

Retweeted by 黒木玄 Gen Kuroki

retweeted at 04:03:31

7時間前

@KenoFischer

Keno Fischer@KenoFischer

Static languages often presume that you basically have all the information (the more information your static system can represent, the more you need to know) about how your program behaves ahead of time, so it can be properly checked. You may have this information, you may not.

Retweeted by 黒木玄 Gen Kuroki

retweeted at 04:02:30

7時間前

@golgo_sardine

ゴルゴ・サーディーン@golgo_sardine

@yamamemomo1 私自身は( #掛算 の順序問題に関心をもっている他の人に比べれば )数学ができる方ではありません。

ただ、算数が自分自身の問題だという意識はあるので、
「順序遵守派は算数が他人事なのだ」
という思いが強いです。

添付画像のような物を見たときから、そう考えるようになりました。 pic.twitter.com/72jzFT4g0Y

Retweeted by 黒木玄 Gen Kuroki

retweeted at 03:59:27

7時間前

@StefanKarpinski

Stefan Karpinski@StefanKarpinski

Can we please just have a discourse that acknowledges that this is a trade off? I.e. that there are costs & benefits to both dynamic & static systems? The pro-dynamic camp does this. Can static type people stop insisting that there are no costs to static type checking? (6/6)

Retweeted by 黒木玄 Gen Kuroki

retweeted at 03:45:12

7時間前

@StefanKarpinski

Stefan Karpinski@StefanKarpinski

But everyone agrees that being able to type check things is really good! The issue is that it is not free to do so: it complicates and restricts the language. That cost may or may not be worth paying, but there is a cost! That is all we (pro-dynamic people) are saying!!! (5/6)

Retweeted by 黒木玄 Gen Kuroki

retweeted at 03:45:09

7時間前

@StefanKarpinski

Stefan Karpinski@StefanKarpinski

When such claims that dynamic languages are strictly worse are countered with examples of things that are easier/simpler/possible in dynamic languages, static language advocates often take it as an attack, as if the claim was that static languages are strictly worse! (4/6)

Retweeted by 黒木玄 Gen Kuroki

retweeted at 03:45:07

7時間前

@StefanKarpinski

Stefan Karpinski@StefanKarpinski

So many static languages advocates, OTOH, insist that static languages are strictly better at everything—that there is no trade off. In this case the linked blog post argues that static language are just as good/expressive dealing with generic processing of external data (3/6)

Retweeted by 黒木玄 Gen Kuroki

retweeted at 03:44:45

7時間前

@StefanKarpinski

Stefan Karpinski@StefanKarpinski

Dynamic language folks acknowledge that there are cases where static type checking is really valuable and appropriate, but feel that there are also many cases where dynamic languages are more productive and expressive and they tend to prefer that side of the tradeoff (2/6)

Retweeted by 黒木玄 Gen Kuroki

retweeted at 03:44:29

9時間前

@souji04261

souji@souji04261

ゼミ形式の教育方法が大学に取り入れられるのは大学というものが出来てからかなり後の19世紀前半っぽい
そして数学で現代風のゼミを行った(最初かどうかまでは調べてないが)第一人者はヤコビらしい
今当たり前のものも意外と古かったり新かったりして、歴史を知ってみるのは楽しい

Retweeted by 黒木玄 Gen Kuroki

retweeted at 02:34:03

9時間前

@ryu_shikun

柳 時熏(囲碁棋士)professional Go play@ryu_shikun

ボードゲームの中でも難解さで知られる囲碁。
2015年の AlphaGoの衝撃的な出現でついにAIが人間を超えてしまいました。
現在、強いAIと人間はどれくらいの差があるのかを自ら検証していきます!!
今回は、最強と噂される囲碁AIのkatagoと実況対局しました。
是非ご覧ください✨
youtu.be/mo5NpcKjW9k pic.twitter.com/ymH4e6nE5S

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:56:24

9時間前

@ropcb08

Bot08(日本カネ不足協会 会員)@ropcb08

これまでは教育政策を、テストの点数や将来の収入などで評価してきましたが、これらを高めるために教育があるわけではありません。近年では、非認知能力を測ろうという動きがあります。今後は、データを使って、目的自体を測ることが重要になるかもしれません。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:50:59

9時間前

@ropcb08

Bot08(日本カネ不足協会 会員)@ropcb08

しかし、日本の明治時代の旧制高等学校の効き目を測ったところ、これについては大きな効果が認められました。旧制高等学校で学んだ人の方が、将来の収入が高くなったり、エリート政治家やエリート官僚になったりする可能性が高いことがわかりました

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:50:47

9時間前

@ropcb08

Bot08(日本カネ不足協会 会員)@ropcb08

(´ω`;)

ニューヨークの研究では、点数以外にくじ引きで合否を決めている側面があります。よって、合格最低点の前後にいる人だけではなく、より学力の高い人たちの効果についても測ることができます。その結果、学力が非常に高い層でも、逆に低い層でも、ほとんど効果がないことがわかりました。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:50:43

9時間前

@ropcb08

Bot08(日本カネ不足協会 会員)@ropcb08

だからこそエリート公立高校に入学できただけで、エリート公立高校の教育のおかげで良い成績が取れているわけではありません。シカゴだけではなく、ニューヨークやボストンの研究でも、同じように、エリート公立高校の効き目はゼロかマイナスだとわかりしました。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:50:38

9時間前

@ropcb08

Bot08(日本カネ不足協会 会員)@ropcb08

普通の高校と比べてエリート公立高校が学生の将来の成績に与える効果は、ほぼゼロかマイナスだということがわかりました。確かに、エリート公立高校に通う生徒の成績は優秀です。しかし、それはそもそも彼らが高い点数を取れる優秀な人たちであり、

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:50:36

9時間前

@ropcb08

Bot08(日本カネ不足協会 会員)@ropcb08

因果関係も見透かす機械学習:21世紀のウェブ産業から22世紀の公共政策へ【議事録】 成田 悠輔(RIETI客員研究員 / イェール大学助教授 / スタンフォード大学客員助教授 / ヂンチ株式会社共同代表) 市川 類(国立研究開発法人産業技術総合研究所) / www.rieti.go.jp/jp/events/bbl/

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:50:35

10時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z #Julia言語 いずれにせよ、このような単純和ではsimdを使って高速化することが常識的だと思うので、CとJuliaの両方でsimdを使った場合の比較をした方がよいです。

Julia側のコードは私がすでに示しました。

Cの側は私は知りません(笑)

C側でsimdを試してみると「色々」分かると思います。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 01:31:46

10時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z #Julia言語 いずれにせよ、このような単純和ではsimdを使って高速化することが常識的だと思うので、CとJuliaの両方でsimdを使った場合の比較をした方がよいです。

Julia側のコードは私がすでに示しました。

Cの側は私は知りません(笑)

C側でsimdを試してみると「色々」分かると思います。

posted at 01:31:38

10時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z それはひどい誤解です。

#Julia言語 のbuiltin sumは、simdを使って高速化しているだけではなく、和を前から順番に取ることをやめることによって、誤差が大きくなる確率を下げているので、高速性と精度の両面で安全牌である

と述べています。続く

posted at 01:28:40

10時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z simdで速くなる理由についてはググって下さい。

値が微小に違って来るのは和の順序が違うからです。

Float32に精度を落とした場合には、前から順番に足すと正しい値を計算できない例を容易に作れます。

#Julia言語 の builtin sum は速いだけではなく、精度的にも安全牌です。 twitter.com/genkuroki/stat

Retweeted by 黒木玄 Gen Kuroki

retweeted at 00:53:31

10時間前

@lpha_z

るふぁ@lpha_z

@genkuroki 初めまして、コメントありがとうございます。
Juliaは初めて触ったので、あまり常識的でないユースケースを選んでしまったかもしれません。

ところで、なぜsimdを使うと速くなるのでしょうか?
それに、計算結果も間違っているような……?

Retweeted by 黒木玄 Gen Kuroki

retweeted at 00:46:24

10時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

Re: RT うけた🤣

Juliaを使っていると、REPLやJupyterで自分で定義した型の値がどのように表示されるかに関するコードを書くことは、"extremely rare exceptions" でもなんでもない。

視野狭窄なことに気付かずに変なことを述べる人は世界中にいる。

posted at 00:40:01

11時間前

@kikumaco

kikumaco(10/31,11/22ビッグアップル)@kikumaco

学生が置いていった100万ファイルのデータを整理するくらいなら全部計算し直したほうが早いと思って、計算し直しついでにサンプルを5倍に増やしてみたところ、元のデータで統計揺らぎかなと思ってた変なディップは本当にあることが分かった。サンプルサイズが大きいのは正義

Retweeted by 黒木玄 Gen Kuroki

retweeted at 00:19:30

11時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z #Julia言語 私見では、頑張って最適化すれば、CとJuliaは同じ程度の速さです。

しかし、Juliaの側では最適化の作業が色々な意味でずっと楽になっており(Lispのような完全なマクロも使える!)、複雑なプログラムになればなるほど、最適化の楽さの違いでJulia側が有利になるものと思われます。

Retweeted by 黒木玄 Gen Kuroki

retweeted at 00:17:01

11時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z #Julia言語 私見では、頑張って最適化すれば、CとJuliaは同じ程度の速さです。

しかし、Juliaの側では最適化の作業が色々な意味でずっと楽になっており(Lispのような完全なマクロも使える!)、複雑なプログラムになればなるほど、最適化の楽さの違いでJulia側が有利になるものと思われます。

posted at 00:16:52

11時間前

@genkuroki

黒木玄 Gen Kuroki@genkuroki

@lpha_z #Julia言語

Juliaでは単純な和には普通にsimdを使うので、JuliaとCの両方でsimdを使って比較した方が良かったと思います。

Juliaでsimdを使うと10倍以上速くなります。
Juliaのbuiltin sumも同じオーダーで速いです。

ソースコード↓
gist.github.com/genkuroki/c3b1 pic.twitter.com/C31z3YPJu7

Retweeted by 黒木玄 Gen Kuroki

retweeted at 00:12:47

このページの先頭へ