ときどきの雑記帖 RE* (新南口)

人にやさしく

夏コミ

今回も行けそうにないなあ…

++

[Q&A] C＃のi++に納得がいかない - Qiita

もっともな質問だと思うけど 回答が「雑」というかなんというか。

向ヶ丘遊園

今はなき｢小田急モノレール｣レア技術の塊だった ｢向ヶ丘遊園｣への足､日本に2例だけのシステム | ローカル線･公共交通 | 東洋経済オンライン

モノレールはさておき

駅と隣接するボーリング場跡地は、現在「川崎市 藤子・F・不二雄ミュージアム」になっている

あそこに建てられたのか!＞ミュージアム

泥棒削り

とある冊子を読んでいたら(鉛筆の)「泥棒削り」というのがあって、 なんじゃそれはと調べてみたら

鉛筆 - Wikipedia

貧乏削り・泥棒削り
両端を削ることを地方によっては貧乏削り・泥棒削りと呼ぶ。 前述したように、鉛筆は複数本用意するのが基本だが、鉛筆の両端を削れば2本分として使える。 これを貧乏削りと揶揄する。貧乏削りは有効利用できる長さが短くなり不経済な使用法でもある。 学用品としての鉛筆は、削らない側の端部の一面の塗装を薄く削ぎ、露出させた木地面に氏名などを書くことがよく行われた。 この記名は、盗んだ鉛筆を「貧乏削り」すれば違和感なく削り落とすことができる。 そこで、そのような窃盗の証拠隠滅が疑われる使い方を「泥棒削り」と揶揄した。

ああ、あれを「泥棒削り」(や「貧乏削り」)と呼ぶのか。

新山さん

新山祐介 (Yusuke Shinyama) (@mootastic@mstdn.social) - Mastodon 🐘

Hacker Newsで見かけたときに タイトルだけスルーしてしまったが 新山さんの解説で 「ああ、そういう記事だったのか」と 読みに行った。 というのが最近何回か。

メモ

区切り位置指定ウィザードを利用する

一年前に知りたかった(謎)

ruby

最近ruby-listに質問の投稿があった。

[ruby-list:51024] 演算子優先度について - ruby-list - ml.ruby-lang.org

PHPで、if(!$x = 〜〜〜) という記述を見つけ、 「PHPではこんなのがエラーにならないんだ」と思ったのですが、 念のため、Rubyで

!x = 123

をやってみると、Rubyでもエラーにならず false になります。 演算子の優先度を考えると、これは、

(!x) = 123

の意味になって構文エラーになるはずと思ったのですが、

!(x = 123)

と見なされているようです。単項演算子 + - でも同様ですね。

これはさすがにバグじゃなくて意図的な仕様だと思うのですが、 演算子優先度の例外を作ってまで、

!(x = 123)
-(x = 123)
+(x = 123)

と見做したいという理由があったのでしょうか？

ふとした疑問ですが、ご存じの方、よろしくお願いします。

なかなかそれに反応の投稿がなく、一週間くらいたって

[ruby-list:51025] Re: 演算子優先度について

古いissueに議論があるのを見つけました。

Bug #9251: ! operator has lower precedence than = in an assignment expression

こうなっている理由はわかりませんが、今の動作で受け入れられているようですね。

という投稿があった。 例によって(謎)、構文定義をみてみると

parse.y

                | k_while expr_value_do
                  compstmt
                  k_end

expr_value_do   : {COND_PUSH(1);} expr_value do {COND_POP();}
                    {
                        $$ = $2;
                    }

expr_value      : expr
                    {
                        value_expr($1);
                        $$ = $1;
                    }
                ;

expr            : command_call
                | expr keyword_and expr
                    {
                        $$ = logop(p, idAND, $1, $3, &@2, &@$);
                    }
                | expr keyword_or expr
                    {
                        $$ = logop(p, idOR, $1, $3, &@2, &@$);
                    }
                | keyword_not opt_nl expr
                    {
                        $$ = call_uni_op(p, method_cond(p, $3, &@3), METHOD_NOT, &@1, &@$);
                    }
                | '!' command_call
                    {
                        $$ = call_uni_op(p, method_cond(p, $2, &@2), '!', &@1, &@$);
                    }

となっているので、意図はともかくそう動くよねえ という定義ではある。

そしてせっかくなので(謎)、 思いっきり古いバージョンでどうなっていたかもみてみると

から見つけられた 0.49では

parse.y

expr2           : IF expr2 then
...
                    }
                | WHILE expr2 term compexpr END end_mark
                    {
                        if ($6 && $6 != WHILE) {
                            Error("unmatched end keyword(expected `while')");
                        }
                        $$ = NEW_WHILE(cond($2), $4);
                    }
...
                | '!' expr2
                    {
                        $$ = call_op(cond($2), '!', 0);
                    }
                | '~' expr2
                    {
                        $$ = call_op($2, '~', 0);
                    }

となっていた。

たぶん最初からの動作ですね。 とはいえ !x = 123が今のような動作をするのは 「アクシデント」のような気もするんだけど。

ruby-hacking-guide

rubyハッキングガイド、なつかしい…

JavaScript

javascriptの等価演算子の謎挙動 - くらげのChangeLog

"1,234" == ["1", "234"] // true

配列を文字列化して比較してるからか?… って、’,‘が

もうちょっと調べた。

等価 (==) - JavaScript | MDN

