ときどきの雑記帖 2012

最新ページへのリンク
目次ページへのリンク

一つ前へ 2012年9月(上旬)
一つ後へ 2012年9月(下旬)

ホームへ

2012年09月20日

■_

情報理論 ―基礎と広がり― / Thomas M.Cover  Joy A.Thomas  著 山本 博資 古賀 弘樹 有村 光晴 岩本 貢 訳 | 共立出版 これはと思い値段を見ると… 税込価格 9,450円 ぐはっ

■_ めも

その1 Comparing Go and Java, Part 2 – Performance | Hacker News comparing Go and Java Comparing Java and Go workloads performance

■_ Patterns in C

Patterns in C - The Book

Patterns in C - The Book

Patterns in C - The Book

by Adam Petersen, September 2012

Dear reader, I'm pleased to announce my first book, Patterns in C. Patterns in C is a collection
of idioms, design and architectural patterns in the C programming language. The book highlights
the value of patterns. In the right context, patterns serve as an excellent tool for communication
and reasoning. The book provides a C programmer with techniques to benefit from the growing body
of knowledge captured in patterns.

(略)

Patterns in C is available as an e-book in different formats. You can read a free 
sample on the book's homepage and view more detailed information on Patterns in C.

I hope you enjoy it. 

ふむ。買ってみようかな。 でも評判は今ひとつ?↓

Patterns in C - The Book : programming

the free sample unfortunately is not very helpful in deciding if I should buy the book or not.

A few pages of one of the later chapters (actually discussing a pattern) would be more helpful.
Completely agreed. While the sample may be a great way of illustrating the authors ability to
write prose it does nothing for illustrating his ability to provide clear technical explanations,
nor does it give a good indication for the skill level of the intended audience, or the authors
knowledge in the subject for that matter.

I work primarily in C, and I'm always up for a good informative book on the subject to improve my
knowledge, but there are a lot of crap books out there on C, and even more that while well
written are shallow enough to not really provide any value to someone who is already a competent
C programmer.

■_

LaTeX をどのようにして iPad に移植したか

How we ported LaTeX to the iPad

How we ported LaTeX to the iPad

Today marks the end of a longterm project for us as the 1.1 update of Texpad makes it to the iPad
App Store with the ability to typeset LaTeX onboard the iPad. Having written a blogpost some time
ago about our first failed attempt I will write an update with how we did it.

The secret this time around was KerTeX, a little known TeX distribution being developed by Thierry
Laronde. It is unencumbered by GPLed code and it does not use TeXLive's atrocious Kpathsea library.
Consequently it is faster, smaller, embeddable and the distribution's directory structure is much
simpler. The build process is quirky, but clear as it carefully separates building the WEB-to-C
translator from building TeX itself from the translated WEB source, which makes it very easy to 
extract the relevant C files and build them into an iOS binary.

(略)


As such we have begun work on refactoring TeX's translated C sources into C++, dropping the
string pool and global variables along the way. Right now we are just getting going, but once the
project has reached a certain level of maturity we will of course open up the repository on Github.
Meanwhile if you are looking for a LaTeX editor for either iPad or your macbook, check out Texpad.

[Posted on 19 Sep 2012]

support@vallettaventures.com

© 2012 Valletta Ventures LLP

■_

■_

んでまあまだ悪戦苦闘しているわけですよ。 レイリー分布のあれとw

いろいろ調べて、わかんないなりに考えてみたんですが (そこ、「下手の考え休むに似たり」とかゆーな)、 中心極限定理のアドバイスをいただきましたが、 これに対し中心極限定理は標本平均と真の平均との誤差を論ずるものである。多くの場合、 母集団の分布がどんな分布であっても、その誤差はサンプルのサイズを大きくしたとき近似的に正規分布に従う。 あの例ではサンプル数は9個ですよね。 ちょっと少なすぎやしないかという疑問と、 そもそもあれらは「独立した」値なんでしょうか? (正直よくわからない)

もうひとつこれもサンプル数の少なさと関連してくるのですが、 求めている分散が不偏分散(n-1で割る方。なんかnで割るのもn-1で割るのも 「標本分散」と呼ぶ流儀があるそうでどうもよくわかりません。 大学ではnで割るのを標本分散と教えられたと思います) 中心極限定理 - Wikipedia 分散 - Wikipedia

2012年09月19日

■_

そういやこの本買ってたよなあということを思い出したのだけど見つからないw スキャン候補にして箱詰めしたんだっけか
プログラミングのための確率統計

プログラミングのための確率統計|Ohmsha

第6章 推定と検定

6.1 推定論
6.1.1 記述統計と推測統計
6.1.2 記述統計
6.1.3 推測統計におけるものごとのとらえかた
視聴率調査
コイントス
期待値の推定
6.1.4 問題設定
6.1.5 期待罰金
6.1.6 多目的最適化
6.1.7 (策ア)候補をしぼる――― 最小分散不偏推定
6.1.8 (策イ)「ベスト」の意味を弱める――― 最尤推定
6.1.9 (策ウ)単一の数値として評価基準を定める――― Bayes 推定
6.1.10 手法の選択に関する注意

この辺りとか今読むべき内容な気がががが。

pdf 版買えという啓示かしらん。

■_

■_

いかん。 どれもまとまらない。 放置して寝よう。

2012年09月18日

■_

PyCon JP 2012 に行かなかった話。 を書こうと思ったけど(実はチケット購入していた) 面倒なので止めた。

いつものように id:odz さんがコメントをしてくださったのですが (ありがとうございます)、

日付はべつなものの、↑のようなツイートを見かけたのでちと様子見。

で、f(1), f(2), ... のそれぞれは正規分布に従った分布になるはず(中心極限定理のため)。 なるほど >中心極限定理 すこーんと頭から抜けてました。はい。 中心極限定理

■_

プログラムをどのような尺度で測るかってーのはまあいろいろありまして

ではあるんですが(異なる言語間ではどうとか問題はあれこれありますが)、 じゃあどうすんのよという話が Making Software ―エビデンスが変えるソフトウェア開発
Making Software ―エビデンスが変えるソフトウェア開発 でちょっと触れられてたりします。

KLOC – What does it mean to Software Testing « Software Testing Blog

■_

んで、プログラマーの実力(能力?)をどう測るかというのも問題でありまして。 IT業界とマネーボール - 虎塚 Moneyball for software engineering - O'Reilly Radar Moneyball for software engineering, part 2 - O'Reilly Radar

oreilly radarのこのエントリ、確か書かれた当時に reddit辺りで結構盛り上がってたはず。 否定的な意見多かったかなあ。 訳そうと思ったけど 1の最初の方をちょっとやって投げ出してるなあw

マネー・ボール (RHブックス・プラス)
マネー・ボール (RHブックス・プラス)

■_

■_

うー、統計学やりなおしてー

2012年09月17日

■_

んでまあ昨日買ったあの本をちょこちょこ読んでいたのですが、 なんと言うかこう統計用語やら計算式やら図表やらがあちこちに ちりばめられていてこまごま書かれているんだけどどうにもすっきりこないというか なんというか。

