サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
qiita.com/Nabetani
これは何? return の後ろにカンマ演算子で区切ったステートメントを記述し、最右のステートメントを返すことに有用性があるかどうか知りたいのです。 という記述を読み、そこに限定せずに コンマ演算子が役に立つパターンについて考えた。 とはいえ、 return 式, 式; が念頭にある。 そもそも そもそも、コンマ演算子は C 言語に由来する。 と言いたいところだけど、よく知らない。BCPL には無かったようなので、B言語か C言語なのかな。 いずれにせよ、C言語がきっかけで広まったと思う。 可読性の低下に寄与 コンマは演算子以外の用途でも使われるのでコンマ演算子なのかそうじゃないのかを判断するのがめんどくさく、可読性の低下に寄与しやすい。 a=(b,c); // コンマ演算子 a=f(b,c); // 引数区切り a=g((b,c)); // コンマ演算子 a=typeof(b,c); /
という具合になっていて、最上位ビットの意味だけが符号なしとは異なる。加減は符号なしと同じ計算ですむ。便利。 符号なしよりも扱える値の上限が小さくなるけど、負になれるので便利。 32bit を 1bit(符号) + 15bit + 1bit(使わない) + 15bit に分けて。 15bit で扱える 0〜32767 のうち 0〜9999 を使って 1万進数 ということもあるかもしれない。 可変長整数 CPU が直接扱えない、大きな整数を扱うのが主な用途。 ruby の 整数や JavaScript の BigInt なんかが可変長整数となっている。 可変長にも符号なしがありえるけど、メリットが少ないのか、符号なしは見かけない気がする。 そう簡単にはオーバーフローしないのが便利。 逆に、計算ミスとか予期せぬ入力とかで思いがけない超巨大数になっても計算が続いてしまって DOS 攻撃みたいになる
"hoge".bytesize #=> 4 "hoge".encode("utf-16le").bytesize #=> 8 "shuffle".encode("utf-16le").bytesize #=> 14 "shuffle".encode("utf-16le").bytesize #=> 10 "𩸽".encode("utf-16le").bytesize #=> 4 "shuffle" は、ffl (U+fb04) という ユニコードキャラクタを含んでいる。 "𩸽" は、いわゆるサロゲートペア文字。ほっけ。Java の char や Windows の wchar_t だと 二個になる。 コードポイント数 コードポイントの数を数えるともうちょっと文字数らしくなる。 String#size または String#length を使う。 "hoge".size #=> 4 "hoge".e
class Foo{略}; void hoge( Foo const & f ); void fuga( Foo const * fp ); Foo piyo(); という状況で hoge( piyo() ); と書けるから。 ポインタで受ける fuga を呼ぶためには一回変数に受けないといけないのでめんどくさい。 もちろん(速度目的ではなく)ポインタの指す先を書き換えてほしいということでポインタを使うことは大いにある。 ムーブセマンティクス ユーザー定義クラスで適切に定義するとめちゃくちゃ速くなることがある。 ユーザー定義クラス以外では、コンパイラが勝手にやってくれるので、あんまり意識して書く必要はないんじゃないかな。 ※ ユーザー定義クラスに適切に move を入れるのはあまり小手先という気がしない。 noexcept ユーザー定義クラスで move コンストラクタを noexcept
これは何? https://qiita.com/nodai2h_ITC/items/6c7b7ad029adf17da5f0#comment-4e0471395d41c1763f8f に ……何故PythonやJSのコードをプロポーショナルフォントで書いたのか問い詰めたい。 というコメントがあったので、プロポーショナルフォントでコーディングする人もいるよ、ということを伝えようと思って筆をとった。 プロポーショナルフォントで書いている人 今はどうか知らないけど、少なくともかつては、 ビャーネ・ストロヴストルップさん はそうだったと思う。 プログラミング言語C++第3版に とある。 これを読んで、私もかつてそうしていた。 プログラミング言語C++第3版に書いてあるとおり、しばらくしたらこちらが良いと感じるようになり、固定ピッチに慣れている人からは不思議がられるようになった。 第4版は、紙では持
は、わりと面白くない。 Twitter 方面で、 'c' の型が int であることに疑問を抱いている方が散見されるので追記。 なぜそうなっているのかは知らないんだけど、C 言語では古来よりシングルクオートで囲まれたリテラルは int 型になっている。規格書にもそう書いてある。 古い C でも のようにすると「sizeof('c') is 1」ではなく「sizeof('c') is 4」など(4 じゃないかも)となることから、 'c' が char ではないことがわかる。'c' が char だと思いこんでいる方は是非試してほしい。なお、C++ では 'c' は char なので、C++ としてコンパイルしないように注意が必要。 それはともかく。実際問題、'c' が char ではなく int だからといって sizeof に入れる以外の方法で違いがわかるパターンがないので、知っていても実
これは何? 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 )
整数を419378回インクリメントするとMacのg++が死ぬ や C++でアスタリスクをつけすぎると端末が落ちる にインスパイアされて。 ruby で (((((1))))) [[[[[1]]]]].flatten[0] 1+1-1+1-1+1-1+1-1+1-1 1.to_s.to_s.to_s.to_s.to_s p(aaaaaaaaaaaaaaaaaa=1) !!!!!!!!!1 のような式を食べさせて、どれぐらいで死ぬのか調べてみた。 環境は macOS High Sierra。メモリ 16GB。 ruby は ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]。 (((((1))))) a = [*1..20000] p(a.bsearch do |n| s="p"+"("*n+"1"+")"*n puts "#{
ruby に慣れていて python に慣れていないんだけど、python を書く機会が増えてきたので備忘録のような感じで。 python は完全に初心者。 python 3。python 2.x のことは気にしないことにした。 手元の処理系 ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-darwin16] Python 3.5.2 :: Anaconda 4.2.0 (x86_64) で確認している 長さ ary_len = [1,2,3].size # [1,2,3].length でもいい hash_len = {a:1}.size # {a:1}.length でもいい string_len = "hoge".size # "hoge".length でもいい range_len = (1..9).size # Range#len
Qiita で初めて LGTM をもらって嬉しかったので C言語のネタをもう一つ。 C言語の文法は、ポインタと配列の辺りで混乱がある。 // 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", s
この記事は Ruby Advent Calendar 2016の20日目の記事のつもりで書いている。 Advent Calendar というものに参加するのは初めてなので緊張している。 実務ではあまり ruby を使っていないので、私は自分が主催しているどう書く( https://yhpg.doorkeeper.jp/ )での ruby の使われ方を書こうと思う。 思いついた順なので、ごちゃごちゃするけど気にしない方向で。 Array#transpose 行列ではないものをtransposeできる言語が他にあるかどうか知らないんだけど、transposeは便利。 x方向で処理するプログラムだけを用意しておいて、y方向の処理は、データを transpose したものを渡すことで済ますとか。 あるいは、平面的なものを回転するときに役に立つ。 2次元配列をreverseしてからtranspose
以下、ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin14] での調査結果。 Float::NAN について知っておくべきこと ruby の Float::NAN は、浮動小数点の非数なので、以下の様な動作になる。 nan=Float::NAN nan==nan #=> false nan==0 #=> false nan<0 #=> false nan<=0 #=> false 0<nan #=> false 0<=nan #=> false 事情を知らないとかなり思いがけない内容だけど、浮動小数点の非数とはそのようなものなので仕方がない。 この、 同じ値を比較しても false になる 大小比較をすると必ず false になる という性質は 浮動小数点の非数がもつ一般的な性質で、ruby に限ったことではない。 これが理由
http://qiita.com/hkanda/items/e7c6001e356cfda3d783 を見て書いた。 以下、対話環境での断片と完全なプログラムがごっちゃになっているけど、1.1×2.2 をいろいろな言語でシンプルに書いてみた結果:
リンクしないけど、0の0乗がゼロ除算同様未定義であるというような記事がブクマを集めていてなんか困るよなぁと思って書いた。 前提として である。 $x^y$ は、$(0,0)$ で不連続になっているので、極限を根拠に $0^0$ を定めるとすると、不定とか定義されないとか、そういうことになる。 これは未定義のほうが好ましいかもしれない理由のひとつにはなるけれど、決して決定的ではない。 連続性を根拠にするのは、一見未定義であっても連続性を保つように定義できれば幸せになるからだと思う。 とはいえ。 $x^y$ の $(0,0)$ における連続性と、$0^0$ の値は、別の話だ。 どうやっても連続性が保てないからといって、よい定義が存在しないという事にはならない。 というわけで、$0^0$ が時折現れる世界をより住みやすくするためにはどうすればいいのかを考える。 ゼロ除算のように未定義にするのがよ
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 では
p( "x" "Y" ) #=> "xY" p( "x" 'Y' ) #=> "xY" p( 'x' 'Y' ) #=> "xY" String#+ はどうあがいてもメソッド呼び出しになる(と思う)ので、実行時の効率という点で、文字列の連接は意味がある。その辺りは Java や(たぶん)perl とは事情が違う。 で。 連接の結果がリテラルになるのであって連接自体が何かの操作というわけではないので、括弧は書けない。
先日の 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))#=
次のページ
このページを最初にブックマークしてみませんか?
『@Nabetaniのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く