等価演算子 (== および !=) は、抽象等価比較アルゴリズムを使用して 2 つのオペランドを比較します。 これは、およそ次のようにまとめることができます。

  • 両方のオペランドがオブジェクトである場合、同じオブジェクトを指している場合に限り true を返します。
  • 一方のオペランドが null で、もう一方が undefined であった場合は true を返します。
  • オペランドの型が異なる場合は、比較前に同じ型に変換を試みます。
    • 数値と文字列を比較する場合、文字列を数値に変換しようとします。
    • 一方のオペランドが論理値である場合、その論理値のオペランドが true である場合は 1 に、 false である場合は +0 に変換します。
      • オペランドのうちの一方がオブジェクトで、もう一方が数値または文字列である場合は、そのオブジェクトの valueOf() および toString() メソッドを使用してプリミティブに変換を試みます。
    • オペランドが同じ型である場合は、次のよう比較します。
      • 文字列型: 両方のオペランドが同じ文字を同じ順序で持っている場合のみ、 true を返します。
      • 数値型: 両方のオペランドが同じ値を持っている場合のみ、 true を返します。 +0 と -0 は同じ値と見なされます。一方のオペランドが NaN である場合は false を返します。
      • 論理型: 両方のオペランドが共に true であるか、共に false である場合のみ true になります。

で、

Array.prototype.toString() - JavaScript | MDN

配列の toString メソッドは内部的に join() を呼び出します。そちらで配列を結合し、配列のすべての要素をカンマで区切って一つの文字列に収めて返します。

なるほど。

ところで日本語版と英語版で書かれていることがだいぶ違うのだけど (今回の件には多分影響しない)、 翻訳が追い付いていないとかなのだろうか

新刊近刊

awk

特に目立った動きはなかった(たぶん)

FORTRAN Compiler on IBM 704

しんちょくありません😓

平均

Rで試してみた

> 3.14159265358979
[1] 3.141593
> rep(3.14159265358979,10)
 [1] 3.141593 3.141593 3.141593 3.141593 3.141593 3.141593 3.141593 3.141593 3.141593 3.141593
> mean(rep(3.14159265358979,187))
[1] 3.141593
> format(v, digit=15)
[1] "3.14159265358979"
> for (n in seq(160,180)) { printf("%d: %18.15f\n", n, mean(rep(3.14159265358979,n))) }
 printf("%d: %18.15f\n", n, mean(rep(3.14159265358979, n))) でエラー: 
   関数 "printf" を見つけることができませんでした 
> for (n in seq(160,180)) { print(sprintf("%d: %18.15f", n, mean(rep(3.14159265358979,n)))) }
[1] "160:  3.141592653589790"
[1] "161:  3.141592653589790"
[1] "162:  3.141592653589790"
[1] "163:  3.141592653589790"
[1] "164:  3.141592653589790"
[1] "165:  3.141592653589790"
[1] "166:  3.141592653589790"
[1] "167:  3.141592653589790"
[1] "168:  3.141592653589790"
[1] "169:  3.141592653589790"
[1] "170:  3.141592653589790"
[1] "171:  3.141592653589790"
[1] "172:  3.141592653589790"
[1] "173:  3.141592653589790"
[1] "174:  3.141592653589790"
[1] "175:  3.141592653589790"
[1] "176:  3.141592653589790"
[1] "177:  3.141592653589790"
[1] "178:  3.141592653589790"
[1] "179:  3.141592653589790"
[1] "180:  3.141592653589790"
> 

> for (n in seq(20,30)) { print(sprintf("%d: %18.15f", n, sd(rep(3.14159265358979,n)))) }
[1] "20:  0.000000000000000"
[1] "21:  0.000000000000000"
[1] "22:  0.000000000000000"
[1] "23:  0.000000000000000"
[1] "24:  0.000000000000000"
[1] "25:  0.000000000000000"
[1] "26:  0.000000000000000"
[1] "27:  0.000000000000000"
[1] "28:  0.000000000000000"
[1] "29:  0.000000000000000"
[1] "30:  0.000000000000000"

Excelの誤差の原因は正確にはわからんけど (単純にナイーブな加算しているからかもしれない)、 Rはさすがに考慮しているっぽい?

printf

printfに与えている引数の記述が見慣れないものだったので調べてみた

Bash Reference Manual

%(datefmt)T

Causes printf to output the date-time string resulting from using datefmt as a format string for strftime(3). The corresponding argument is an integer representing the number of seconds since the epoch. Two special argument values may be used: -1 represents the current time, and -2 represents the time the shell was invoked. If no argument is specified, conversion behaves as if -1 had been given. This is an exception to the usual printf behavior.

ksh93(1) - Linux man page

%(date-format)T

A %(date-format)T format can be use to treat an argument as a date/time string and to format the date/time according to the date-format as defined for the date(1) command.

date関連のものとそうでないものの区別をするため (書式指定文字に被りあったっけ?)に こうしたのかな。

ところでcopilotに これは何をするコマンドですか? /bin/ksh -c 'printf "%(%s.%N)T\n"' と聞いてみたらかなりまともな回答が返ってきて驚いた。

このコマンドは、現在のUNIXエポックタイム（1970年1月1日からの秒数）を表示します。具体的には、 /bin/ksh -c ‘printf “%(%s.%N)T\n”‘というコマンドは、以下のように動作します：

  1. /bin/ksh -c：これは、ksh（Korn Shell）を使用して、引数として渡されたコマンドを実行します。
  2. ‘printf “%(%s.%N)T\n”’：これは、printfコマンドを使用して特定のフォーマットで時間を表示します。 %(%s.%N)Tは、UNIXエポックタイムをナノ秒単位で表示するためのフォーマット指定子です。 %sはエポック秒を、%Nはナノ秒を表します。

また、このコマンドは、ksh93u+以降のバージョンでのみ動作します。 それ以前のバージョンでは、このフォーマット指定子はサポートされていません。

NDA

DRY

ベーマガ

38400

小さな防衛線 ≪ prev
next ≫ 速さは力