えでぃおん
かつて石丸本店であった店舗に行ってみた。 なんか新しい曲がかかっていた。 例のキャラクターはどうなったんだろか

■_

恒例の途中で放り投げ

PHP is much better than you think - Fabien Potencier

PHP is much better than you think
 (PHP はあなたが考えているよりもずっと良い)

Fabien Potencier
July 04, 2012

Rants about PHP are everywhere, and they even come from smart guys. When Jeff Atwood wrote yet
another rant about PHP, it made me think about the good parts of PHP.

PHP に関する rants は至る所にあり、賢い連中 (smart guys) でさえもそういったことを (大声で)
云っています。Jeff Atwood が yet another な PHP についての rant を書いたときに、
それはわたしに PHP の good parts に関して考えさせたのです。


The biggest problem of these rants is that they come from people stuck in the old days of PHP. They
either don't care or they don't want to admit that PHP actually evolves at a very fast pace, both at
the language level but also at the community level. In fact, it evolves much faster than any other
language or web platform. It has not always been the case, but the last 5 years have been an amazing
journey for PHP.

これらの rants の最大の問題は、それが過去の PHP に縛られた人たちからのものだということです。
そういった人たちは PHP が実際には言語レベルだけでなくコミュニティのレベルにおいても
非常に速いペースで進化していることに注意を払わないし認めようとともしません。
事実、PHP の進化は他のどの言語や web プラットフォームよりも格段に早いものです。
常にそうだったわけではありませんが、ここ最近の5年間は PHP にとって amazing journey でした。


Before talking about the amazing things the PHP community has achieved recently, let's have a look
at some interesting numbers: PHP is used by 77.9% of all the websites whose server-side programming
language is known. WordPress is used by 16.6% of all the websites in the world. If you have a look
at the top three CMSes, for the websites that use a monitored content management system: Wordpress
is first with 54.3%, Joomla is second with 9.2%, and Drupal is third with 6.8%. Three products
written in PHP.

最近 PHP コミュニティが achieve した amazing things について話す前にいくつかの興味深い数字を見てみ
ましょう。PHP は既知のサーバーサイドプログラミング言語を使っているウェブサイトの 77.9% で使われてい
ます。そして WordPress は全世界の webサイトの 16.6% で使われています。
monitored content management system を使っている web サイトのための CMS のトップ 3を見てみると
Wordpress が一位で 54.3%、Joomla は二位で 9.2%、Drupal は三位で 6.8% となっています。
これら三つの products は PHP で書かれているのです。


PHP must have done something right, no?

Now, let me tell you a secret, the PHP "tour de force": Despite the changes over the years,
PHP is still the easiest language to learn for non-technical people: it allows anyone to create
dynamic websites faster than with any other technologies, it allows anyone to host websites cheaply
and without any hassles. PHP is probably not the best designed language in the world, but it lets
you get things done, and you can't argue with that.


Now, let me tell you a secret, the PHP "tour de force":
何年にもわたる数々の変更もかかわらず、
PHP は依然として non-technical people にとっての最も簡単な言語であるのです。
誰でも PHP を使えばほかのどの technologies を使った場合よりも素早く動的な
webサイトを構築することが可能です。
PHP はおそらく best designed な言語ではありません。
しかし、PHP は仕事をきちんと果たしてくれますし、
それに異議を唱えることはできないでしょう。


PHP, the Language
言語としての PHP

PHP 5.0 (released in 2004) brought us a very solid object model... wait a minute, I'm talking about
something released almost 8 years ago. Fast forward now. The latest PHP release, PHP 5.4, comes with
all the bells and whistles you might dream of in a modern web language: yes, PHP supports namespaces;
yes, PHP supports closures; yes, PHP supports traits.

(2004 年にリリースされた) PHP 5.0 はわたしたちに solid なオブジェクトモデルをもたらしました…
でもちょっと待ってください。
わたしはおおよそ8年も前にリリースされたものについて話をしているのです。
Fast forward now.
PHP 最新のリリース PHP 5.4 では modern な web 言語にあれば良いとあなたが思っていたかも知れない
笛太鼓 (bells and whistles) がすべてあります。
PHP は名前空間をサポートしています。
PHP はクロージャをサポートしています。
PHP はトレイトをサポートしています。


It took some time, but PHP 5.4 also comes with some nice syntactic sugar that makes the whole
experience better than ever: yes, PHP supports [] to define arrays; yes, PHP supports calling a
method on a newly created object ((new Foo())->bar()); yes, PHP supports getting an array item
from any expression ($foo->bar()[1]).

PHP 5.4 には makes the whole experience better than ever する
いくつかの nice な syntactic sugar があります。
PHP は配列を定義する [] をサポートしています。
PHP は newly created なオブジェクト上のメソッドの呼び出し ((new Foo())->bar())
をサポートしています
PHP は任意の式から配列の item を得る手段 ($foo->bar()[1]) をサポートしています。


PHP has even learned from its mistakes: register_globals and magic_quotes are definitely gone.

PHP は自身のミスからさえも学んでいるのです:
register_globals と magic_quotes は完全になくなりました。


Last, but not the least, PHP even comes with a built-in web server that eases local testing... and
it starts in a matter of micro-seconds.

最後に、PHP にはローカルでテストするのが容易な組み込みの web サーバーさえあります。
そしてこれはマイクロ秒単位で起動します。


Next challenges: How do we "upgrade" all the old tutorials talking about PHP on the web?
What is the best way to support the WebSocket technology in a PHP application?

Next challenges:
わたしたちはどのようにして web 上の PHP について述べられた古いチュートリアルのすべてを
“upgrade”するのでしょうか?
ある PHP アプリケーションにおける WebSocket technology をサポートするための
最善の方法とはどういったものでしょうか?


PHP, the Ecosystem
PHP そのエコシステム

Having a good language is great, but having a great ecosystem is even better. And the 
PHP ecosystem has evolved a lot in the last few years.

優れた言語を得ることは great です。しかし great なエコシステムを持つことはさらに良いことです。
そして PHP のエコシステムは過去数年で非常に進歩しています。

Git

I won't talk too much about this one. Git is everywhere and PHP embraced Git pretty fast. Almost all
major PHP libraries, frameworks, and products are now using Git, including PHP itself.

これについては多くを述べません。
Git はどこにでもあり、PHP は Git をとても embrace しています。
ほぼ全ての major な PHPの ライブラリ、フレームワーク、products は、
PHP そのものも含めて現在 Git を使っています。



Composer

Two years ago, I wanted to get rid of my ugly-PEAR-hack I did in symfony 1 to support plugins. I
wanted to replace it with something that was able to manage project dependencies, not a global
installer like PEAR. Managing dependencies is not an easy task, so I tried to find the best algorithm
to manage software dependencies; I had a look at everything: from Perl to Ruby, from Debian to Redhat.
Nothing was satisfactory: only homegrown solutions that happen to work... empirically. Then, I
stumbled upon ZYpp. That was it. ZYpp uses a SAT solver to manage dependencies. Fast forward. Thanks 
to the hard work of Nils Adermann and Jordi Boggiano, PHP now has one of the best dependency manager,
Composer.

