知らないauto指定子について行ってはいけない

std::vector<std::uint32t> 長いですね。
Perlの国の民にはこのような長い形名をタイプするのは苦行以外の何物でもありません。
そこで苦しむPerl民のために、C++11から型推論により長い形名のタイプから我々を開放してくれるauto指定子が導入されました。
しかしこのauto指定子はさながら、純真な女児を甘いお菓子で誘惑する知らないおじさんのようなものなのです。

純真なのでオブジェクトの参照を返すところでauto指定子を使いたいとします。
以下のソースコードをご覧ください。

#include <vector>
#include <iostream>
#include <cstdint>

class A {
    private:
        std::vector<std::uint32_t> v;
    
    public:
        A(){
            for(int i = 0; i < 10; ++i){
                v.push_back(i * 2);
            }
        }
        
        int get(int i){
            return v[i];
        }
    
        std::vector<std::uint32_t>& ref(){
            return v;
        }
};

int main(){
    A obj;
    std::cout << obj.get(3) << std::endl;
    auto r = obj.ref();
    r[3] = 1;
    
    std::cout << obj.get(3) << std::endl;
}

これをコンパイルし、実行すると恐ろしいことにこうなります。

6
6

怖いですね。知らないと3時間ぐらいは無駄にしそうですね。

ここでは普通の値渡しと同じようにコピーが行われています。
正しくは呼ぶ側のautoを

auto& r = obj.ref();

と明示的に参照の形で宣言してやる必要があります。

(実行結果)

6
1

このautoの特性はポインタに対しても同様です。

これは純真な女児を陥れる大きな罠であり、物心ついた子どもには必ず教える必要があると思います。

Gamma関数を使おう

ちょい書きメモです。

ようじょはある日perlでΓ函数を使いたくなりました。
するとCPANにMath::GammaFunction*1がありました。
でもRMath.hが無いとかで入りませんでした。

ようじょは考えるのさえ面倒なので実装することにしました。
精度は欲しいですがPPの実装なので計算も軽そうなLanczos近似*2による実装をしてみました。

sub gamma($){
	my $x = shift;

	my $u = 2.102394798991390;
	my $a_inf = 3.062185443705942e-1;
	my $a_0 = 1.024166094985555;
	my $a_1 = 4.258010456317367e-1;
	my $b_1 = 1.000008131602802;

	return (( ( $a_1 / ( $x + $b_1 ) + $a_1 ) / ( $x + $b_1 ) + $a_0) / $x + $a_inf ) * exp(( $x - 0.5 ) * log( $x + $u ) - $x );
}

まあいいかなと思ったら、C99にtgamma関数なるものがすでに実装されていたのでした。
ということでXSでラップするだけ

double
gamma(input)
	double input
	CODE:
		RETVAL = tgamma( input );
	OUTPUT:
		RETVAL

アホらし。

