ときどきの雑記帖 めぐりあい電脳空間編

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

一つ前へ 2010年12月(上旬)
一つ後へ 2010年12月(下旬)

ホームへ

2010年12月20日

■_

だるーん。

■_ なぜRを使うのか?

Why Use R? | (R news & tutorials)
Why Use R?
December 14, 2010
By Joshua Ulrich

I use R very frequently and take for granted much that it has to offer.  I forget how
R is different from similar tools, so I have trouble communicating the benefits of
using R. The goal of this post is to highlight R's main strengths, but first...
my story.

How I got started with R
わたしが R をどのように始めたか

I was introduced to R while I was working as a Research Analyst at the Federal Reserve
Bank of St. Louis.  I wanted to do statistical analysis at home but the tools I used
at work (GAUSS and SAS) were expensive, so I started doing my analysis in Excel.

But as my analysis became more complex, the Excel files became large and cumbersome.
The files also did not document my thought process, which made it difficult to revisit
analysis I had started several months earlier.  I asked my fellow analysts for advice
and one introduced me to R and Modern Applied Statistics with S.  Thus began my
auto-didactic journey with R.

Why should you use R?
あなたは Rを使うべきか?

R is the leading tool for statistics, data analysis, and machine learning.  It is more
than a statistical package; it's a programming language, so you can create your own
objects, functions, and packages.

R は統計やデータ解析、機械学習といったものに向いたものです。
さらに多くの統計パッケージがあります。 R はプログラミング言語ですから、
あなたは自作のオブジェクトも作れますし、関数やパッケージも同様です。

Speaking of packages, there are over 2,000 cutting-edge, user-contributed packages
available on CRAN (not to mention Bioconductor and Omegahat).  To get an idea of what
packages are out there, just take a look at these Task Views.  Many packages are
submitted by prominent members of their respective fields.

パッケージに注目したとき、2000を超える cutting-edge な user-contributed による
パッケージがあって、CRAN から入手可能です。


Like all programs, R programs explicitly document the steps of your analysis and make
it easy to reproduce and/or update analysis, which means you can quickly try many ideas
and/or correct issues.

You can easily use it anywhere.  It's platform-independent, so you can use it on any
operating system.  And it's free, so you can use it at any employer without having to
persuade your boss to purchase a license.

あなたは R をどこででも簡単に使えます。
R はプラットフォーム独立なので、任意のオペレーティングシステム上で使えます。
また R は

Not only is R free, but it's also open-source.  That means anyone can examine the source
code to see exactly what it's doing.  This also means that you, or anyone, can fix bugs
and/or add features, rather than waiting for the vendor to find/fix the bug and/or add
the feature--at their discretion--in a future release.

R は無料であるだけでなくオープンソースでもあります。
これは、何をしているのかを正確に把握するために誰もがソースコードの精査ができるということを
意味します。そしてまたこれは、あなたを含めた誰であってもバグを修正したり機能の追加が
できるということでもあります。
ベンダーがバグを見つけ出して修正したりだとか
機能を追加するのを待つのではなく


R allows you to integrate with other languages (C/C++, Java, Python) and enables you to
interact with many data sources: ODBC-compliant databases (Excel, Access) and other
statistical packages (SAS, Stata, SPSS, Minitab).

R はあなたが別の言語 (C/C++、Java、Python) とintegrateするのを許し、
あなたが ODBC-compliant databases (Excel, Access) and other
statistical packages (SAS, Stata, SPSS, Minitab) のような
多くのデータソースと interact するのを可能にします。


Explicit parallelism is straightforward in R (see the High Performance Computing Task View):
several packages allow you to take advantage of multiple cores, either on a single machine
or across a network.  You can also build R with custom BLAS.

explicit parallelism は R において straightforward です
(see the High Performance Computing Task View)。
いくつかのパッケージは (単一のマシンでもネットワークをまたいでいても)
マルチコアの利点をあなたが得ることを可能にします。


R has a large, active, and growing community of users.  The mailing lists provide access
to many users and package authors who are experts in their respective fields.  Additionally,
there are several R conferences every year.  The most prominent and general is useR.
Finance-related conferences include Rmetrics Workshop on Computational Finance and Financial
Engineering in Meielisalp, Switzerland and R/Finance: Applied Finance with R in Chicago, USA.

R には、大規模で、活発的な、成長途上のユーザーコミュニティがあります。
メーリングリストは多くのユーザーや(自分の専門分野におけるエキスパートである)パッケージ作者に
対するアクセスを提供します。
加えて、毎年いくつかの R のカンファレンスが開催されています。
その中でもっとも prominent で general なのが useR です。



I hope that's a helpful overview of some benefits of using R.  I'm sure I have forgotten
some things, so please add them in the comments.

■_