二年前、わたしは自分が symfony 1 でプラグインをサポートするために行った
ugly-PEAR-hack を取り除きたいと考えていました
わたしはそれを project dependencies を管理できるような、
PEAR のようにグローバルなインストーラーではないものに置き換えたいと望んでいました。
依存性の管理は簡単な仕事ではありませんから、
わたしはソフトウェアの依存性の管理のためのベストなアルゴリズムを見つけようとしました。
Perl から Ruby まで、あるいは Debian から Redhat までいろいろ探してみましたが
満足いくものはありませんでした。
only homegrown solutions that happen to work... empirically.
それからわたしは ZYpp に取り組みました。
That was it.
ZYpp は dependencies を管理するために SAT solver を使っています
Fast forward.
Nils Adermann と Jordi Boggoano の hard work のおかげで
PHP は現在 best dependency manager のひとつを手にしています。
それこそが Composer です。



Yes, PHP has a better dependency manager than any other languages.

そう、PHP には他のどの言語よりも優れた dependency manager があるのです。


And thanks to Git, Composer, and the PHP built-in web server, it has never been easier to
download/install/test a PHP project.

そして Git、Composer、PHP のビルトイン web サーバーのおかげで、
PHP プロジェクトのダウンロード/インストール/テスト
がこれまでになかったほど簡単なものになったのです。

Want to test Symfony (using PHP 5.4)?
(PHP 5.4 を使って) Symfony をテストしたい?

  $ composer.phar create-project symfony/framework-standard-edition
  $ cd framework-standard-edition
  $ ./app/console server:run

Want to test Silex?
Silex をテストしたい?

  $ composer.phar create-project fabpot/silex-skeleton
  $ cd silex-skeleton
  $ php -S localhost:8888 -t web/

Don't know Composer yet? You should learn about it. Browse Packagist, the main Composer repository:
it already has 1900+ packages available and they have been installed more than a million times in
less than 3 months.

まだ Composer をご存知なかった? であればあなたは Composer について学ぶべきです。
Browse Packagist, the main Composer repository:
すでに1900を超えるパッケージが利用可能であり、
過去三ヶ月においてそれらは100万回を超えた回数インストールされているのです。

Next challenge: include the Composer installer in the next PHP version?

Collaboration

Community collaboration is the most important point of this post; the one I'm the most proud of. We
start to see better collaboration between PHP projects, even from the very big ones, the ones you
would think are large enough to not care about the others. phpBB, Drupal, eZ Publish, Symfony, and
many others (phpDocumentor, PHPUnit, Behat, Zikula, Propel, Doctrine, Midgard, ...) are sharing
code. Yes, they are "competitors" but they all understood that cross-pollination was a
good thing. And Composer is a good enabler.

comunity collaboration はこの post の最も重要なポイントであり、わたしが最も誇るところです。
わたしたちは、あなたが他を顧みないほど大きなものと考えるような大規模なものからさえ
PHP プロジェクト間でのよりよい collaboration を見つけることを始めました。
phpBB, Drupal, eZ Publish, Symfony, and many others
(phpDocumentor, PHPUnit, Behat, Zikula, Propel, Doctrine, Midgard, ...)
はコードを共有しています。
そう、彼らは「競争相手」ではありましたが、
cross-pollination が良いこと (good thing) であることを
理解していたのです。


Next challenge: Convince even more projects to join the trend.

Conclusion
結論

Let me say it again: PHP is probably not the best language out there, and I'm the first one to
scream about its quirks, but PHP is the best web platform... ever.

    (c) 2007-2012 Fabien Potencier

    Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License

■_

■_

比較するものでもないんだろうけど某社の現状を見るに(省略されました) 「食」からイノベーションを促進! グーグル式ダイエット講座 - GOURMET - X BRAND

2012年09月16日

■_

例の人が(単著じゃないけど)本を出していた。というか出たばっか。 ということで買ってみた。
データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践
データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践

The Art of Computer Programming の Vol.4 はほぼ未チェックなんだよなあ。 だって分冊があの厚さであのねだ(ぴー) 良いもの。悪いもの。: 「フカシギの数え方」の問題を解いてみた

The power of ignoring mainstream news そういやこう言う本を読みかけで放置してた The Information Diet: A Case for Conscious Consumption

■_ the

ウォズ曰く、最高の製品を作るために特許をみんなで共有すればいい | スラッシュドット・ジャパン YRO

ウォズ曰く、最高の製品を作るために特許をみんなで共有すればいい | スラッシュドット・ジャパン YRO

Bloombergによるインタビューで、AppleとSamsungの特許訴訟について尋ねられたウォズニアック氏は、カリ
フォルニアでの評決に対して不満の意を表し、決定は覆されるだろうとの予測を述べたという。また、取り
上げられている特許は革新的とは言えない細かいものばかりであるとし、すべての特許を共有して誰もが最高
の物を作れるようになればいいのに、とも述べたとのこと。

この「すべての特許を共有して」の部分なんですけど

Apple’s Wozniak Hopes IPhone Photos Beat His Samsung Galaxy’s - Bloomberg

The two companies also are battling in court, with Apple being awarded more than $1 billion last
month by a California jury that said Samsung copied the iPhone's design. Samsung said it will
appeal.

“I hate it,” Wozniak said when asked about the patent fights between Apple and Samsung. “I
don't think the decision of California will hold. And I don't agree with it -- very small things
I don't really call that innovative.

“I wish everybody would just agree to exchange all the patents and everybody can build the best
forms they want to use everybody's technologies.”

exchange all the patents と「the」がくっついているので、 ここで Woz が言及しているのはありとあらゆる特許ではなく、 Apple と Samsung の間で問題となった特許群のことじゃあないかと思うのですがどうでしょうか。

「all the time」と 「all time」 - 質問・相談ならMSN相談箱

えーごむずいす。

■_

あとで読むタブに残ってた Programming Language Concepts

Programming Language Concepts

The book Programming Language Concepts (PLC) provides an introduction to programming language
concepts and implementation technology, such as interpretation, compilation, type checking and
type inference, abstract machines, and garbage collection.

This book takes an operational approach to programming language concepts, interpreters and
compilers, thus enabling practical exercises and experiments. It covers basic concepts such as
abstract syntax, interpretation, stack machines, compilation, type checking, and garbage
collection techniques. Also, it covers more advanced topics such as polymorphic types, type
inference using unification, co- and contravariant types, continuations, and backwards code
generation with on-the-fly peephole optimization. The book presents the practical construction of
lexers and parsers, but not the more theoretical aspects of regular expressions, automata,
grammars and formal languages, which are well covered by many other texts.

The book's examples present several interpreters and compilers for toy languages, including a
compiler for a small but usable subset of C, several abstract machines, a garbage collector, and
ML-style polymorphic type inference. Each chapter has exercises based on such examples.

The book puts programming language concepts and constructs into their historical context and
shows how they affect Java and C#, thus strengthening students' understanding of these widely
used languages. The functional language F# is used as meta language throughout. Like other
languages in the ML family, F# has datatypes and pattern matching and is strongly typed, and
therefore is ideal for implementing language processors. An appendix provides a crash course in
F#. 

