quabbin (17251) の日記
throwsにGenerics
Java の throws 節では型変数が使える - 宮川拓の日記
を見て、これいつから有るんだろうと思ってJava5で試してみた
C:\...>java -version
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode, sharing)
C:\...>copy con Test.java
interface TestIF {
void method() throws T;
}
public class Test implements TestIF {
public void method() throws Exception {
throw new Exception();
}
public static void main(String[] args) {
TestIF t = new Test();
try {
t.method();
} catch (Throwable e) {
e.printStackTrace();
}
}
}
^Z
1 個のファイルをコピーしました。
C:\...>javac Test.java
C:\...>dir /w
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は ..... です
C:\... のディレクトリ
[.] [..] Test.class Test.java TestIF.class
3 個のファイル 1,134 バイト
2 個のディレクトリ ....... バイトの空き領域
C:\>java Test
java.lang.Exception
at Test.method(Test.java:3)
at Test.main(Test.java:9)
普通にコンパイルできて、実行できた…。
Java5から実装されていたのですね…これは知らなかった。
- 0 コメント
扇の耐久性
ふと、shitamoさんの日記のタイトルが目について、仕事の息抜きに体験した内容をコメントに書こうかと思ったのですが、だいぶ個人的な体験談になってしまったのでこちらに記録しておきます。
私は普段使いで扇をよく使っています。
値段は100円~10000円のものと、いろんなグレードのものを専門店や百貨店含め漁ってます。
しかし体験を元に結論から言うと、扇は普段使いをしている限り消耗品であり、長く使えるものではないと思ったほうが良いです。
最初にダメになるのは、shitamoさんも書かれてるとおりではありますが、要の部分です
金属製のしっかりしたものでないと、毎日使用していると4ヶ月くらいで外れてしまいます。
何がいいかは金額ではわかりにくいです。
金属製だけでは緩んで外れるものもかなりあるので、いろいろダメにしてみないとどれが良いかはわからないとおもいます。
一応基準的なものがあるとするならば、表と裏の両方から要を少しいじってみて、接合部分が見えないものを選ぶといい。
というくらいでしょうか。
要は良いものならばしっかり持つので、4000円以上のものを中心に上記基準で選ぶと良いかも知れません。
(4000円以上ならどれでも大丈夫というわけじゃないです)
次にダメになるのは扇面。
開閉が多いと磨耗して切れてしまいます。
体感的には厚紙<布地で耐久性が上がります。
しかし、布地は厚いと開閉が悪くなりますし、癖がついて開閉が困難になることも多いです。
薄いと当然、摩耗などでほつれ、最終的には破れます。
厚紙は言わずもがな、布以上に磨耗しやすいです。
切れても張替え(有料)をしてくれるところも結構ありますが、下のように張り替えればいいじゃんとはならないこともあります。
最後にダメになるのが中骨です。
これは扇面の張替えを何回かやっているとダメになります。
開閉の調子が良い物は竹の地が薄いのですが、扇面の張替えの時に少し削る関係で、いいもので1回の張り替えが限度です。
太いと耐久性は上がりますが、今度は開閉が困難となり、使いにくくなります
というわけで、私は一夏かそれに満たないくらいで一本潰している感じです。
そりゃまぁ使い方が乱暴なだけっていうのは…きっとそうなんでしょうけどorz
# というわけで、再度書きますがタダの体験談です。って程度に読んでいただけると嬉しいです。
- 5 コメント
Google IO 2012
ストーリーで書き込んだ以上、こちらに書くべきと思い、久しぶりに日記を書きます。
このような記事にあるとおりなかなか手に入らなかったGoogle IOのチケットですが、Code Jam sprint 2012で100位以内に入ったため、行けることになりました。
しかし、頑張って100位以内に入ったにも関わらず、出題ミスで参加者全員にinviteメールが…。
嬉しいのか悲しいのか。フクザツな気分です。
# 出題がミスっている事に気づけなかった…。う~む。
- 0 コメント
システムアーキテクト試験
久しぶりに日記。
成績紹介ページ、Chromeのdev版ではタイムアウトするが、Firefoxなら接続ができる。なんでだろう。
そして結果。
午前Ⅰ得点 91.80点
午前Ⅱ得点 ---.--点
午後Ⅰ得点 ---点
午後Ⅱ評価 ランク-
…あれ?
何が起こった…。
問合せるとするか。
追記
調査してもらった。
下一桁のマークが受験番号を間違えていたそうだ。
自己採点的にはイケたのだが、コレは痛い。笑うしかないなぁ。
まぁ来年頑張るとしよう。
再追記
申し込み時に免除申請忘れたりしたし、思えばその時からミソがついてたんだな。
- 0 コメント
lsしてみた
lsの結果をさらすのがはやっているらしいので
普段使いのNote。cygwinでの一覧
quabbin@Litchi ~ $ ls
SystemOut.log fact.rb javamail migration paging.rb template.txt
SystemOut_1.log fc2.rb kiseki.rb mitt pp.rb template2.txt
SystemOut_2.log git-test logger2.rb mitt2 product.rb u.rb
enum.patch gpl.txt maven.txt mitt3 sample.dot video.rb
extract.rb hdlg methinks.rb origin sample.yml
作りかけのゴミみたいなのがいっぱいあるなぁ
次に自宅の実験用サーバ機
quabbin@itsumi:~$ ls
mysql-5.1.34 pgdata8.3 stop-secret 音楽 公開 動画
mysql-5.1.34.tar.gz start-secret デスクトップ 画像 雛形 文書
思ったよりすっきり。
あまり面白みないですね。
ところで、別の話ですが…マウスの話のコメント。
G5 Laser Mouseの最速設定で、VisioやExcelのセルを1ドット単位で弄り回すと。
世の中には私と同じ事をやってる人が居るのだなぁと関心してしまいました。
ああいうのができるのは、単純に慣れなんですけどね…。
# チラ裏なのでここに。
- 0 コメント
[Chrome] 新しいタブが進化していた
先ほど気づいたのですが、Chrome3系(dev版)で「新しいタブ」ページが変更されていました。
見た目こんな感じ
新しいタブ全体
Chromeの3.0.193.0で確認。
ぱっと見たところの相違点は、
- 「Tips and Suggestions」という謎の領域が
- 「最近追加したブックマーク」の消失
- 「Recent Activities(最近の活動…くらいに訳されるかな)」に、最近のダウンロード結果が
- 「よく使うページ」のサムネの並びが変わった
あたりでしょうか
私がまず気になったのは、Tips and Suggestionsという謎の領域についてです。
いまのところ、トリガーになる動作を私がしていないのか、実装されていないのかは分からないのですが、とりあえず私の手元では動作した状況が見れていません。
そこで想像するしかなくなるわけですが、もしこれがChromeの使い方についてのTipsやら提案ならば、長く使っているユーザには不要な領域となっていくことは自明でしょうし、Googleっぽい情報エントロピーに配慮した画面配置から考えると、少し違和感があります。
よく使うページやらブックマークやらの活動から類推した、ページリコメンド機能あたりかなぁと想像すると納得いくわけですが、それだと言葉に違和感があるわけです。
ここは実際に動作した姿を待つとするしかないわけですが、だいぶ興味深い領域ですね。
次に気になったのは、「最近追加したブックマーク」の消失です。
よっぽど不評だったのでしょうか。
…私には、あの機能の問題点は、削除機能のUI部分にしか無さそうに思えたのですが。
ブックマークであっても時間的局所性はありそうなので、有用なモノだったはず…と思いつつ、そういえばあまり使ってなかったなぁと自分の行動を思い起こすことも。ん~。どうしてでしょうね。
「Recent Activities」としてダウンロード結果が見えるのは嬉しいですね。
ダウンロード中の表示が嫌で消してしまうと、落としたファイルを見失いそうになってCtrl+Jで履歴みていたのですが、新しいタブにもあるとダウンロード履歴ページを気にしなくてよくなるので、探しやすくなりそうです。
「よく使うページ」のサムネイルの配置は、配置変更ではなく削除しやすい機能をつけた点でもよい感じです。
サムネイルにカーソルを合わせると、表示が下のように変わります。
サムネイルにカーソルを合わせたの図
この右上にある×ボタンで、よく使うページ一覧から該当ページを削除することができます。
またドラッグ&ドロップで位置を変更したり、PINを設定したり(どう動くか、うまく実験できませなんだ)もできるようです。
このサムネイルの表示方法は、リスト形式とサムネイル形式があり、右上のボタンで変更できるようになっています。
リスト形式でよく使うページを表示
そして、これらをひっくるめて、表示・非表示の制御をする機能がついています。
表示変更ボタンで表示されるリスト
右上の▼を押すと出てくるリストでもって、各領域を表示したり隠せたり、遊べるわけですね。
まだ正式版は出てないわけですが、「新しいタブ」をキラー機能と位置づけているのか、更なる進化を追及してきたChrome。これからも目が離せませんね。
- 0 コメント
[Ruby] NaN。結論はまた今度
Ruby側でNaNが同一視されない問題について、どこをどうすれば他の言語と同じ動きになるか分かったので、先行論議がないか調べてみました。
すると
Ruby 1.9 - Bug #1720: [NaN] == [NaN] が true になる - Ruby Issue Tracking Systemを発見。
日付は2009/7/3。
あ~。つまるところ、乗り遅れなわけですねorz
内容を見てみると、
(1) NaN == NaN も true にする
一貫性はあるが NaN の本来の挙動ではない
(2) rb_equal()でまずequal?でのチェックをやめる
性能が劣化するので避けたい
(3) rb_equal()でT_FLOATを特別扱い
2ほどではないにしても性能劣化が気になる
特別扱いは後悔することが多い
(4) このまま。これは例外的なケースとする
で、4に傾きそうな感じ。
ちなみに私は3の案を考えてましたが、パフォーマンスに引っかかりを覚えるだろうなと思っていたら予想通りでした。
一つ前のエントリーに、ACさんとttさんからコメントを頂きました。
ACさんの指摘。
SQL では null 比較を = ではなく is や is not で行うというところにも目を向けると面白いかもしれません。
が興味深い。
手元のMySQLで試してみます
quabbin@itsumi:~$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 52
Server version: 5.1.31-1ubuntu2 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> select 0.0 / 0;
+---------+
| 0.0 / 0 |
+---------+
| NULL |
+---------+
1 row in set (0.00 sec)
mysql> select NaN, NaN is null, NaN = NaN, NaN is false
-> from ( select 0.0 / 0 as NaN) s;
+------+-------------+-----------+--------------+
| NaN | NaN is null | NaN = NaN | NaN is false |
+------+-------------+-----------+--------------+
| NULL | 1 | NULL | 0 |
+------+-------------+-----------+--------------+
1 row in set (0.00 sec)
なるほど。MySQLではNaNのかわりとしてNULLで実装されていますね。
これはSQLではNULL = NULLがtrueでもfalseでもなく、NULLだから…ってことでしょうか。
3値理論のfalseとはまた別だったと思うので、このあたりDBは複雑そうですが。
SQL92などで、こう定義されているってことなのかなぁと想像しますが、実際はどうなのでしょう。
ttさんの指摘。
本当はNaNは比較さえできないものなので、比較を含めてなんらかの処理を行った段階で例外を起こす(Signaling NaN)か、そうでなければ(QuietNaNであれば)仕方ないのでNaN!=NaNとなるのがIEEE754的な標準です。これは数学ではなく工学規格でありますが。
となると、NaN同士の比較は特別扱いにする(か、そこまで考慮した比較の仕様にする)必要が出てくるってことですね。
どうもセンスがないので、理解に時間かかりそうですorz
- 0 コメント
[Java] JavaにおけるNaN比較
先日の続き。
Javaではどうなるか気になったので試してみました。
C:\Develop>copy con NaN.java
public class NaN {
public static void main (String[] args) {
System.out.println(0.0 / 0 == 0.0 / 0);
}
}
^Z
1 個のファイルをコピーしました。
C:\Develop>^Z
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\javac.exe NaN.java
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\java.exe NaN
false
普通にfalseになるようです。
実際はどんな動きをしているか、javapを使ってみてみました。
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\javap.exe -verbose NaN
(中略)
public static void main(java.lang.String[]);
Code:
Stack=2, Locals=1, Args_size=1
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: iconst_0
4: invokevirtual #3; //Method java/io/PrintStream.println:(Z)V
7: return
LineNumberTable:
line 3: 0
line 4: 7
…あ、コンパイラが最適化してたorz
というわけで、やりなおし。
C:\Develop>del NaN.*
C:\Develop>copy con NaN.java
public class NaN {
public static float getZero() {
return 0.0f;
}
public static void main(String[] args) {
System.out.println(getZero() / 0 == getZero() / 0);
}
}
^Z
1 個のファイルをコピーしました。
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\javac.exe NaN.java
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\javap.exe -verbose NaN
(中略)
public static void main(java.lang.String[]);
Code:
Stack=4, Locals=1, Args_size=1
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: invokestatic #3; //Method getZero:()F
6: fconst_0
7: fdiv
8: invokestatic #3; //Method getZero:()F
11: fconst_0
12: fdiv
13: fcmpl
14: ifne 21
17: iconst_1
18: goto 22
21: iconst_0
22: invokevirtual #4; //Method java/io/PrintStream.println:(Z)V
25: return
(中略)
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\java.exe NaN
false
今度は問題無さそうです。そして動作は、やはりfalseでした。
# しかし、実行時最適化されているかどうかは不明です
# このあたりのJavaの動きは、ある種クレイジーで面白いわけですが。
では、計算しない場合はどうなのでしょう。
C:\Develop>copy con StaticNaN.java
public class StaticNaN {
public static float getNaN() {
return Float.NaN;
}
public static void main(String[] args) {
System.out.println(getNaN() == getNaN());
}
}
^Z
1 個のファイルをコピーしました。
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\javac.exe StaticNaN.java
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\javap.exe -verbose StaticNaN
(中略)
public static void main(java.lang.String[]);
Code:
Stack=3, Locals=1, Args_size=1
0: getstatic #3; //Field java/lang/System.out:Ljava/io/PrintStream;
3: invokestatic #4; //Method getNaN:()F
6: invokestatic #4; //Method getNaN:()F
9: fcmpl
10: ifne 17
13: iconst_1
14: goto 18
17: iconst_0
18: invokevirtual #5; //Method java/io/PrintStream.println:(Z)V
21: return
(中略)
C:\Develop>\Develop\Language\jdk1.6.0_07\bin\java.exe StaticNaN
false
やはりfalseです。
こちらもPythonと同じ結果が得られました。
実装上、たまたまそうなっているだけでしょうか。
Java言語仕様のFloating-Point Operationsを見ると、
a numeric comparison operation involving one or two NaNs returns false and any != comparison involving NaN returns true, including x!=x when x is NaN
と、同一の変数であっても==での比較結果は常にfalseと明示的に書かれています。
世の中的には、どうやらx=NaNの時、x==xはfalseのようです。
しかし、それと数学とが一致しているかは、キット別の話なのかなぁと思いつつ、数学が弱いので判別つきません。
ん~。数学の勉強、どっかでしなければ。
- 2 コメント