Julia Juno Jupyter part1 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/02/12(金) 19:05:13.83

LLVM で動く Julia のお勉強
Python に少し似てネイティブの速さで動く素敵な関数型言語
http://julialang.org/
http://junolab.org/
http://jupyter.org/

関連
Pythonista のための Julia 100 問 100 答
http://bicycle1885.hatenablog.com/entry/2014/12/23/170745

**デフォルトの名無しさん** · 2016/08/02(火) 10:29:05.14

>>111
manual/calling-c-and-fortran-code/

Struct Type correspondences

Packed structs and union declarations are not supported by Julia.

You can get a near approximation of a union if you know, a priori,
the field that will have the greatest size (potentially including padding).
When translating your fields to Julia, declare the Julia field to be only of that type.

...

In the future, some of these restrictions may be reduced or eliminated.

**デフォルトの名無しさん** · 2016/08/04(木) 11:46:11.27

reinterpretとBase.boxとどっち使うのが良いんですか？

**デフォルトの名無しさん** · 2016/08/05(金) 10:14:39.63

>>79
それな

**デフォルトの名無しさん** · 2016/08/05(金) 11:34:17.96

なぜ僕らはJuliaを創ったか
http://marui.hatenablog.com/entry/20120221/1329823079

ゆるいライセンスのオープンソースで、Cの速度とRubyの動的さが欲しい。
Lispのような真のマクロが使える同図象性のある言語で、
Matlabのように分かりやすい数学の記述をしたい。
Pythonのように汎用的に使いたいし、Rの統計処理、
Perlの文字列処理、Matlabの線形代数計算も要る。
シェルのように簡単にいくつかのパーツをつなぎ合わせたい。
チョー簡単に習えて、超上級ハッカーも満足する言語。
インタラクティブに使えて、かつコンパイルできる言語が欲しい。
（そういえば、C言語の実行速度が必要だってのは言ったっけ？）

イイね！

**デフォルトの名無しさん** · 2016/08/12(金) 14:09:58.96

マクロを入れ子で使ってるときの評価順が良く判らんな

**デフォルトの名無しさん** · 2016/08/19(金) 20:54:44.94

Juliaの継承システムってなんでgoみたいなシステムにしなかったんだろうな

**デフォルトの名無しさん** · 2016/08/20(土) 14:07:49.70

goはgoでアグレッシブすぎる気がするけど

C++とかJavaとか
結果的に抽象クラスとインターフェイスの関係が微妙になってしまったことを考えれば
Juliaの型システムは明確で合理的だと思う

あと多重ディスパッチが特徴に挙げられるくらいなので
ロジック・実装の散逸を防ぐ思想があるんだろう

具象型が継承不可な点は最適化の面でも有利に働くはず

**デフォルトの名無しさん** · 2016/08/20(土) 14:58:26.80

コンストラクタがきもい

**デフォルトの名無しさん** · 2016/08/24(水) 18:07:53.88

おまえそんなんばっか

**デフォルトの名無しさん** · 2016/08/24(水) 20:40:56.81

@timeとか@showとか便利すぎて逆になんでpythonにはないのかと悲しくなるレベル

**デフォルトの名無しさん** · 2016/09/01(木) 20:24:06.33

一切カプセル化出来ないから無能を含む大規模プロジェクトには使えないな

**デフォルトの名無しさん** · 2016/09/02(金) 07:56:04.86

intをdepricated にして代わりに l->[parse(Int, s) for s=l] を使えって言ってくるのはマジで基地外じみてる

**デフォルトの名無しさん** · 2016/09/02(金) 12:51:45.65

新言語のフリしたFORTRANだよなこれ

**デフォルトの名無しさん** · 2016/09/02(金) 15:34:46.39

3次元の配列を効率よく初期化するにはどうすれば良いでしょうか？

**デフォルトの名無しさん** · 2016/09/02(金) 20:42:33.40

[f(I,j,k) for i=1:n, j=1:m, l=1:o]
Pythonとは訳が違う便利さ

**デフォルトの名無しさん** · 2016/09/03(土) 13:20:01.65

>>136
じゃあ何が正解だというの？

**デフォルトの名無しさん** · 2016/09/03(土) 13:59:08.29

添え字が 0 から始められるように設定変更ってどうするんだっけ

**デフォルトの名無しさん** · 2016/09/03(土) 22:13:37.19

>>140
安価ミスか？何を聞かれてるのかわからん

**デフォルトの名無しさん** · 2016/09/13(火) 10:04:52.46

>>141
マクロ使えば行けるけど見た目は良くないな