型検査と型推論があるらしいので買ってみるかな。 残念ながら電書はないっぽいけど。

目次→ http://www.itu.dk/people/sestoft/plc/sestoft-plc-toc.pdf で、amazon.co.jp でもぽちれるっぽいので アフィリエイト貼り付け Amazon.co.jp: Programming Language Concepts (Undergraduate Topics in Computer Science): Peter Sestoft: 洋書

Programming Language Concepts (Undergraduate Topics in Computer Science)

■_

Perl 6

Parsing command line arguments in Perl 6

Parsing command line arguments in Perl 6

(略)

Boolean argument with a default value
デフォルト値を持った Boolean 引数

In the next example, we extended the signature. In addition to the $source field we are now
expecting a boolean value to be assigned to $debug. We also gave it a default value, making this
parameter optional.

  use v6;

  sub MAIN($source, Bool $debug = False) {
    say "source: $source";
    say "debug:  $debug";
  }

Save the code and run it as perl6 cli.pl6.

You will find the output quite clear. We have to supply the source parameter and optionally the
debug parameter.

  Usage:
    cli.pl6 <source> [<debug>]

Let's try it again running it with one parameter: perl6 cli.pl6 data.txt

We get this output:

  source: data.txt
  debug:  False

And try it again, now supplying both parameters: perl6 cli.pl6 data.txt True

  source: data.txt
  debug:  True

You cannot pass the values in the opposite order and the boolean values must be True or False.

If we try something else: perl6 cli.pl6 data.txt 1 we get the usage message again:

  Usage:
    cli.pl6 <source> [<debug>]

Named parameter
名前つきパラメーター

As in regular subroutines, Perl 6 allows to turn arguments into named parameter.
通常のサブルーチン同様、 Perl 6 は引数を名前つきパラメーターにできるようになりました

Put a colon : in front of the variable name to turn it into a named variable:
変数名の前にコロン : を置くことでその変数を named variable にします

  use v6;

  sub MAIN($source, Bool :$debug = False) {
    say "source: $source";
    say "debug:  $debug";
  }

Let's see what happens if we execute the code without any parameter: perl6 cli.pl6

The usage message indicated that now we need to used the --debug flag if we want to turn on
debugging and that the named parameters must come before the positional parameters.

  Usage:
    cli.pl6 [--debug] <source>

Try this: perl6 cli.pl6 data.txt

  source: data.txt
  debug:  False

And now try perl6 cli.pl6 --debug data.txt

  source: data.txt
  debug:  True

You cannot change the order of the parameters as positional parameters have to arrive after the
named parameters. try perl6 cli.pl6 data.txt --debug and you'll get the usage message.

位置パラメーターのあとに名前つきパラメーターが来るという順序を変えることはできません。


All the parameters are named

In the next example we turn the source parameter to be named as well by preceding it with a colon ::

  use v6;

  sub MAIN(:$source, Bool :$debug = False) {
    say "source: $source";
    say "debug:  $debug";
  }

Try without any parameters: perl6 cli.pl6 and get:
このスクリプトに一切パラメーターを与えないと次のようになります

use of uninitialized value of type Any in string context  in method Str at ...

  source:
  debug:  True

That happens because named parameters are optional and the code will run without any parameter.
When we try to print the content of the $source variable, it will be undef and generate this warning.

これは名前つきパラメーターが optional なので
パラメーターが与えられない状態でコードが実行されるからです。
$source の内容を表示しようとすると、undef となり上記の警告が発せられます。

There are several ways to fix this:

