No Such Blog or Diary

要素の型Eを抽象化したデータ構造を Java で実装しようと思って E [] elements をフィールドに置きつつコンストラクタで elements = new E[8]; とかやったらコンパイラに怒られた．そういえば Generics のパラメータ E に対しての配列は作れなかったな……

ということで，elements = (E[]) new Object[8]; とかやって誤魔化す．JDK の ArrayList とかもこうやってるし，これが正しいのだろう．なにか色々なものを投げ捨てている気もするし警告でちゃうのだけど．

基本的には ArrayList 使っとけってことだろうけど，どうせなら配列生成の構文だけでも警告の出ない構文を用意してほしかった気がする．

昨日の続きで，ループ系の計算でも比較してみた．

#include
#include
int main(int argc, char *argv[])
{
	int sum = 0;
	int n = 0, i, j;
	n = atoi(argv[1]);
	for(j = 0; j  < 1000; j++) for(i = 0; i < n; i++) sum += i;
	printf("%d\n", sum);
	return 0;
}

import sys
n=int(sys.argv[1])
s=0
for j in range(0,1000): 
	for i in range(0, n):
		s += i
print(s)

結果：

hogehoge:~/work/pypytest$ gcc -O3 -o sumI sumI.c
hogehoge:~/work/pypytest$ time ./sumI 1000000
882236160
 
real    0m0.255s
user    0m0.252s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy sumI.py 1000000
499999500000000
 
real    0m2.105s
user    0m2.088s
sys    0m0.020s

もう一回：

hogehoge:~/work/pypytest$ time ./sumI 1000000
882236160
 
real    0m0.155s
user    0m0.152s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy sumI.py 1000000
499999500000000
 
real    0m2.130s
user    0m2.120s
sys    0m0.008s

10数倍くらい？　再起しまくりのフィボナッチと同じ程度．多倍長整数の演算になっている点が響いてるかも？

ということで，double でやった時：

hogehoge:~/work/pypytest$ time ./sum 1000000
5e+14
 
real    0m1.159s
user    0m1.156s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy sum.py 1000000
4.999995e+14
 
real    0m3.085s
user    0m3.064s
sys    0m0.024s

こっちは 2～3倍程度．

ということで，Python は C の 3～10倍程度の遅さでしょう．なお，CPU は Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz で．

フィボナッチ数の計算で C の 70倍遅いとかいうことを聞いて，何となく今までの体感と違かったので手元で測ってみた．PyPy だけど．

プログラム達：

#include
int fib(int n) {
	if(n  <= 1) return 1;
	return fib(n-1)+fib(n-2);
}
int main(int argc, char *argv[])
{
	printf("%d\n", fib(42));
	return 0;
}

def fib(n):
	if n  <= 1:
		return 1
	else:
		return fib(n-1)+fib(n-2)
print(fib(42))

結果：

hogehoge:~/work/pypytest$ gcc -O3 -o fib fib.c
hogehoge:~/work/pypytest$ time ./fib
433494437
 
real    0m0.902s
user    0m0.900s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy fib.py
433494437
 
real    0m9.285s
user    0m9.240s
sys    0m0.044s 

もう一回：

hogehoge:~/work/pypytest$ time ./fib
433494437
 
real    0m0.883s
user    0m0.880s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy fib.py
433494437
 
real    0m9.429s
user    0m9.372s
sys    0m0.056s 

10倍？　大体このくらいな気がする．

それぞれの --version の結果：

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
Python 2.7.10 (5.1.2+dfsg-1~16.04, Jun 16 2016, 17:37:42)
[PyPy 5.1.2 with GCC 5.3.1 20160413]

Python のライブラリの NetworkX が実験用のグラフをちょちょいと生成しようと思った時に便利だった．よくある生成の仕方に対して各種生成器が提供されているので．あとは目的の形にファイルに書き出すスクリプトを書いてあげれば OK．

インストールも pip で入るので楽．cygwin でも OK だった(setuptools 入れて easy_install pip して)．

どこまで大きなサイズまで実用できるのかはわからないけれど．

幾つかの言語で 0.5, 1.5, 2.5, 3.5, 4.5 を round 関数を使って丸めてみる．

C: 1, 2, 3, 4, 5 （直感的な四捨五入）

Java: 1, 2, 3, 4, 5 （直感的な四捨五入）

Haskell: 0, 2, 2, 4, 4 （偶数しか出てこない……）

ということで，Haskell は X.5 の時には偶数に丸めてくれるらしい．累積誤差を小さくできるとかで銀行で好まれるとか．Haskell は銀行に優しいのかもしれない．

これを知らずに微妙にハマった．

普通の Haskell ソース(.hs) だと下のような {-# LANGUAGE ... #-} をファイルの頭に書くのだけど，.lhs でそのまま同じに書いといたら ghc が認識してくれなくて困った．

{-# LANGUAGE FlexibleInstances,MultiParamTypeClasses,FunctionalDependencies #-}

で，{- -} がコメントだから，コメントがデフォルトになってる Literate Haskell では # LANGUAGE ... # と書くのか？　とかアホなことをしつつ，最終的にプラグマはプログラムの一部なんだから頭に > つけなきゃ認識されないよなとかいうことを理解した．

ということで，こう書けばよかった：

> {-# LANGUAGE FlexibleInstances,MultiParamTypeClasses,FunctionalDependencies #-}

今まで Literate Haskell でプラグマが必要なプログラムなんか書いてなかったのでアホなことに躓いた．