*1:[http://search.cpan.org/~smueller/Math-GammaFunction-0.02/lib/Math/GammaFunction.pm]

*2:[http://www.kurims.kyoto-u.ac.jp/~ooura/papers/jsiam95.pdf]

undefの各コンテキストにおける振る舞いについて

この記事におけるperlのバージョンは5.18.0,
式の評価などは特に指定のないときperl対話シェルのReply*1上で行っているものとします。

未定義値undefははスカラ値です。
undefは単純なスカラコンテキストにおいてスカラ値undefを返します。

120> scalar undef
$res[85] = undef

121> undef
$res[86] = undef

122> my $a = undef
$res[87] = undef

123> $a
$res[88] = undef

またよく知られるようにブール値コンテキストにおいてundefが渡るときそれは必ず偽を返します。

134> (undef) ? 1 : 0
$res[92] = 0

135> if(undef){ 1 } else { 0 }
$res[93] = 0

136> unless(undef){ 0 } else { 1 }
$res[94] = 0

ここまではよく知られたundefの挙動です。
さてそのundefをいろいろ虐めてみたところこいつは結構怪しい挙動をすることがわかったのでここに記しておきます。

さて、上の例でスカラコンテキストにおいてundefはundefと書きました。これは厳密には不定コンテキストにおいてのみundefはundefとして振る舞うのです。
比較などにおいて特に数値コンテキスト、文字列コンテキストとしてundefが評価される時、数値コンテキストにおいては0,文字列コンテキストにおいては''(空文字列)として振る舞います。

144> 0 == undef
$res[101] = 1

145> '' eq undef
$res[102] = 1

ただしここで

148> '' == undef
$res[105] = 1 #true

149> 0 eq undef
$res[106] = '' #false

となかなかに不可解な動作をしますがこれは

154> ''.0
$res[110] = '0'

155> 0 + ''
$res[111] = '0'

156> 1 * ''
$res[112] = '0'

に見るように文字列コンテキストにおいて0が'0'として、数値コンテキストにおいて''が0として振る舞う（+, *, .はいずれも左結合な演算子）ためで、undefを責めるのはすこし可哀想です。

リストコンテキストにおいてundefを使う用事といえばこんなものが思いつきます。

190> my ($a, $b, $c) = undef
$res[142] = [
  undef,
  undef,
  undef
]

191> ($a, $b, $c)
$res[143] = [
  undef,
  undef,
  undef
]

これは左辺値のリストコンテキストをundef埋めする時によく使うものです。コードは行儀良く書かなければいけませんからね。
ところで同じリストコンテキストでも

192> my @a = undef
$res[144] = undef

193> @a
$res[145] = undef

194> scalar @a
$res[146] = 1

195> @a[0]
$res[147] = undef

196> @a[1]
$res[148] = undef

と少し違った動作をしますがここで忘れてはならないのが代入演算子=は右結合であり、上にあるいずれの式においても先ずundefが先に評価されるということです。
よってこれはundefによる動作ではなくスカラコンテキストにおける配列構造の性質であると捉えるべきです。

思い出してください。($a, $b, $c)は明らかにリストですが、@SOME_ARRAYは配列です。

269> @a = (4, 3, 2, 1)
$res[207] = [
  4,
  3,
  2,
  1
]

270> scalar @a
$res[208] = 4

271> scalar (4, 3, 2, 1)
$res[209] = 1

272> (1, 2, 3) == (3, 2, 1)
$res[210] = ''

273> (2, 1, 3, 2) == (1, 2)
$res[211] = 1

つまり何を言いたいかといえば上の($a, $b, $c)の例だけを見て

249> ($a, $b, $c)
$res[191] = [
  1,
  1,
  2
]

250> ($a, $b, $c) = ()
$res[192] = [
  undef,
  undef,
  undef
]

「と同じだ！そうか、リストコンテキストにおいてundefは空リストと同じだ！」などという早とちりをしないようにしようということです。

スカラコンテキストでundefが評価されると直接undefが渡るからスマートマッチングで'' ~~ undef, 0 ~~ undefは共にfalse、でもリストコンテキストを期待するときには空リスト扱いになるから() ~~ undefはtrueなんだな

2013-08-24 02:11:04 via YoruFukurou

↑バカ

前述のとおり代入演算子=は右結合なのでリスト代入の時本来は左辺値であるリストの方がスカラとしての振る舞いを持つのですが、これは取りうる全てのパターンにおいて

配列またはリスト = undef

が

配列またはリスト = @{ [undef] } => (undef)

と等価に振る舞うと見て差し支えないはずです。

そのため

274> @a = undef
$res[212] = undef

のとき@a = (undef)であり

275> defined @a
$res[213] = 1

は真を返します。これは直感的でありません。

配列@ARRAYに対するdefined @ARRAYが偽を返すのは

• my @ARRAY;のように単純に宣言されたとき
• undef( @ARRAY )が明示的に呼ばれたとき

のみで
@ARRAY = (undef)やdefined @ARRAYが真の後@ARRAY = ()を実行してもdefined @ARRAYは真を返します。

ただし上記の状態defined @ARRAYが偽の状態から@ARRAY = ()のように内部で無視される式を実行してもdefined @ARRAYは偽であったため、defined @ARRAYはメモリの状態を参照している物と考えられます。

このへんのundefの挙動って把握してないとちょっと複雑なデータ構造でギミックなことをしようとしたときドツボにはまりかねないですね。
僕としてはundefを含む式の評価は全て偽、と言うかそんなものは多く意味を持たないことが多いと思うので全部undefを返して欲しいものです。
文字列コンテキスト、数値コンテキストのundefの挙動と配列評価のときなんかで一貫して「未定義値」というfalseでないと困ることって多いと思うんですけどね。undefはあくまで実行の初期段階における内部的な振る舞いしか想定しておらずユーザレイヤでギミックな使い方をするのは想定されていないんでしょうか…
殊に、文字列コンテキストと数値コンテキストのあの挙動は少々頂けないです。

本当はこの後にスマートマッチングの悪口を書くつもりだったのですがこれ以上はエントリがごちゃごちゃしそうなので別エントリにて書こうと思います。
スマートマッチングは割と好きなので気は進みませんが… 5.18.0でexperimentalになった理由が少しは実感できたような…？

*1:http://search.cpan.org/~doy/Reply-0.07/lib/Reply.pm