Juliaってcolumn majorのくせに多次元配列のconcatenation は左の添字からやろうとするの本当に謎

**デフォルトの名無しさん** · 2016/09/13(火) 20:37:02.00

>>140
すまん、intをdeprecate にされたことがまず辛い。消すなら消すで同じくらい短くかける別の関数を用意してほしい
毎回これを書くのは嫌だし、自分でこれの別名をつけるのはなんか違う

**デフォルトの名無しさん** · 2016/09/14(水) 13:14:08.84

parseint なんで死んでもうたん

**デフォルトの名無しさん** · 2016/09/19(月) 18:47:11.41

君死に勿給ふこと

**デフォルトの名無しさん** · 2016/09/20(火) 11:35:12.98

IPython - 対話的にPythonプログラミングができるコマンドラインツールです。とはいえ初心者だと何をどうしていいかわからないかも
Jupyter Notebook - IPythonをブラウザ上で実行するツールです(全然それだけじゃないけど) 。とっかかりとして一番のおすすめ。
様々なサンプルがこのツールのNotebook形式で配布されており、学習効率もいいです。

とりあえずVisual StudioとPycharmがIDEで, 前者はpythonに限定しないIDE,
後者はpython用のIDEですね. ※Visual Studioはpythonに対応してるとの事です.
アナコンダはパッケージのインストーラーで, IpythonとJupyterも一緒に
ダウンロードされますよね.
JupyterもIDEではないのですか？

IDEの定義によるんだろうけど
JupyterはIDEの条件を満たしてはなさそう
ノート機能が付いたEditorに近いのかな

私のとらえ方ではIDEは3ペイン・2ペイン構成のデスクトップアプリで
IPythonをブラウザ上で(シングルペインではあるが)IDE「的」に使えるのがJupyterですね
Anacondaにはpython用IDEデスクトップアプリのSpyderというものも入ってますので
インストール後両方起動されると、おおよその雰囲気の違いがわかると思います

Jupyter-IPython は Mathematica を目指してる。
Kernel + Notebook の構造。
IDE とはまた違うかな。

**デフォルトの名無しさん** · 2016/09/20(火) 16:45:47.03

俺定義とかどうでもいい

**デフォルトの名無しさん** · 2016/09/20(火) 18:24:31.81

0.5正式版出た？

**デフォルトの名無しさん** · 2016/09/23(金) 22:24:53.87

ジェネレータ式はトリッキーなマクロが要らなくなっていいな

PROGRAM_FILEはやっとか

**デフォルトの名無しさん** · 2016/09/23(金) 23:25:21.12

この調子で引数に_を使った時に部分適用になるあれもこないかな

**デフォルトの名無しさん** · 2016/09/27(火) 10:01:40.02

Julia0.5正式に出たっていうのになんだこの話題なってなさは

**デフォルトの名無しさん** · 2016/10/20(木) 11:50:05.14

FORTRAN2016

**デフォルトの名無しさん** · 2016/11/03(木) 03:38:05.60

煽り抜きでダメだなもう
ガバナンスも利いてないしめちゃくちゃ
文法も思想もとっちらかったクソ言語に成り果ててる

**デフォルトの名無しさん** · 2016/11/03(木) 06:39:55.89

もうガバガバなんす

**デフォルトの名無しさん** · 2016/11/03(木) 08:35:32.33

>>154
ほんまこれ。迷走しすぎて言語仕様めちゃくちゃ

**デフォルトの名無しさん** · 2016/11/03(木) 10:49:45.39

どこで間違ったし

**デフォルトの名無しさん** · 2016/11/10(木) 00:39:14.58

pythonでよくね

**デフォルトの名無しさん** · 2016/12/02(金) 20:17:55.46

type Pos
x::Float64
y::Float64
end

Base.+(a::Pos, b::Pos) = Pos(a.x + b.x, a.y + b.y)

ってやると(a::Pos, b::Pos) is not a valid function
ってエラー吐くのですが、オリジナルの型用の演算子定義するにはどうすればいいのでしょうか？

**デフォルトの名無しさん** · 2016/12/03(土) 14:42:15.35

(+)(a::Pos, b::Pos) = Pos(a.x + b.x, a.y + b.y)

**デフォルトの名無しさん** · 2016/12/03(土) 14:45:29.61

こっちか
(:(+))(a::Pos, b::Pos) = Pos(a.x + b.x, a.y + b.y)

**デフォルトの名無しさん** · 2016/12/03(土) 22:57:39.15

>>160をやると普通の+が使えなくなり、
>>161をやるとsyntax: invalid function name ":+"
ってなりました……

**デフォルトの名無しさん** · 2016/12/04(日) 16:46:36.86

import Base.+
.+(a::Pos, b::Pos) = Pos(a.x + b.x, a.y + b.y)
とか？

**デフォルトの名無しさん** · 2016/12/04(日) 16:55:46.44

すまん+の前のドット要らん

**デフォルトの名無しさん** · 2016/12/18(日) 17:43:44.11

Tk.jl わろす

**デフォルトの名無しさん** · 2016/12/24(土) 06:10:21.30

３ヶ月程前からPython+Numpy 覚えながら前から作ろうと思っていたプログラム書き始めていたのですが、
最近Juliaを知って日本語で書かれたドキュメント読み切って中身知ったら凄く綺麗で良い言語に見えてきて、
むしろPythonの方はダメな部分を補う為に無理やりNumpyをくっつけているようにすら見えてきたのですが、
その認識は間違ってないでしょうか？
書きかけのプログラムをPython+NumpyやめてJuliaを覚える方にシフトしようかある程度Pythonを覚えてきたこともあって悩んでいます。

**デフォルトの名無しさん** · 2016/12/24(土) 12:34:17.22

めりくり

**デフォルトの名無しさん** · 2016/12/24(土) 15:53:34.28

numpyで充分

**デフォルトの名無しさん** · 2016/12/26(月) 19:37:06.22

Juliaは上手く統合されてると思うけど、まだ色々足りないでしょ
自分でバンバン書ける人ならともかく、覚え始めとかならPythonやっとけ

**デフォルトの名無しさん** · 2016/12/26(月) 20:42:06.86

JuliaスレでJuliaをディスるな��

**デフォルトの名無しさん** · 2016/12/27(火) 14:39:42.88

disってるようには思わないな
正当な批判はちゃんと批判として受け入れるべき

**デフォルトの名無しさん** · 2016/12/27(火) 20:29:48.62

JuliaにはRを殺して欲しい

**デフォルトの名無しさん** · 2016/12/27(火) 20:54:54.62

配列が線形代数向けに整備されてる言語ってJuliaとRくらいのもんか？

**デフォルトの名無しさん** · 2016/12/27(火) 21:07:35.36

**デフォルトの名無しさん** · 2016/12/27(火) 21:16:00.31

Jはちょっと……

**デフォルトの名無しさん** · 2016/12/27(火) 21:56:48.37

線形代数向けに整備されてるってどういうこと？

**デフォルトの名無しさん** · 2016/12/28(水) 00:10:38.62

配列を使って高速に内積とか行列演算とか出来るということ
C++のEigenとかPythonのNumpyにあたる機能がJuliaでは標準の配列でサポートされている

**デフォルトの名無しさん** · 2016/12/28(水) 01:58:11.43

そんなもん書いたら終わりじゃん。
宣言型だとか、原始再帰関数がどうとか言い出すならともかく。

**デフォルトの名無しさん** · 2016/12/28(水) 11:27:50.75

>>178
いちいち自分で外積内積アダマール積、逆行列行列式特異値分解とかLAPACKラッパー書いていくの？

**デフォルトの名無しさん** · 2016/12/28(水) 12:24:00.73

>>179
標準、がフワフワしすぎ、って事。

**デフォルトの名無しさん** · 2016/12/28(水) 12:24:37.91

>>177
勝手にCUDAってくれたりするってこと？

**デフォルトの名無しさん** · 2016/12/28(水) 12:25:24.34

>>179
一回書いたら終わりだろ

**デフォルトの名無しさん** · 2016/12/28(水) 12:59:27.07

>>182
最近の言語は大体色々楽するために発展して来てるのに、その発想はストイックすぎるだろ。俺はそれをD言語でやろうとして途中で面倒になってやめたわ。ライブラリの存在を全否定するような発想はC言語とFortranの世界の中でお願いします。

それに線形代数よく分かってなくてもJuliaの関数を色々使ってみて理解が進むという側面もあるから、出来るやつが書いた使いやすい線形代数APIが標準で搭載されている言語は重要だと思うわ

ちなみにJuliaでのcudaのサポートはまだまだこれから

>>180
すまんが意味がわからんかった

**デフォルトの名無しさん** · 2016/12/28(水) 13:10:29.72

>それに線形代数よく分かってなくてもJuliaの関数を色々使ってみて理解が進むという側面もあるから

こんなとこで高卒自慢ですねわかります