We could set a default value, even if that is an empty string:

  sub MAIN(:$source = '', Bool :$debug = False) {

Required parameters
必須パラメーター

Exclamation point

We could also tell Perl, that $source is a required parameter by adding a trailing exclamation point !.

  sub MAIN(:$source!, Bool :$debug = False) {

Try to run the program now without any parameter perl6 cli.pl6

and you'll get the new usage message.

  Usage:
    code\cli.pl6 --source=<Any> [--debug]

You could, of course, declare that the $source variable should be an integer Int or some other
data type, if that was the requirement. For example like this:

  sub MAIN(Int :$source!, Bool :$debug = False) {

In that case the usage message will indicate the required data type:

  Usage:
    code\cli.pl6 --source=<Int> [--debug]

In order to supply the value for the source, currently you have to use exactly the above form

  perl6 cli.pl6 --source=data.txt

  source: data.txt
  debug:  False

If you happen to try the other common way:

  perl6 cli.pl6 --source data.txt

You will get the usage message as Rakudo currently does not yet support this form.

Conclusion

There is more of course, but I think this can already get you started writing applications Perl 6
that accept parameters on the command line.

Written by Gabor Szabo

Published on 2012-09-14

: を前置したり !を後置したりというやり方はまた賛否両論ありそうな。 いやまあこの仕様は前からだったのだろうけど気づいてなかった(忘れてた?)ので。はい。

■_

■_

2012年09月15日

■_

アレ

電卓の(演算キーの)配置について
数字キーの部分については規格で決まってるっぽいんですが、 演算キーはどうなんでしょうか(ざっと探したところでは見つからなかった)。 とはいえ、ある程度のグループ分けはできそう。 たとえば、四則演算キーが縦一列に並んでいる場合はどれも 上から ÷ × - + となっているようだし、 縦一列でない場合もそれなりの規則があるっぽい。

プレゼン本
高橋会長とかかくたにさんといった方々が執筆した プレゼンテーションの本とかあったらいいなあなどと思った。

■_

例の、レイリー分布云々のスライドの作者(の少なくとも一人)が ついった上にいるらしい(というか見つけた)。

フォローすべきか否か…ってマサカリ投げつけるわけにもいかんしなあ。

■_ ウォーターフォールとは

Waterfall is a mindset - Interrupted

Waterfall is a mindset - Interrupted

The Agile camp has become an industry, books, seminars, agile coaches, awesome incubators,
there's a lot of people making a living preaching this approach to building software, and it's
ok. Hey, this guy even said you can build a product without writing up-front what you're fucking
supposed to do, kudos to him.

But there's one thing missing in the picture, and it's the fact that everybody seems to think
agile is about process, and I dare to say it's not only about process, it's also about people.
There's a lot of waterfallists thinking they're agile just because they're in a meeting every
morning where nobody's allowed to use a chair.

Bullshit, let me show you.

Fortunately they're easy to spot if you come across one of them, they almost always say:

    I wan't to be an architect
    I don't want to be a tester
    I don't want to program forever, it's just a step in my career.

Let them burn in hell, yet another reason why we don't have ranks.

なんとなく「Let them burn in hell」が気に入ったので。

■_ ランダムに選び出す

Ned Batchelder: Selecting randomly from an unknown sequence

Ned Batchelder: Selecting randomly from an unknown sequence

import random

def random_element(seq):
    """Return an element chosen at random from `seq`."""
    it = None
    for n, elem in enumerate(seq):
        if random.randint(0, n) == 0:
            it = elem
    return it

↑を、「k個選び出す」ように一般化↓

Ned Batchelder: Selecting randomly from an unknown sequence

def random_elements(seq, k):
    """Return `k` elements chosen randomly from `seq`."""
    them = []
    for n, elem in enumerate(seq):
        if len(them) < k:
            them.append(elem)
        else:
            if random.randint(0, n) < k:
                them[random.randint(0, k-1)] = elem
    return them

■_ Tumbleweed

メモ。 Tumbleweed Smalltalk goes Native - Indigo Beetle pgregory/tumbleweed

Tumbleweed Smalltalk goes Native - Indigo Beetle

One of the first things I added to Tumbleweed was the ability to call out to native code directly
from within Smalltalk. The FFI (Foreign Function Interface) functionality of Tumbleweed is quite
simple to use, and very flexible. It is based on the libffi library. A recent commit extends the
support to include arbitrary ‘C’ structures as parameters to external functions, on top of the
already supported list of common ‘C’ language types.

Summary (for now)

This provides a very powerful and flexible mechanism for calling out to native code from Smalltalk.
The FFI framework also includes support for callbacks, calling back to Smalltalk from native, and
the latest changes to the FFI code support passing in and out ‘C’ structs. I'll go into how these
features work in another post, watch this space…

■_ 比較

GC あり/なし

Ingrater’s 3D Blog » Real World Comparison, GC vs. Manual Memory Management

During the 4th Semester of my studies I wrote a small 3d spaceship deathmatch shooter with the
D-Programming language. It was created within 3 Months time and allows multiple players to play
deathmatch over local area network. All of the code was written with a garbage collector in mind
and made wide usage of the D standard library phobos. After the project was finished I noticed how
much time is spend every frame for garbage collection, so I decided to create a version of the
game which does not use a GC, to improve performance.

In a pc game you usually want to achive 60 FPS (frames per second). That means you have 16.6 ms
time to simulate and render a single frame. Also you have to prevent big variations in frame time,
as this will lead to visual stuttering or other issues.

I created three version of the game for comparsion:
比較のために、わたしはこのゲームを 3バージョン作成しました

    GC Version compiled with DMD: The original version of the game. Compiled with dmd 2.058
    (-O -release -noboundscheck -inline). Not all memory is managed by the garbage collector.
    Large blocks of memory that only contain data and no pointers are allocated manually to
    improve garbage collector performance. In this version the GC is run manually once every
    frame, otherwise the frame times would vary to much, as you would get collection times of
    multiple seconds, which is not acceptable for games.

    DMD でコンパイルした GC バージョン。このゲームのオリジナルバージョンでもあります。
    dmd 2.058 でコンパイルしました (指定したオプションは -O -release -noboundscheck -inline)。
    すべてのメモリーをガーベジコレクターが管理しているわけではありません。
    ガーベジコレクターの性能を向上させるために、データのみを保持していてポインターを含まない
    large blocks は manually に allocate されています。
    このバージョンの GC は各フレームで一度 manually に実行します。
    そうしなければ frame times は非常に大きなものとなり
    as you would get collection times of multiple seconds, which is not acceptable for games.、
    それはゲームにとって受け入れがたいものです。


    GC Version compiled with GDC: Same as above just compiled with 2.058 GDC eqivalent.
    (-fno-bounds-check -frelease -O -finline-small-functions -findirect-inlining 
    -fpartial-inlining -fpeephole2 -fregmove)

    GDC でコンパイルした GC バージョン。
    GDC 2.058 でコンパイルした以外は上のものと同じ
    (指定オプションは -fno-bounds-check -frelease -O -finline-small-functions -findirect-inlining 
    -fpartial-inlining -fpeephole2 -fregmove)。

    Manually Memory Managed Version compiled with DMD: I throw away most of phobos and wrote my
    own replacements for it with different interfaces, as the phobos interfaces are usually not
    suitable for manual memory management. Small parts of phobos could be reused, for example
    std.traits. Also I made quite some changes to druntime. I added a reference counting mechanism
    to druntime to make threads reference counted. Also I added a memory tracker which would track
    and report memory leaks on program ending. Also all parts of druntime that did leak memory
    during developement have been fixed. For example I implemented a non leaking cache friendly
    hashmap. This version of the game uses manual memory management most of the time. If manual
    management is not feasable reference counting is used instead.

    DMD でコンパイルしたマニュアルメモリー管理バージョン。
    わたしは phobos の大部分を throw away して異なるインターフェースを持った自作の代替物を書きました。
    phobos のインターフェースはマニュアルメモリー管理には具合が良くなかったのです。
    phobos の、std.traits のような small parts は再利用しました。
    わたしはまた druntime にもいくつかの変更を行いました。
    スレッドに参照カウントさせるために参照カウント機構を druntime に追加しました
    メモリー利用を記録しプログラム終了時にメモリーリークを報告するメモリートラッカーを追加しました。
    開発中にメモリーリークを起こしていた drutime のパーツすべてを修正しました。
    たとえば non leaking で cache friendly な hashmap を実装しました。
    このバージョンのゲームはほとんどの部分でマニュアルメモリー管理を使用します。
    マニュアル管理が feasible でない場合には参照カウントが代わりに使われます。

Other then the memory management code, the code of the GC version and the manual memory management
version are exactly the same. This is the ideal real world comparison for GC vs. manual memory
management.

メモリー管理のコード以外は、GC バージョンとマニュアルメモリー管理バージョンとは
まったく同じコードです。
このことは GC とマニュアルメモリー管理とを比較するのに理想的なものです。

Results

    DMD GC Version: 71 FPS, 14.0 ms frametime
    GDC GC Version: 128.6 FPS, 7.72 ms frametime
    DMD MMM Version: 142.8 FPS, 7.02 ms frametime

以下略

■_ 遅延学習?

The Lazy Learner

The Lazy Learner

Summary

Chris Matts discusses ways of learning - Kolb’s Circle of Learning, Meme Wombling, Hangover –
with a focus on the cycle starting from Unconscious Incompetence to Conscious Competence.

訳されないよね。たぶん。

■_

ちと古い記事 (文:Justin James(TechRepublic) 翻訳校正:村上雅章・野崎裕子 2010年03月02日 07時00分) ですが、ある記事からリンクをたどっていきました。 プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集 - ZDNet Japan

プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集 - ZDNet Japan

基礎的な知識の有無を判定する質問の例として、以下のようなものを挙げることができる。

    「等値」と「等価」の違いを説明してください(この質問はTechRepublicのTony Patton氏に教えてもらったものである)。
    「値渡し」と「参照渡し」の違いは何ですか?オブジェクト指向システムや手続き型システムにおいて、これらにはどのような違いが存在するのかを説明してください。
    「ポリモーフィズム」とは何かを説明してください。
    「悲観的ロック」と「楽観的ロック」を比較し、違いを明確に述べてください。

 これらの質問のうち、最初の2つに答えられない応募者は、どう考えても「入門者レベル」ということになる。
また残り2つの質問は、「中級」開発者であれば答えられるはずである。

できると思うけどちと怪しいかもしれない。 call by value と call by reference の違いってのはともかく、 オブジェクト指向システムや手続き型システムにおいて~ と続いてるのはどういう意図だろう。

■_ もうすぐ絶滅するという紙の書物について

「もうすぐ絶滅するという紙の書物について」の薦め - Macテクノロジー研究所

気になってはいるし、他の用事で書店に行ったときに思い出したように探してみたりすることも あるのだけど、タイトルをきちんと控えていなかったりで見つけられないこと度々w。 見つけたときもなんのかんので買ってなかったりで(結構厚い) 未だに読んでいないこの本。 誰か感想聞かせてくだちい。

■_ メモ

買うと決めたわけでもないし、お勧めの本というわけでもありません (だから意地でもアフィリエイトをつけない)。

■_

2012年09月14日

■_

建築と動線の話 動線 - Google 検索

■_

■_ Understanding Computation

Understanding Computation: upcoming O'Reilly book on semantics, computability, lambda calculus, type theory : programming 経由で知った面白そうな本。 Understanding Computation Understanding Computation?-?O'Reilly Media

紹介文には

Understanding Computation - O'Reilly Media

Finally, you can learn computation theory and programming language design in an engaging,
practical way. Understanding Computation explains theoretical computer science in a context you'll
recognize, helping you appreciate why these ideas matter and how they can inform your day-to-day
programming. 

Rather than use mathematical notation or an unfamiliar academic programming language like Haskell
or Lisp, this book uses Ruby in a reductionist manner to present functional programming and lambda
calculus. It's ideal for programmers versed in modern languages, with little or no formal training
in computer science. Discover the theoretical underpinnings of your work with Understanding
Computation. 

 Learn fundamental computing concepts, such as Turing equivalence in languages 
 Discover how programs can handle difficult or impossible problems 
 Explore how many features a programming language needs 
 Examine how computers can help you write correct programs 
 Understand how to build data structures without mutation of state 
 Learn how programmers can make a simple language like the lambda calculus actually run on a computer
  

お、.jpにもあった。 Understanding Computation: Impossible Code and the Meaning of Programs

■_ 最上級

【宇宙戦争】横山信義総合スレ25【碧海の玉座】

988 名無し三等兵 [sage] 2012/09/14(金) 08:45:11.88 ID:??? Be:
    時々ミニッツとニミッツのどっちだか判らなくなる 

989 名無し三等兵 [sage] 2012/09/14(金) 08:54:34.93 ID:??? Be:
    >>988
    ちょっと違うけど、自分は学生時代に英語の授業で“最上級”を
    “もがみきゅう”
    と読んだことが… 

990 名無し三等兵 [sage] 2012/09/14(金) 09:52:03.73 ID:??? Be:
    >>989
    なあに、軍艦オタなら一度は通る道だw
    実際に口に出すかはともかく 

996 名無し三等兵 [sage] 2012/09/14(金) 15:38:47.80 ID:??? Be:
    本すれハ力戦敢闘、善クのびー作品ノ批評ヲ行ヒタリ

    無念ニモ残れす数尽キ、身動キスラ不可能ニナリタリ
    サレドモ住民ノ栄光ハ不滅デアル

    ヨッテ軍艦旗ノ降納ハコレヲオコナワナイ

    各員、誇リヲモッテ次すれニ向カハレタシ
    武運長久ヲ祈ル

997 名無し三等兵 [sage] 2012/09/14(金) 17:06:56.62 ID:??? Be:
    産めるか 

998 名無し三等兵 [sage] 2012/09/14(金) 17:52:13.23 ID:??? Be:
    産め 

999 名無し三等兵 [sage] 2012/09/14(金) 18:15:27.56 ID:??? Be:
    埋め方用意 

1000 名無し三等兵 [sage] 2012/09/14(金) 18:16:28.29 ID:??? Be:
    スレ、沈みます 

1001 1001 [] Over 1000 Thread ID: Be:
    このスレッドは1000を超えました。
    もう書けないので、新しいスレッドを立ててくださいです。。。 

■_ literate programming

DropboxがブラウザサイドのJavaScriptを1週間でCoffeeScriptに書き換え–コードの可読性をアップ

Dropboxの技術者チームは7月に、そのブラウザサイドのコードベースを1週間で書き直した。Dropboxの技術
部門のブログに、そう書かれている。書き直しによってそのJavaScriptのコードがすべて、CoffeeScriptと
呼ばれる言語に翻訳された。

CoffeeScriptは、コンパイルするとJavaScriptになる言語だ。シンタクスがPythonやRubyに似ていて、
“読解性の良いプログラミング(literate programming)”*ができることを目標として作られた。それはつま
り、人間が読んで分かるコードを書ける、という目標だ。
〔*: 余計な訳注: literate programming, 日本語Wikipediaなどが採用している“文芸的プログラミング”
という訳語は、私は個人的にキモチワルイ。〕

気持ち悪いと表現するかどうかはともかく違和感はある>文芸的~

■_

土曜日はアレに。

2012年09月13日

■_

某所でとある人たちと濃い話を

  F社の話
  N社の話
  プロジェクトマネージャの話
  ついったのブロックの話
  Rubyのブロックの話
  モナドとかモノイドとか型クラスと
  OCcamlとかHaskellとかF#とか
  F# MVPの話
  ロングゲート社の話
  F# に型クラスは(ry

  その他色々

■_

■_

Building a super-computer using Raspberry Pi and Lego : programming http://www.reddit.com/r/programming/comments/zs9a6/building_a_supercomputer_using_raspberry_pi_and/ Raspberry Pi Supercomputer Guide Steps http://www.southampton.ac.uk/~sjc/raspberrypi/pi_supercomputer_southampton.htm

2012年09月12日

■_

レイリー分布(レイリー分布 - Wikipedia) というのがありまして。 正規分布とか二項分布などとお仲間の、 確率分布 - Wikipedia のひとつです。 なんでも、ソフトウェア開発におけるあるプロダクトのバグの出方はこの 分布に従うようだという話があるのですね。 経験上そのように思われるだけで理論的にきっちり検証されてるものでもないようですし ロジスティック曲線やらゴンペルツ曲線とか言うのもありますがまあ今回はその辺りは脇に置きます。 ソフトウェアの品質を学びまくる:Rayleighモデル ─ その1 rayleigh distribution software defects - Google 検索 rayleigh distribution software test - Google 検索

で、 JaSSTソフトウェアテストシンポジウム-JaSST'10 Tokyo での発表の中に「テスト技術者のためのソフトウェアメトリクス入門- 信頼性を測定し予測する正しい作法 -」 というのがあり、そこでこのレイリー分布を使って「予測」してたりするんですが どうもよくわからんところが。

いやまあ自分は大学でも統計学のさわり、ではなく初歩的なところだけしか やっていないので勘違いしている可能性大ありなんですけれど、 発表資料 (http://www.jasst.jp/archives/jasst10e/pdf/D4.pdf) の69枚目。 レイリー分布の確率密度関数 (x/σ^2)×exp(-x^2/(2×σ2)) (わかりづらい書き方で申し訳ない) をあーだこーだした K × (1 / tm)^2 × t × e^(-(1/tm^2)×t^2) という式で ある区間(第十週)に見つかるであろうバグの数の予測を求めようとしています。 ここで、K はバグの総数(の予測)、t は求める区間(ここでは10)、 tm はもっともバグが多く見つかった区間(発表資料では 5(第五週)) です。

話はここで回り道?をしまして、 第一週から第九週までのそれぞれの時点での K を求めます。 そして求められた9個の予測値の平均を使って第十週のバグ発見数を予測するというのですが、 ここで「平均値」って意味があるんでしょうか? また、ここで求めた「予測値」って標準偏差がどうこういう性質のものじゃあない気がしますし (最終的にはわかったはずの「真のバグ総数」との比較もないし)、 標準偏差としてあげられている 29.3 って n-1 を使った式じゃなく n を使った方の式で出てくる値なんですよね。 それはいいのか? という疑問もふつふつと 標準偏差 - Wikipedia 標準偏差について - 数学 - 教えて!goo

あ、あと第二週の446.9、第四週の516.4は先述の式から求まる値とは違うものに なってると思います。なんかこういう計算間違い(転記ミス?)があると 信じる気が失せていくというかなんというか。 求むよくわかる解説 ○| ̄|_

マンガでわかる統計学 マンガでわかる統計学 回帰分析編 マンガでわかる統計学 因子分析編 マンガでわかるナースの統計学 -データの見方から説得力ある発表資料の作成まで- データ分析入門 データ解析のための統計モデリング入門――一般化線形モデル・階層ベイズモデル・MCMC (確率と情報の科学)

■_

■_

ああ今日も一日ぐだぐだだった

■_

2012年09月11日

■_

京王線も複々線化するのね。 京王線連続立体交差化・複々線化 環境影響評価書送付|東京都 本日、東京都は、京王電鉄京王線(笹塚駅~つつじヶ丘駅間)連続立体交差化及び複々線化事業について、環境影響評価法に基づき、東京都都市計画審議会の議を経た環境影響評価書を国土交通省関東地方整備局長及び関東運輸局長に送付しましたので、お知らせします。

イブニング
しばちゅうさんとかレッドとか。 劉備が退場したり総括が始まったり。

レイリー分布。 の話は明日にしよう。

■_

コーディングスキルと employee スキル (こっちはなにか良い日本語ないだろか カタカナ書きにしちゃうとどうしようもないし)。

Coding skill vs. employee skill | Mike Crittenden

Coding skill vs. employee skill
You can get far without being a great coder
On September 5, 2012 - 5:41pm

At the extremely basic level, there are basically two good qualities that each programmer should
strive for: programming skill and employee skill.

Programming skill is basically the ability to write good, solid, performant, maintainable, and
all-the-other-desireable-code-adjectives code. This is what coders tend to spend their time
harping on and debating about and reading about.

プログラミングのスキルとは基本的には、優れたコード、solid なコード、性能の良いコード、
保守しやすいコード、そして all-the-other-desireable-code-adjectives なコードを書く能力です。
これは coder が自分の時間を費やしたり、議論したり読んだりするものです。

Employee skill is the ability to be a good employee and coworker. This means being responsive,
being able to communicate well, hitting deadlines, being open to feedback, being able to explain
complex things clearly, stuff like that.

Employee skill は良い employee かつ良い coworer でいるための能力です。
これはつまり、
responsive でいて、
良いコミュニケーションをとることができ、
hitting deadlines,
フィードバックに対してオープンであり、
複雑なことがらを明快に説明できるといったものです。


An extreme example
極端な例

Picture two people:

Rodrigo is an MIT graduate who writes compilers in his spare time. He is a core contributor to
Haskell and wrote a few very well known Python packages. He can generally write very solid code
that's readable and handles edge cases beautifully. However, he takes days to answer emails, he
rarely picks up his phone, he doesn't seem to have much of an understanding of the importance of
deadlines, he does things his own way, and you can't get a clear thought out of him without
rambling incoherence surrounding it.

Rodrigo は自分の spare time にコンパイラーを書くような MIT の卒業生です。
彼は Haskell の core contributor であり、a few very well known な Python パッケージを
書いたこともあります。彼はまた generally に非常に solid なコードを書きます。
そのコードは readable であり、edge cases も美しく handle しています。
しかし一方で、彼はメールの返事を返すのに数日かけたりしますし、
かかってきた電話に出ることは滅多にありません。
deadlines の重要性を良く理解していないように見えますし、
自分のやり方で作業を行います。
あなたは
rambling incoherence surrounding it.
抜きには彼を良く理解することはできないでしょう。
#後半だいぶ怪しい


Gabriella isn't a very good coder. Her code is obviously written by an amateur. She takes 30 lines
to write what should be written in 15 or 20, she introduces bugs that QA has to spend their time
on, and she doesn't really grasp the concept of writing code that performs well--
"if it works, it works!". However, she's incredibly responsive--she answers emails
within minutes and never misses a call, she is a great communicator and is able to explain complex
technical issues quite clearly to clients, she has never missed a deadline, she is constantly
looking for feedback to improve her work, and she's an easy person to talk to.

Gabriella は特に優れた coder ではありません。
彼女のコードは明らかにアマチュアレベルのものです。
彼女は15行から20行で書くべきコードを30行使って書きますし、
QA が時間を浪費してしまうようなバグを埋め込んでしまいます。
そして彼女は性能の良いコードを書くという concept に対して無頓着です。
"if it works, it works!".
けれども彼女は、incredibly resposive です。
彼女は数分のうちにメールに返事しますし、電話に出ないこともありません。
彼女は great communicator であり、
クライアントに対して複雑な technical issues をとても明快に説明することができます。
deadline を miss することは絶対にありませんし、
自分の仕事に対するフィードバックを constantly に求めていて、
とても話しかけやすい人物です。

So really think about it. Which would you really rather work with on a day to day basis?

What really matters?
本当に重要なことは何?

In my experience, a programmer would rather work with Rodrigo, and a manager would rather work
with Gabriella.

This makes some sense--after all, programmers are the ones who would have to deal with crappy
code, and managers are the ones who would have to deal with missed deadlines and crappy team
communication, so we all want the person who causes us the least amount of pain.

However, the point is that managers are the people you need to impress to get jobs and promotions
and raises and pats on the back, so in this scenario, Gabriella comes out way ahead. And I've seen
it happen many times--programmers who are great employees but not great coders move to the top
while the great coders but poor communicators stay on the bottom.

Despite what we as programmers like to think, coding skill is not what really matters if you want
to find success in a job, or at least in many jobs. Being a good employee is at least as important,
sometimes more.

From @mcrittenden with love

じかんぎれー

■_

ここまでやって飽きたw

Functr: Java Oddities (Part II)

Friday, August 31, 2012
Java Oddities (Part II)
Posted by Raoul-Gabriel Urma

My previous post (Java Oddities Part I) created a lot of discussion on reddit. People suggested
many interesting cases and I would like to describe some of them with additional details.

Thanks to Ben Evans for contributing some further information.

Dangerous Method Overloading
危険なメソッドオーバーローディング

  // credit to choychoy
  List<Integer> list = new ArrayList(Arrays.asList(1,2,3));
  int v = 1;
  list.remove(v);
  System.out.println(list); // prints [1, 3]

  List<Integer> list = new ArrayList(Arrays.asList(1,2,3));
  Integer v = 1;
  list.remove(v);
  System.out.println(list); // prints [2, 3]

The java.util.List interface describes two methods named remove.
java.util.List インターフェースは remove という名前のメソッドが二つあると describe しています


The first one is remove(int). It removes an element from the list based on its index, which is
represented by a value of type int (note: an index starts at 0). The second one is remove(Object).
It removes the first occurrence of the object passed as argument.

その一つめは remove(int) です。これは int という型の値として表現されている
index に基づきリストから要素を一つ取り除きます (index は 0 始まり)。
二番目のものは remove(Object)です。
これは引数として渡されたオブジェクトの first occurrence を取り除きます。



This is referred to as method overloading: the same method name is used for describing two
different operations. The choice of the operation is based on the types of the method
parameters. In academic terminology we will say that it is an example of ad-hoc polymorphism.

これはメソッドのオーバーローディングとして  reffered されます:
二つの異なる operation を describe するのに同一の名前を使う
操作の選択はメソッドのパラメータの方に基づいて行われます。
In academic terminology we will say that it is an example of ad-hoc polymorphism.



So what happens in the piece of code above? The first case is straightforward as we pass a
variable of type int and there's a signature for remove which expects exactly an int. This is
why the element at index 1 is removed.

先ほど例示したコードで起きることはどういったことでしょうか?
最初の case では


In the second case, we pass an argument of type Integer. Since there is no signature for remove
that directly takes an Integer parameter, Java tries to find the closest matching signature. The
Java Language Specification (Determine Method Signature) states that resolution based on
subtyping comes before allowing boxing/unboxing rules. Since java.lang.Integer is a subtype of
java.lang.Object, the method remove(Object) is invoked. This is why, the call remove(v) finds
the first Integer containing the value 1 and removes it from the list.

二番目の case では Integer という型の引数を渡しています。
取り除く対象の指定に Integer のパラメータを直接受け取る signature はありませんから、
最も closest に matching する signature の検索を Java は試みます。
The Java Language Specification (Determine Method Signature) では
subtyping comes before allowing boxing/unboxing rules
に基づく resolution で説明されています。
java.lang.Integer は java.lang.Object の subtype なので remove(Object) というメソッドが
invoke されます。
これが、remove(v) の呼び出しが 1という値を持っている最初の Integer を見つけ、
それをリストから削除してしまう理由です。



Note that this problem wouldn't exist if the java.util.List interface differentiated the two
remove operations with two different method names: removeAtIndex(int) and removeElement(Object).
For those interested in getting more views about method overloading, there is a famous paper
from Bertrand Meyer on the topic.


Array Initializer Syntax Curiosity
Array の Initilizer syntax が curiosity である


Java just like C and C# allows a trailing comma after the last expression in an array initializer.
This is documented in the Java Language Specification (Array Initializer).

Java は C や C# と同様に array initializer にある最後の式のあとの trailing comma を許しています。
このことは Java Language Specification (Array Initializer) に記載されています。


However, what if the initializer contains no expression? This is where Java differs from other
languages like C and C#:

しかし、ここでもし initializer が式を含んでいなかったらどうなるでしょうか?
この点に Java と C、C#のような言語との違いがあります。

  // Java
  int a[] = {}; // valid
  int b[] = {,}; // also valid, an array of length 0 >:o

  // C
  int a[] = {,}; // error: expected expression before ‘,’ token

  // C#
  int a[] = {,}; // Unexpected symbol ','


The Type of a Conditional Expression
条件式の型

  // credit to fragglet
  Object o = true ? 'r' : new Double(1);
  System.out.println(o); // 114.0
  System.out.println(o.getClass()); // class java.lang.Double

This looks a bit odd. The conditional expression is true, so you might expect that the char 'r'
would be boxed into java.lang.Char.

この結果は少々奇妙なものに思われます。条件式は true なのですから、
'r' は java.lang.Char に boxed されると期待するのではないでしょうか。


How did we end up with java.lang.Double as the runtime type of o? The value 114.0 
looks suspicious as well - but we might guess that it's the ASCII value which 
corresponds to the character 'r'. But why is it ending up in a numeric type?

さて、どのようにして実行時に o の型が java.lang.Double になったのでしょうか?
114.0 という値も奇妙に思われますが、これは 'r' という文字に対応する
ASCII value であろうと推測できるでしょう。
しかしなぜ numeric type になっているのでしょうか?


Let's take a step back, and examine the general question - which is: what should the type of the
conditional expression be if the type of the second and third operand are different?

一歩戻って、general question を examine してみましょう。
二番目のオペランドと三番目のオペランドの型が異なったときに、
条件式の型はどうなるべきでしょうか?


Java has a set of rules to determine this as explained in the Java Language Specification
(Conditional Expression).

Java Language Specification (の Conditional Expression) にこれを解決するルール群があります。


In this case, the rules say that first of all the third operand is unboxed to the 
primitive type double. This is specified by the binary numeric promotion rules. After 
that, a more familiar rule kicks in - the promotion rule for doubles.

今回の例のような場合、規則では第三オペランドは primitive type double に unbox される
ように書かれています。このことは binary numeric promotion rules によって specified されています。
そのあとでもっと慣れ親しんでいるルール である promotion rule for double の適用がなされます。


This says that if either operand is of type double, the other is converted to double as well. This
is why the second operand of type char is widened to a double.

これは、いずれかのオペランドの型が double であった場合にはもう一方も double に変換される
と言っています。これが型が char である二番目のオペランドが double に widened された理由です。


The second and third operand have now the same type and this is the resulting type of the
conditional expression - so the expression's type is the primitive type double (and it's value is
now the primitive value 114.0). Finally, since we are assigning the result of the conditional
expression to a variable of type Object, Java performs assignment conversion. The primitive type
double is boxed to the reference type Double (java.lang.Double).

その結果第二オペランド及び第三オペランドはいまや同じ型を持つようになっていて
それは条件式の resulting type です。つまり、この式の型は primitive type double なのです
(そしてその値は primitive value の 114.0)。
結局のところ、わたしたちは条件式の結果を Object 型の変数に代入しているので
Java は assignment conversion を実行します。
結果、primitive type double は reference type Doulbe (java.lang.Doulbe) へ box されます。


Note that such a mechanism wouldn't be needed for conditional expressions if Java restricted the
second and third operands to be strictly of the same type. An alternative option could be union
types.

Java が二番目と三番目のオペランドが strcictly に同じ型であることように制限していたならば
このようなからくりは条件式には不要であったことに注意してください。
もう一つの選択肢は union type です。


■_

■_


一つ前へ 2012年9月(上旬)
一つ後へ 2012年9月(下旬)

ホームへ


リンクはご自由にどうぞ

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp