はてなブックマーク

という具合になっていて、最上位ビットの意味だけが符号なしとは異なる。加減は符号なしと同じ計算ですむ。便利。 符号なしよりも扱える値の上限が小さくなるけど、負になれるので便利。 32bit を 1bit(符号) + 15bit + 1bit(使わない) + 15bit に分けて。 15bit で扱える 0〜32767 のうち 0〜9999 を使って 1万進数 ということもあるかもしれない。 可変長整数 CPU が直接扱えない、大きな整数を扱うのが主な用途。 ruby の 整数や JavaScript の BigInt なんかが可変長整数となっている。 可変長にも符号なしがありえるけど、メリットが少ないのか、符号なしは見かけない気がする。 そう簡単にはオーバーフローしないのが便利。 逆に、計算ミスとか予期せぬ入力とかで思いがけない超巨大数になっても計算が続いてしまって DOS 攻撃みたいになる

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

これは何？ 下記の記事が興味深かったので、C++ でできる小手先の速度改善について書いた。 手段色々 以下に色々小手先の技っぽいもの（小手先じゃないものも含む）を色々書いてみた。 効果がありそうなものもほとんど逆効果のものも書いた。 見出しでは区別できないので気になったら本文読んでね。 シフト演算 C/C++ で符号なし整数の 2倍・半分 などを計算する際にシフト演算で書いたほうが速い、という処理系はほとんどないと思うんだけど、どうだろう。 定数による除算・乗算 はコンパイラが賢くやってくれるので任せるのが良い。u*5 と u+(u<<2) のどちらが良いかはコンパイラに任せたほうがいい。CPU によって違うので。 それと。コードの意味がわかりにくくなるのでお勧めできない。 測定の上でなるほど速くなるということならそうすればいいとは思うけれど、その場合は単に掛け算割り算がしたいだけだとコメ

これは何？ https://qiita.com/nodai2h_ITC/items/6c7b7ad029adf17da5f0#comment-4e0471395d41c1763f8f に ……何故PythonやJSのコードをプロポーショナルフォントで書いたのか問い詰めたい。 というコメントがあったので、プロポーショナルフォントでコーディングする人もいるよ、ということを伝えようと思って筆をとった。 プロポーショナルフォントで書いている人 今はどうか知らないけど、少なくともかつては、 ビャーネ・ストロヴストルップさん はそうだったと思う。 プログラミング言語C++第3版に とある。 これを読んで、私もかつてそうしていた。 プログラミング言語C++第3版に書いてあるとおり、しばらくしたらこちらが良いと感じるようになり、固定ピッチに慣れている人からは不思議がられるようになった。 第4版は、紙では持

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

これは何？ Zig を学ぼうと 公式文書 (0.91時点) を読んでいるんだけど、読みながら思ったことを記していく。 続編は Zig の文書読んで所感を記す #2 へ。 その前に Zig への言及が最近多いなぁ、でもシンプルな言語だって言うしまあどうでもいいかなぁ、ぐらいの気持ちでいたんだけど、ZigはCMakeの代替となるか を読んで、俄然興味が湧いてきて、じゃあ読んでみるか、と思った。 数値 i32 とか u16 のような名前で型が提供されている。 整数は 128bit まである。そればかりか、 3bit とか 53bit のような中途半端な幅の整数も使える模様。面白い。 さらに。何に使うのかわかってないけど、 i0 u0 のようなゼロビットの整数もある。 ちなみに0ビット整数には 0 が代入できる。 u1 は、 0 または 1。 i1 は、 0 または -1 が代入可能。 浮動小数点

file "generated/cooked.json" => "hoge.json" do |a| cook_json( a.sources, a.name ) end hoge.json をなんか処理して、 cooked.json を作っている。 cooked.json 自体はそんなに大きくはない。 しかし、なにかわからない事情によって hoge.json のタイムスタンプは信用できないので、上記の rakefile はうまく機能しない。 touch hoge.json などとした上で rake するとビルドされるが、 cooked.json を生成する処理は割と重いので、hoge.json が変わっていないのであればそっとしておきたい。 解決方法

これは何？ 指数演算子が ** だとして。 -3**2 という文字列を評価する場合。 (-3)**2 -(3**2) という二通りの解釈があり得る。 一方。 数学では $-3^{2}$ は $-(3^{2})$ と評価するのが常識となっている。 プログラミング言語ではどうなっているだろうという調査。 各言語の対応 ruby この調査を始めようと思ったきっかけ。

これは何？ go の slice や C++ の std::vector のようなものに要素を追加する場合に世の人々がどうするのかを調べた。 そもそも いわゆる可変長配列というものの代表的な実装は 適当にメモリ確保して、そこに要素を格納する 確保した容量に入らなくなったら、別の場所にメモリを確保して、そこに全部移動してから新要素を追加する というものになっている。 この「別の場所にメモリを確保」の際にどうするのかが悩みどころ。 必要サイズぴったりにメモリ確保すると「1個追加」を1000回行った場合に絶望的に遅くなる。 多めに確保したいところだけど、多すぎるのはやっぱり損。 みんなどうしているのかなと思って調べてみた。 各実装 go の slice https://github.com/golang/go/blob/go1.18.1/src/runtime/slice.go#L193 辺りに

