non vorrei lavorare

ブログ名の通りです。javascript three.js mruby rust OCaml golang julialang blender

Goの符号なし整数の計算でハマった件

こんにちは。最近は奥さんは寝室で、子供たちと自分はエアコンのあるリビングで雑魚寝しているkjunichiです。

背景

Goで画像ファイルを読み込んで、Windowsコマンドプロンプトに表示するimgtype

github.com

コマンドのコードがひどく、内部処理をRGBからHSVにして、もう少しコードをスマートにしようとしていた。

なんかGoの整数演算はキャストの仕方がCと異なる

Cだと、より表現範囲の広い型への代入はキャストしなくても、少なくともコンパイラには怒られないが、 Goだと、この辺も指摘される。

画像処理なら符号なし整数型も割と使う

割とCを知っていると、数値計算浮動小数点より整数型での計算の方が早いことを体験しているし、 さらに画像処理なんかやってると、符号なしの整数側で画素値を扱うことが多い。

そんなバックグラウンドがあってか

RGB2HSV変換を見よう見まねで符号なし整数を使っておこなって、 以下のようなコードを書いていた

h := int32((60.0 * (g - b)) / (max-min))

なんか、表示が変だ!

安定のデバッグプリントで、hが1431655745とやらかしている値だった。 Cだとsinged unsignedわりと、いい感じに適当にやってても扱ってくれてた気がしたんだけど、 goだと明確に否定された感じ

答えがマイナスになる演算をすると駄目

Cではこの辺とよきには計らってくれる気がしなくもないが、Goでは明確に駄目だった。

(int32(a) - int32(b))/int32(c)

というように、明示的に符号付整数型に変換して演算しないといけない。

Rustだと

定数の演算場合、コンパイル時にエラー、動的に発生させると、実行時にパニックとなった。

まとめ

16色しか使えないので、当初、まぁ、色が白とびするのは仕方ないのかなぁ、 でも、HSV変換ではなく、

と感想持たれた、R,G,Bの組み合わせで色を決定する方式だと、それっぽく着色されており、モヤモヤしていた。

テスト大事

f:id:kjw_junichi:20170826145810p:plain

関連記事