**デフォルトの名無しさん** · 2016/12/28(水) 13:31:41.63

線形代数の動きやどんな関数があるかは大学でもMapleやMathematicaで実際に動かして実習するというのに、それがJuliaに変わるだけで高卒自慢と捉えるのは数学ガチ勢か老害か効率悪いアホかただの煽り野郎かのどれかだな

**デフォルトの名無しさん** · 2016/12/28(水) 14:35:26.89

>>183
実装みてない関数で集計とかキチガイの所業じゃん。

**デフォルトの名無しさん** · 2016/12/28(水) 16:24:36.07

166ですが、結局Julia漬けの毎日になってしまいました。
昔Cでアルゴリズムを書いて学んだのですが、それをそのままJuliaで書いて練習してます。いくつか言語の経験はあったのですが、Cの組み込みをやっていたのもあって、型をきちんと指定出来る上にCの構造体のように書けるのでとても扱いやすくて良いです。

**デフォルトの名無しさん** · 2016/12/28(水) 17:06:05.37

↑amazonの自演レビュー見てる気がしてきた

**デフォルトの名無しさん** · 2016/12/28(水) 18:51:49.10

>>186
オープンソースなんだから見ればいいじゃん

**デフォルトの名無しさん** · 2016/12/28(水) 19:01:40.76

>>186
おまえは自分が使ってるもののソース全部見てんのか？

**デフォルトの名無しさん** · 2016/12/29(木) 00:05:08.16

>>190
全部書いてる。

**デフォルトの名無しさん** · 2016/12/29(木) 00:15:27.73

>>190
その2chブラウザもか、やるな！

**デフォルトの名無しさん** · 2016/12/29(木) 00:35:10.76

>>191
LAPACK使わないの？MKL使わないの？それで速くてまともなプログラムを一から十までちゃんと作って完成させられるのなら相当凄いな

でも今時は量子化学ソフトの開発者だって当然のように他人のコード混ぜるし、量子化学ソフト使ってる人は使ってるプログラムのアルゴリズムの詳細までは知らないことが多い。
数学の教授だってMathematicaの実装知らずに使ってるよ。統計の学者だってRの中身全部把握してる訳じゃない。
そもそも実験屋はコードが何かもよく分かってなかったりするけど出来合いのアプリケーションで集計して論文を書く。どこかで妥協して人を信用しないと新しいものを作れる段階に行けないことが多いから。
だから、実装見てない関数で集計するのがキチガイの所業だと思う方がキチガイだと思うぞ

**デフォルトの名無しさん** · 2016/12/29(木) 00:40:53.56

>>193
お金もらってるしね。
実験屋のデータを意味のあるものにするのが仕事だから。
Rの中身は全部読んでるし、割と枯れたものに修正入れて全部検証してるよ。
そんなのは実験屋であって、研究者でもないし、
研究者は実験屋でもない。
妥協と信頼は金で買うんだよ、普通の研究所って。
こんなとこでママゴトみたいな言い分聞くとは思わなかったな。

**デフォルトの名無しさん** · 2016/12/29(木) 01:12:28.24

>>194
じゃあ一体何のためにこの世にRは存在しているの？

**デフォルトの名無しさん** · 2016/12/29(木) 01:14:25.61

>>195
足場。

**デフォルトの名無しさん** · 2016/12/29(木) 01:17:59.94

>>196
Rを使って研究している計量経済学の教授で、Rの内部実装をちゃんと読んでない教授はキチガイ？

**デフォルトの名無しさん** · 2016/12/29(木) 01:33:55.87

>>194
この世にはシミュレーションソフトを回すことを専門とする教授が一定数いるんだけど彼らはGaussianの内部実装を全部読むのは無理という人ばかりだよ。彼らはキチガイ？

**デフォルトの名無しさん** · 2016/12/29(木) 02:33:47.93

>>197
知ってる限りの学者は、ソース読んでる。
マクロ系ばっかりだけど。

>>198
そんなもん「オペレータ」だよ。
活字拾うジョバンニと同じ。
ただしその人らが、Gaussianに限らず、方程式として書いたものを、所内のQCに投げて、オッケーですと確認する事を怠らなければ研究者だろうね。
大体は組み込みの関数やら標準ライブラリはオーバースペック。しかもバージョンアップある。
なら内製したほうがマシ。

**デフォルトの名無しさん** · 2016/12/29(木) 02:45:49.88

>>199
大学の研究室にQCはいないよ。標準ライブラリの代わりを再開発してるような手数もないよ。めちゃくちゃ言うのやめてくれる？