[ { "name": "An object that takes many lines to describe" }, { "name": "Many lines of definition" }, { "name": "Multi-line object" } ] のような場合、末尾の要素を末尾以外に移動したり、末尾に要素を追加したりすると「ここにカンマがあると文法エラーです」とか「ここにはカンマが必要です」とかいう文法エラーに見舞われる。というわけで、順序変更や末尾付近で追加削除するときにストレスを感じる。 これがケツカンマ問題である。 ケツカンマ問題が問題なのは、行末にコンマが必要な場所と行末のコンマが禁止の場所が両方あるからなので 全部コンマありなら問題ないような文法 全部コンマなしなら問題ないような文法 のいずれかなら人間としては楽になる。 具体的には、 最後の要素の後にコンマ

知っておくといいかもしれないこと。 go の chan が close済みかどうかを知る方法は、昔あったらしいけど今はない。 途中のバージョンで削除されたらしい。 削除された理由はおそらく、無いほうがいいから。あるとむしろトラブルの原因になる。 「close済みでなければ xxx する」というコードを書いても、「close済みでなければ」と「xxxする」の間で他人が close する可能性があり、それを排除することができない。 chan が nil だったり close済みだったりする場合の動作 nil の chan からの読み出しと書き込み。 そこで止まり、書き込み・読み出しが終わることはない。 それが唯一の goルーチンの場合、panic する。Recover できない。 close済み の chan への書き込み panic する。Recover できる。 send on close

mt19937の周期は1秒間に無量大数個の無量大数倍の乱数を発生させるコンピュータがあっても、無量大数年の無量大数倍を遥かに超える周期になっている。周期の長さを日本語で表現するのが困難である。 一方。 Xorshift128の周期 は $2^{128}-1 ≒ 3.4×10^{38}$ で、mt19937 より遥かに短い。 それでも十分長い。 1秒間に$10^{15}$個(千兆個。1ペタ個)の乱数を発生させると $10^{16}$年、つまり 1京年ぐらいで一周する。 日本語で表現できる範囲内ではあるものの、この周期で不足する状況を起こすのは難しいと思う。 というわけで mt19937 がファーストチョイス。とりあえず mt19937 を使う。 mt19937 だと計算速度面で問題があるようなら、 Xorshift128 を使う。 という対応を行ってきた。 xoshiro / xoroshi

先日、浮動小数点数の非正規化数と絡む機会があった。 で、非正規化数のことをよく知らなかったので調べた。 せっかく調べたのでメモを書いておく。 はじめに まあ、ふつうの環境の C / C++ の double 、ふつうの環境の ruby の Float 、いわゆる倍精度のことを念頭に。 以下、IEEE754 の 倍精度のみが唯一の浮動小数点数であるかのような感じで文章を書くけどもちろん本当はそうではないのでご注意を。 よく、C/C++ の DBL_MIN に double型の浮動小数点で表現できる正の値の最小値 などという説明が付与されているけど、これは間違っている。実際 #include <stdio.h> #include <float.h> int main(void) { printf( "DBL_MIN=%e DBL_MIN/10=%e DBL_MIN/1000=%e", DBL_

JSON には非数(NaN)は入れられない。入れられるフォーマットになっていないので仕方ない。 無限大も入れられない。入れられるフォーマットになっていないので仕方ない。 仕方ないんだけど、入れようとしたらどうなってしまうのか、各言語の対応を見ていく。 Ruby まずはソースコード： require "json" def test(e) print( e.inspect, ":" ) begin puts([e].to_json) rescue=>e p e end end test( Float::NAN ) test( Float::INFINITY )

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

// compiled with "gcc -std=c99 -Wall" #include <stdio.h> void test( short arg[5] ) { printf( "arg : %zd\n", sizeof( arg ) ); printf( "*arg : %zd\n", sizeof( *arg ) ); short foo[10]; printf( "foo : %zd\n", sizeof( foo ) ); printf( "*foo : %zd\n", sizeof( *foo ) ); printf( "&foo : %zd\n", sizeof( &foo ) ); printf( "*&foo : %zd\n", sizeof( *&foo ) ); printf( "&*foo : %zd\n", sizeof( &*foo ) ); printf

