MathJaxテスト
翼の周りの気流によって生成される揚力（軌道に対して垂直）を $L$ ，軌道に水平な抗力を $D$ とする． それぞれの力は揚力係数 $C_L$ と抗力係数 $C_D$ によって表現され，どちらの係数も翼の設計と迎角に依存している．
揚力と抗力は機体の表面積 $S$ と，動圧 $1/2 \rho v^{2}$ に比例する．ここで $\rho$ は空気の密度，そして $v$ は飛行機の前進速度である．揚力と抗力の方程式は以下のようになる：
$$ \begin{eqnarray} L &=& C_L S \times \frac{1}{2} \rho v^{2} \\ D &=& C_D S \times \frac{1}{2} \rho v^{2} \end{eqnarray} $$
グライダーが平衡状態にあるとき，それぞれの力も釣り合っている．以下のように，軌道の垂線方向および軌道と平行に力を等しいとすることができる： $$ \begin{eqnarray} L = W \cos \theta \\ D = W \sin \theta \end{eqnarray} $$
ここで $W$ はグライダーの重さである．
角度 $\theta$ は滑空角と呼ばれ，運動方向と水平線のなす角である．
Content under Creative Commons Attribution license CC-BY 4.0, code under MIT license (c)2014 L.A. Barba, C. Cooper, G.F. Forsyth, A. Krishnan.
記号のみを使った Julia プログラミングをしたかった
punctuations のみを使ってプログラミングすることを記号プログラミングと呼ぶ人がいるらしいです。*1
これを真似て Julia で記号のみのプログラミングをやってみようと思いました。上のリンク先の内容（特にPerlの記事）をなぞっただけなので新規性はないです。
記号のみでプログラミングをするための方策は次の2ステップに分解できます。
- 任意のAscii文字列を記号のみで表現する
- 作った文字列を eval する
この記事では 1. についてはやりましたが 2. は妥協しました。eval を記号で済ます方法は Julia にはないように思われたからです。
さて、まずは 1.を実現するために、任意の文字 [a-zA-Z] が2つの文字記号の論理演算から作れるということを利用します。
julia> bin('`')
"1100000"
julia> bin('!')
"100001"
julia> bin('A')
"1000001"
julia> '`' $ '!'
'A'
この組み合わせは手作業で探してもいいですが、面倒なのでプログラムで全探索して辞書を作りました。
punctuations = "!\"#\$%&'()*+,-./:;<=>?@[\\]^_`{|}~"
println("{")
for i in ['A':'Z', 'a':'z']
lists = (Char, Char)[]
for p in punctuations
x = i $ p
if (p, x) in lists
continue
end
if x in punctuations
push!(lists, (x, p))
end
end
println(" '$i' => $lists,")
end
println("}")
この辞書を元に好きな文字列を作ります。Julia では Char と String の扱いが異なり、+記号を使ってカジュアルに Char を結合したりすることはできません。なので文字列挿入記法を使います。
julia> "$('`'$'(')$('['$'>')$('@'$',')$('@'$',')$('@'$'/'),$('^'$')')$('@'$'/')$('^'$',')$('@'$',')$('_'$';')!"
Hello,world!
以上で任意の文字列を作ることに成功しましたが、ではこれを実行するにはどうしたらいいでしょう。Julia で文字列をプログラムとして評価するには parse してから eval する必要がありますが、これを記号だけで行う方法は見つけられませんでした。なので次のように単にアンダースコアで置き換えて妥協しました。これはひどい。
_ = parse __ = eval
こうすれば他の関数は記号のみで参照を得ることができます。例えば次のようにすれば記号のみで println を使えるようになります。
julia> "$('^'$'.')$('^'$',')$('@'$')')$('@'$'.')$('\\'$'(')$('@'$',')$('@'$'.')"
"println"
julia> ___ = __(_("$('^'$'.')$('^'$',')$('@'$')')$('@'$'.')$('\\'$'(')$('@'$',')$('@'$'.')"))
println (generic function with 2 methods)
これにより、（ほぼ）記号のみの Hello world プログラムを得ることができました。わーパチパチパチパチ！
_ = parse
__ = eval
___ = __(_("$('^'$'.')$('^'$',')$('@'$')')$('@'$'.')$('\\'$'(')$('@'$',')$('@'$'.')"))
___("$('`'$'(')$('@'$'%')$('@'$',')$('@'$',')$('@'$'/'), $('\\'$'+')$('@'$'/')$('^'$',')$('@'$',')$('^'$':')!")))
# => Hello, world!
やってみたかっただけなので妥協部分をどうにかしようというモチベーションはありません。
*1:記号プログラミングという言葉を記号のみを使うプログラミングという意味で使うことは少し憚られます。Symbolic programming と混同する恐れがあるからです。なのでタイトルは記号のみプログラミングとしました。
Daily Julia #12
Julia 0.3 の rc 版が公開
Rust の開発者 Graydon Hoare が語る対話的な科学技術計算環境
Part1 で Python, Part2 で Julia について語っている。
graydon2 | technicalities: interactive scientific computing #1 of 2, pythonic parts
graydon2 | technicalities: interactive scientific computing #2 of 2, goldilocks languages
Daily Julia #11
Scipy 2014 meeting で Julia が紹介された
New Julia tutorial from SciPy now online - Google グループ
Introduction to Julia - Part 1 | SciPy 2014 | David Sanders - YouTube
Julia Graphics が発足した
まずは OpenGL や SDL, Processing 等の Julia ライブラリの参加を見込んでいる？
Jupyter というプロジェクトが発足した
Julia に直接は関係ないが Jupyter という IPython の姉妹プロジェクトのようなものが始まった。これは IPython から Python に依存しない部分を切り分けるためのものらしい。Python に依存しない部分を以下のスライドから挙げておくと次のものである。
- 対話的コンピューティングのためのネットワークプロトコル
- クライアント
- コンソール
- Qt コンソール
- Notebook
- Notebook のフォーマットとツール (nbconvert)
- Nbviewer
雑記
Daily Julia の更新が芳しくないですが体調不良のため今後も更新速度が上がりません。このしょっぱい企画名は微妙に検索よけを狙ってわざわざ考えたものだけど、Weeklyに切り替えたほうがいいかもしらん。
Daily Julia #10
世界で 2 番目の Julia Conference となる Julia Tokyo が開かれているようだ。
軽くまとめようと思ったが、日本語圏の話だし参加していない私があれこれ書くのも変であるのでやめた。そのうちどこかでまとめ記事が上がってくるんじゃないだろうか。
`sort` にジェネリックな比較関数を渡すと遅い
しかもメモリ割当が 2 倍に増える。
既知の問題である。名前解決がイテレーション毎に起こるから遅いらしい。メモリ使用量が 2 倍に増える理由について Karpinski は I'm not sure と応えており「えっ」となる。NumericExtensions.jl が既にこの手の問題に対して 回避策 を講じているが、こんなところで Functor が登場しているのか。もっとも、Functor を渡してもインライン化が働くのは単純な関数の場合に限られるため、本当に最適化しようと思ったら @inbound 使って境界チェック切ろうということらしい。
長期的には、何も考えなくても効率的に実行されるようになるのが好ましいと Karpinski は述べている。
それにしても @elapsed や @allocated のようなマクロを挟むだけで実行速度やメモリ割当量を気軽に計測できるのは鬼のように便利だな…
Julia の文字列結合演算が積 (*) である理由（他言語との比較）
+ という記号は経験的に交換則が成り立つことを期待するものであるのに対して、文字列結合は交換則が成り立たたないからというのがその理由である。
"Hello, " * "World." != "World." * "Hello, "
ただしIssue #1771の議論を見れば分かるように、* を良い演算子と思っている人はあまりいないようだ。本質的に文字列結合演算は IO Buffer を介さない非効率的なものであって、パフォーマンスに敏感な場面では適さない（煎じ詰めると「これって要らない子なのでは？」）というのが論点のようだ。
以下文字列の性質に関して Issue #1771 を読みながらノート。
- Karpinski も言及しているように、Haskell では文字列結合演算は
++として表現されている。これも代数的な見地からして+を使うのは好ましくないからということである - 文字列の結合演算はモノイドである
- Haskell では Monoid クラスの実装として
<>という記号を使っている - ここで Karpinski への反論として言われているように モノイド演算には正統（canonical）な表現があるわけではない。例えば、Haskeller にも次のように Monoid を定義する人はいた
class Monoid a where zero :: a (+) :: a -> a -> a instance Monoid [a] where zero = [] (+) = (++)
これは分かりやすさの便宜上（この記事では半環を扱っているのでモノイド演算との差を際立たせている）こうしているのであって、なんでもかんでも + をオーバロードするのはやっぱおかしいと言われればその通りですが。
- このコメントで Rust と Dart の状況が紹介されている。
- まず Rust 。
+を++にリプレースする提案が ML に投げられたが、十分な関心を得られていないようだ - 次に Dart 。文字列結合演算子そのものを廃止して、次のような挿入記法か
StringBufferを使えと述べている
var to = 'Dart developer'; var msg = 'Hello $to!'; assert(msg == 'Hello Dart developer!')