**デフォルトの名無しさん** · 2016/12/29(木) 02:59:11.48

標準ライブラリの存在意義を全否定する典型的なキチガイおるな
一時期C++スレに沸いてたのと同一人物か？

**デフォルトの名無しさん** · 2016/12/29(木) 06:07:19.08

LLVMのコード見ても不十分
全部アセンブリ以外認めない（きりっ）
ですね

**デフォルトの名無しさん** · 2016/12/29(木) 10:35:54.26

gccのコード見ても不十分
intelのチップの命令セット把握せずにコンピューター使うとかキチガイの所業（笑）

**デフォルトの名無しさん** · 2016/12/29(木) 11:27:51.11

まぁ、コンパイラ変わったらアセンブリは見るなぁ。

**デフォルトの名無しさん** · 2016/12/29(木) 11:49:57.94

なければ創れ
いまのJuliaはまだそういうレベル

**デフォルトの名無しさん** · 2016/12/30(金) 15:37:34.62

女性プログラマーに"熱視線"
http://www3.nhk.or.jp/news/web_tokushu/2016_1229.html

**デフォルトの名無しさん** · 2017/01/04(水) 20:17:28.54

JuliaでGUIする時の定番って何？

**デフォルトの名無しさん** · 2017/01/04(水) 22:59:59.17

tk.jl

**デフォルトの名無しさん** · 2017/01/05(木) 09:16:45.27

サンクス

**デフォルトの名無しさん** · 2017/01/05(木) 11:15:39.38

これ度のバージョンの Tk なんだろ

**デフォルトの名無しさん** · 2017/01/05(木) 11:30:57.02

最近ダウソしたのみたら tcl/tk 8.6.0 だったわ

**デフォルトの名無しさん** · 2017/01/13(金) 00:03:06.57

既存のパッケージ使って
使い捨てのスクリプト書くのは簡単なのに
クラスベースのOOPに慣れすぎた弊害か
いざ自分でモジュールを設計しようとすると途方に暮れる

**デフォルトの名無しさん** · 2017/01/13(金) 00:32:54.45

GoでGrumpyが出来るのだからJuliaでJumpyみたいなのって出来ないですか？
ライブラリが足りなくて無理？

**デフォルトの名無しさん** · 2017/01/13(金) 16:09:05.38

>>212
>クラスベースのOOPに慣れすぎた弊害か

違うよ
元々OOPやOODを判ってないだけ

**デフォルトの名無しさん** · 2017/01/14(土) 14:53:43.03

>>214
「本質が同じ」で片付けるなら
Juliaという言語が生まれる動機なんて無いのでは

それに理解していることと実践できることは同じではない
判っていても難しいものは難しいし
判っていなくても簡単ということだってある

**デフォルトの名無しさん** · 2017/01/16(月) 16:59:03.34

コンストラクタの造り方(書き方)知らないだけだろ

**デフォルトの名無しさん** · 2017/01/16(月) 18:00:28.81

どちらかと言うとクラスベースだと思うけどな
昔のプロトタイプベースのjavascriptより100倍わかりやすい

**デフォルトの名無しさん** · 2017/01/17(火) 17:23:59.95

mounko

**デフォルトの名無しさん** · 2017/02/11(土) 00:31:23.05

依存関係解析してincludeをソートしたりとか
変更のあったファイルだけテストするとか
そういったツールってあるの？

**デフォルトの名無しさん** · 2017/02/12(日) 08:00:36.63

Juliaと似た思想のhalideという画像処理言語がある
どっちもやりたいこと同じなんだから
統合してくれないものか

**デフォルトの名無しさん** · 2017/02/12(日) 10:26:38.18

思想は似てない部類だと思うが

Images.jlの中の人がちょっと実験していたみたいだけど
統合することはないだろうね

**デフォルトの名無しさん** · 2017/02/14(火) 19:36:03.24

コンストラクタがよく分からん

type Hoge{T}

hoge::T

end

type Fuga{T}

hoge::T

Fuga(h::Hoge{T}) = new(h.hoge)

end

このFuga(h::Hoge{T})って外に出せないの？

**デフォルトの名無しさん** · 2017/02/14(火) 19:50:40.55

Fuga(h) = Fuga(h.hoge)

**デフォルトの名無しさん** · 2017/02/14(火) 20:26:35.21

それはコンストラクタじゃなく
いわゆるファクトリーメソッドなんじゃ？

Fuga{Int}(Hoge{Int}(123))
みたいに呼べないからtypealiasを使ったときに都合が悪い

それならconvert()の方がいい