この記事は Ruby Advent Calendar 2016の20日目の記事のつもりで書いている。 Advent Calendar というものに参加するのは初めてなので緊張している。 実務ではあまり ruby を使っていないので、私は自分が主催しているどう書く( https://yhpg.doorkeeper.jp/ )での ruby の使われ方を書こうと思う。 思いついた順なので、ごちゃごちゃするけど気にしない方向で。 Array#transpose 行列ではないものをtransposeできる言語が他にあるかどうか知らないんだけど、transposeは便利。 x方向で処理するプログラムだけを用意しておいて、y方向の処理は、データを transpose したものを渡すことで済ますとか。 あるいは、平面的なものを回転するときに役に立つ。 2次元配列をreverseしてからtranspose

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

def try_sit( chairs, cus ) n=cus[0] pos = 8.times.find{ |x| (x...(x+n)).all?{ |y| chairs[y%8]==0 } } if pos (pos...(pos+n)).each{ |x| chairs[x%8]=1 } cus.shift end end def progress( chairs ) chairs.size.times do |ix| chairs[ix] = (chairs[ix]+1) % 4 if chairs[ix]!=0 end end def solve_impl( chairs, cus ) loop do try_sit( chairs, cus ) return chairs if cus.empty? progress(chairs) end end def solve(s)

先日、 JRuby は JIT によって 10倍ぐらい速くなる場合がある。 という記事を書いたんだけど、測りなおしたらそんなもんじゃなかったことがわかった。 まずはグラフ。対数目盛に注意。 わけのわからないところに横線があるが、一本2倍になっている。 今回は、【「とある無駄な計算」10回セット】を200回行った。 「とある無駄な計算」は、前回と同じ。 前回は「とある無駄な計算」を20回だったので、計算の規模は百倍になる。 前回は平均をとったが、今回は平均はとっていない。 という辺りが前回との違い。 グラフを見ると、あまり出入りのない CRuby に対し、JRuby は出入りが多い。 グラフが凸凹しているのは、測定しているのが生の時間だから、他のプロセスがCPUを専有していたのかもしれないんだけど、JRuby と CRuby の傾向の違いは読み取れると言っていいと思う。 横軸の回数は、【10

昨日書いたベンチマークの記事 http://qiita.com/Nabetani/items/2d054512c45990dd1235 で、JRuby の場合の測定時間の変化が面白かったので、変化だけを調べてみた。 結論：JITすごい。 追記： もう少し調べた記事を書いた。 JRuby は実行時最適化によって 50倍以上速くなり、CRuby を華麗に抜き去る場合がある。を参照 やってみたことは、 「ちょっと時間がかかる処理を、時間を計りながら20回行う」というプログラムをJRubyで3回、CRuby で1回 動かす、という作業。 で。 まずはグラフ。 JRuby に注目すると。 どの trial も初回が一番遅い。 2回目はいきなり半分ぐらいの時間で処理が終わる。 5回目で遅くなり、6回目以降は大きな山はないもののどんどん速くなる。 10〜15回目ぐらいで落ち着く感じ。 5回目の山は、JI

以前、 http://qiita.com/Nabetani/items/9776d99d09476d07c9e2 と http://qiita.com/Nabetani/items/47d357cc7f80f5c42f0d でベンチマークの記事を書いたんだけど、2.2.3 とか jruby9000 が出ているのでまた勝手なベンチマークをとってみた。 当初ここに書いた記事では JRuby が Java7 になっていたので、Java8で測りなおして追記した。 「3倍以上」より「4倍以上」が適切なようなので、タイトルも変えてみた。 まずはグラフ。 横軸は時間なので、長いほうが遅い。 simple_lambda の方は、jruby がやけに頑張っている。 jじゃないrubyでは、新しくなるほど速くなっていて、開発者の皆様ありがとうございますという感じ。 対照的に、complex_string では

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

先日の find_allのindex版( http://qiita.com/pocari/items/0b4e632ef2a2b6a97ba9 )という記事を受けて。 ruby 1.9 ruby 2.0 ruby 2.1 jruby1.7.12 --1.9 jruby1.7.12 --2.0 の5つの環境で速度がどう変わるか調べてみたよ。 わかったこと ※ すべて、今回のベンチマークの範囲の話。一般的かどうかはわからない。 each_with_index.select や flat_map.with_index は、ruby 1.9 → 2.0 → 2.1 と、すごく速くなっている。都合 10倍以上。 CRuby だと、each_with_index と each.with_index は、同じっぽい。 JRuby だと、each_with_index より each.with_index

ruby は改行がどうなるのかが大変わかりにくい。 まあ、こうなるだろうと想像できる感じに書くと想像通りになるので普通は困らないんだけど、微妙なケースが結構あって、そういうときにはほんとうに全然わからない。 微妙だな、と思わないように書けばいいんだけど、他人のソースに微妙なパターンがあるとドキドキする。 私自身はほとんど利用したことがないけど、ruby にはバックスラッシュによる行継続がある。 あるんだけど、C/C++ の行継続とは異なり、文脈によって行継続したりしなかったりする。 というわけで、いろいろ試した。 全て、ruby 2.1.3p242 での動作結果。 + による結合 p(3+4) #=> 7 ※ 当たり前 p(3+ 4) #=> 7 ※ ここで改行してもよい p(3 +4)#=> エラー。なんでだかわからない。p(3;+4) で 4 が出ると思ってた。 p((3 +4))#=