Why Use R? (A nice introduction to R's advantages) : programming

Maybe it's just something like Stockholm Syndrome, but I love R as a language. After 
using R, using something like Python feels incredibly archaic and crufty, kind of like 
trying to use Java after coding in Python for a long time.

R has absolutely killer indexing semantics, not only can you subset, reorder, and 
otherwise easily munge vectors by either character names or integer indices, but you 
can also assign to these slices.

Also, the handling of arguments to functions is incredibly versatile, which allows for 
writing a single function that can do all sorts of things.


In addition to the great indexing semantics, I feel one of the lesser explored areas 
of R's features is that of its function call semantics. It features things like 
argument matching and lazy evaluation of arguments which very few other languages have.

Earlier this year I wrote a post about them (shameless plug) that may be of interest 
to those who spend a lot of time with R.

Numpy gives python most of, if not all of, the indexing and labelling features you 
rightly rave about. Check it out.



I've done a lot of array programming in R and Python and I can tell you without a 
doubt that Numpy shits all over R for indexing and slicing arrays.

Numpy does everything you described, but it is even more versatile. You can feed in an 
entire array as an indexing argument in Numpy, R will have a fit if you try that.


    You can feed in an entire array as an indexing argument in Numpy, R will have a fit if you try that.

LOL. R had array indexing before Numpy was a gleam in the programmer's eye!

Python も結構この分野強そうね。

■_

事情を知らない方にはまったく面白くないであろうネタですが。

南関東開発機構 : 冬コミ用手続き型言語インタプリタのソースコードと未実装になっている機能のまとめgist: 738786 - 冬コミに向けて作る手続き型言語の言語仕様(2010年12月13日案)- GitHubgist: 746791 - 冬コミ用手続き型言語インタプリタ- GitHub

>make
cl -c AST.c
Open Watcom C/C++ CL Clone for 386  Version 1.7
Portions Copyright (c) 1995-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
AST.c
AST.h(83): Warning! W138: No newline at end of file
AST.c(135): Warning! W107: Missing return value for function 'getNext'
AST.c(227): Warning! W107: Missing return value for function 'getSymbol'
AST.c(59): Warning! W131: No prototype found for function 'exit'
AST.c(19): Warning! W131: No prototype found for function 'malloc'
cl -c y.tab.c
Open Watcom C/C++ CL Clone for 386  Version 1.7
Portions Copyright (c) 1995-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
y.tab.c
AST.h(83): Warning! W138: No newline at end of file
y.tab.c(1467): Warning! W131: No prototype found for function 'yylex'
cl -c interp.c
Open Watcom C/C++ CL Clone for 386  Version 1.7
Portions Copyright (c) 1995-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
interp.c
AST.h(83): Warning! W138: No newline at end of file
interp.h(29): Warning! W138: No newline at end of file
interp.c(181): Warning! W138: No newline at end of file
cl -c interp_expr.c
Open Watcom C/C++ CL Clone for 386  Version 1.7
Portions Copyright (c) 1995-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
interp_expr.c
AST.h(83): Warning! W138: No newline at end of file
interp.h(29): Warning! W138: No newline at end of file
interp_expr.c(60): Warning! W107: Missing return value for function 'executeExpr'
interp_expr.c(109): Warning! W138: No newline at end of file
interp_expr.c(53): Warning! W131: No prototype found for function 'executeCallFunc'
interp_expr.c(73): Warning! W131: No prototype found for function 'exit'
interp_expr.c(93): Warning! W131: No prototype found for function 'malloc'
cl -c interp_main.c
Open Watcom C/C++ CL Clone for 386  Version 1.7
Portions Copyright (c) 1995-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
interp_main.c
AST.h(83): Warning! W138: No newline at end of file
interp.h(29): Warning! W138: No newline at end of file
interp_main.c(4): Error! E1055: Unable to open 'tree.h'
interp_main.c(26): Warning! W138: No newline at end of file
interp_main.c(9): Warning! W131: No prototype found for function 'yyparse'
interp_main.c(16): Warning! W131: No prototype found for function 'lookupSymbol'
interp_main.c(16): Warning! W131: No prototype found for function 'executeCallFunc'
make: *** [interp_main.obj] Error 255

>touch tree.h
>make
cl -c interp_main.c
(略)
cl -o kml.exe AST.obj y.tab.obj lex.yy.obj interp.obj interp_expr.obj interp_main.obj
Open Watcom C/C++ CL Clone for 386  Version 1.7
Portions Copyright (c) 1995-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.

>kml
main() {println("hello, world");}

^Z
execute main ...
hello, world
execute end ...

>kml
main() {println("hello, world");"}
 syntax error
execute main ...
execute end ...

>kml
main() {println("hello, world");");}

^Z
execute main ...
hello, world");
execute end ...

>kml
main(){ 1 / 0;}

^Z
execute main ...
An integer divide by zero was encountered at address 0x00402f4a.
Exception fielded by 0x00405d40
EAX=0x00000001 EBX=0x001b4cd0 ECX=0x00000000 EDX=0x00000000
ESI=0x00000000 EDI=0x00000000 EBP=0x0012fe50 ESP=0x0012fdbc
EIP=0x00402f4a EFL=0x00010256 CS =0x0000001b SS =0x00000023
DS =0x00000023 ES =0x00000023 FS =0x0000003b GS =0x00000000
Stack dump (SS:ESP)
0x00000000 0x00000000 0x001b4cd0 0x00000000 0x00402cc8 0x00000000
0x00000000 0x00000000 0x001b4ce8 0x00000000 0x00402d26 0x00000000
0x001b4d00 0x00000108 0x00402c48 0x00000000 0x00000000 0x00000000
0x0040d000 0x00000108 0x00402b40 0x00000108 0x0040d000 0x00000000
0x00000000 0x00000000 0x0012fe50 0x00402b2c 0x0012fe10 0x00230023
0x003b001b 0x00230000 0x0012ff74 0x00000048 0x00000000 0x0012fe6c
0x00000108 0x0012fe60 0x00403189 0x00000000 0x00407974 0x0012ff7c
0x00130000 0x004055e1 0x00033000 0x00000000 0x00000000 0x00000001
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0012ff74
0x00000000 0x00000000 0x00000002 0xffffffff 0x00000002 0xffffffff

>kml
main(){ 1 % 0;}

^Z
execute main ...
An integer divide by zero was encountered at address 0x00402f6a.
Exception fielded by 0x00405d40
EAX=0x00000001 EBX=0x00394cd0 ECX=0x00000000 EDX=0x00000000
ESI=0x00000000 EDI=0x00000000 EBP=0x0012fe50 ESP=0x0012fdbc
EIP=0x00402f6a EFL=0x00010256 CS =0x0000001b SS =0x00000023
DS =0x00000023 ES =0x00000023 FS =0x0000003b GS =0x00000000
Stack dump (SS:ESP)
0x00000000 0x00000000 0x00394cd0 0x00000000 0x00402cc8 0x00000000
0x00000000 0x00000000 0x00394ce8 0x00000000 0x00402d26 0x00000000
0x00394d00 0x00000108 0x00402c48 0x00000000 0x00000000 0x00000000
0x0040d000 0x00000108 0x00402b40 0x00000108 0x0040d000 0x00000000
0x00000000 0x00000000 0x0012fe50 0x00402b2c 0x0012fe10 0x00230023
0x003b001b 0x00230000 0x0012ff74 0x00000048 0x00000000 0x0012fe6c
0x00000108 0x0012fe60 0x00403189 0x00000000 0x00407974 0x0012ff7c
0x00130000 0x004055e1 0x00033000 0x00000000 0x00000000 0x00000001
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0012ff74
0x00000000 0x00000000 0x00000002 0xffffffff 0x00000002 0xffffffff

>kml
main() {println("hello");}

main() {println("world");}

^Z
execute main ...
world
execute end ...

>kml
main()

{

        var x;

        var y;
        syntax error
execute main ...
execute end ...

>kml
var x;

main() { x=1; println(x);}

^Z
execute main ...
The instruction at 0x004067cf referenced memory at 0x00000001.
The memory could not be read.
Exception fielded by 0x00405d40
EAX=0x00000000 EBX=0x0012fd9c ECX=0x00404780 EDX=0x00000001
ESI=0x00404780 EDI=0x00000001 EBP=0x0012fd9c ESP=0x0012fcf4
EIP=0x004067cf EFL=0x00010246 CS =0x0000001b SS =0x00000023
DS =0x00000023 ES =0x00000023 FS =0x0000003b GS =0x00000000
Stack dump (SS:ESP)
0x00000012 0x00000001 0x00000000 0x001f1f20 0x00000042 0x001f1f1f
0x001f1f1a 0x00000001 0x001f1f1b 0x0012fcf0 0x001f0148 0x0012ff74
0x775cfd89 0x7f42b7ee 0xfffffffe 0x775daa36 0x00404ae0 0x00000000
0x0040c242 0x00c80000 0x0012fd4c 0x00000000 0x00000000 0x00000007
0x00000000 0x001c4be8 0x00000012 0x0040c242 0x00404cc8 0x00000012
0x0040b2d9 0x00404780 0x0040c200 0x00000000 0x00000000 0x0040c242
0x0040480b 0x0012fe50 0x00000000 0x00000000 0x001c4d40 0x0040354c
0x0012fdb0 0x00000000 0x001c4d58 0x004030dc 0x00000001 0x00000000
0x001c4d58 0x00403055 0x00000000 0x00000000 0x001c4d58 0x00000000
0x00402cc8 0x00000000 0x00000000 0x00000000 0x001c4d70 0x00000000
0x00402d26 0x00000000 0x001c4d88 0x00000108 0x00402c48 0x00000000
0x00000000 0x00000000 0x0040d010 0x00000108 0x00402b40 0x00000108

>kml
var x;

main() { x=1; println("x=", x);}

^Z
execute main ...
x=
execute end ...

飽きたw

あの機能もないこの機能もない追加しなきゃとか言う前に、 きちんとデバッグしたほうがいいんじゃないすかね。

VC でコンパイルしようとすると失敗するんだけど、body とか val とかいう名前に なにか呪いがかかってたっけ? >VC

Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

interp.c
interp.c(20) : error C2143: 構文エラー : ';' が '型' の前にありません。
interp.c(23) : error C2065: 'i' : 定義されていない識別子です。
interp.c(24) : error C2065: 'var' : 定義されていない識別子です。
interp.c(24) : warning C4047: '==' : 間接参照のレベルが 'Symbol *' と 'int' で異なっています。
interp.c(25) : error C2065: 'val' : 定義されていない識別子です。
interp.c(26) : warning C4098: 'defineFunction' : 戻り値の型が 'void' で宣言された関数が、値を返しました。
interp.c(29) : error C2223: '->val' : 左側が構造体か共用体に対するポインタではありません。
interp.c(30) : warning C4098: 'defineFunction' : 戻り値の型が 'void' で宣言された関数が、値を返しました。
interp.c(57) : error C2065: 'funcReturnVal' : 定義されていない識別子です。
interp.c(72) : error C2065: 'args' : 定義されていない識別子です。
interp.c(72) : warning C4047: '関数' : 間接参照のレベルが 'AST *' と 'int' で異なっています。
interp.c(74) : error C2065: 'params' : 定義されていない識別子です。
interp.c(74) : warning C4047: '関数' : 間接参照のレベルが 'AST *' と 'int' で異なっています。
interp.c(74) : warning C4047: '関数' : 間接参照のレベルが 'AST *' と 'int' で異なっています。
interp.c(74) : error C2099: 初期化子が定数ではありません。
interp.c(76) : error C2057: 定数式が必要です。
interp.c(76) : error C2466: サイズが 0 の配列を割当てまたは宣言しようとしました。
interp.c(76) : error C2143: 構文エラー : '{' が '.' の前にありません。
interp.c(76) : error C2059: 構文エラー : '.'
interp.c(77) : error C2057: 定数式が必要です。
interp.c(77) : error C2466: サイズが 0 の配列を割当てまたは宣言しようとしました。
interp.c(77) : error C2143: 構文エラー : '{' が '.' の前にありません。
interp.c(77) : error C2059: 構文エラー : '.'
interp.c(78) : error C2143: 構文エラー : '{' が '++' の前にありません。
interp.c(78) : error C2059: 構文エラー : '++'
interp.c(80) : error C2059: 構文エラー : 'return'
interp.c(81) : error C2059: 構文エラー : '}'
interp.c(117) : error C2143: 構文エラー : ';' が '}' の前にありません。
interp.c(131) : error C2143: 構文エラー : ')' が '(' の前にありません。
interp.c(131) : error C2059: 構文エラー : ','
interp.c(131) : error C2143: 構文エラー : ')' が '定数' の前にありません。
interp.c(131) : error C2091: 関数は関数を返せません。
interp.c(131) : error C2143: 構文エラー : '{' が '定数' の前にありません。
interp.c(131) : error C2059: 構文エラー : '<不明>'
interp.c(131) : error C2059: 構文エラー : ')'
interp.c(131) : error C2059: 構文エラー : ')'
interp.c(132) : error C2059: 構文エラー : '}'
interp.c(135) : error C2059: 構文エラー : '}'

■_

■_

2010年12月19日

■_

・the
オライリーにも the art of なんとかってパターンのタイトルが結構ありますけど、 翻訳されると「アート・オブ」と冠詞が抜けちゃったりするんですよね。 「ジ・」って語感が嫌われてたりするんでしょうか。 なんとなーく間抜けな感じを受けるんですけどね。 英語のネイティブスピーカーはどう感じるんだろか。
アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング


ザ・クオンツに関しては読んでいろいろ思うところがあったのですが、 どうにもナイーブ(日本語的な意味で)な文章にしかならないので止めました。

Togetter - 「関数型プログラミングと論理型プログラミングのハッカソン」
えーと、何書こうと思ってたんだっけ(^^; というかですね。発表が面白くて肝心のハックとかほとんどやってないですよw F# の勉強とか勉強とか勉強ですけど。 とりあえずリストで要素を区切るのが ';' だってのは覚えた!(マテ

・「Elements of programming」

■_


C言語なら俺に聞け(入門編)Part 74 
976 デフォルトの名無しさん [] 2010/12/18(土) 21:13:01 ID: Be:
    ある本でメモ帳みたいなテキストエディタをつくるというのがあり、それのファイルの読み込みで
    ファイルサイズを取得し、それに応じてメモリを確保して読み込む
    また、書き込みで
    書き込む内容のサイズを取得し、それに応じてメモリを確保して書き込む
    というのがありますが、これは安全といえる方法なんでしょうか?
    何ギガというファイルを読み書きしようとしたらメモリを確保できずに大惨事になりそうで怖いのですが 

977 デフォルトの名無しさん [sage] 2010/12/18(土) 21:16:15 ID: Be:
    ファイルがでかいと、そもそも標準でファイル読むことすら安心して出来ません 

978 デフォルトの名無しさん [sage] 2010/12/18(土) 21:19:41 ID: Be:
    書き込みでもメモリ確保が必要なのか。 

979 デフォルトの名無しさん [sage] 2010/12/18(土) 21:24:25 ID: Be:
    emacsとかオンメモリでデータもってるんじゃないの?
    昔windowsのemacsででかいファイルを読み込もうとしたら固まったけど、
    DOS時代からあるエディタは、オンメモリで処理してないからストレスなく
    編集できてた。 

980 デフォルトの名無しさん [sage] 2010/12/18(土) 21:25:57 ID: Be:
    ええとアレだ
    ファイルマッピングとかでアレしろ 

981 デフォルトの名無しさん [] 2010/12/18(土) 21:26:37 ID: Be:
    >>977
    そうだったんですね ありがとうございました

    >>978
    そこは間違えました すいません 

途中まで読み込んでキー入力を受け付けるようになってその裏で読み込みってのは覚えにあるけど、 ファイルの一部だけ読み込んで編集ができるエディターってあったっけ… あ、Mifes ができるとか見たような覚えが。 いやまて。979 のいうように、単位が違うけどDOS時代も実装メモリの量と ファイルの大きさの関係は似たようなもんだしな。 あの頃のエディタはどうだったけか。

話は変わるが Vz エディターのソースが読みたい。 自分もちゃんと買ったから、本来ならソースコード持ってるはずなのだけど (製品のディスクにソースコードも入ってた)、製品ディスクが行方不明w

■_ 命名規則


【初心者歓迎】C/C++室 Ver.74【環境依存OK】 
291 デフォルトの名無しさん [sage] 2010/12/13(月) 01:14:31 ID: Be:
    でわネタ豆乳

    class hoge{
    private:
      int _data;
    public:
      hoge():_data(0){}
      ~hoge(){};
    };


    がいいいですか それとも

    class hoge{
    public:
      hoge():_data(0){}
      ~hoge(){};
    private:
      int _data;
    };

    のほうが好きですか
    privateが上にあるか下にあるか。
    ま どっちでもいんですがw 

292 デフォルトの名無しさん [sage] 2010/12/13(月) 01:18:59 ID: Be:
    googleは後者 

293 デフォルトの名無しさん [sage] 2010/12/13(月) 01:21:47 ID: Be:
    アンダーバーで始まる識別子は敬遠される。
    私は横着だから、
    class hoge {
    int data_;
    public:
    // construction
    hoge() : data_(0) {}
    ~hoge() {};
    // operation
    int get() const {return data_;}
    };
    こんな感じになるかな。 

294 デフォルトの名無しさん [sage] 2010/12/13(月) 01:39:42 ID: Be:
    やぱメンバ変数は
    m_付きがいいのでしょうか。 

295 デフォルトの名無しさん [sage] 2010/12/13(月) 02:01:02 ID: Be:
    >>294
    賛否両論ある話なので好きにしたらいいと思うよ 

296 デフォルトの名無しさん [sage] 2010/12/13(月) 02:11:53 ID: Be:
    人には言えないけどアンダーバー開始にしてる
    理由、VC++のインテリセンスで下にまとまって便利だから
    VC++stlもそうなってるし趣味プログラムだから許してちょ 

297 デフォルトの名無しさん [sage] 2010/12/13(月) 02:19:10 ID: Be:
    処理系が提供しているライブラリだから
    処理系予約の識別子記法で書いてるだけ。

    もちろん、絶対に個人でしか扱わないものなら
    どうしようと(それで将来不具合が出ようと)自由だけどね。 

298 デフォルトの名無しさん [sage] 2010/12/13(月) 12:17:26 ID: Be:
    俺は member data は _ で終わりにしてるけど
    _ で始める人もいる(ちょっと気持ち悪いけど)

    なんとなく何かと衝突しそうで怖い
    __ で始めるとヤバそうだけど一個なら安全なのかな 

299 デフォルトの名無しさん [sage] 2010/12/13(月) 14:52:52 ID: Be:
    _からはじめない派の人は、_の後に大文字が使えない(規格に違反する)ことを気にしているのですか? 

300 デフォルトの名無しさん [sage] 2010/12/13(月) 16:24:55 ID: Be:
    でもぶつかればコンパイルエラーになるのでわ? 

301 デフォルトの名無しさん [sage] 2010/12/13(月) 17:10:07 ID: Be:
    グローバルな関数に使ったりするのはダメだけどそれ以外はいいよ
    名前空間に入れるなりクラスのメンバにするなりする分にはいい 

302 デフォルトの名無しさん [sage] 2010/12/13(月) 17:10:53 ID: Be:
    >>296
    アンスコ2つで始まるのは標準ヘッダのマクロで使われてるかもしれないから問題あるが
    アンスコ一つならグローバルとstd名前空間で予約されてるだけだから
    問題無い。 

303 デフォルトの名無しさん [sage] 2010/12/13(月) 17:20:50 ID: Be:
    アンダースコア2つで「始まる」じゃなくてアンダースコア2つを「含む」識別子じゃなかったっけ 

304 302 [sage] 2010/12/13(月) 17:26:57 ID: Be:
    >>303
    アンスコ二つは「含む」でした。失礼したでござる。 

305 デフォルトの名無しさん [sage] 2010/12/13(月) 17:53:04 ID: Be:
    どうせタイプ一回ならmHogeでよくねーかアンスコだとシフト押さないといかんし 

306 デフォルトの名無しさん [sage] 2010/12/13(月) 17:54:40 ID: Be:
    麻雀プログラム書くときに卑猥になるからダメだ。
    bool mAnko; 

307 デフォルトの名無しさん [sage] 2010/12/13(月) 17:54:45 ID: Be:
    キャピタライズのときにもシフトは押すわけだが 

308 デフォルトの名無しさん [sage] 2010/12/13(月) 18:05:24 ID: Be:
    インテリセンスのためにも m_ を愛用してる。 

309 デフォルトの名無しさん [sage] 2010/12/13(月) 20:06:28 ID: Be:
    でもm以下の関数呼ぶのに邪魔じゃね? 

310 デフォルトの名無しさん [sage] 2010/12/13(月) 20:20:40 ID: Be:
    俺は_だな。
    先頭に_が付いてるってことで触って欲しくないとアピールできる。 

311 デフォルトの名無しさん [sage] 2010/12/13(月) 20:44:42 ID: Be:
    同じような話題で
    ヘッダの2重読み込み禁止のdefineの記述はちょっと悩まない?
    多分ぶつからんとは思うけどぉって。
    VCだと適当に付けてくれるんだけどね。

    #ifndef __HOGE_H__
    #define __HOGE_H__
    ・・・
    #endif

312 デフォルトの名無しさん [sage] 2010/12/13(月) 20:50:12 ID: Be:
    #define PROJECTNAME_ROOTDIR_・・・_HEADERNAME_HPP

    これでおk
    衝突したこと一度も無い 

313 デフォルトの名無しさん [sage] 2010/12/13(月) 21:04:01 ID: Be:
    #pragma once最強。
    他の処理系でもサポートしてくれれば・・・ 

314 デフォルトの名無しさん [sage] 2010/12/13(月) 21:08:22 ID: Be:
    >>309
    邪魔かもしれんけど、プログラムリストが一目で、ローカル変数と区別が付くのがいい 

315 デフォルトの名無しさん [sage] 2010/12/13(月) 21:23:08 ID: Be:
    >>311
    アンスコ二つを含む名前はコンパイラ以外が使っちゃいかん。

    ぶつからないよう氏名生年月日を入れるのがマジオススメ
    #define _山田太郎_19801231_プロジェクトA_TEST_H_ 

316 デフォルトの名無しさん [sage] 2010/12/13(月) 21:23:32 ID: Be:
    メンバもほかの変数も区別せんけどなぁ
    実装書くときに変数を省略形にするから被ることないし 

317 デフォルトの名無しさん [sage] 2010/12/13(月) 21:37:39 ID: Be:
    >>315
    てか作成時の時間を入れておけば大丈夫だよね 

318 デフォルトの名無しさん [sage] 2010/12/13(月) 22:05:33 ID: Be:
    アプリケーション命名規則じゃなく。
    作成時間命名規則、又は、作者名命名規則かw 

わたし個人の意見ですが、 _ を先頭に置くのはなんかいろいろ引っかかりそうだからら止めておこう というのはまあいいとして、 後ろにくっつけるのもなーんか余計な尻尾がくっついているみたいでいやなんですよね (いけがみさんの TwitterID を非難しているわけではありません)。

ということで m_ でいいじゃん。という異見だったり。 まあそんなのつけないですむパターンが一番いいのですが。

■_ irb alternative


J-_-L | ripl: Why should you use an irb alternative?

ripl: Why should you use an irb alternative?

What does it mean when the guy who blogged about irb's details and wrote most of the 
successful irb gems (hirb, bond, boson) decides to implement his own irb alternative? 
There must be something wrong with irb!

OK, to be polite, nothing is wrong with irb. Except that it is old and big. irb 
consists of more than 5000 lines – is this really necessary? You can build a simple 
irb in less then 40 byte ;)

Listing 1

loop{$><<">> ";gets;$><<'=> ';p eval$_}

The purpose of most of irb's code is to analyse the input for multi-line and 
auto-indent support. ripl (which stands for “ruby interpreter print loop”) does not 
care about these things and aims to be small and modern.

So, what does it do better than the “5000 lines” and “39 bytes” approaches? The 
github description tells it:

ripl is a light, modular alternative to irb. Like irb, it loads ~/.irbrc, has 
autocompletion and keeps history in ~/.irb_history. Unlike irb, it is highly 
customizable via plugins and supports commands i.e. ripl-play. This customizability 
makes it easy to build custom shells (i.e. for a gem or application) and complex 
shells (i.e. for the web).

The main advantage: It is easily extendable!

Furthermore, it is better documented than irb and comes with tests ;)

(略)

You can extend each of these methods, except loop. You can (and mostly should) use the 
super keyword to call the original ripl functionality (or the next plugin). This is 
possible, because the base methods are not directly declared in the Ripl::Shell class, 
but in an API module which gets included before any plugin. You should also read the 
main source file before starting to hack.

Besides Ripl::Shell, there is Ripl::Commands and Ripl::Runner, which work in a similar 
manner. You can include your custom module into Ripl::Commands and its methods become 
available in a ripl session (although, they are only available after a call to 
add_commands(eval("self", @binding))). You can extend Ripl::Runner to 
customize the starting process, e.g. by adding command line options.

To see some small example plugins, take a look at ripl-misc!

Creative Commons License
Comments


You may want to mention that unlike irb, ripl is well documented and tested. Also ripl 
has better autocompletion and 0.3.0 should have autocompletion hooks for plugins. As 
for ripl-irb, it's worth knowing it prints messages to convert irb configuration to 
ripl equivalents.

Thanks for the writeup. :)
© 2009 - 2010 Jan Lelis contact

ripl ね。試してみようかな。 The purpose of most of irb's code is to analyse the input for multi-line and auto-indent support. 確かにこれはうれしい。というかないと悲しい。

■_ gawk

今まで見落としていたのですが

gawk devel.- processing arrays of arrays
gawk devel.- processing arrays of arrays
From: 	Manuel Collado
Subject: gawk devel.- processing arrays of arrays
Date: 	Sun, 12 Dec 2010 23:15:42 +0100

The forthcoming gawk 4.0 supports arrays of arrays. But it seems that there is no way 
to write generic code that process all (scalar) elements of a generalized array without
knowing its structure in advance. The expected recursive construction could be:

来る gawk 4.0 では配列の配列をサポートします。
けれども、高度なその構造を知ることなしに
generaiized された配列の要素を処理する汎用的なコードを書く方法がないようです。
予想される再帰 construction は次のようになるでしょう:

function array_process( a ) {
   for (i in a) {
      if (isarray(a[i])) {
         array_process( a[i] )
      } else {
         ... process a[i] as scalar ...
      }
   }
}


Regrettably, there is no 'isarray()' primitive. I've thought about using 
'length(array)', but it is not array-specific (gives string length for scalars).

残念なことに、'isarray' プリミティブはありません。
わたしは 'length(array)' を使うことを考えましたが、これは
配列固有のものではありません(スカラーに対しては文字列長を返します)。

So please consider adding a new primitive to gawk-4.x. Perhaps either:
- isarray(x), or
- alength(x)
x been a scalar or an array - alength(scalar) should give a negative value.


The second alternative could render the length(array) extension unnecessary.


Am I missing something already available? Is there another way of enumerating all 
final elements of a multi-array without knowing its particular structure in advance?

Regards.


PS: Would it be appropriate to discuss this issue in comp.lang.awk?
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado


The forthcoming gawk 4.0 supports arrays of arrays. TODO リストなんかはあまり信用してなかったのだけど、これやってたのか。 でも 4.0候補のツリーっていつの間に。 stable と trunk くらいで、trunk にしてもそんなに大きな変更が入ってた印象はなかったのだけど。 まあしばらく見ていなかったからなあ。

■_

■_

んー、今日はもうちょっと自前の文章書くはずだったんだけどなあ(苦笑

2010年12月18日

■_

Windows Updateを掛けたら色々あって18日分のアップロードまでできなかった○| ̄|_

hackathon

・50周年
NMAH | COBOL - COBOL の2ページ目にある FLOW-MATIC Programming for the UNIVAC I & II Data Automation Systems, 1959 に興味津々。

■_ Currying subtraction

あれ? この操作は「カリー化」でいいんだっけ? なんかまた混乱してきた(^^; Haskell - Wikipedia Scalaの関数部分適用とカリー化 - kyabの日記


haskell - Currying subtraction - Stack Overflow

If we want to map a function that increases every element of a range by 1, we could write

map (\x -> x + 1) [1..5]

but I guess most people would just go for

map (+1) [1..5]

instead. But this obviously doesn't work with (-1) since that's negative one.

So the first thing that came to mind was

map (+(-1)) [1..5]

which would make sense considering how subtraction is defined in the Prelude (x - y = x + negate y),
but looks a bit odd to me. I then I came up with

map (flip (-) 1) [1..5]

This somehow looks better to me, but is maybe a bit too complicated.

Now I know this no big deal, but I'm wondering if I'm missing a more obvious way to 
write this? If not, which of the 2 ways would you prefer? I'm really just asking 
because often it's small details like this that make your code more idiomatic and 
hence pleasant for other developers who have to read it.

Solution

Now that I got a couple of answers, I think my personal favorite is

map (subtract 1) [1..5]

followed by

map pred [1..5]

mostly because the first one is really explicit and nobody needs to guess/look up what 
pred means (predecessor).

A small note: the problem isn't currying, it's the operator section syntax. (-) 1 is a 
(syntactically valid) way to partially apply the curried - function. – Antal S-Z 



I was struggling with a title for this and couldn't come up with anything better. Also 
map ((-) 1) [1..5] doesn't work, hence the version with flip. – Michael Kohl 


If they are Integral, and you just want to subtract 1, why not map pred – Grazer 

@Grazer Because I didn't know about it, hence the question if I'm missing something 
obvious. – Michael Kohl 


You can use the subtract function instead of - if you want to right-section subtraction:

map (subtract 1) [1..5]


That was the type of obvious thing I meant, thanks! Sometimes you just can't see the 
forest for the trees, Hoogle and all. – Michael Kohl


Since - is both the infix subtract and the prefix negate, you can't use the
(*x) (where * is an infix operator and x a value)
syntax for -. Luckily Prelude comes with negate and subtract, which is
\x -> -x and \x y -> x-y
respectively, so that you may use those where you need to differentiate between the two.


I think map (\x -> x - 1) [1..5] transmits the programmer's intention better, since
there's no doubt about what is being subtracted from what. I also find your first solution,
map (+(-1)) [1..5], easy to read too.

map (subtract 1) [1..5]はともかく、 map (+(-1)) [1..5]easy to read too なんかなあ…(^^;

■_ Why does a 'for' loop in python change unreferenced lists?

もうひとつ stackoverflowから


Why does a 'for' loop in python change unreferenced lists? - Stack Overflow

Hi all,

I'm working on a py script which reads in lines from a csv file, manipulates them, and 
puts them back out. So far I have the csv to list conversion working.

The problem I am having is when I iterate over the temporary lists, the for loops 
change ALL the temp lists, instead of just the one I want. Here is a simple example of 
what I'm trying to say.

>>> l = [['hi', 'ho'],['no', 'go']]
>>> t = []
>>> y = []
>>> 
>>> for row in l:
...     row[0] = '123'
...     y.append(row)
...     t.append(row)
... 
>>> y
[['123', 'ho'], ['123', 'go']]
>>> t
[['123', 'ho'], ['123', 'go']]

So the above is straightforward (hopefully). (Let's assume I want to do other things 
besides just copy the list l. Just wanted to keep it simple).

But now here is the part I don't get.

>>> z = []
>>> for row in y:
...     row[0] = 'xxxx'
...     z.append(row)
... 
>>> z
[['xxxx', 'ho'], ['xxxx', 'go']]
>>> t
[['xxxx', 'ho'], ['xxxx', 'go']]
>>> y
[['xxxx', 'ho'], ['xxxx', 'go']]

When I want to modify the first part in the sub-lists, and save it to a new list 'z', 
it modifies list t as well!

What's going on here? Are z, y and t pointing to the same memory location?

Also, what's happening here?:

>>> for rowx in y:
...     rowx[0] = 'x55x'
...     z.append(rowx)
... 
>>> z
[['xxxx', 'ho'], ['x55x', 'go'], ['x55x', 'go'], ['x55x', 'go']]
>>> t
[['xxxx', 'ho'], ['x55x', 'go']]
>>> y
[['xxxx', 'ho'], ['x55x', 'go']]

Similar to the above question, why are y and t getting changed?

Thanks in advance!!
python list variables for-loop variable-scope

Your three lists are different, but there are only two elements shared between them:

>>> y[0] is t[0] is z[0]
True
>>> y[1] is t[1] is z[1]
True

If the is operator tells you that your references point to the same object, then 
changes to the object will appear no matter which reference you use.

To avoid this, use the copy module if you want a copy of the elements:

>>> import copy
>>> a = copy.deepcopy(y)
>>> a
[['xxxx', 'ho'], ['xxxx', 'go']]
>>> a[0] is y[0]
False
>>> a[0][0] = 'copy!'
>>> y
[['xxxx', 'ho'], ['xxxx', 'go']]


For a shallow copy of lists, you can use y[:] – TokenMacGuy


Thanks jleedev! While [:] answered and solved my question, so does your copy.deepcopy 
solution, which is what I had to do in my script since a shallow copy wasn't enough 
(apparently). You solved my problem! :) – RaytheonLiszt


@Raytheon The [:] slice, a simple for loop, and a shallow copy all have exactly the 
same effect. – jleedev


@jleedev: I would think so too, but for some reason when I implemented it my script it 
still didn't work. It wasn't until I tried your copy solution that the script worked. 
It's definitely some error on my part, probably due to the csv or the haste that went 
into creating the script itself. – RaytheonLiszt


Python has nothing but references. row is a reference to the actual element within l 
or y. Mutating row mutates that element, and adding it to another object adds the 
original element.


Use row[:] to make a copy of row. – katrielalex


@katrielalex: Can I upvote you, like, 100 times? I've run into the OP's issue with 
list references and could not for the life of me figure out how to copy a list instead 
of copying the reference. Do all list slices return a copy instead of a reference like 
this? – DGH


@DGH: For list, yes. A shallow copy though. – Ignacio Vazquez-Abrams


Thanks Ignacio for that. I can 'see' in my head now how these list references work. 
And thanks katrielalex for that solution! – RaytheonLiszt


"Are z, y and t pointing to the same memory location?"

No, but z[0], y[0] and t[0] are (although don't call it memory locations, this is not 
C). You are appending the same list ['hi', 'ho'] to both z, y and t. So it's the same 
list. If you don't want it to be the same list, you have to make a copy first.

■_

■_

Common Lispで赤黒木 - 壊れた計算機 Red-black tree - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Red-black_tree Red-Black tree http://www.geocities.jp/h2fujimura/mutter/tree/red-black-tree.html

■_ もなど



λ Tony's blog λ » Blog Archive » The Writer Monad using Scala (example)

The Writer Monad using Scala (example)

Prompted by a question on the scala mailing list, I have produced below a minimal 
library representing a data type called Logger and its monad implementation (see the 
map and flatMap methods).

scala のメーリングリストでの質問に触発されて、Logger と呼ばれるデータ型を取り扱う
モナドを実装した最小限のライブラリを書いてみました (see the map and flatMap methods)。


This data type represents logging in a pure functional environment where you maintain 
compositionality of your code (i.e. no side-effects) and also, brevity of code — see 
the example usage below using a for-comprehension demonstrating this.

このデータ型はあなたがメンテしている compositionality of your code (i.e. no side-effects)
などが置かれた pure functional な環境における logging を represents します。また、
brevity of code -
詳しい使い方は以下にある例を見てください。

trait Monoid[A] {
  def append(a1: A, a2: A): A
  def empty: A
}
 
object Monoid {
  implicit def ListMonoid[A]: Monoid[List[A]] = new Monoid[List[A]] {
    def append(a1: List[A], a2: List[A]) = a1 ::: a2
    def empty = Nil
  }
}
 
case class Logger[LOG, A](log: LOG, value: A) {
  def map[B](f: A => B) = 
    Logger(log, f(value))
 
  def flatMap[B](f: A => Logger[LOG, B])(implicit m: Monoid[LOG]) = {
    val x = f(value)
    Logger(m.append(log, x.log), x.value)
  }
 
  // insert much more
}
 
object Logger {
  def unital[LOG, A](value: A)(implicit m: Monoid[LOG]) =
    Logger(m.empty, value)
 
  // insert much more
}
 
object Util {
  // utility
  implicit def ListLogUtil[A](a: A) = new {
    def ~>[B](b: B) = Logger(List(a), b)
 
    def <|~[B](k: A => B) = Logger(List(k(a)), a)
  }
 
  def noLog[A](a: A) =
    Logger.unital[List[String], A](a)
}
 
// begin example
 
/*
$ scala Main 456
RESULT: 7000
 
LOG
---
adding one to 456
converting int to string 457
checking length of 457 for evenness
multiplying 1000 by 7 to produce 7000
*/
object Main {
  import Util._
 
  def main(args: Array[String]) {
    val x = args(0).toInt // parse int from command line
 
    val r = 
      for(a <- addOne(x);
          b <- intString(a);
          c <- lengthIsEven(b);
          d <- noLog(hundredOrThousand(c));
          e <- times7(d)
         ) yield e
 
    println("RESULT: " + r.value)
    println
    println("LOG")
    println("---")
    r.log foreach println
  }
 
  def addOne(n: Int) = 
    ("adding one to " + n) ~> (n + 1)
 
  def intString(n: Int) = 
    ("converting int to string " + n) ~> n.toString
 
  def lengthIsEven(s: String) =
    ("checking length of " + s + " for evenness") ~> (s.length % 2 == 0)
 
  def hundredOrThousand(b: Boolean) = // no logging
    if(b) 100 else 1000
 
  def times7(n: Int) =
    (n * 7) <|~ ("multiplying " + n + " by 7 to produce " + _)
}

とりあえず使い方(と使う局面)をわかっておけばいいんだよとは キャミバ様もおっしゃっていたような気がする>もなど

■_

2010年12月17日

■_

・ザ・クオンツ読了
ザ・クオンツ  世界経済を破壊した天才たち

面白かった。 という表現はまあ不穏当かもしれないけど。 世の中頭の出来が違うやつはいるんだなあと。CDSとか何回説明読んでもよくわからん(笑)


クオンツとは - 意味/解説/説明/定義 : マネー用語辞典

高度な数学的手法を用いて、市場を分析したり投資戦略や金融商品を考案・開発すること、または
その専門家のこと。たとえば日経225に連動するポートフォリオを20銘柄で作成するために、過去の
さまざまな銘柄の動きを分析し、業種分散なども考慮した上でもっともブレの少ない銘柄の組み合
わせを選ぶなど、人間の判断ではなく数理的なアプローチによって分析・判断を行う。クオンツに
基づいて銘柄を選定したり運用を決定していく運用を「クオンツ運用」といい、株価に対して影響
を与えるパラメータとそれぞれのパラメータがもつ株価への感応度を設定し、今後値上がりしそう
な銘柄を選定していく手法である。具体的には、株価の変動要素となりうる項目を10~20項目程度
設定し、それらの項目ごとの変動幅に応じて、過去の実際の株価がどのように変動しているかやそ
れぞれの要素の貢献度はどの程度かを多変量解析によって求めるという方法である。

リーマン・ショック前後のあの混乱の中でもしっかり(それも莫大な額の)儲けを出した クオンツがいたというのはびっくり。

■_ i, j, k

恒例の(笑)

ってまあ reddit や stackoverflow と同じタイミングだったんですが。


Hacker News | Why are variables "i" and "j" used for counters?

i, j, and k come from Hamilton's Quaternions.

Euler picked i for the imaginary unit.

Hamilton needed two more square roots of -1:

    ii = jj = kk = ijk = -1

Hamilton was really influential, and quaternions were the standard way to do 3D 
analysis before 1900. By then, mathematicians were used to thinking of (ijk) as a 
matched set.

Vector calculus replaced quaternionic analysis in the 1890s because it was a better 
way to write Maxwell's equations. But people tended to write vector quantities as like 
this: (3i-2j+k) instead of: (3,-2,1). So (ijk) became the standard basis vectors in 
R^3.

Finally, physicists started using group theory to describe symmetries in systems of 
differential equations. So (ijk) started to connote "vectors that get swapped 
around by permutation groups," then drifted towards "index-like things that 
take on all possible values in some specified set," which is basically what they 
mean in a for loop.


What variable did mathematicians use for summation before physicists started using 
group theory to describe symmetries in systems of differential equations? Isn't that a 
fairly recent development?

My search for an old paper with a bloody summation symbol found nothing. I did, 
however, find this OT gem about Newton, written in 1848:

From the thick darkness of the middle ages man's struggling spirit emerged as in new 
birth; breaking out of the iron control of that period; growing strong and confident 
in the tug and din of succeeding conflict and revolution it bounded forwards and 
upwards with resistless vigour to the investigation of physical and moral truth; 
ascending height after height; sweeping afar over the earth, penetrating afar up into 
the heavens; increasing in endeavour, enlarging in endowment; every where boldly, 
earnestly out stretching, till, in the Author of the Principia, one arose, who, 
grasping the master key of the universe and treading its celestial paths, opened up to 
the human intellect the stupendous realities of the material world, and in the 
unrolling of its harmonies, gave to the human heart a new song to the goodness, wisdom, 
and majesty of the all creating, all sustaining, all perfect God.


If you want an old paper with a summation symbol, you could do worse than the book 
where the symbol was first used, by Euler: 
http://www.math.dartmouth.edu/~euler/docs/originals/E212sec1...

(He uses x as the index variable there.)


In FORTRAN identifiers starting with I,J,K,L,M,N declared as INTEGER by default.


FORTRAN's system of giving default types based on the first letter of a variable name 
gives rise to the old joke, "God is real... unless declared integer".


It is exactly I was taught in university when I learned FORTRAN. But it is probably 
influenced from mathematical notation of indexing.


I always used and thought of i as "index", c as "count", and n as "number".


More specifically, I think the N stands for "Natural number".


I think this:

http://en.wikipedia.org/wiki/Summation#Capital-sigma_notation


This is correct. I assure you that the physics texts all tend to use i and j as index 
variables. Particularly for matrices, whose terms have a tendency to be written as 
M_i_j. [1]

Remember that modern electronic computing was invented by mathematicians and 
physicists.

---

[1] HN isn't about TeX, so read that as "M sub-i sub-j".

I agree, it probably comes from maths.

As a side note, the first letters are used for constants, the last letters are for 
variables; and it was Descartes who popularized this usage: 
http://en.wikipedia.org/wiki/Polynomial#Notation

I believe they used i for index, and also for the reason that it wasn't used by other 
usages as above.

Similarly, the integration sign is actually a long s, standing for sum. 
http://en.wikipedia.org/wiki/Integral_symbol

Fortran is the culprit


Not quite. Fortran enshrined the convention, so the question becomes "Why did 
Fortan pick that range for integers?"


I don't agree that the question changes. I would argue that the fact that Fortran 
enshrined the convention is a more relevant answer than the answer to why Fortran 
picked that range. The reason being that the answer to the latter question is most 
likely from another domain, such as Mathematics.

Although I do find the answer to the latter question interesting as well, just not as 
interesting as the answer to the first.


Because mathematicians, physicists, and engineers use i through n for integers in 
their mathematical formulas, and Fortran was their FORmula TRANslator into computerese. 
(Additional fun fact: They begin their matrix row and column counts with 1, which is 
why Fortran array indices start at 1.)

バッカスなり、FORTRAN 最初期に携わった人たちがこの辺に関する話を残してないのかなあ。 それがあればほぼ疑問は氷解するのに。

■_ considerd harmful

たくさんあるもんだw


Jeffrey Overbey - Miscellaneous - Considered Harmful

"considered harmful" considered harmful
the incomplete bibliography of topics considered harmful

4/9/07 • I'm not entirely sure why, but I searched ACM and IEEE for all papers with 
"Considered Harmful" in the title. The length of this list should 
substantiate my claim that that phrase should be banned from the literature. I was 
pleased to find that someone has already formed the same opinion as me but actually 
bothered to justify it: see "Considered Harmful" Essays Considered Harmful.

Guy Steele is the winner with two entries. I moved the more interesting ones to the 
top and linked them to the full text... everything through "Garbage In/Garbage 
Out."

Knowledge considered harmful
Scott, P.D.; Markovitch, S.

Hello, world considered harmful
Ralph Westfall

Software engineering considered harmful
Dennis de Champeaux

The arrogant programmer: Dijkstra and Wegner considered harmful
Robert J. DuWorks, Steven W. Smoliar

Junk considered harmful
Philip S. Abrams

Polymorphism considered harmful
Carl Ponder, Bill Bush

"=" considered harmful
Dean W. Gonzalez

Comments considered harmful
Anders Beckman

Ignorance of ALGOL 68 considered harmful
Richard Hamlet

IF-THEN-ELSE considered harmful
Gerald M. Weinberg, Dennis P. Geller, Thomas W. S. Plum

Pseudo object-oriented programming considered harmful
Conrad Weisert

Web services considered harmful?
Rohit Khare, Jeff Barr, Mark Baker, Adam Bosworth, Tim Bray, Jeffery McManus

In defense of program testing or correctness proofs considered harmful
Andrew S. Tanenbaum

Use cases considered harmful
Simons, A.J.H.

Primitive types in Java considered harmful
Nick Ourusoff

Operators Considered Harmful
Martin Gfeller

C++ templates considered harmful
H. Paul Haiduk

Arrays and pointers considered harmful
D. C. Ince

Frameless rendering: double buffering considered harmful
Gary Bishop, Henry Fuchs, Leonard McMillan, Ellen J. Scher Zagier

I/O considered harmful (at least for the first few weeks)
John Rosenberg, Michael K??lling

Toy projects considered harmful
Fred Martin

Multiple choice questions not considered harmful
Karyn Woodford, Peter Bancroft

Analogy considered harmful
Frank Halasz, Thomas P. Moran

Fragmentation considered harmful
C. A. Kent, J. C. Mogul

Benchmark health considered harmful
Craig B. Zilles

C in the first course considered harmful
L. F. Johnson

Compiler textbook bibliographies considered harmful
V. Schneider

Debunking the "expensive procedure call" myth or, procedure call 
implementations considered harmful or, LAMBDA: The Ultimate GOTO
Guy Lewis Steele

Address/memory management for a gigantic LISP environment or, GC considered harmful
Jon L. White

Operators considered harmful
Martin Gfeller

Garbage In/Garbage Out: You could learn a lot from a quadratic: overloading considered harmful
Henry G. Baker

Programming early considered harmful
Lewis E. Hitchner, Judith Gersting, Peter B. Henderson, Philip Machanick, Yale N. Patt

The education and licensing of software professionals: the myth of "a perfected science" considered harmful
Don Gotterbarn

Design early considered harmful: graduated exposure to complexity and structure based 
on levels of cognitive development
Duane Buck, David J. Stucki

Goal-oriented programming, or composition using events, or threads considered harmful
Robbert van Renesse

Bandwagons considered harmful, or the past as prologue in curriculum change
David G. Kay

Considered harmful--still
Robert Bernecky

L-one-two-three (L1:..L2:..L3:) considered harmful
F. H. D. van Batenburg

Partially overlapped channels not considered harmful
Arunesh Mishra, Vivek Shrivastava, Suman Banerjee, William Arbaugh

Fresh: Human-centered design considered harmful
Donald A. Norman

Dataless objects considered harmful
Chenglie Hu

Lack of priority queuing considered harmful
Vijay Gill

Life cycle concept considered harmful
Daniel D. McCracken, Michael A. Jackson

"Cloning Considered Harmful" Considered Harmful
Kapser, C.; Godfrey, M.W.

Rainbow Color Map (Still) Considered Harmful
David Borland; Russell M. Taylor II

W* effect considered harmful
Khare, R.

Monopoly considered harmful
Geer, D.E., Jr.

Visuo-Haptic Systems: Half-Mirrors Considered Harmful
Christian Sandor; Shinji Uchiyama; Hiroyuki Yamamoto

IPv6 Stateless Address Autoconfiguration Considered Harmful
Lindqvist, J.

Random waypoint considered harmful
Yoon, J.; Liu, M.; Noble, B.

Communication primitives for ubiquitous systems or RPC considered harmful
Saif, U.; Greaves, D.J.

Policy division and fusion: examples and a method-or, multiple classifiers considered harmful
Kanada, Y.

Current parsing techniques in software renovation considered harmful
van den Brand, M.; Sellink, A.; Verhoef, C.

Strictly class-based modelling considered harmful
Krogh, B.; Levy, S.; Dutoit, A.; Subrahmanian, E.

Symbol security condition considered harmful
Schaefer, M.

Virtual Processors Considered Harmful
Christy, P.

Global consistency constraints considered harmful for heterogeneous database systems
Garcia-Molina, H.

Independence assumptions considered harmful
Alexander Franz

Emergent behaviours considered harmful
Dana Moore, William Wright

English for decision tables considered harmful
Michael Lesk

Structured programming considered harmful
William Slater, Howard Modell

"Structured programming" considered harmful
Paul Abrahams

Send-receive considered harmful: Myths and realities of message passing
Sergei Gorlatch

Arithmetic shifting considered harmful
Guy L. Steele

Global variable considered harmful
W. Wulf, Mary Shaw

Go to statement considered harmful
Edsger W. Dijkstra
© Copyright 2010, Jeffrey L. Overbey.  All rights reserved. [Site Index]

■_ バージョン管理システム

一人だけで使うときにはどれがよいか


personal version control system to recommend - Stack Overflow

For personal use. Anyone can recommend the version control system for Windows


For a difference between DVCS (Distributed) and CVCS (Centralized): 
stackoverflow.com/questions/2563836/… and stackoverflow.com/questions/2704996/…: 
that way, when you choose amongst the answers below, you at least have an idea of the 
differences between the two kinds of VCS. – VonC Dec 14 at 4:55


Git. You won't regret it.


Or CollabNet Subversion. It's easy to set up and run as a Windows service.


Subversion has an excellent client, Tortoise, available on Windows. Git has a version 
of Tortoise as well, however, it's not as reliable.

If you are going to be working on a project just by yourself, and more importantly, 
committing regularly and can afford maintaining multiple branches(only if you need to), 
Go for subversion. Otherwise, choose Git, because,

    * it allows you to stash changes without committing to your repository

    * The entire version history is maintained locally, so this makes it quicker to 
      view changes for others who are going to access your code

    * In Git you dont need to maintain separate project(source) directories for each 
      of your code branches.

■_

■_

来週発売だと思っていたのだけど、「プログラミング原論」(Elements of Programmin の翻訳) が金曜日に売られていたらしい。 先行発売ではないのかなあ。日曜日に見つかるかな。

2010年12月16日

■_

先週合併号が出ていたのを忘れて同じモーニングを買ってしまった○| ̄|_

しかし、きのこ本をげと。

■_ 9 Programming Languages To Watch In 2011

指標で目立ったから取り上げたのであって、書いた人が本当にその言語を推している というわけでもないらしい。


9 Programming Languages To Watch In 2011 | Javalobby

I have written several posts regarding job trends in programming languages. However, I 
have not really written any posts that looked towards the future of programming 
languages. With job trends, I have been focusing on more heavily adopted languages. In 
this case, I wanted to look at some other languages that are gaining popularity but 
have not really become one of the top languages to use. Part of this analysis uses the 
Tiobe December 2010 rankings, some from ReadWriteWeb's recent programming languages 
post (based on this Dataists post), and the rest comes from the job trends that are 
included. Two languages from the normal job trends posts that will continue to see 
solid growth and deem mentioning are Objective-C and Python. Obviously, with the 
growing Apple ecosystem, Objective-C continues to grow. Python is being used in data 
analysis, which is growing rapidly, as was mentioned in my recent post on some O'
Reilly data.

I have not split these languages into any particular type, like traditional and 
scripting, because I wanted to look at everything together. Some of the jobs data is 
difficult to include because of the amount of noise from other industries. Go and R 
have a lot of noise in particular and are not included in the graphs. However, they 
are included due to their origin (Google) and usage (Data Analysis) respectively. 
First, let's look at the languages themselves ordered by Tiobe rank (Tiobe ranking 
and RWW & Dataist Tier included) :

(略)

So, I have presented a good amount of data, but I have not really said anything 
specific. All 9 languages should be watched in the next year as they all have some 
interesting level of activity in one area or another. Google searches, GitHub projects, 
StackOverflow questions and job trends are all flawed in some way. But if you look at 
them together, they present an interesting picture of what programming languages are 
really seeing activity or adoption. Without further ado, here is my ranking of what 
programming languages watch in the next year:

   1. Lua – The language is seeing some good activity on GitHub and StackOverflow. It has
      a solid Tiobe ranking, but more importantly, jobs for Lua are becoming available. 
      The relative trend for Lua is a great indicator that it is ready to go mainstream.

      この言語はGitHub や StackOverflow において活発な活動を見ることができる。
      この言語は solid な Tidle ranking を持っているが、もっと重要なのは Lua での
      仕事が available になってきているということである。Lua の relative trend は
      Lua がメインストリームに登場する下地ができていることをよく示している。

   2. R – With data analysis and big data becoming a part of every web startup, languages
      catering to the data crowd will become popular. The job trend data will be the most
      interesting part to watch here.

      データ解析と big data がすべての web startup に重要なものとなるのにともなって
      data crowd に対する languages catering は pupular となるだろう。
      その job tred data は最も注視すべきものとなるだろう。

   3. Clojure – While not popular within the Tiobe index, it is popular in some programming
      circles. In particular, its job trend growth is showing that it could be posed for a
      big year of adoption.

      Tidle 指標では popular ではないものの、一部のプログラミングサークルでは popular
      なものになっている。とくにその job trend の成長は big year of adoption となる
      可能性を示している。

   4. Go – Only Tiobe really shows this as a popular language. It is not ranked well in the
      Dataist Tier, and job trends are not very reliable yet. However, with a parent of
      Google it may not need purely organic growth.

      Tidle だけがこの言語が popluar な言語であると示している。Go は Dataist Tier に
      おいてはそれほど良い位置にはないし、job trends は今もって reliable なものではない。
      

   5. Erlang – This has been around for a few years and has decent trends all around. With
      the continued growth of real-time technologies like XMPP (eJabberd specifically), 
      PubSubHubbub and others, 2011 could be a year where it becomes the next Python.

      この言語はここ数年知名度を上げてきていて、良好な tredns を見せている。
      XMPP や PubSubHubbub などといったリアルタイム分野では成長を続けているので
      2011年は Erlang が next Python となる年となるかもしれない。
      #チョー訳


   6. Scala – This is one of the interesting trends. Scala has a very good showing in the
      Dataist Tier, but is not really ranked in the Tiobe index. With the solid job growth
      trends and popular adopters (i.e. Twitter), Scala could gain a serious amount of
      acceptance.

      これは興味深い trends のひとつである。Scala は Dataist Tier では非常に良い成績で
      あるが、Tidle index ではそれほどではない。solid な job growth trends と
      popular adopters (たとえば Twitter) とともに、Scala は serious amount of acceptance
      を得るかもしれない。

   7. Groovy – More than anything, I believe Groovy missed its window of opportunity. 
      It is a solid scripting language with decent job growth trends, but how can it 
      differentiate itself from Ruby, Python, Erlang and Scala?

      More than anything, わたしは Groovy はその window of opportunity を失ってしまって
      いると考えてる。Groovy はまずまずの job growth トレンドを持っている
      solid なスクリプティング言語であるが、それ自身は Ruby や Python、Erlang、Scala
      とどれほど差別化できているのであろうか?

   8. Scheme – For whatever reason, this language refuses to go away and has even picked
      up some interest. Without decent job growth, we could be another year away from 
      Scheme breaking out again, at least 30 years after it broke out the first time.

   9. ActionScript – ActionScript is included in this list because of its high ranking on
      Tiobe and the Dataist Tier. However, the job trends do not point to good things for 
      the language. It could be a temporary slump, so you should keep an eye on it next
      year.

      ActionSciprt がこのリストに含まれているのは、Tidle や Dataist Tier での
      高いランキングが理由である。しかし、その job trends はこの言語に対して
      good things を示してはいない。それは一時的な slump な可能性があるので、
      来年も注目しておくべきだろう。

I know people will have lots of comments on this, but specifically I am looking for 
other languages that may be gaining popularity. Let me know what I missed in the 
comments.

■_ What is the biggest current problem in Ruby community?


What is the biggest current problem in Ruby community? : ruby

I've been trying to figure this one out in past few days and I'm quite unable to come 
up with reasonable answer.

    * We have GitHub, most awesomest social network on the internet.

    * We have RubyGems, centralized libraries for everything.

    * We have JRuby, for those who want to stick in the Java world or do some real
      threading.

    * We have Rails, possibly the best web framework available (django people please don't
      burry me alive)

    * We have RSpec and Cucumber, which make me cry when I have to work with JUnit.

    * We have great cloud hosting solutions like Heroku and Engine Yard.

    * We have huge number of screencasts and tutorials, especially those high quality ones
      (Peepcode, Think Vitamin, Railscasts).

    * Last but not least, we have Ruby, language which is fun to work with, expressive ...
      well you know.

The list could go on and on, so I guess you get my point.

My question is: What is missing? What do we need, but don't (yet) have?


The single most important thing that Ruby lacks is speed. Ruby is still one of the 
slowest language in the speed test. It becomes difficult to write stuff that should 
run fast. I think if V8 can make JS run fast then Ruby can run fast too. May be it is 
just matter of time but it is a big pain point for me


1.9.2 is decently fast, but GC and memory-bloat is still holding Ruby back.


I think it is more than that. Ruby MRI needs improvements and optimizations overall. 
Plus we need JIT and probably even type hints.


Thats being worked on- it is called Rubinius :)


YARV is sure way faster than MRI, but it is still far behind something like V8.

(Just not to mention LuaJIT which is the fastest JIT for a dynamic language. I know it 
is unfair to compare a Lua runtime to a Ruby runtime, because Lua is much simpler.)


Documentation. Better documentation. Up to date documentation. Amazing documentation.

Seriously, PHP is kicking Ruby's ass in this department.


Here's how we can fix the docs:

    * Make it clear which web site is the 'official' or canonical documentation site. 
      The real one (ruby-lang.org maybe?) comes up on Google after a competitor
      (ruby-doc.org ... which seems to have some outdated info).

    * The web site needs to be organized like Apache's: first by version, and then by 
      topic. The current organization we have is unnecessarily tedious.

    * The site needs three docs listed prominently, like docs.python.org does it: Tutorial,
      Library Reference, and Language Reference. Boom, boom, boom. The years I programmed
      in Python, I answered 90% of my questions from those docs: so easy to find and get
      the info I needed. The ruby doc site gets this about 50% right at the moment.

    * The API docs need to be in a more helpful format like Javadoc does. Ruby is a 100%
      object-oriented language, but the standard API format obscures this: Files are the
      most prominently listed, although they're purely an implementation artifact. Many 
      many classes are simply empty documents that provide no help. The way Modules are 
      listed could be much more helpful, etc. Take a look at Javadoc format, and how easy
      it is to find out the essentials a working programmer needs: Modules and class names. 
      Descriptions for each. Method names, parameters and return values. Etc.


EDIT:

    * Include crowd-sourced comments in the docs like PHP.

tl;dr Let's learn from others' successes.

■_

What is so great about Lisp? :


What is so great about Lisp? : lisp

I mostly write in C/C++, Java, Perl and Bash. However, I have been getting into .NET. 
That is my language background. That being said, Is there something wrong with my 
learned languages? I mean, I guess I just do not understand what Lisp is for? Why is 
it better than some other language? I have tried to implement things in Scheme, mostly 
just to see if I could, but I apparently suck at it. Any good book suggestions? I 
apologize if I sound like I'm bashing Lisp, but I am seriously wondering why one would 
choose Lisp over any other language. Is it better at implementing certain data 
structures? Is it really that much faster? If I am not looking at this from the right 
angle, please correct me.

TL;DR: Tell me about Lisp and where/when It should be used over another language.

いつ、どこで他の言語ではなく Lisp を使うべきなのかについて教えてください。

EDIT: Thank you for adding all of your input. I am going to try to get into Scheme. I 
really like having the ability to write my own macros. I have been writing in assembly 
for the past month or so and I would hate to not have the ability to write my own 
macros. I am very impressed by some of the comments, You Lisp guys are seriously in 
love with your language!

What do you guys thing about Scheme and its common namespace for all data and procedures?

Some of my favorite things about Common Lisp (I can't speak for scheme):
わたしが Common Lisp について気に入っていること (schemeについては言及できません)

   1. The condition system. Nobody ever seems to mention this but it is the main 
      reason I often reach for Lisp even though most other languages have richer
      libraries. What's so great about it? It allows you to handle a condition
      without unwinding the stack!

   2. It is visually appealing. To me, the parentheses seem to round off all the sharp 
      edges which makes it easier and more enjoyable to look at. And after a while you
      start to notice the overall shape of the code such that many common errors are
      glaringly obvious because it just looks wrong.

   3. It does the right thing with numbers (unless you poison an expression with a 
      float). So 7 divided by 11 yields 7/11 instead of 0 or 0.6363636363636363.

   4. Development is very fluid. This is hard for me to articulate so bear with me. 
      You know how interpreted languages get rid of much of the waiting involved in the 
      traditional edit/compile/debug cycle? Well Lisp does away with even having to
      restart your program when you have to make a change. In other words, when you
      find an error and edit some code -- you can reevaluate that part of the code
      without losing where you are in the running program. So the edit/compile/debug
      cycle is not only shortened, but you don't get interrupted so your brain doesn't
      have to make a big context switch. Oh, and it's still compiled -- you just don't
      have to compile it.

There are a other things that I don't even want to get into because they're such big 
subjects. But they're huge wins as well. Specifically CLOS and macros. In short CLOS, 
the Common Lisp Object System is OO done right. And Lisp macros allow you to redefine 
the way the language works -- making Lisp a programmable programming language.

    Why is it better than some other language?

Here are reasons why I like Common Lisp:
わたしが Common Lispを好きな理由を挙げます:

   1. Nice, unambiguous syntax -- no need to remember lots of weird rules, and if you 
      forgot something you can easily look up in doc.

   2. Excellent possibilities for elimination of boilerplate code through macro system. 
      Almost everything is possible. (Related to 1)

   3. Mature standard written by sane people, no confusing over different versions.

   4. Dynamic typing, but high performance, compiled to native code. (Related to 3: 
      language designers took performance into consideration.)

   5. A lot of nice language features -- multiple-values, condition system, LOOP etc.

   6. CLOS as a pretty advanced object system.

   7. Interactive development, ideal for explorative programming and research.

   8. Mature implementations with IDE support and stuff like that.

It has downsides too, but for me upsides outweight downsides.


1) Lisp Macros - functions which generate code. This is by far the most powerful and 
distinctive feature of the language today, and what, I think, makes Lisp Lisp. This is 
possible because in Lisp, data structures (lists) are code. So macros are merely 
functions which are registered with the compiler which produce output that is treated 
as code.

This enables the language itself to be extended. For example, whereas in other 
languages, AND and OR are keywords, in Lisp they are macros which could be implemented 
by the programmer (though are provided by the default package). Here's a simplified 
version of OR:

 (defmacro or2 (x y) `(if ,x t (if ,y t))

Impossible in any other language. But why should you care? This allows you to build 
new language constructs. The patterns movement was created to cope with deficiencies 
in languages like Java and C++. To implement a pattern, you must painstakingly 
implement a pattern by hand, coding classes and their relationships to each other. In 
Lisp, there's no need for a patterns movement. You write a macro that instantiates 
several classes or related functions in a single expression.

In fact, the entire object system (CLOS) is pretty much just a bunch of macros. Your 
jaw should be dropping right about now. Imagine doing that in any other language. You 
can't. And the reason is that in Lisp, code is data.

Any language that treats code as data, and gains Lisp's ability to manipulate 
expressions, will look awfully close to Lisp.

2) In the past, we would say that another distinctive feature of Lisp is that it is 
functional. It is still a wonderful functional language, but now ML, Haskell, and even 
mainstream languages like Ruby (and to a lesser extent, Python) allow you to do much 
of what Lisp did decades ago.

3) Number system. The standard operator seamlessly interoperate floats, ints, complex 
numbers, bigints, and rationals.

  数値システム。標準の演算子は float、int、complex、numbers、bigint、rational を
  シームレスに interoperateします。

4) Higher performance functional programming. Compiler advice and expansions allow you 
to fine tune performance, rivaling performance of other functional languages and even 
besting Java. (See Norvig's comparisons).

高性能な関数型言語であること。
コンパイラーのアドバイスや拡張 (expansions)は
あなたに性能の fine tune を可能にさせ、他の関数型言語や


Lisp handles complexity really well. AI and symbolic math are tough in other languages, 
but relatively easy in Lisp. You can write a usable Prolog interpreter in a page of 
Lisp, for example. Try that in any of the other languages you mention.

I have seen AI systems written in Java and C. Greenspun's 10th rule is not a joke.

■_

2010年12月15日

■_

http://i.imgur.com/xuCIW.png

近代麻雀
哭きの竜外伝とムダヅモはそろそろ終わりかな。

irb(main):011:0> "A".split(//).inject(0){|acc,e| acc+=e.ord-64;acc}
=> 1
irb(main):012:0> "A".split(//).inject(0){|acc,e| acc=acc*26+e.ord-64;acc}
=> 1
irb(main):013:0> "Z".split(//).inject(0){|acc,e| acc=acc*26+e.ord-64;acc}
=> 26
irb(main):014:0> "AA".split(//).inject(0){|acc,e| acc=acc*26+e.ord-64;acc}
=> 27
irb(main):015:0> "XFD".split(//).inject(0){|acc,e| acc=acc*26+e.ord-64;acc}
=> 16384
irb(main):028:0> def xx(n)
irb(main):029:1>   return (n+64).chr if n<=26
irb(main):030:1>   xx((n/26).to_i) + xx(n%26)
irb(main):031:1> end
irb(main):032:0> xx(1)
=> "A"
irb(main):033:0> xx(27)
=> "AA"
irb(main):034:0> xx(16384)
=> "XFD"
irb(main):035:0> xx(256)
=> "IV"
irb(main):039:0> "XFD".enum_for(:each_byte).inject(0){|acc,e| acc=acc*26+e.ord-64;acc}
=> 16384

特に意味はありません :)

Dijkstra: Why numbering should start at zero : programming

Why numbering should start at zero

       To denote the subsequence of natural numbers 2, 3, ..., 12 without the pernicious three
       dots, four conventions are open to us:

a) 2 ≦ i < 13
b) 1 < i ≦ 12
c) 2 ≦ i ≦ 12
d) 1 < i < 13

       Are there reasouns to prefer one convention to the other? Yes, there are. The
       observation that conventions a) and b) have the advantage that the difference
       between the bounds as mentioned equals the length of the subsequence is valid.
       So is the observation that, as a consequence, in either convention two subsequence
       are adjacent means that the upper bound of the one these observations are, they
       don't enable us to choose between a) and b); so let us start afresh.

There is a smallest natural number. Exclusion of the lower bound -- as in b) and d --
forces for a subsequence starting at the smallest natural number the lower bound as
mentioned into the realm of the unnatural numbers.  That is ugly, so for the lower bound
we prefer ≦ as in a) and c). Consider now the subsequences starting at the smallest
natural number: inclusion of the upper bound would then force the latter to be unnatural
by the time the sequence has shrunk to the empty one. That is ugly, so for the upper
bound we prefer < as in a) and d). We conclude that convention a) is to be preferred.

Remark:
The programming langauge Mesa, developed at Xerox PARC. has special notations for
intervals of integers in all four conventions. Extensive exprerience with Mesa has
shown that the use of the other there conventions has been a constant source of
clumsiness and mistakes, abd on account of that experience Mesa programmers are
now strongly advised not to use the latter three avaiable features. I mention this
experimental evidence -- for what it is worth -- because some people feel uncomfourtable
with conclusions that have not been confirmed in practice.
(End of Remark)

What dealing with a sequence of length N, the elements of which we wish to distinguish
by subscript, the next vexing question is what subscript value to assign to its stariting
element. Adhering to convention a) yields, when starting with subscript 1, the subscript
range 1 ≦ i < N+1; starting with 0, however, gives the nicer range 0 ≦ i < N. So
let us our ordinals start at zero: an element's  ordinal (subscript) equals the number of
elements preceding it in the sequence. And the moral of the story is that we had better
regard -- after all those centuries! -- zero as a most natural number.

Remark:
Many proramming languages have been designed without due attention to this detail.
In FORTRAN, subscript always start at 1; in ALGOL 60 and in PASCAL. convention c)
has been adopted; the more recent SASL has fallen back on the FORTRAN convention;
a sequence in SASL is at the same time a function on the positive integers.
Pity!
(End of Reamark)

The above has been triggederd by a recent incident, when, in an emotional outburst,
one of my mathematical colleagues at the University -- not a computing scientis --
accysed a number of younger computing scientists of "pedantry" because -- as they
do by hobit -- they started numbering at zero.  He took consciously adopting the
most sensible convention as a provocation. (Also the "End of ..." convention is
viewd as provocative; but the convention is useful. I know of a student who almost
failed at an examination by the tacit assumpion that the questions ended at the
bottom of the first page.) I think Anthony Jay is right when he states; "In corporate
religious as in others, the heretic must be cast out not because of the probability
that he is wrong but because of the possibility that he is right"

■_

なんか続きが。

Yacc is dead: An update
Yacc is dead: An update

The draft of "Yacc is Dead" that David Darais and I posted on arXiv received 
some attention, so we'd like to share updates and feedback.

(You don't have to read the draft to read this post; it's self-contained.)

The draft claims that Brzozowski's derivative eases parser implementation; that it 
handles all CFGs (yes, including left-recursive); that it seems to be efficient in 
practice; and that it should eventually be efficient in theory too.

We reply to Russ Cox's "Yacc is Not Dead" by running the example that he 
claims has best-case complexity of Ω(3n). It terminates instantly for n > 100.

This post also describes compaction (not in the draft), and makes a formal argument 
that the cost of parsing with derivatives is O(n|G|) on average.

We also explain the derivative again (with less academic prose), and release our 
latest implementations in Racket, Scala and Haskell.

[The Racket implementation minimizes the use of laziness, and it abstracts away the 
impure parts (caching and computing fixed points) behind a purely functional interface: 
define/memoize and define/fix.]

Read on for more, and stay tuned for updates.

(ry

We (David, I and now also Daniel Spiewak) are working on several solutions to the 
"sharing" issue, but we'd love to hear from if you have an idea as well.

More resources

■_ \

やっぱこの選択はまずかったろうよ(^^;


PHP: FAQ: things you need to know about namespaces - Manual
Dynamic namespace names (quoted identifiers) should escape backslash

It is very important to realize that because the backslash is used as an escape 
character within strings, it should always be doubled when used inside a string. 
Otherwise there is a risk of unintended consequences:

Example #9 Dangers of using namespaced names inside a double-quoted string

<?php
$a = new "dangerous\name"; // \n is a newline inside double quoted strings!
$obj = new $a;

$a = new 'not\at\all\dangerous'; // no problems here.
$obj = new $a;
?>

Inside a single-quoted string, the backslash escape sequence is much safer to use, but 
it is still recommended practice to escape backslashes in all strings as a best 
practice. 

■_ Top 50 Programming Quotes of All Time

コメントで寄せられた方もなかなか。 こっちも盛り上がってます→ Top 50 Programming quotes of all time : programming

結構知らないものもあるな。


Top 50 Programming Quotes of All Time | TechSource

Top 50 Programming Quotes of All Time
Posted by jun auza On 12/10/2010

I hope you have enjoyed our collection of funny computer quotes, Linux quotes, and all 
those quotes that we have shared with you so far. For today, I've decided to gather a 
good number of my all-time favorite programming-related quotes.

Most of the programming quotes I've collected are made by some of the famous names in 
the industry, while others came from not-so-famous people. Nevertheless, they are all 
witty so I hope you will find them fascinating and enlightening.

Without further delay, here are my top 50 programming quotes of all time:


50. "Programming today is a race between software engineers striving to build bigger and
better idiot-proof programs, and the universe trying to build bigger and better idiots. So far,
the universe is winning."
- Rick Cook

49. "Lisp isn't a language, it's a building material."
- Alan Kay.

48. "Walking on water and developing software from a specification are easy if 
both are frozen."
- Edward V Berard

47. "They don't make bugs like Bunny anymore."
- Olav Mjelde.

46. "A programming language is low level when its programs require attention to the irrelevant."
- Alan J. Perlis.

45. "A C program is like a fast dance on a newly waxed dance floor by people carrying razors."
- Waldi Ravens.

44. "I have always wished for my computer to be as easy to use as my telephone; my wish has
come true because I can no longer figure out how to use my telephone."
- Bjarne Stroustrup

43. “Computer science education cannot make anybody an expert programmer any more 
than studying brushes and pigment can make somebody an expert painter.”
- Eric S. Raymond

42. “Don't worry if it doesn't work right. If everything did, you'd be out of a job.”
- Mosher's Law of Software Engineering

41. “I think Microsoft named .Net so it wouldn't show up in a Unix directory listing.”
- Oktal

40. “Fine, Java MIGHT be a good example of what a programming language should be like. 
But Java applications are good examples of what applications SHOULDN'T be like.”
- pixadel

39. “Considering the current sad state of our computer programs, software development is clearly still a black art, and cannot yet be called an engineering discipline.”
- Bill Clinton

38. "The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense."
- E.W. Dijkstra

37. "In the one and only true way. The object-oriented version of 'Spaghetti code' is, of course, 'Lasagna code'. (Too many layers)."
- Roberto Waltman.

36. "FORTRAN is not a flower but a weed — it is hardy, occasionally blooms, and grows in every computer."
- Alan J. Perlis.

35. “For a long time it puzzled me how something so expensive, so leading edge, could be so useless. And then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match.”
- Bill Bryson

34. "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt."
- Blair P. Houghton.

33. "When someone says: 'I want a programming language in which I need only say what I wish done', give him a lollipop."
- Alan J. Perlis

32. "The evolution of languages: FORTRAN is a non-typed language. C is a weakly 
typed language. Ada is a strongly typed language. C++ is a strongly hyped 
language."
- Ron Sercely

31. "Good design adds value faster than it adds cost."
- Thomas C. Gale

30. "Python's a drop-in replacement for BASIC in the sense that Optimus Prime is a drop-in replacement for a truck."
- Cory Dodt

29. "Talk is cheap. Show me the code."
- Linus Torvalds

28. "Perfection [in design] is achieved, not when there is nothing more to add, 
but when there is nothing left to take away."
- Antoine de Saint-Exupéry

27. "C is quirky, flawed, and an enormous success."
- Dennis M. Ritchie.

26. "In theory, theory and practice are the same. In practice, they're not."
- Yoggi Berra

25. “You can't have great software without a great team, and most software teams 
behave like dysfunctional families.”
- Jim McCarthy

24. "PHP is a minor evil perpetrated and created by incompetent amateurs, whereas 
Perl is a great and insidious evil, perpetrated by skilled but perverted 
professionals."
- Jon Ribbens

23. "Programming is like kicking yourself in the face, sooner or later your nose will bleed."
- Kyle Woodbury

22. "Perl – The only language that looks the same before and after RSA encryption."
- Keith Bostic

21. "It is easier to port a shell than a shell script."
- Larry Wall

20. "I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind."
- Alan Kay

19. "Learning to program has no more to do with designing interactive software than learning to touch type has to do with writing poetry"
- Ted Nelson

18. “The best programmers are not marginally better than merely good ones. They are 
an order-of-magnitude better, measured by whatever standard: conceptual creativity, 
speed, ingenuity of design, or problem-solving ability.”
- Randall E. Stross

17. “If McDonalds were run like a software company, one out of every hundred Big Macs 
would give you food poisoning, and the response would be, ‘We're sorry, here's a 
coupon for two more.' “
- Mark Minasi

16. "Beware of bugs in the above code; I have only proved it correct, not tried 
it."
- Donald E. Knuth.

15. "Computer system analysis is like child-rearing; you can do grievous damage, 
but you cannot ensure success."
- Tom DeMarco

14. "I don't care if it works on your machine! We are not shipping your machine!"
- Vidiu Platon.

13. "Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code."
- Christopher Thompson

12. "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
- Bill Gates

11. "Debugging is twice as hard as writing the code in the first place. Therefore, 
if you write the code as cleverly as possible, you are, by definition, not smart 
enough to debug it."
- Brian W. Kernighan.

10. "People think that computer science is the art of geniuses but the actual 
reality is the opposite, just many people doing things that build on each other, like 
a wall of mini stones."
- Donald Knuth

9. “First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack.”
- George Carrette

8. “Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.”
- Larry Wall

7. “Most software today is very much like an Egyptian pyramid with millions of bricks 
piled on top of each other, with no structural integrity, but just done by brute force 
and thousands of slaves.”
- Alan Kay

6. “The trouble with programmers is that you can never tell what a programmer is doing until it's too late.”
- Seymour Cray

5. “To iterate is human, to recurse divine.”
- L. Peter Deutsch

4. "On two occasions I have been asked [by members of Parliament]: 'Pray, Mr. 
Babbage, if you put into the machine wrong figures, will the right answers come out?' 
I am not able rightly to apprehend the kind of confusion of ideas that could provoke 
such a question."
- Charles Babbage

3. "Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program."
- Linus Torvalds

2. "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
- Martin Golding

1. “There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make it so 
complicated that there are no obvious deficiencies.”
- C.A.R. Hoare


If you have other interesting programming quotes to add, you may share them with us 
via comment.

まあ、多分ほとんどのものは誰かが訳してんじゃないかなあ(^^;

そしてここはやはり、先日亡くなられた Wilkes のお言葉を。

programming, quotes | edit post
73 Response to "Top 50 Programming Quotes of All Time"

   2. Elder Geek Said,
      December 14, 2010 5:04 AM

      As soon as we started programming, we found to our surprise that it wasn't as easy
      to get programs right as we had thought. Debugging had to be discovered. I can 
      remember the exact instant when I realized that a large part of my life from then
      on was going to be spent in finding mistakes in my own programs.
      -- Maurice Wilkes, designer of EDSAC, on programming, 1949")
       

■_

2010年12月14日

■_

くじけた(今年何回目だ)

■_

Substring search algorithm
Substring search algorithm

Substring search speed comparison
部分文字列の検索速度の比較

Described substring search algorithm which allows faster string traversal. Current 
implementation is substantially faster than any other substring search algorithm known 
to me.

文字列の高速な traversal を可能にする部分文字列検索アルゴリズム。
現状の実装は、わたしが知っている他の部分文字列検索のアルゴリズムのどれよりも
substantally に高速です。


Substring (needle) SS of length M is sought in source (haystack) string S of length N.

長さ M の部分文字列 (needle) SS を長さ N のソース (haystack) 文字列 S から探します。

As in the Boyer–Moore algorithm, this algorithm steps forward not by 1 character, but 
by as many as possible, effectively decreasing the number of times we iterate through 
the main comparison loop, so that the number of comparisons can be as small as N/M.

Boyer-Mooreアルゴリズムと同じく、このアルゴリズムは一文字ずつではなく
可能な限りの長さを一ステップで前進します。

As in Rabin–Karp, hash is used to speed up comparison. Rabin-Karp uses hash for whole 
substring, here only small part of substring (word) is hashed.

Rabin-Karp と同様に、比較を高速に行うためにハッシュを使用しています。
Rabin-Karpはハッシュを部分文字列全体に対して使っていますが
この手法では部分文字列(単語)の小さな一部分だけをハッシュ化しています。

Algorithm
アルゴリズム

Algorithm sequentially steps through string S, and probe word W if it belong to SS.
Step length is SS size-Wsize+1. The Wsize is small number (typically 2, 4 or 8 bytes).

アルゴリズムは sequentially に文字列 S を through して SS の中に word W があるか
どうか調べます。
ステップの幅は SS のサイズ - Wsize + 1 です。
Wsize は小さな数字(典型的には2、4、8バイトといったもの)です。


Test if probed word belong to SS is done in structure, similar to hash table with open 
addressing which is generated in preprocessed step. Hash can tell if probed word belongs
to SS.

探し求める word が SS にあるかどうかテストすることは、
プリプロセスの段階で生成される
開番地方式のハッシュテーブルに似た構造のもとで行われます。
ハッシュは検索対象の単語がSSの中にあるかどうかを判定できます。


Empty hash cell indicates that W does not belong to SS. Value in hash cell tells how 
far W is from SS head. If hash collision occurs, next free cell is used.

空のハッシュセルは W が SS の中にはないことを示します。
ハッシュセルにある値によって SS の先頭からWがどのくらい離れているかを知ることができます。
ハッシュに衝突が発生した場合には次の自由セルが使われます。

After it was determined that probed word belong to SS,

we find address of possible substring starting in probed_position-hash_cell_value and 
compare is with SS. If equal, sub-string is found.

probed_position-hash_cell_value から始まる部分文字列候補のアドレスを見つけ出したら
それを SS と比較し、等しい場合には部分文字列が見つかりました。

This algorithm especially well suited for long substrings, multi-substring and regex 
search.

このアルゴリズムは特に長い部分文字列に対してだとか、
多重部分文字列の検索、正規表現検索に向いています。


Reference C++ implementation
C++による参照実装

(略)

Compared Implementations
比較に使用した実装

    * GLIBC MEMMEM() — GNU LIBC 2.11.2
    * NAIVE MEMMEM() — simple brute force implementation, Source in naive.cc.
    * STD::SEARCH() — STL algorithm from libstdc++ 3.3.6 (bundled with GCC-4.5.1).
    * BM_HORSPOOL_MEMMEM() — Boyer-Moore-Horspool implementation from [17]
    * BM_TUNED — Tuned Boyer-More from [18]
    * BM_HORSPOOL_YLILUOMA() — Boyer-Moore-Horspool implementation by Joel Yliluoma with
      Hongli Lai optimization for Intel [20]
    * BM_HAL() — Hashed Accelerated Linear algorithm by David R. Musser and Gor V. Nishanov [21]
    * VOLNITSKY() — refrence implementation of described here algorithm
    * VOLNITSKY_X86_64() — optimized for intel closed source implementation

Everything was compiled with with GCC-4.5.1 -O3 -native (including glibc/libstdc++ ) 
and run on x86_64 linux on Core2 Duo CPU at 2200Mhz.

Several other implementation were tested but results for them not shown. They were 
slow, buggy or not representative.

いくつかの実装に関しては、テストをしましたがその結果をここには示しません。
それらは遅かったり、バグがあったり、representative ではなかったりしました。

Tested but not shown

    * boost::find_first() v1.41 — about x2 slower than std::search.
                                  std::search の半分の速さ

    * KLIBC memmem()/strstr() — slow
                                遅い

    * boyer_moore() — from [3], if compiled with optimization — returns incorrect results.
                                最適化付きでコンパイルした場合、正しくない結果を返す

    * strstr() — from [12], according to author, it was fastest implementation of strstr() in 2007.
      In my tests, it is only slightly faster than naive_strstr().
      著者によれば、2007年において最速のstrstrの実装であった。わたしのテストでは
      naive_strstr() よりも速いだけだった。

    * GLIBC strstr() — GNU LIBC 2.11.2. Very slow - about x20 times slower than described
      here algorithm. See [6,7] about bad performance. Uses Two-Way algorithm.
      非常に遅い - ここで説明したアルゴリズムよりも20倍ほど遅かった。

    * xc_boyer_moore() — from [19]. Sometimes incorrect result was returned (not found).
      正しくない結果を返すことがありました(対象を見つけられなかった)。

Note that C style zero-terminated string functions are at disadvantage, as they need 
to check every byte for string end.

C 形式のゼロ終端される文字列を扱う関数は、文字列の末尾を探すためにその文字列すべての
バイトを検査する必要があるので disadvantage があることに注意してください。

参考→ Efficient substring search (not a Boyer-Moore) : programming

■_

The 3 Basic Tools of Systems Engineering
The 3 Basic Tools of Systems Engineering
システムエンジニアリングにおける三つの基本ツール

by Ted Dziuba Tuesday December 07 2010

One of the most important things I learned when programming for a startup is how to 
design reliable systems. A startup programmer needs to understand the business 
economics of systems design: that the goal is to create the desired functionality, not 
to write code. Code is only incidental, and it should be the last tool you use to 
solve a problem.

スタートアップでのプログラミングでわたしが学んだことで最も重要なもののひとつが
信頼性のあるシステムをいかにして設計するかということです。
スタートアップのプログラマーは、システム設計のビジネス経済 (business economics) を
理解する必要があります。その目標は要望された機能を作り出すことであって、コードを
書くことではありません。コードは incidental であるのみであり、
問題を解決するためにあなたが使う最後のツールであるべきものなのです。


There are three basic tools you can use to solve a technical problem: money, time, and 
code. This seems obvious, but the critical point is that you must try them in that 
order. Out-of-order execution of these tools leads to Very Bad Things, which we will 
discuss later.

技術的な問題を解決するために使える三つの基本ツールがあります。それは
お金、時間、そしてコードです。これらは明らかなことのように思えますが
crritical な点はあなたがそれらを試すその順番です。
これらのツールを out-of-order で実行することは
わたしたちがあとで論じるような Very Bad Things につながります。


Money

Money is by far the best way to solve a problem because it saves time and helps you 
avoid writing code. You can usually use money to solve performance and scalability 
problems, either by buying more hardware or faster hardware. My favorite example is 
how solid state disk drives make disk I/O problems go away because there is no penalty 
for disk seek.

なぜならお金は時間を節約するし、
あなたがコードを書かないですむように助けてくれます。
普通あなたは、性能やスケーラビリティについての問題を解決するために
お金を使えます。
より多くのハードウエアを買ったり
より高速なハードウェアを買って


At Milo, we did this when we had a database performance problem: read queries were 
running slowly, so we spent the money to buy a really powerful server for our database: 
24 cores, 64 gigabytes of RAM, and solid state disk drives. This solved the problem 
for the life of the company until we were acquired. It was absolutely worth the money 
because we then had more time to spend building the product, and no liabilities that 
would come from re-architecting the data model.

Milo においてデータベースの性能問題に直面したときに、わたしたちはこれを行いました。
読み出しクエリが遅かったので、わたしたちは金を払って自分たちのデータベースのために
24コアで64ギガバイトのRAMを搭載し、SSDドライブを持つ強力なサーバーを購入したのです。
これは、わたしたちが買収されるまで会社の命脈を保たせるという問題を解決しました。



It is rare that money can completely solve the problem (or that you have enough money), 
but it is an easy tool to try first.

金銭が問題を完璧に解決することは稀にしかありませんが(or that you have enough money)、
最初に挑戦するのに easy なツールではあります。

Time

If money doesn't work, invest time to research existing pieces of functionality that 
do. As I have said before, basic Unix literacy can help you know what tools are 
available to solve a given problem. For systems design, it helps to know what larger 
services are available for different classes of problems. To name a few:

もしお金が役に立たないのなら、すでに存在している pieces of functionality that do
を調べるのに時間をかけましょう。
先にわたしが述べたように、Unix の基本的なリテラシーは
与えられた問題に対して使うことのできるツールが何かを知るのを助けてくれます。
システムの設計に対しては、問題の異なるクラスにおいてより大きなサービスが可能で
あるかどうかを理解する助けになります。
To name a few:

    * Load balancing/redundancy: HAProxy

    * Caching: Squid, Varnish (not Memcache because it forces you to write too much code)

    * Database: PostgreSQL or Oracle if you can afford it. If you're using a NoSQL
      database, you fucked up somewhere.

    * Database replication: Slony-I

    * Full-text search: PostgreSQL, Solr (warning: if you use Solr the way I think you 
      will, you will have multiple points of truth in your system)

    * Queueing: if you're using a queue, again, you fucked up somewhere.

    * Logging: syslog, and nothing else. Ever.

It seems obvious, but sometimes it needs to be stated: use other peoples' work to 
accomplish your goals. Well-known open source packages are very high quality, and are 
far more reliable than anything you could build yourself. Even a 90% solution off the 
shelf is worth it because of the time you save in maintenance.

Code
コード

Writing code is the last resort for solving a problem. Code is a versatile enough tool 
that you can make it solve just about any problem, but every line is a liability. It's 
design, future maintenance, monitoring, testing and profiling. Write code only when 
you have proven categorically that money and third party software don't work.

コードを書くことは問題を解決するための最後の resort です。
コードはあなたがどんな問題についても解決できるようにできる versatile enough tool  です。
しかしすべての行が liability です。
それは設計であり、将来におけるメンテナンスであり、モニタリングであり
テストやプロファイリングです。
お金やサードパーティのソフトウェアが役に立たないカテゴリを見つけたときにだけ
コードを書きましょう。

As a side note, when you are testing the code, I have found that unit testing is a 
losing investment. Acceptance tests, however, are the most cost effective way to 
manage the risk that new code introduces, in terms of time spent developing.

しかしながらテストを受け入れることは、開発に要する時間という観点において
新しいコードを導入するリスクを管理するのに最もコスト面で効果的な方法です


Using the Tools Out of Order

The worst thing you can do is to try the code tool first, without considering money or 
time. This is called technical masturbation and it can sink a project in a hurry.

最悪なのは、お金や時間のことを考えずに最初にツールをコーディングしようとすることです。
これはtechnical masturbation と呼ばれるもので、
it can sink a project in a hurry.

When the first thing you do is dive into code, you are dooming yourself to either designing
an unmaintainable system, or to reinvent existing tools poorly. This may be acceptable in an
academic or research setting, but in a startup, it's downright foolish. You may be able to
deploy your system faster if you code it all yourself, but it will be a monkey on your back
for its entire lifetime. PostgreSQL has never woken me up in the middle of the night with a
segmentation fault or NullPointerException, but databases I've written myself have.

Functionality is an asset, but code is a liability. I will say this until you like it.

■_

すでに他でも紹介されていますが。


Day 10 – Feed operators « Perl 6 Advent Calendar

Perl 6 Advent Calendar
Something cool about Perl 6 every day


Anyone who has programmed in Perl 5 for a while has probably run across or written 
code similar to this:

しばらく Perl 5でプログラミングした人は誰でも次のようなコードを書いたり見たりしたことが
たぶんあることでしょう:

    my @new = sort { ... } map { ... } grep { ... } @original;

In this construction, the data flows from the @original array which feeds into the 
grep, and that, in turn, feeds into the map, and then into the sort, and then finally, 
the result is assigned to the @new array. Because they each take a list as their final 
parameter, simply by juxtposition, the data feeds leftward from one operation to the 
next.

この構造では、データフローは grep にfeed される配列 @original から始まり、
その結果は map に feed され、そして sort へと流し込まれ、最終的な結果が
配列 @new に代入されます。それぞれの演算子がそれぞれのfinal parameter としてリストを
受け取るので、
simply by juxtposition, the data feeds leftward from one operation to the next.

Perl 6, on the other hand, makes this idea of data flowing from one operation to 
another explicit by introducing the feed operator. The above Perl 5 code could be 
written like this in Perl 6:

一方Perl 6では、このデータフローの考えが feed 演算子の導入によって
一つの操作からもう一つの操作が明確な形にされました。
上にあったPerl 5のコードは Perl 6 では次のように書けます:

    my @new <== sort { ... } <== map { ... } <== grep { ... } <== @original;


Note that TMTOWTDI is alive and well in Perl 6. You could have also written much the 
same as in Perl 5:

TMTOWTDI は Perl 6でも生きていて活用されていることに注意してください。
あなたは Perl 5で次のように書いたこともあるかもしれません。

    my @new = sort { ... }, map { ... }, grep { ... }, @original;

The only difference would be the addition of commas.

唯一の違いはカンマが足されることだけです。


So, what do we gain from these feed operators? Normally, when reading code, you read 
from left to right. In the original Perl 5 code you would read from left to right 
until you realize that you're dealing with constructions where the direction of flow 
is right to left, then you jump to the end and follow the processing in a 
right-to-left manner. In Perl 6 there is now a prominent syntactic marker that clues 
you in to the leftward flowing nature of the data.

これらの feed 演算子によってわたしたちが得るものとはなんでしょうか?ふつうコードを読む
とき、あなたが左から右へと読み進めます。オリジナルの Perl 5 のコードでは、あなたはフロ
ーの方向が右から左となっている箇所をrealize するまで左から右へとコードを読み進め、そし
てそれから終端にジャンプして right-to-left manner での処理を追いかけることになるでしょ
う。
現在の Perl 6 では、prominent syntactic marker があります。
あなたを leftward flowing nature of the data へと clues する


Still, the right-to-left nature of this code is somewhat troublesome. It may not seem 
so onerous if all of the code fits on one line as above. But imagine if the blocks 
associated with grep, map, and sort were little longer. Finding the end of the 
statement could be a bit annoying.

それでも、このコードの right-to-left の性質はトラブルを招くようなものです。
すべてのコードが先に挙げた一行のように fit するものであればそれほど
問題にはならないかもしれません。
けれども、grep や map 、sort に結びつけられているブロックが
少々長めのものであったらという状況を想像してみてください
ステートメントの終端を見つけ出すことが少々骨の折れることになるかもしれません。

Luckily, Perl 6 has another feed operator that allows you to write the same code in a 
left-to-right fashion:

幸運なことに、Perl 6には同じコードを左から右形式で書くことを可能にするもう一つの feed 演算子があります

    @original ==> grep { ... } ==> map { ... } ==> sort { ... }  ==> my @new;


一番右に my @new; とかあるのは非常に妙な感じがしないでもない。

一番上の、Perl 5形式の構文て Perl 6では許されていないんだろうか? (そう読めるような)

■_

こっちもですが。


Day 12 – Smart matching « Perl 6 Advent Calendar

Perl 6 Advent Calendar
Something cool about Perl 6 every day Day 12 – Smart matching
By ttjjss

Remember the http://perl6advent.wordpress.com/2010/12/04/the-sequence-operator/ 
sequence operator? As the last argument it takes a limit, which makes the sequence 
generation stop. For example:

    1, 2, 4 ... 32;         # 1 2 4 8 16 32
    1, 2, 4 ... * > 10;     # 1 2 4 8 16

* > 10 という書き方がなんとも。

■_

もうひとつ。 これは Larry っぽいセンスのような印象が。


Day 14 – nextsame and its cousins « Perl 6 Advent Calendar

Perl 6 Advent Calendar

Day 14 – nextsame and its cousins

By carl

Maybe you're familiar with the way the keyword super in Java allows you to delegate 
to the method (or constructor) of a base class. Perl 6 has something similar… but in 
a world with multiple inheritance and mixins it makes less sense to call it super. So 
it's called nextsame. Here's an example of its use:

多重継承やmixins がある Perl 6 では「super」ってのはいい名前じゃないんじゃね?
ということで、nextsame と呼ぼう。
例。

class A {
    method sing {
        say "life is but a dream.";
    }
}

class B is A {
    method sing {
        say ("merrily," xx 4).join(" ");
        nextsame;
    }
}

class C is B {
    method sing {
        say "row, row, row your boat,";
        say "gently down the stream.";
        nextsame;
    }
}
(略)


In summary, nextsame works in a lot of places you'd expect it to work, and it works 
the way you expect it to. It defers to the next thing.

Oh, and nextsame has three closely related cousin keywords:

nextsame             Defer with the same arguments, don't return
                     同じ引数を渡し、リターンしない

callsame             Defer with the same arguments, then  return
                     同じ引数を渡し、その後リターンする

nextwith($p1, $p2, ...) Defer with these arguments, don't return
                        指定された引数群を渡し、リターンしない

callwith($p1, $p2, ...) Defer with these arguments, then  return
                        指定された引数群を渡し、その後リターンする

Naturally, the other three can be used in the same situations nextsame can.

■_

Staging Servers, Source Control & Deploy Workflows, And Other Stuff Nobody Teaches You: MicroISV on a Shoestring

Staging Servers, Source Control & Deploy Workflows, And Other Stuff Nobody Teaches You

By Patrick on December 12, 2010

I worked for almost three years as a cog in a Japanese megacorporation, and one of the 
best parts about that experience (perhaps even worth the 70 hour weeks) was that they 
taught me how to be a professional engineer.  Prior to doing so, my workflow generally 
involved a whole lot of bubble gum, duct tape, and praying.  I spent a lot of time 
firefighting broken software as a result, to the detriment of both my customers and 
myself.  Talking to other software developers has made me realize that I'm not the 
only person who was never taught that there are options superior to bubblegum.  If you 
aren't lucky enough to work at a company that has good engineering in its very DNA, 
you're likely to not know much about them.


C++ tutorial for C users
C++ tutorial for C users

This text shows and highlights features and basic principles of C++. It is aimed at 
experienced C users who wish to learn C++. You will be able to express your code using 
the richer C++ syntax and you will be able to read some C++ code.

Though the concept is introduced and made usable, this is not a tutorial about Object 
Oriented Programming. You will still have to learn the spirit of OOP and the details 
of its implementation in C++, in order to be a true C++ programmer.

2010年12月13日

■_

今月下旬に発売の「センゴク外伝 桶狭間戦記」の特装版はどうやら 30ページほどの書き下ろしの話がつくとか何とか。

■_ R

はまったw

> x <- 1:50
> x
 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
[34] 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
> x[x %% 2 == 1]
 [1]  1  3  5  7  9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
> x[x %% 2 == 1 & x > 10]
 [1] 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
> prd1 <- function(n) { n %% 3 == 0}
> prd1(3)
[1] TRUE
> prd1(4)
[1] FALSE
> x[prd1(x)]
 [1]  3  6  9 12 15 18 21 24 27 30 33 36 39 42 45 48
> prd2 <- function(n) { if (n == 2) return(TRUE); if (n %% 2 == 0) return(FALSE); return(TRUE)}
> x[prd2(x)]
 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
[34] 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Warning messages:
1: In if (n == 2) return(TRUE) :
  the condition has length > 1 and only the first element will be used
2: In if (n%%2 == 0) return(FALSE) :
  the condition has length > 1 and only the first element will be used
> 

一見 list comprehension のような記述ができるのですが、そこに関数呼び出しは書けなかったという。 や、正確に言うと、function(n) { return(n %% 3 == 0)} みたいな「単純な」ものだと問題ないのですが。

■_

Twitter / @Faith and Brave: 何これ何これ 「C++ crazy typedef」 ...


C++ crazy typedef : what is the point of allowing this syntax? - Stack Overflow
The old familiar one:

typedef int my_int; //cute

This syntax is perfect. No problem.

Now, when we can write typedefs like above, then what is the point of allowing this syntax:

int typedef my_int; //crazy

Just to confuse programmers? Is this syntax even needed anywhere (when in fact we've the above one)? What do you think from the compilers' point of view? Do they find it cute or crazy? Or it doesn't matter to the compilers at all?

By the way, this code came from here : Use of typename keyword with typedef and new

In case if you're wondering if that is syntax error, then check out the working code here at ideone.

C++/C were pretty much designed to confuse programmers. It was a clear design goal to 
maximise the complexity of the expressions that you can write - upside is you can 
write crazily complex code in loads of different ways - downside is you can write 
crazily complex code in loads of different ways. – James Gaunt


@James if you want to see a language which maximizes the complexity of expressions, 
you should learn perl. – SoapBox 

James ひでえ言いようじゃなイカ?

■_



Twitter / @キョート・サラリマン: GNU Modula-2 がバージョン 1.0 にな ...

GNU Modula-2 がバージョン 1.0 になったらしいけど、いまさら感がすごすぎる。 
http://www.nongnu.org/gm2/

ごもっとも。


GNU Modula-2 1.0 released! : programming

At first I was like "meh" but then I read how well it works with GCC from 
their homepage:

    The GNU Modula-2 compiler is one of a number of front end languages to GCC (GNU 
    Compiler Collection). As such it has been designed to coexist with other GCC languages 
    for example it can be used in mixed language projects and it can catch C++ exceptions 
    and throw exceptions which can be caught by C++. Users can also exploit conditional 
    compilation and full gcc backend optimization and architecture coverage.

    GNU Modula-2 can produce position independant code and can easily produce shared 
    libraries from modules. The compiler provides a swig interface file generator option 
    which allows scripting languages such as Python to import modules written in Modula-2 
    and also catch exceptions thrown by Modula-2.

That it can even handle C++ exceptions (and scripting languages can catch Modula-2 
exceptions) is just really, really damn cool.

Indeed. This is 2010, and Modula-2 still looks better than most widely-used system 
programming languages right now. It has a well thought-out module system, a 
straightforward standard library (with coroutines), a strict type system, variant 
records, bit sets and a saner (non-C(ish)) syntax. Your definition of 'old' would 
probably fit C or C++ more.

    Even its claim to fame (the "modul" in "Modula") looks like a toy
    compared to Java's packaging system.

Java packages are not modules, they are just glorified namespaces. Does Java support 
nested packages? Qualified Imports/Exports? Reexports? Not really - though that 
functionality might be bolted-on in Java 8 (JSR277).

    I also chuckled at the old school HTML documentation. Repeating links twice, using 
    "here"... This is so last century.

I chuckled too, but only because I think that it's a quite impressive feat considering 
the fact that the whole thing has been pretty much a one-man project since day 1.

I'm not going to lie, I originally said Modula-2 was crappy because it was old, I was 
uncomfortable with the syntax, and the Wikipedia page didn't offer much that impressed 
me. Plus, the only language with several major dialects that I'm really comfortable 
with is Scheme, and that's because it's kind of the point of Scheme that the required 
common implementation details are very small.

But digging into it, I'm actually quite attracted to it. I can't stand the uppercase 
keywords, but hey, details aren't worth getting caught up in I guess. The coroutines 
are a big plus, that's for sure.

Man, I thought Modula-2 was pretty awesome.

In 1986.

As the documentation states, the primary expected use for this is to compile existing 
codebases. There was lots of code written in Modula-2 back 10-15 years ago. Until now, 
people were faced with the prospect of re-writing the code. Now they have access to a 
modern 64 bit native compiler.

I do often wonder why languages like Modula-2 and Modula-3, Eiffel, Oberon, Sather et 
al never achieved the same traction as languages like Java or C++. Even Pascal 
currently enjoys support in the form of Delphi for Windows and FreePascal and Lazarus 
for everywhere else. Eiffel's only free compiler, SmartEiffel, appears to have died, 
as has its descendant, Sather. Of the Pascal descendants, only Ada appears to have 
gained any following.

I think it's sad. I used to write Delphi code back in the day when I wrote Windows 
code (mid to late nineties). I would love to see a revival of these languages. What a 
pleasant change it would be from Java.

まあオブジェクト指向の機能もサポートしてませんしねえ > Modula-2

でもいいところもあると思うんだよなあ。 ただ、リンカーやらにも手を入れないと100%の力w は発揮できないような気がする。

■_

■_

ネタが被っても、さらには先を越されても泣かない ○| ̄|_

2010年12月12日

■_

泳ぐやる夫シアター やる夫で学ぶ日露戦争  第二十三話

・「デザインのためのデザイン」
買った。 ちょっとだけ読んだのですが、JCLの下りが結構面白い。

・ 池袋ジュンク堂での C と C++ と Java の棚面積
やっぱり C の面積が大きすぎるよなあ。 さらにその内容も「入門書」が大半てどゆことー?

・TAPL読書会
がありまして(途中でなぜか有界の会と合流したり)。 その懇親会で Haskell と Common Lisp(と Java) で仕事をしているという方とお話しました。 Haskell では電話などで割り込みが入っても、 その用事が済んだあとコーディングできるまでの復帰が早い といわれてたのが印象的でした。 できれば Haskell だけで片付けたいのだけどもろもろの理由で Common Lisp (や Java) になることもあるのだとか。 ということで Lisp で仕事ができるところはやっぱりあるようです。 ん、 経験15年のOCaml ユーザーが Haskell を仕事で半年使ってみた - Oh, you `re no (fun _ → more) おお、これは。

・IT批評
1号が出たので買ったんですが、 「アンドロイドOSはアップル帝国の牙城を崩せるか」 という記事。

発売当初は品薄状態が続き、なかなか手に入らなかったが、現在はソフトバンクモバイルの各シ
ョップ、アップルストア各店舗、家電量販店などでも購入できるようになり、いまだに好調な売
れ行きという。実際、電車の中やカフェなどでiPadを使っている人を見かけるようになった。外
国人などは、歩きながらiPadを使っていたりして、筆者は「グッジョブ!」と心の中でサムアッ
プしたりしていたものだ。

なにが「グッジョブ」なんだろう? Apple の宣伝活動? にしたって、歩きながら iPad を使うとなぜグッジョブなのかわからない… 誰か教えてくんなまし。

■_ Ranking the popularity of programming languages

この図のはなし → http://www.dataists.com/wp-content/uploads/2010/12/rank_scatter1.png


dataists » Blog Archive » Ranking the popularity of programming languages

Ranking the popularity of programming languages

How would you rank the popularity of a programming language? People often discuss 
which languages are the best, or which are on the rise, but how do we actually measure 
that?

プログラミング言語の popularity をどのようにランクづけしますか?
しばしば人は最良の言語はどれかであるとか、勢いのある言語はについてだとか
について議論をしています。でも実際のところ、わたしたちはなにを基準にして
いるのでしょうか?

One way to do so is to count the number of projects using each language, and rank 
those with the most projects as being the most popular. Another might be to measure 
the size of a language's “community,” and use that as a proxy for its popularity. 
Each has their advantages and disadvantages. Counting the number of projects is 
perhaps the “purest” measure of a language's popularity, but it may overweight 
languages based on their legacy or use in production systems. Likewise, measuring 
community size can provide insight into the breadth of applications for a language, 
but it can be difficult to distinguish among language with a vocal minority versus 
those that are actually have large communities.

方法のひとつが、各言語を使っているプロジェクトの数を数えるというもので、
最も多くのプロジェクトに使われた言語が最も popular であるとするものです。
もうひとつは、言語の「コミュニティ」の大きさを基準として
それをその言語の popularity に対する proxy として使用するというものでしょう。
これらはそれぞれに利点と欠点があります。
プロジェクトの数を数えるものはおそらく言語の “purest” measure でしょうが、
それはその言語の歴史だとか production system で使われているということを
過大評価してしまっているかもしれません。
同様に、コミュニティの大きさを基準とするものは
insight into the breadth of applications for a language
を提供しますが、マイナーな言語と大きなコミュニティを有している言語とを
区別するのが難しいかもしれません。

Solution: measure both, and compare.
解決策: 両方使って比較する。

略

■_ GNU Modula-2 version 1.0

実はModula-2も大好きなんです :) いやまあ予約語が全部大文字で case-sensitive ってのはどうにかならないもんか とは思いますけども(ごにょごにょ



[Gm2] GNU Modula-2 version 1.0

Hi,

GNU Modula-2 1.0 has been released.  Full details on how to download
gm2 can be found on the homepage www.nongnu.org/gm2.  It successfully
passes all regression tests on both the x86_32 and x86_64 Debian
GNU/Linux platforms, for details about other ports please also see the
homepage.

A huge thanks to all the numerous people that have supported this
project over the last decade.

regards,
Gaius


GNU Modula-2 へ。


GNU Modula-2
The home of the GNU Modula-2 compiler. The compiler has undergone quite a number of 
changes recently and the current version in the CVS being worked upon is gm2-1.0.1. 
The native x86_64 and x86_32 ports are the most stable.

The GNU Modula-2 compiler is one of a number of front end languages to GCC (GNU 
Compiler Collection). As such it has been designed to coexist with other GCC languages 
for example it can be used in mixed language projects and it can catch C++ exceptions 
and throw exceptions which can be caught by C++. Users can also exploit conditional 
compilation and full gcc backend optimization and architecture coverage.

GNU Modula-2 can produce position independant code and can easily produce shared 
libraries from modules. The compiler provides a swig interface file generator option 
which allows scripting languages such as Python to import modules written in Modula-2 
and also catch exceptions thrown by Modula-2.

Modula-2 のモジュールってきちんと作るとかなり面倒な気がするんだけど どうやってんのかな。

■_ 文字列比較

Boyer-Moore つーてもいろいろバリエーションあるのねえ (古いのは知ってたw)。


Efficient substring searching – Phusion Corporate Blog

By Hongli Lai on December 6th, 2010

There are many times when programmers need to search for a substring, for example when 
parsing text. This is commonly referred to as searching for a needle (substring) in a 
haystack (the string to search in). The most straightforward way to do this is by 
using search functions that your language provides:

    * C: strchr()/memchr(), strstr()/memmem()
    * C++: string::find()
    * Ruby: String#index or regular expressions
    * Python: string.find() or regular expressions

However those functions are usually implemented in a naive way. They usually go 
through every index in the haystack and try to compare the substring at that index 
with the given needle. Thus, given a needle of length M and a haystack of length N, 
those algorithms need O(M*N) steps in the worst case. This is acceptable for small 
haystacks, but becomes more and more problematic as the the haystack grows.

In this article we'll examine smarter algorithms, in particular Boyer-Moore and its 
variants. Finally we'll present the reader with an optimized Boyer-Moore-Horspool 
implementation in C++. This implementation differs from most others in that it's 
heavily optimized and is capable of accepting haystack input in a streaming manner.

Before we move on, it should be noted that Python's string.find(), Ruby regular 
expressions and glibc's implementation of memmem() actually can use smarter 
algorithms when conditions are right, but that is besides the main point of this 
article.

Demonstration of a naive substring search algorithm

Smarter algorithms

Are there faster algorithms for searching needles? Why yes, computer science has 
already found the answer decades ago. Here are two algorithms that can find needles in 
less than O(M*N) time:

    * Knuth-Morris-Pratt, invented in in 1977.
    * Boyer-Moore, also invented in 1977.

略

Boyer-Moore has several variants.

“Tuning the Boyer-Moore-Horspool String Searching Algorithm” by Timo Raita, 1992

    * Turbo Boyer-Moore takes more space but needs 2*N steps in the worst case instead 
      of the original's 3*N steps.

      Turbo Boyer-Moore はオリジナルに比べてより多くの空間を使用しますが、
      ワーストケースにおいてオリジナルが 3*N ステップを要するのに対して
      このアルゴリズムは 2*N ステップしか要しません。

    * Boyer-Moore-Horspool uses less space (only requires the good suffix table) and 
      has a simpler inner loop with less constant overhead per iteration. Its average 
      performance is O(N) but it has a worst-case performance of O(M*N).

      Boyer-Moore-Horspool はオリジナルよりも少ない空間しか使用せず
      (good な suffix table のみを必要とします)、さらに繰り返しあたりの
      オーバーヘッドが less constant であるような、シンプルな内部ループを
      有しています。その平均性能は O(N) ですが、ワーストケースでの性能は
      O(M*N) となります。

    * Boyer-Moore-Horspool itself also has variants. In Timo Raita's 1992 paper “Tuning
      the Boyer-Moore-Horspool String Searching Algorithm” he asserts that text is
      rarely random and that there usually exist strong dependencies between characters. 
      Thus there are smarter ways to match the needle: instead of matching it backwards
      from the last character, one should first match the last character, then the first 
      character, then the middle one, etc. The advantage of this heuristic becomes obvious 
      if we consider an example in which we search for the needle “hello world” in a 
      haystack that often contains the word “world” in combination with a word other
      than “hello”, e.g. “beautiful world”, “my world”, “another world”. When the 
      algorithm matches the last needle character “d”, instead of wasting time matching 
      “worl” as well, it can match the first needle character “h” and immediately 
      determine that there is no match. This heuristic can drastically improve 
      Boyer-Moore-Horspool's average performance.

Theory vs practice

Which algorithm should one use, Boyer-Moore, Turbo Boyer-Moore or Boyer-Moore-Horspool? 
In theory Turbo Boyer-Moore is an attractive alternative because of its worst-case 
performance, but real-world experience has shown that theory is rarely the same as 
practice. Clearly, this calls for benchmarks.

Boyer-Moore, Turbo Boyer-Moore or Boyer-Moore-Horspool のいずれのアルゴリズムを
使うべきなのでしょうか? 理論的には Turbo Boyer-Moore が attractive alternative です。
理由はそのワーストケースでの性能です。しかし現実世界で経験したところでは
理論が実践と同じとなることは稀です。
Clearly, this calls for benchmarks.


Various implementations of Boyer-Moore (and variants) exist in a variety of languages, 
but for the purpose of benchmarking we will want to use C or C++ because they allow 
the most optimal implementations. (Or assembly, but let's not be too l33t today.) 
However there seem to be few good C/C++ implementations out there that are:

   1. Readable.
   2. Correct.
   3. Tested.
   4. Optimal.

以下略


■_ だめだー

ネタはたくさんあるのに能力が追いつきません ○| ̄|_

■_

2010年12月11日

■_

ニフティの会議室貸しますって始めますというアナウンスのあと使ったという話を 見てない気がするんですがどんな感じなんでしょ。

■_


会議室の直前キャンセルを無くしたい! | OKWave
会議室の直前キャンセルを無くしたい!

会議室の直前キャンセルを無くしたい!
社員の意識変革はもっともですが、少しでもツールで解消できないものでしょうか。
例えば当日キャンセルが頻発すると一定期間会議室予約できなくなるなど。

何かツールをご存じの方は教えてください!

これはついている回答のひとつにもあるように、 システム以外のところで対処したほうが良いような気がする。

■_ from 知恵袋


R言語で、「1000以下の最大の素数」を出すには、どうすれば良いのでしょうか? 「1... - Yahoo!知恵袋

R言語で、「1000以下の最大の素数」を出すには、どうすれば良いのでしょうか?
「1000以下の素数」をすべて出すのはできたのですが、最大の数だけを出すことができません。


/*
1000以下の整数で7で割り切れる最大の整数を示せ。
なら、こうすればOK。
条件「7で割り切れる」を「素数:約数がない」
に置き換えればいい。
*/
#include_<stdio.h>

int_main(void){
__int___n;__//_条件に適合する整数
__int___k;__//_試算用変数

__for(k=7;k<=1000;k++){
____if(k%7==0)_n_=_k;
__}
__printf("それは%dです。\n",n);
__return_0;
}
/*_出力
それは994です。
*/

>「1000以下の素数」をすべて出すのはできたのですが
そのソースを載せること。

なんで C で回答書いているんだろう…

  numbers <- 2:1000
  max(numbers[isprime(numbers)]

R だとこんな感じ? isprime の定義はおいといて。

あるいは、エラトステネスの篩で1000以下のものリストを作ってその max とりゃいいのか。

R で面白いやり方のエラトステネスの篩って書けるのかな。 Haskell のアレのような。

■_ 今日の巡回から

なんかイベントにいってたりするとRSS消化するのも半端だにゃー

■_ hoc2

変数(aからzまでの一文字のもの26個)が扱えるようになりました。


%{
double  mem[26];        /* memory for variables 'a'..'z' */
%}
%union {                /* stack type */
        double  val;    /* actual value */
        int     index;  /* index into mem[] */
}
%token  <val>   NUMBER
%token  <index> VAR
%type   <val>   expr
%right  '='
%left   '+' '-'
%left   '*' '/'
%left   UNARYMINUS
%%
list:     /* nothing */
        | list '\n'
        | list expr '\n'        { printf("\t%.8g\n", $2); }
        | list error '\n'       { yyerrok; }
        ;
expr:     NUMBER
        | VAR           { $ = mem[$1]; }
        | VAR '=' expr  { $ = mem[$1] = $3; }  
        | expr '+' expr { $ = $1 + $3; }
        | expr '-' expr { $ = $1 - $3; }
        | expr '*' expr { $ = $1 * $3; }
        | expr '/' expr {
                if ($3 == 0.0)
                        execerror("division by zero", "");
                $ = $1 / $3; }
        | '(' expr ')'  { $ = $2; }
        | '-' expr  %prec UNARYMINUS  { $ = -$2; }
        ;
%%
        /* end of grammar */

/*
 * includes
 */
(略)

■_ 伊吹鞍馬穂高戸隠

伊吹級なら欲しい…置き場所も作る時間も(さらには道具も)ないけどさ○| ̄|_

【碧海の玉座】横山信義総合スレ19【擾乱の海】 [chaika]
531 名無し三等兵 [sage] 2010/12/11(土) 00:03:56 ID:??? Be:
    なんと八八艦隊の天城級巡戦のプラモ発売がフジミから発表された。
    おそらく次はバリエーションキットでその次が土佐・加賀だろう。

    このスレの住人は買うだろ?

532 名無し三等兵 [sage] 2010/12/11(土) 01:04:42 ID:??? Be:
    まず置き場を確保しないと悪気は無かったにしても家族にブッ壊されてしまう… 

533 名無し三等兵 [sage] 2010/12/11(土) 01:21:54 ID:??? Be:
    破壊されたらポートモレスビーを再現すればいいじゃまいか。 

534 名無し三等兵 [sage] 2010/12/11(土) 04:07:20 ID:??? Be:
    無条件降伏の上、今後1000円以上のプラモを購入する事を禁じる、とかって
    破滅的な条約結ぶ羽目になったりしてw 

535 名無し三等兵 [sage] 2010/12/11(土) 10:57:36 ID:??? Be:
    >534
    最近のプラモで1000円以下だと軽巡クラスまで? 

536 名無し三等兵 [sage] 2010/12/11(土) 12:20:34 ID:??? Be:
    ttp://www.tamiya.com/japan/waterline/destroyer.htm
    残念ながら駆逐艦ですら買えません 

537 名無し三等兵 [sage] 2010/12/11(土) 12:26:43 ID:??? Be:
    週刊天城にすればいいんだよ、52号集めると完成するのさ
    あるいは船体を細かく分割して、合体マシン天城にするとか、
    アオシマならきっとwww 

538 名無し三等兵 [sage] 2010/12/11(土) 12:42:30 ID:??? Be:
    >536
    ひでぇ、最近のWLそんなするのか。
    子供の頃、500円玉握って何買うか迷っていたのが懐かしい。
    昭和は遠くなりにけり、だなぁ。 

539 名無し三等兵 [sage] 2010/12/11(土) 12:58:59 ID:??? Be:
    むぅ、ミリタリーミニチュアもだいぶ高くなってるな
    79年のカタログ引っ張り出してきたら四号戦車H型が900円だったが
    いまは税込み4095円か・・・

    ちなみにウォーターラインの駆逐艦は200円w 

540 名無し三等兵 [sage] 2010/12/11(土) 14:32:34 ID:??? Be:
    三百円で食玩であったりとかしないかな……
    箱ごと買うのに 

541 名無し三等兵 [sage] 2010/12/11(土) 16:14:37 ID:??? Be:
    それじゃ144の飛行機も買えないよ… 

542 名無し三等兵 [sage] 2010/12/11(土) 17:18:01 ID:??? Be:
    >>538-539
    一応フォローしておくと、昔のキットをそのまんま値上げしてるのではなく、
    ここ十年位の間に新規開発されたり、武装やカッター等の装備品がリニューアルされてたりします 

543 名無し三等兵 [sage] 2010/12/11(土) 17:53:14 ID:??? Be:
    >536
    1000円以下だと辛うじて松型までか。
    ある意味リアルだなw 

【楽天市場】FUTOKU46 日本海軍巡洋戦艦 天城:模型・ホビーのノースポート これか。

2010年12月10日

■_

なんでグレートブリテンのチャールズさんは王太子じゃなくて皇太子なんだろうというのが気になったり。

■_


推薦図書/必読書のためのスレッド 60 
150 デフォルトの名無しさん [sage] 2010/12/10(金) 13:33:36 ID: Be:
    今一番欲しい本なに? 

151 デフォルトの名無しさん [sage] 2010/12/10(金) 13:52:28 ID: Be:
    もしも高校野球のマネージャーが明解C++を読んだら、かな 

152 デフォルトの名無しさん [sage] 2010/12/10(金) 14:14:23 ID: Be:
    俺の妹がデイビッド・カトラーみたいなプログラマーのはずがない 

153 デフォルトの名無しさん [sage] 2010/12/10(金) 14:45:48 ID: Be:
    侵略!バグ娘 

154 デフォルトの名無しさん [sage] 2010/12/10(金) 16:13:54 ID: Be:
    このスレでやれw
    http://hibari.2ch.net/test/read.cgi/prog/1271821794/l50

バグとテストと残業中 
37 仕様書無しさん [sage] 2010/12/10(金) 16:14:58 ID: Be:
    http://hibari.2ch.net/test/read.cgi/tech/1291394559/151-153n
    151 :デフォルトの名無しさん:2010/12/10(金) 13:52:28
    もしも高校野球のマネージャーが明解C++を読んだら、かな

    152 :デフォルトの名無しさん:2010/12/10(金) 14:14:23
    俺の妹がデイビッド・カトラーみたいなプログラマーのはずがない

    153 :デフォルトの名無しさん:2010/12/10(金) 14:45:48
    侵略!バグ娘 

38 仕様書無しさん [sage] 2010/12/10(金) 16:24:51 ID: Be:
    とあるbugsの禁書目録 

■_ 何だこの流れ

良くある丸投げくんかと思えば


askaasakaさんに怒っています | OKWave

askaaskaさん、「あまりにも人を馬鹿にしたコードに見えるんだけど。」とはなんですか!!!!!(怒)

   プログラムのコードの構造が分からないからこうやって質問しているのすよ(怒)!!

   「とりあえず実装していかにも努力していますなふりをして答えを教えてくださいって言っているよ
   うに思えるんだけど?」とか言わないでください(怒)!!!
   
   いくら努力しても分からないものは分からないんじゃーーーー!!!(怒)

ANo.7

ああそうだ, 1点言い忘れてた.

怒るんだったら, (どうせ課題なんだろうから) 課題を出した人間に対して直接面と向って怒る
のが筋だろうな.

ANo.6

※署名活動みたいな気持ちで書き込み。


>いくら努力しても分からないものは分からないんじゃーーーー!!!(怒)

どんな努力をしているというのか。
QAサイトに質問するだけなのは努力しているとはいわないよ。

しかも、回答してくれた人にお礼は無し。
たまに書いたかと思えば、文句だけ。
さらには「いいから、黙ってプログラムを書けばいいんだよ!!!!」なんて返事だけ。


で、努力のかけらも見えないコードをかいておいて、それを注意されると文句のスレ。

ありえないだろ。


自分のことを棚にあげて、人のことを文句言えた立場じゃないだろうに。

どんだけ自分勝手だ?

自分がしてきたことを冷静になって考えてみた方がいいだろう。


※さて、このスレ、どれだけ反響があるか楽しみだ。
ANo.5

努力してないように見える」と言われて怒るようではだめだな.
「こんなに努力してもわからない」と努力の跡を見せるのが大人の対応.

ANo.4

http://oshiete.goo.ne.jp/qa/6369248.html
の「補足」より

> だって分らないんだもん!!いいから、黙ってプログラムを書けばいいんだよ!!!!

解決のヒントを書いてくれている人達に、こんな言葉を返すようでは、とても「プログラムを理
解しようと努力している」ようには感じられません。

努力って何をしたんですか?
回答者を脅してプログラムを書いてもらっただけですか?
それで問題が「解けた」ら、もう次の問題ですか?

おそらく、今のあなたは、人の書いたプログラムを眺めて理解したつもりになってるだけです。
だから、新しい問題になると、まったく手が出せないんです。
ろくに復習しないまま進めてては、いつまでたっても理解なんかできませんよ。

ANo.3

あのぉ…
怒りはブログとか日記とかでぶちまけていただけませんでしょうか…

ここ質問サイトですよ。たまに、モラルの無いバカな回答者がいますがこういった不特定多数の
人が利用する場所では十分起こり得る事です。

運が悪かった以外にどうも言えませんよ。

ANo.2

aw345 さん、「askaasakaさんに怒っています」とはなんですか!!!!!(怒)



文字列について
クラスメソッドについて
全く分かりません(2)
先ほどのプログラムで
クラス宣言の身長と体重の比較
配列の乱数と平均値、個数表示
入力した値を表示する方法
キーボードから10人分の点数を格納する配列を用意し、平均点および平均点
入力データ数を入力して、その数だけ整数値を入力し配列を格納した後、入力
入力された入力値と最大値、最小値を表示させるプログラムで、最大値と最小


これらの質問への解答に対してお礼が0ならそりゃ文句も言いたくなるでしょうよ。

ANo.1


まずですね、
直接
http://oshiete.goo.ne.jp/qa/6375647.html
で言わずに、わざわざ別質問を立てる意図から教えて下さい。
貴殿のこの質問のおかげで、トップページから落ちてしまった質問が一つあることは当然ご理解の上のご質問ですよね。

■_

お金の話。


Developer Income Report #5

(略)

So how is it going now…?

My income got a little steady. This happed because I have been moving to new house and 
had very little time to work on all my projects. So it is not growing so rapidly anymore.
Anyway there is still one amazing thing! I have been working just a little to keep the
things going and I still made quite a nice income!

Show me the money…!

So here is my total income report for month November 2010. As usual I will start my 
list from lowest income source to the highest one:

    * $59.85 – Amazon referral earnings -  just a few bucks here and there…

    * 69.80€ – PPC – slowly increasing due of my websites popularity

    * $104.13 – Freelancer.com referral earnings – as I am regular service buyer (used
     to be provider) I recommend this service and get some affiliate earnings

    * $412.96 – iStockphoto – not really working on this income source but still
     generating income from royalty fees from my photos

    * $1,691.27 – Android – money made on ads in my free Android applications.

■_ JavaScirptじゅーよー

You Must Learn JavaScript ― Article ― The Nerdary
You Must Learn JavaScript

By Kenny Meyers December, 2nd 2010

If you asked me 3 years ago what language you should learn I would've said Ruby. If 
you asked me 6 years ago, it was PHP.

もし三年前に学ぶべき言語は何かと尋ねられたら、Ruby とわたしは答えたでしょう。
六年前に尋ねられたならば、PHP だと答えたことでしょう。

If you're going to learn a language now, you need to learn JavaScript.

もし今、あなたが言語をなにかひとつ学ぼうとするのなら、あなたには
JavaScript を学ぶ必要があります。

Why?
なぜか?

It's my belief that every single web programmer should learn JavaScript. There are 
many new technologies coming out that fuel this principle. There is one single reason 
behind it. It's ubiquitous. You can work for anyone and do amazing things if you're 
using JavaScript. You can do it instantly on any machine.

Not every company is a Ruby shop. Not every company is a .NET shop. It's my belief 
that 99% of the time both of these companies will need someone who knows JavaScript, 
and knows it well. Microsoft, Facebook, Apple and Google all use JavaScript to make 
great things.

すべての企業が Ruby shop ではありません。
すべての企業が .NET shop ではありません。

Microsoft や Facebook、Apple、Google などはみな、make great things のために
JavaScript を使っています。

Knowing JavaScript well is probably one of the most challenging and rewarding things you
can do as a programmer. It's an incredibly diverse language, much larger in application
than you think. There are a large amount of gotchas, some great new APIs, and it's in
constant development.

Knowing JavaScript well is probably one of the most challenging and rewarding things
you can do as a programmer.
It's an incredibly diverse language,
much larger in application than you think.
There are a large amount of gotchas, some great new APIs,
and it's in constant development.


When people talk about HTML5, they are talking mostly about JavaScript.
皆が HTML5 について話をしているとき、ほとんどの場合彼らは JavaScript について話をしているのです。

But where to begin?
でもなにから始めれば?

The starting point to learn JavaScript is with manipulating a web page: with operating 
on the DOM. Many JS programmers have issue with this, because before Ajax and the JS 
revolution JavaScript was underestimated due to its role as a DOM Manipulator. You 
should know that it's greater than a show/hide mechanism on your website.

JavaScirpt を学ぶための出発点は、DOM による operating によって
webページを manipulating することです。
Many JS programmers have issue with this,
なぜなら、Ajax や JS revolution より前では
JavaScript はその役割が DOM Manipulator であると過小評価
(underestimated) されていたからです。
あなた方は、 JavaScript の役割が webサイトでの show/hide mechanism よりも
大きいものだということを知るべきなのです。

Manipulating the DOM is easy, however, and instantly rewarding. The single greatest book
I've found on DOM manipulation is DOM Scripting. The great news is that it's finally
getting a much needed update. Jeremy Keith's book is the best gateway to some basic
fundamentals of JavaScript.

DOM の操作は簡単ですが、即座に恩恵を受けます (rewarding)。
わたしが DOM 操作に関して見つけた single greatest book は DOM Scripting です。
The great news is that it's finally getting a much needed update.
Jeremy Keith の本は、
JavaScript についての some basic fundamentals への best gateway です。

This is just the beginning. If you thirst for more knowledge look at this Stack Overflow
question. It has some great recommendations, many of which I've read. JavaScript: The
Definitive Guide is the JavaScript bible. Praise be unto it.

これは単なる出発点にすぎません。
If you thirst for more knowledge look at this Stack Overflow question.
It has some great recommendations, many of which I've read.
JavaScript: The Definitive Guide は JavaScript の bible です。
Praise be unto it.

I recommend Angus Croll's JavaScript, Javascript as the single best blog on understanding
core JavaScript. It's so good and thorough that knowledge practically jumps into your tiny
skull. Douglas Crockford is also great, but his writing isn't as meticulous or detailed as
Angus's.

わたしは Angus Croll の JavaScript をお勧めします
Javascript as the single best blog on understanding core JavaScript.
It's so good and thorough that knowledge practically jumps into your tiny skull.
Douglas Crokford もまた great ではあるのですが、
彼の著作 (his writing) は Angus のそれと比べると詳しさや精密さで劣ります。

Frameworks are nice. They are helpful. If anyone scoffs at you for using a framework while
you're learning, don't listen to them. You're on the right path. I think jQuery educates
more people about the importance of context in JavaScript than any book or reference doc.
After you've selector'd your face off, dive deeper into the core.

フレームワーク群は nice で、helpful なものです。
もし誰かが、あなたが使うため学んでいるフレームワークを嘲笑したとしても、
それに聞く耳を持つ必要はありません。
あなたは正しい道のりにいるのです。
jQuery は JavaScript におけるコンテキストの重要性に関して、
どんな本やリファレンスのドキュメント
よりも多くの人を educate したとわたしは確信しています。
After you've selector'd your face off, dive deeper into the core.


Install Firefox and install Firebug. I still think Firebug is the best setup. Webkit is
catching up. Watch the introductory video on the Firebug site to see how it works. As my
friend and colleague Leevi Graham said “Firebug… still keeping firefox relevant”
(source). A new version just arrived.

Firefox をインストールし、さらに Firebug をインストールしましょう。
わたしは今でも Firebug が best setup であると確信しています。
Webkit は catching up です。


Mozilla, to their credit, still has one of the best online documentation sites for
JavaScript. It should be your reference.

Mozilla は今でも JavaScript について one of the best
なオンラインドキュメントサイトを持っています。
それはあなたのリファレンスとすべきでしょう。

Learn JavaScript. It's more important than any other language you're thinking of.
JavaScript を学びましょう。
JavaScript はあなたが考えているどの言語よりも重要なものなのです。

You Must Learn JavaScript : programming

■_

■_

「人月の神話」の新装版はあったけど、「デザインのためのデザイン」がなかったので しょんぼりんぐ。同時発売と思ってたのににいに。


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

ホームへ


KIMURA Koichi (木村浩一)
リンクはご自由に

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