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

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

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

ホームへ

2010年07月20日

■_

あぢー

■_ 0.1+0.1+...

んと、言語、処理系に関わらずほぼすべてのもので同じ結果になるんじゃないかと思います。 いまどきは IEEE 754でライブラリ丸投げな感じでしょうから。 とはいえ最下位桁(とさらにその下の桁)の扱いによって違いが出たりするんですが。

Hena Hena Nikki ~悔い倒れの日々~(2010-07-16)
* [computer] 浮動小数点数のちょっとしたクイズ

へるみさんの日記の記事。 GNU Emacs 環境でどうなるのかなと思い、試してみた。

(emacs-version)
=> "GNU Emacs 22.3.2 (i486-apple-darwin10.4.0, Carbon Version 1.6.0 AppKit 1038.32)
    of 2010-07-17 on hogehoge.local"

(format "%.17f" 0.1)
=> "0.10000000000000001"

(let ((i 0) (n 0.0))
  (while (< i 10)
    (setq n (+ n 0.1)
          i (+ i 1)))
  (format "%.17f" n))
=> "0.99999999999999989"

というわけで、同じだった。 ちなみに Ruby でも同じ。

(let ((i 0) (n 0.0))
  (while (< i 10)
    (setq n (+ n 0.1)
          i (+ i 1))
    (insert (format "%d\t%.17f\n" i n))))
=> nil
1       0.10000000000000001
2       0.20000000000000001
3       0.30000000000000004
4       0.40000000000000002
5       0.50000000000000000
6       0.59999999999999998
7       0.69999999999999996
8       0.79999999999999993
9       0.89999999999999991
10      0.99999999999999989

こちらは木村さんの記事のマネ。 ふむ…。 

解説しよう!(笑) 仮数部を二進数にするとこんな感じになります。↓ 指数部は今回脇役なので十六進で。

0.10000000000000001
+ 3fb 1.1001:10011001:10011001:10011001:10011001:10011001:10011010

0.1 はこうなります。 とはいえ最後は打ち切っているだけで本来はずっと続くのは 改めて言うまでもないですね。 で、これに同じく0.1を足します

+ 3fb 1.1001:10011001:10011001:10011001:10011001:10011001:10011010
+ 3fb 1.1001:10011001:10011001:10011001:10011001:10011001:10011010

+ 3fc 1.1001:10011001:10011001:10011001:10011001:10011001:10011010

これが 0.2 です。結果として仮数部のパターンは変わらずに 指数部が1だけ変わります(要するに全体が2倍になった)。 さらに繰り返します。


+ 3fc 1.1001:10011001:10011001:10011001:10011001:10011001:10011010
+ 3fc 0.1100:11001100:11001100:11001100:11001100:11001100:11001101:0
↓
0.30000000000000004
+ 3fd 1.0011:00110011:00110011:00110011:00110011:00110011:00110100

加算の前に桁をそろえるために指数部の値を変えて 仮数部もずらしていることに注意。

+ 3fd 1.0011:00110011:00110011:00110011:00110011:00110011:00110100
+ 3fd 0.0110:01100110:01100110:01100110:01100110:01100110:01100110:10
↓
0.40000000000000002
+ 3fd 1.1001:10011001:10011001:10011001:10011001:10011001:10011010
+ 3fd 0.0110:01100110:01100110:01100110:01100110:01100110:01100110:10
      1.1111:11111111:11111111:11111111:11111111:11111111:11111110:10
↓
0.50000000000000000
+ 3fe 1.0000:00000000:00000000:00000000:00000000:00000000:00000000

ここまででめでたく 0.5 となりました。0.4 + 0.1 の結果が 0.5 とは微妙に違っていることに注意してください。 これは、最後にはみ出たビットを0捨1入したりした結果、 「たまたま」そうなったということです。 さらに続けると、

0.50000000000000000
+ 3fe 1.0000:00000000:00000000:00000000:00000000:00000000:00000000
+ 3fe 0.0011:00110011:00110011:00110011:00110011:00110011:00110011:010

0.59999999999999998
+ 3fe 1.0011:00110011:00110011:00110011:00110011:00110011:00110011
+ 3fe 0.0011:00110011:00110011:00110011:00110011:00110011:00110011:010

0.69999999999999996
+ 3fe 1.0110:01100110:01100110:01100110:01100110:01100110:01100110
+ 3fe 0.0011:00110011:00110011:00110011:00110011:00110011:00110011:010

0.79999999999999993
+ 3fe 1.1001:10011001:10011001:10011001:10011001:10011001:10011001
+ 3fe 0.0011:00110011:00110011:00110011:00110011:00110011:00110011:010

0.89999999999999991
+ 3fe 1.1100:11001100:11001100:11001100:11001100:11001100:11001100
+ 3fe 0.0011:00110011:00110011:00110011:00110011:00110011:00110011:010
      1.1111:11111111:11111111:11111111:11111111:11111111:11111111:010

0.99999999999999989
+ 3fe 1.1111:11111111:11111111:11111111:11111111:11111111:11111111

足される側の値が大きくなっているために、0.1を加算するときに 仮数部をシフトしている量が大きくなっていることに注目してください。 その結果、0捨1入しても繰り上がりが発生せずに加算結果が1にならなくなってしまっている というわけです。丸めの位置やよけに保持する桁の数によっては 丸めによって最終結果が1になったりする場合もありますので、 たとえば %.10f あたりでは一見正しく合計が求まったように見えたりすることもあると いうわけです。

こういうことがあるので、数値の加算をするときは小さい方から足しこんでいけ という言い伝えがあったりしたわけですね。

説明の仕方が違っても、この程度の内容は基本情報の参考書にもあるはずですよ~♪

■_ 本日の巡回から

■_ next

これはまあ知らないと面食らうだろうし、この書き方がそれに輪をかけているかな。

What is this Ruby syntax? - Stack Overflow

I recently ran into code that looks like this:

 next {
          'foo'         => bar,
          'foobar'      => anotherbar,
      }

At first it looks like a simple hash, but there is no assignment to next. Next in this 
case looks like a reserved Ruby keyword. What does this code do?
next is typically used in cases like iterating through a list of files and taking 
action (or not) depending on the filename.

next can take a value, which will be the value returned for the current iteration of 
the block.

  sizes = [0,1,2,3,4].map do |n|
    next("big") if n > 2
    puts "Small number detected!"
    "small"
  end

  p sizes

Output:

  Small number detected!
  Small number detected!
  Small number detected!
  ["small", "small", "small", "big", "big"]

from http://ruby-doc.org/docs/keywords/1.9/


■_ Introduction to Perl 6

Introduction to Perl 6 - screencast
Introduction to Perl 6 - screencast

Published on 2010.07.19 at 17:07:33 Bookmark and Share


Code examples:

  use v6;
  say "Hello world";


  use v6;
  my $name = prompt "Please type in your name: ";
  say "Hello $name, how are you?";


  use v6;
  my $year = prompt "When were you born? ";
  if $year > 1987 {
    say "You are younger than Perl by { $year - 1987 } years";
  }


  use v6;
  my $year = prompt "When were you born? ";
  if 1995 > $year > 1987 {
    say "You are younger than Perl 1 but older than Perl 5";
  }



  use v6;
  my $luck = prompt "What is your lucky number? ";
  if $luck == 3 or $luck == 7 or $luck == 13 {
    say "Oh, that's like mine";
  }

  if $luck == 3|7|13 {
    say "Oh, that's still like mine";
  }


use v6 ってあるのは?

2010年07月19日

■_

・セミ
鳴いていました。種類は何だったのだろう。 アブラゼミにはちょっと早いような気もするけど

仕込みの途中で投げ出すネタ多数。 誰かやる気の元を以下略。

・これはひどい
Software Desgin誌の最新号(2010年8月号)なんですが、
Software Design 2010年8月号から
誰だよニクラウス・ヴィルドって… 二回出てきているから単なる入力間違いとも思えないし、 なにより編集者もこれを見落としてたってことですよね。 まあ編集さんがこの道に明るいのを期待してはいけないのかもしれませんが、 にしてもどうにかならんかったのかと。

Modulaー2入門: 紀伊國屋書店BookWeb ニクラウス・ヴィルト - Wikipedia ニクラウス・ヴィルト (Niklaus Wirth, 1934年2 月15日 - )はスイスの計算機科学者。 プログラミング言語Pascal、Modula-2などの開発や、ソフトウェア工学分野の開拓的研究で知られる。

■_ int *hoge

これまた良くある話題から。

Pointer syntax in C: why does * only apply to the first variable? - Stack Overflow

The following declaration in C:

int* a, b;

will declare a as type int* and b as type int. I'm well aware of this trap, but what I 
want to know is why it works this way. Why doesn't it also declare b as int*, as most 
people would intuitively expect? In other words, why does * apply to the variable name, 
rather than the type?

Sure you could write it this way to be more consistent with how it actually works:

int *a, b;

However, I and everyone I've spoken to think in terms of a is of type "pointer to int",
rather than a is a pointer to some data and the type of that data is "int".

Was this simply a bad decision by the designers of C or is there some good reason why 
it's parsed this way? I'm sure the question has been answered before, but I can't seem 
to find it using the search.

int * までで「型」と解釈してくんないの~ ということですが。


C declarations were written this way so that "declaration mirrors use". This 
is why you declare arrays like this:

int a[10];

Were you to instead have the rule you propose, where it is always

type identifier, identifier, identifier, ... ;

...then arrays would logically have to be declared like this:

int[10] a;

which is fine, but doesn't mirror how you use a. Note that this holds for functions, 
too - we declare functions like this:

void foo(int a, char *b);

rather than

void(int a, char* b) foo;

In general, the "declaration mirrors use" rule means that you only have to 
remember one set of associativity rules, which apply to both operators like *, [] and 
() when you're using the value, and the corresponding tokens in declarators like *, [] 
and ().

C is a very different language from Java. A Java array is totally different. 
The array variable holds only a modifiable reference to an array. A C array variable 
is the array. Another example of "declaration mirrors use" is a declaration 
of a function returning a pointer to an integer. int *foo(int bar);. This reflects the 
fact that *foo(3) is an int. I suggest you read K&R C 2nd ed., where this is 
explained.



There's a web page on The Development of the C Language that says, "The syntax of 
these declarations reflects the observation that i, *pi, and **ppi all yield an int 
type when used in an expression." Search for that sentence on the page to find 
the relevant section that talks about this question.


There may be an additional historical reason, but I've always understood it this way:

One declaration, one type.

If a, b, c, and d must be the same type here:

int a, b, c, d;

Then everything on the line must an integer as well.

int a, *b, **c, ***d;

The 4 integers:

   1. a
   2. *b
   3. **c
   4. ***d

It may be related to operator precedence, as well, or it may have been at some point 
in the past.

The * modifies the variable name, not the type specifier. This is mostly because of 
the way the * is parsed. Take these statements:

char*  x;
char  *x;

Those statements are equivalent. The * operator needs to be between the type specifier 
and the variable name (it is treated like an infix operator), but it can go on either 
side of the space. Given this, the declaration

int*  a, b;

would not make b a pointer, because there is no * adjacent to it. The * only operates 
on the objects on either side of it.

Also, think about it this way: when you write the declaration int x;, you are 
indicating that x is an integer. If y is a pointer to an integer, then *y is an 
integer. When you write int *y;, you are indicating that *y is an integer (which is 
what you want). In the statement char a, *b, ***c;, you are indicating that the 
variable a, the dereferenced value of b, and the triply-dereferenced value of c are 
all of type char. Declaring variables in this way makes the usage of the star operator 
(nearly) consistent with dereferencing.

I agree that it would almost make more sense for it to be the other way around. To 
avoid this trap, I made myself a rule always to declare pointers on a line by 
themselves.

This is quite subjective, but I would go with the bad decision option.

Obviously, they did not think int* was data type. They decided that int was data type 
and pointers were just a type of access to data of some type. So, int *a is an int 
accessed through a pointer and int b is and int accessed directly.

That may look like a big mistake now, but have in mind that C is 40 years old! Those 
were different times.

C のこれとか、FORTRAN の空白無視の字句解析とか今の視点で見ると かえってそう実装する方が大変なような気がする。

■_ 十周年つーてもなあ


Journal of masak (6289)
Sunday July 18, 2010 03:34 PM
Happy 10th anniversary, Perl 6
[ #40451 ]

On this date exactly 10 years ago, Jon Orwant threw coffee mugs against a wall during 
a meeting. Wikipedia chronicles the announcement of Perl 6 as being on July 19 ten 
years ago... but the throwing of mugs on the 18th can be said to spark the birth of 
Perl 6.


Why did he throw mugs? Larry Wall's own explanation covers it in sufficient detail:

(略)

By now, Perl 6 has a 10-year history. I thought I'd spend the rest of the blog post 
recounting it from (mostly) my perspective. With this I hope I will manage to convey 
not only the actual sequence of events, but also some of my enthusiasm about the 
project, and why I think Jon Orwant's broken mug kicked off one of the coolest 
projects in modern programming language history.

The early years

Perhaps you've heard about the RFC process. This was right at the beginning of Perl 
6's life, when even Larry Wall wasn't sure which direction to take Perl 6, and a 
system was created wherein people could send in their proposals for language features. 
Something on the order of 20 or 30 RFCs were excpected before the closing date.

361 RFCs were sent in.

(略)

In the end, Larry Wall took on the work of triaging the RFCs and distilling them into 
a coherent whole. He did this in the form of Apocalypses, which collected the RFCs in 
different categories and commented on them one by one. The RFCs were either accepted 
with different amounts of caveats, or rejected. The Apocalypse numbers were based on 
different chapters in the Camel book; for example, chapter 3 of that book describes 
operators, so Apocalypse 3 talks about operators in Perl 6.

Here are all the Apocalypses that were published:

    * Apocalypse 1, May 2001
    * Apocalypse 2, May 2001
    * Apocalypse 3, Oct 2001
    * Apocalypse 4, Jan 2002
    * Apocalypse 5, Jun 2002
    * Apocalypse 6, Mar 2003
    * Apocalypse 12, Apr 2004

In other words, the whole period 2001-2004 can be seen as the period when Perl 6 was 
still being distilled from the various wishes people had about it.

Along with the Apocalypses were published same-numbered Exegeses, by Damian Conway who 
also had a central role in designing Perl 6. Where the Apocalypses were geared towards 
explaining language decisions for and against features, the Exegeses set out to 
showcase the new combinations of features, and to explain to Perl 5 programmers the 
improvements introduced in Perl 6.

(略)

Rakudo Star: Perl 6 takes off

Ok, so this part of history hasn't happened yet. But it's about to. On July 29, the 
Rakudo team is releasing Rakudo Star, the first distribution of Rakudo Perl, a Perl 6 
implementation. (Info links here, here, and here.)

I find it quite fitting that 10 years and a couple of days after the Jon Orwant mug 
that started it all, the Perl 6 people come forth and say "Here. We made this, 
and it's at a first stage of ready. We've been tinkering with it for quite some time, 
fixed a lot of bugs and polished the pearl to a relative shine. We'd like you to try 
it out and make something cool with it."

I, and many people with me, have been excited about this porcelain descendant for many 
years now. It's time to let a bigger circle of people in, and let them get excited as 
well.

ああ、Apocalypse とかもうそんな前の話なのねえ。

■_ 本日の巡回から

■_ 非推奨

非推奨のモジュールに関する記述を「Perlモジュール徹底解説」に追加しました - サンプルコードによるPerl入門



Perlモジュール徹底解説 - サンプルコードによるPerl入門
非推奨のモジュール

    * encoding - 公式に非推奨。ソースコードはUTF-8で書いて、utfプラグマを使いましょう。
    * Jcode - 公式に非推奨。文字列を扱うにはEncodeモジュールを使用します。
    * bytes - 公式に非推奨。実際にEncodeモジュールのencode関数でエンコードしてから長さを調べるようにします。
    * vars - 古い。ourでパッケージ変数を宣言するのと同じ効果を持ちます。今ならourを使ってパッケージ変数を宣言しましょう。
    * Class::ISA - 公式に非推奨。コアモジュールから取り除かれます。

bytes も非推奨なのかあ。 Class::ISA って何に使うやつだっけ(^^;

NAME
    Class::ISA -- report the search path for a class's ISA tree

SYNOPSIS
      # Suppose you go: use Food::Fishstick, and that uses and
      # inherits from other things, which in turn use and inherit
      # from other things.  And suppose, for sake of brevity of
      # example, that their ISA tree is the same as:

      @Food::Fishstick::ISA = qw(Food::Fish  Life::Fungus  Chemicals);
      @Food::Fish::ISA = qw(Food);
      @Food::ISA = qw(Matter);
      @Life::Fungus::ISA = qw(Life);
      @Chemicals::ISA = qw(Matter);
      @Life::ISA = qw(Matter);
      @Matter::ISA = qw();

      use Class::ISA;
      print "Food::Fishstick path is:\n ",
            join(", ", Class::ISA::super_path('Food::Fishstick')),
            "\n";

    That prints:

      Food::Fishstick path is:
       Food::Fish, Food, Matter, Life::Fungus, Life, Chemicals

DESCRIPTION
    Suppose you have a class (like Food::Fish::Fishstick) that is derived,
    via its @ISA, from one or more superclasses (as Food::Fish::Fishstick is
    from Food::Fish, Life::Fungus, and Chemicals), and some of those
    superclasses may themselves each be derived, via its @ISA, from one or
    more superclasses (as above).

    When, then, you call a method in that class ($fishstick->calories), Perl
    first searches there for that method, but if it's not there, it goes
    searching in its superclasses, and so on, in a depth-first (or maybe
    "height-first" is the word) search. In the above example, it'd first
    look in Food::Fish, then Food, then Matter, then Life::Fungus, then
    Life, then Chemicals.

    This library, Class::ISA, provides functions that return that list --
    the list (in order) of names of classes Perl would search to find a
    method, with no duplicates.

FUNCTIONS
(略)

ふむ。

2010年07月18日

■_

・500越えたか
Zed Shaw on C++ : programming

しかし日曜の夜がなかなかつらい。

■_ 質問者おいてきぼり

これもまたよくあるパターン


ゲームの開発言語(1980~2010年)(1/3) | OKWave

ゲームの開発言語って何を使っている(いた)のでしょうか?
マシン語? アセンブラ? コボル? C?

インベーダーの時はハードウェアを造って、マシン語で造ったそうですが、
過去~現代まで、どの言語を使っている事が多かったのか知りたいです。

開発経験のある方、ご存知の方、教えてください。
特定の時代についてだけ知っている方でも結構です。

お願い致します。

「ゲームの」というくくりでは結構範囲が広いような。

ANo.13

>そもそも洋ゲーもWin98のころOpenGLの物がまだ多かった記憶もあるんですが、
Win98の頃はVoodooのGlideとMSのWindows用の汎用APIのDirectX(3D)がって時代。
OpenGLはどちらかというとビデオカード側が追いついて無くて個人向けのGPUでは
まだまだ使えた物ではなかった。
OpenGLとDirect3Dの溝が縮んで個人向けのGPUでまともに使えるようになってきたのは
もう少し後。
それとWindowsゲームのいくつかは描画にDirect3DかOpenGLのどちらかを
選択できるようになっているゲームは今の方が多いと思う。
後、DirectXは3D以外の部分もカバーする総合的なAPIの集まりですから
3D部分はOpenGLでもサウンドや入力インタフェースなどはDirectXが利用されるって事は
昔からよくありますね。
ついでに言うとDirectXが出る前(ででもまともに使えるようになるまで)は
各ビデオカードメーカが独自にAPIを実装していましたね。
Edge 3Dはその筆頭でした。
その後にはPowerVRなんかもありました。PowerVRはDirect3Dに対応したけどEdge 3Dは非対応。

>そのとおりですよ。他の意味に取れる書き方、私がしましたでしょうか?

>MFCを使ったアプリの方は早々とC++に移行していたと思いますけどね
この書き方だとMFCがすでにあって別の言語で使われていたのがC++に移行したと読める。
あえて書くなら
WindowsのAPIを使ったアプリは早々にMFCを利用するC++に移行したと・・・・
と書かないと駄目ですよね。

>C++でも書けるというコト?
>C++で書く事が前提というコト?
オブジェクト指向を意識した作りって事。
もちろんC++でもCでもWin32APIは使えますよ。

ANo.12

>>zwiさんはエロゲーメーカのひとなのでしょうか?それとも国内で希少な一般ゲームの開発者なんですかね?

家庭用ゲーム機の人です。
家庭用ゲーム機では、それほど早くからC++は使ってませんねぇ。
CPUでもメモリでも無理がありましたから。
Windowsのゲームの方もベターC言語(最低限のC++記述でクラスを使わない書き方)で初期の頃は記憶があるんですけどねぇ。
そもそも洋ゲーもWin98のころOpenGLの物がまだ多かった記憶もあるんですが、

>いやいやMFCはWin32APIをラッパしたC++向けのクラスライブラリなんだからC++で使う物だよ。
そのとおりですよ。他の意味に取れる書き方、私がしましたでしょうか?
あんまり上から目線で書かれると良い気がしませんね。

>>Win32APIもC++で書かれることを前提とした作りになっているね。

昔からのインターフェイスを引きずっているから、C++と言い切るのは辛い気がするんですが。

ANo.11

ちょっと気になってるのですが、

>>Win32APIもC++で書かれることを前提とした作りになっているね。

これ、厳密にはどのような意味なのでしょう。
C++でも書けるというコト?
C++で書く事が前提というコト?
ANo.10

>すいませんが、私はゲーム業界にいたのですが、ゲーム業界の方ですか?
ゲームではないプログラマです。
でこの頃やっていたゲームは洋ゲーメインでやっていましたね。
この頃(Win9x時代)のWindowsの国内ゲームはエロゲーがほとんどで
国内ではファルコム、工画堂、アートディンク、光栄くらいで
カプコンやセガはビデオカードについていバンドルソフトって感じだけでしたからね。
(コナミあたりはMSX時代はPCで頑張っていたけどWindows時代は国内ではやらなくなって海外のみで頑張っているね。)
zwiさんはエロゲーメーカのひとなのでしょうか?それとも国内で希少な一般ゲームの開発者なんですかね?
エロゲーならC++使うまでもなくてその当時ならC言語で十分だったのかも。(DirectX必要もなくGDIで十分でしょうから)

>MFCを使ったアプリの方は早々とC++に移行していたと思いますけどね。
いやいやMFCはWin32APIをラッパしたC++向けのクラスライブラリなんだからC++で使う物だよ。
で上で書いたように洋ゲーやろうとしたときにMFCのdllがないとか怒られたこと時々あったからね。

ANo.9

>元々C++で書かれることを前提としたDirectXの構造。
>Win32APIもC++で書かれることを前提とした作りになっているね。
>まぁCでもかけないことはないがスマートではないというか

現実にはC++で書かれているゲームは国内では少なかったと記憶してるんですけど。
すいませんが、私はゲーム業界にいたのですが、ゲーム業界の方ですか?

MFCを使ったアプリの方は早々とC++に移行していたと思いますけどね。

ANo.8

>DirectXの利用とC++の本格的な利用は時代が一致していると思えませんが、どうなのでしょう?
元々C++で書かれることを前提としたDirectXの構造。
Win32APIもC++で書かれることを前提とした作りになっているね。
まぁCでもかけないことはないがスマートではないというか

ANo.7

>Windowsでのゲーム開発はWin95以降のDirectXがひとつのターニングポイント。

DirectXの利用とC++の本格的な利用は時代が一致していると思えませんが、どうなのでしょう?
最初の頃はC言語もどきの記述で書いていたゲームメーカーも多い様な・・・。


ANo.6

mudamuda546

>Windows時代になってC++が使われだしたのは2000年を超えてからだと思います。
いや2000年前からC++だったでしょう。
Windowsでのゲーム開発はWin95以降のDirectXがひとつのターニングポイント。
それ以前のWin3.1時代まではWinG。

ANo.5

とりあえず家庭用ゲーム機は、ファミコン~スーパーファミコンはアセンブラでの開発です。

サターン、PS1、N64辺りからCPUの性能が上がったのでC言語で本格的に作られる様に
なって来ました。Xbox360、PS3だとC++も実用レベルで使えるようになりましたね。

パソコンだと、X1、PC8801、MSX時代はアセンブラです。PC9801はC言語、Windows時代になって
C++が使われだしたのは2000年を超えてからだと思います。

ファミコン以前は詳しくないのですが、いつハンドアセンブルのマシン語からアセンブラ利用に
変わったかは不明です。

お礼

回答ありがとうございます。
やはりアセンブラ使いの方が開発していたんですね。
(スーパーメトロイドを)

ANo.4


80年代のPCゲームだと、一部のアドベンチャーゲーム(BASICで書いてあるものも結構あった)以
外はマクロアセンブラかマシン語モニタでニーモニックを直接打ち込むというのがほとんどです。

当時のC言語のコンパイラ(16bitだとLattice-C、8bitだとBDS-Cが主流、マイクロソフトのCは当
初、LatticeのOEMだった)がはき出すコードでは、当時のCPUにとっては重すぎます。まあ、今の
コンパイラが出すコードはもっと重いけど、CPUが格段にスピードアップし、メモリ空間も広大
になっているので問題にならないだけです。

ファミコンだと任天堂が用意する8bit-PCの開発マシンがあって、そこでアセンブラで開発しま
す。この時代はCPUだけではなく、使用できるメモリ空間が狭く、ROMの容量も限られていたので、
コンパイラの冗長なコードではROMにおさまりません。

SFCの頃だと環境も整ってきたので、高級言語も使われています。また、プレステは黒ステには
開発環境が付属していますが、これは高級言語だったそうです(どこのものかは不明)
お礼

回答ありがとうございます。

任天堂はアセンブラの開発環境を用意していたということですね。
C言語のコンパイラの変換も上手くなかったと。(えっ!今もですか?)

仕様を見る限り、このメモリ容量でどうやって造ったのか不思議です。
職人芸だったんですかね。

SFC時代だとSONYのワークステーションを使っていたみたいですが、
使いづらかったみたいですね。
(結局SONYは任天堂と喧嘩して独自でCDゲーム機を作りましたが…)



80年代にはC言語でもう書かれていたと思いますよ。
C言語がメインで高速動作させたい所やハードを直接叩いた方が効率が良い場所はアセンブリで書かれていたと思われます。

>マシン語とアセンブラは同じ意味です。
違います。別です。
アセンブリ言語ね。アセンブラは翻訳機(コンパイル型言語のコンパイラみたいな物)の事。
だからマシンごとアセンブラを比較して同じと言うのは変だし
マシン語とアセンブリ言語を比べてもマシン語は0と1の言語。
アセンブリ言語は0と1で書かれていた部分を記号化してわかりやすくしてある。

投稿日時 - 2010-07-11 18:35:27
お礼

回答ありがとうございます。

やはり速度が優先される箇所はアセンブラですよね。
昔からゲームにもCは使われていたんですか、息が長いですね C言語。


ANo.2

1です。すいません訂正します。
マシン語とアセンブラが同じと書きましたが、私の勘違いでした。

1994年ならC言語はありましたね。
そのゲームが何で作られているのかは知りませんけど、スーパーファミコンならアセンブラかな。

お礼

回答ありがとうございます。

C言語自体は80年時点で既にあったと思います。
スーファミ時代のゲーム開発においてもアセンブラだったのですかね。

ANo.1

昔はC言語なんてありませんでしたから、アセンブラですね。
マシン語とアセンブラは同じ意味です。
Cが出てきてからはCとかC++が増えてきたと思う。
PC用ならCが出てくる前はBASICもあったでしょう。
最近は知りません。

ところであなたのいうゲームって、PCゲーム? アーケード? 家庭用ゲーム機?

補足

質問内容に不備がありました。申し訳ございません。

質問するきっかけはスーパーメトロイド(SFC/1994)を遊んでいた時に、
「そういえば94年ってWindows95よりも前じゃん」って思って、
当時どういう開発環境だったんだろう→何の言語を使っていたんだろう
というものでした。

ゲームは、PCでも、アーケードでも、家庭用でも構いません。

いつ頃にどの言語を使っていたとか、使っているソフトハウスが多かったと
いうことが知りたいです。

お願い致します。

なにやってんだかw

■_ dereference

決定打がないんだよねえ。この訳語。


なぜポインタで引っかかる人が多いのか c
373 デフォルトの名無しさん [] 2010/07/17(土) 08:34:26 ID: Be:
    ぬるぽ 

374 デフォルトの名無しさん [sage] 2010/07/17(土) 11:21:28 ID: Be:
    ポインタはすんなり理解できたけど「逆参照」だけはずっと意味不明だった。
    なんだよこの訳語は。 

375 デフォルトの名無しさん [sage] 2010/07/17(土) 11:57:59 ID: Be:
    デリファレンスでいいだろ 

376 デフォルトの名無しさん [sage] 2010/07/17(土) 12:28:15 ID: Be:
    俺なら訪問と訳して全国のポインタ脱落組を3000人くらい救っていたな。 

381 デフォルトの名無しさん [] 2010/07/17(土) 21:35:13 ID: Be:
    >>373
    Javaじゃないからガッしてくれないよ 

382 デフォルトの名無しさん [sage] 2010/07/17(土) 22:55:15 ID: Be:
    スマポで引っかかりました。

    詳細は以下から。


    class Dog : public IAnimal
    というクラスがあって、これをスマポでインスタンスを生成すると
    void fanc(IAnimal animal)
    に入れられなくなります。
    どう書けばいいんですか? 

383 デフォルトの名無しさん [sage] 2010/07/17(土) 22:57:19 ID: Be:
    >>380
    間接参照の概念さえあれば大体何がやりたいのかは分かる 

384 デフォルトの名無しさん [sage] 2010/07/17(土) 23:00:17 ID: Be:
    >>382
    そのスマートポインタをデリファレンスすれば委員で内科医?
    言語が判らんから具体的には答えられないが。 

385 デフォルトの名無しさん [sage] 2010/07/17(土) 23:12:08 ID: Be:
    >>382
    アセンブラやればわかるようになる 

386 デフォルトの名無しさん [sage] 2010/07/17(土) 23:12:10 ID: Be:
    C++(VC10)です

    ↓こういうふうに書いたら駄目なんですか?
    何で入らないのかわかりません
    std::shared_ptr<IAnimal> dog_ptr(new Dog()); 

387 デフォルトの名無しさん [sage] 2010/07/17(土) 23:16:15 ID: Be:
    >>386
    ポインタを実態を必要とする関数に渡したいなら、>384の言うように逆参照すればいい。
    もしかして、単項*演算子も知らないのか? 

388 デフォルトの名無しさん [sage] 2010/07/17(土) 23:18:59 ID: Be:
    >>382
    auto_ptr<Dog> p(new Dog());
    func(*p); 

389 デフォルトの名無しさん [sage] 2010/07/17(土) 23:54:24 ID: Be:
    うーん何言ってるかよくわからないのはポインタを避けて通ってるからなのですかね

    とりあえず.get()って付けたら入りました
    func(dog_ptr.get());
    全く意味わからないですが急場しのぎって感じで満足してます
    やっぱもってるなってことで 

390 デフォルトの名無しさん [sage] 2010/07/18(日) 00:01:10 ID: Be:
    その程度で満足できるんなら勝ちでいいよ 

391 デフォルトの名無しさん [sage] 2010/07/18(日) 00:37:28 ID: Be:
    >>389
    メモリの絵を描いて理解するんだ。 

392 デフォルトの名無しさん [sage] 2010/07/18(日) 00:54:50 ID: Be:
    たとえばK&Rは第5章がポインタで第6章が構造体だが
    ポインタは避けるが構造体 (クラス) は避けないって感覚は異常だよ
    ふつうに考えるとポインタよりもクラスのほうが難しいはずだよ

    なぜか知らないがクラスが難しいと言うのは恥ずかしい
    ポインタが難しいと言うのは恥ずかしくないという空気に支配されている気がする 

393 デフォルトの名無しさん [sage] 2010/07/18(日) 02:43:01 ID: Be:
    知らんがな 

394 デフォルトの名無しさん [sage] 2010/07/18(日) 03:00:05 ID: Be:
    何かあるとK&Rという空気に支配されている気がする 

396 デフォルトの名無しさん [sage] 2010/07/18(日) 07:46:40 ID: Be:
    >>392
    ポインタのほうが構造体よりずっと難しい
    ポインタは存在しないオブジェクトを指す可能性があるし、表記が複雑になる
    構造体のほうが難しいと勘違いするのはポインタを理解していないからだ

397 デフォルトの名無しさん [sage] 2010/07/18(日) 11:21:38 ID: Be:
    逆をいえば、存在しないオブジェクトを指さなくて構文が複雑にならない
    ようなポインタなら問題ないんだよな
    JavaやPythonの間接参照に引っかかるようなヤツはそうそうおるまい 

意味している動作を考えると「訪問」も悪くないんだけどねえ。

■_ もうぜんぜん進みませんがな


An Interview with the Old Man of Floating-Point

An Interview with the Old Man of Floating-Point
(浮動小数点数の Old Man へのインタビュー)

Reminiscences elicited from William Kahan by Charles Severance

20 Feb. 1998

This interview underlies an abbreviated version to appear in the March 1998 issue of 
IEEE Computer.

Introduction

If you were a programmer of floating-point computations on different computers in the 
1960's and 1970's, you had to cope with a wide variety of floating-point hardware. 
Each line of computers supported its own range and precision for its floating point 
numbers, and rounded off arithmetic operations in its own peculiar way. While these 
differences posed annoying problems, a more challenging problem arose from 
perplexities that a particular arithmetic could throw up. Some of one fast computer's 
numbers behaved as non-zeros during comparison and addition but as zeros during 
multiplication and division; before a variable could be used safely as a divisor it 
had to be multiplied by 1.0 and then compared with zero. But another fast computer 
would trap on overflow if certain of its numbers were multiplied by 1.0 although they 
were not yet so big that they could not grow bigger by addition. ( This computer also 
had nonzero numbers so tiny that dividing them by themselves would overflow.) On 
another computer, multiplying a number by 1.0 could lop off its last four bits. Most 
computers could get zero from X - Y although X and Y were different; a few computers 
could get zero even though X and Y were huge and different.

もしあなたが 1960 年代や 1970 年代にいて複数の異なるコンピューター上で浮動小数点計算を
するプログラマーであったなら、あなたは浮動小数点ハードウェアの多くのバリエーションを 
cope (うまく扱う、対抗する) しなければならなかったでしょう。コンピューターのライン毎に
浮動小数点数に対して固有の範囲と精度をサポートしていて、独自の方法による算術演算の丸め
(rounded off arithmetic operations) を持っていました。こういった違いが問題を無視するよ
うな態度を取っている一方で、より challenging な問題が、特定の算術演算によって引き起こ
される可能性のあるperplexities (問題を複雑にするもの、当惑させるもの) から起こっていま
した。高速コンピューターの中には、比較や加算のときにはゼロでないように振舞うのに乗除算
のときにはゼロのように振舞う数値を持つものがありました。そういったコンピューターでは、
ある変数を divisor (除数) として安全に使えるようにするのにその変数に 1.0 を乗じてから
ゼロと比較するといったことをしなければなりませんでした。しかし別の高速コンピューターで
は、一部の数値に 1.0 が乗ぜられたときに、その数値が加算によって grow bigger できないよ
うな大きな数値でない場合であってさえオーバーフローがトラップされることがありました(こ
のコンピューターはまた、それで除算を行うとオーバーフローを起こすようなゼロではない非常
に小さな数値を持っていました)。別のコンピューター上では 1.0を乗じたときに最後の 4ビッ
トが lop offする可能性がありました。大部分のコンピューターでは相異なる数値である X と 
Y に対してX-Y がゼロになる可能性がありましたが、極少数のコンピューターで非常に大きく相
異なる値 X と Y のときに X -Y がゼロとなる場合がありました。


Arithmetic aberrations like these were not derided as bugs; they were 
"features" of computers too important commercially for programmers to ignore. 
Programmers coped by inventing bizarre tricks like inserting an assignment " X = 
(X + X) - X " into critical spots in a program that would otherwise have 
delivered grossly inaccurate results on a few aberrant computers. And then there were 
aberrant compilers ... .

このような arithmetic aberrations (算術的欠陥?) はバグとして derided (嘲る、嘲笑する) 
されることはありませんでした。それは、プログラマーが無視するにはコンピューターにとって
商業的に重要すぎる“機能”(features) だったのです。プログラマーたちは、プログラムのク
リティカルスポットに " X = (X + X) - X " のような代入を挿入するといった奇妙
なトリックを編み出してコーディングしました。そうしてもなお、異常なコンパイラーが存在し
ていたのです…


"Reliable portable numerical software was becoming more expensive to develop than 
anyone but AT&T and the Pentagon could afford. As microprocessors began to 
proliferate, so did fears that some day soon nobody would be able to afford it."

"信頼性が高く (Reliable)、 移植性のある (portable) numerical ソフトウェアはさらに高価な、
AT&Tとペンタゴン以外には開発することのできないようなものとなってしまいました。マイ
クロプロセッサーが激増 (proliferate) し始めたのと歩調を合わせて、そんなことができる人
が一人もいなくなる日がすぐにも訪れるだろうと恐れられていたのです。"


Some History (ちょっとした歴史)

(続く)

■_ 本日の巡回から

2010年07月17日

■_

・シグルイ
なんというかこう、ディレクターズカットの方のブレードランナーを思わせるというか(省略されました)

シグルイ終わるとあと読んでいるのはジャイアントロボくらいなんだけど、 それで毎月買うのもなんだなあ。どうしよ。

なつかしー。欲しいなあ。とちょっと思った(要財布と相談) リブギゴ続報! - CM'sのおもちゃ1000本ノック!

・RSBC
あー、また読みたくなってきた。 潜水艦群の攻撃をどうにかこうにしながら船団護衛を続けていくのがなんとも。 が、どこに埋もれているのやら(^^; 駆逐艦ベッドフォード 「われわれはあきらめない。誰も見捨てない。かれらはわれわれを信じている。 ならばその信頼にこたえねばならない。そう誓ったのだ。私も君も。 どうだ、思い出したか?よろしい、ならば義務を果たせ」

・連想配列→ハッシュ
連想配列 (associative array) がハッシュになった理由が書かれているものをようやく発見。 プログラミング Perl 改訂版(分冊になってない方の青いやつ)でした。 perldoc で読めるやつにもあったような気がするけど勘違いかも。
プログラミングPerl 改訂版
プログラミングPerl 改訂版

8p

ハッシュ: ハッシュ(hash)は、順序づけされていないスカラーの集合で、各スカラーに関連づけ
られた文字列によってアクセスされる。そのためハッシュは「連想配列」(associative array) 
と呼ばれることもある。しかし、これは怠惰なタイピストにとってタイプするのが面倒だし、頻
繁に使われるので、私たちはもっと短くて、ぴりっとした (snappy) 呼び名を付けることにした
のだ。「ハッシュ」という名前を選んだ別の理由は、中身が順序づけされていないことを強調す
るためである(ハッシュは、内部的にはハッシュ表を使って実装されている。ハッシュに値をど
んなにたくさん格納しても、動作が速いのは、ハッシュ表のおかげである)。

第三版では、この部分の記述はばっさり削られて短いものになっています。
プログラミングPerl〈VOLUME1〉
プログラミングPerl〈VOLUME1〉

■_ 初心者向け


推薦図書/必読書のためのスレッド 56 
927 デフォルトの名無しさん [sage] 2010/07/16(金) 23:52:25 ID: Be:
    まったくの初心者なんですが
    世界一わかりやすいCプログラミングの授業か
    やさしいC、どちらがいいでしょうか?

    評価的にはやさしいCですが
    世界一わかりやすいCプログラミングの授業の対話式の説明がすごくわかりやすいと思いました

    みなさまのご意見お待ちしてます 

928 デフォルトの名無しさん [sage] 2010/07/16(金) 23:54:46 ID: Be:
    二つ立ち読みして自分が好きそうな方でいいと思うよ 

929 デフォルトの名無しさん [] 2010/07/16(金) 23:55:28 ID: Be:
    あなたが分かりやすいと思ったのならそちらでいいと思います
    というかそのレベルならネットでいいと思います
    ちょっとセンスのある人ならあなたがどちらの本がいいか考えてる間に
    基本的なことはマスターしてしまうでしょう 

930 デフォルトの名無しさん [sage] 2010/07/16(金) 23:56:29 ID: Be:
    プログラミング言語Cでいいんじゃね 

931 デフォルトの名無しさん [] 2010/07/16(金) 23:57:44 ID: Be:
    >>928
    近場の本屋に両方置いてない
    前者はamazonの試し読みした
    だから、やさしいCがどんなのか一切分からない

    >>929
    ちょっとはやった
    今、条件分岐とかループ文 

932 デフォルトの名無しさん [sage] 2010/07/16(金) 23:58:37 ID: Be:
    前者を読んだことのある人がこのスレにいるのだろうか

    それはさておき自分を信じて好きな本を買ったらよろし
    もし買った本がトンデモだったとしても
    経験つんだり別のまっとうな本を読めば修正できるんだから 

933 デフォルトの名無しさん [] 2010/07/16(金) 23:58:45 ID: Be:
    >>930
    若干初心者には難しめらしいので敬遠してます。。。 

934 デフォルトの名無しさん [] 2010/07/17(土) 00:01:32 ID: Be:
    >>932
    なるほど
    いろんな意味での勉強のために前者買ってしょうかね。

    このスレ的にやさしいCはどうなんですか?

    あと、それを読了したあと
    実際プログラムを作っていくためのいい参考書有りますか? 

937 デフォルトの名無しさん [sage] 2010/07/17(土) 00:20:41 ID: Be:
    初心者向けにCのお薦めなら
    「実践Cプログラミング」なんだが、
    高いとか分厚いとか字が多いとイヤだとか思うなら、
    まあ好きなの読めば

    最近「簡単な本教えてください」みたいなコトを言う人に
    ちゃんと読めばわかりやすい本を教えても無駄だと思いはじめてしまって・・・

939 デフォルトの名無しさん [sage] 2010/07/17(土) 01:02:14 ID: Be:
    やさしい○○ってのは
    専門じゃない著者による量産シリーズだからな 

940 デフォルトの名無しさん [] 2010/07/17(土) 01:10:26 ID: Be:
    やさしい~のソース独特じゃない?
    書いててイライラするんだが 

941 デフォルトの名無しさん [sage] 2010/07/17(土) 01:14:57 ID: Be:
    >>940
    具体的に言ってみろよ 

948 デフォルトの名無しさん [sage] 2010/07/17(土) 02:07:53 ID: Be:
    一冊も読んだことがないから知らん。

    つーか、本当の入門書の推薦て意味がないだろう。
    複数の入門署を買いそろえる人間て、自分の知能が低いことを証明しているようなもんだし、
    そいつが何冊目かでわかった、なんてのはサイコロころがして3回目で1が出ました!と
    言ってるのとたいしてかわらん。
    一冊読んで多少なりとも書けるようになったやつは、それ以降当該言語の入門署は読まん。

    うまいビールは何度でも買うが、うまい本は一冊しか買わず
    しかもその本はすぐうち捨てられることになる。 

955 デフォルトの名無しさん [sage] 2010/07/17(土) 05:53:09 ID: Be:
    エキスパートの目から見て間違ったことが書いてあるダメな入門書をはじけば、
    いい入門書の数なんて限られてるだろ。 

956 デフォルトの名無しさん [sage] 2010/07/17(土) 10:46:36 ID: Be:
    入門書の間違いなんて、たまたまそれに嵌って痛い目にあったりでもしない限り、
    いちいち覚えちゃねえよ。
    複数言語やってりゃ、記述が間違っていても何となく回避してるし。

    子どもの時に乗った三輪車の善し悪しなんぞ誰もわからんのと同じ。
    ぐだぐだ言うのは、三輪車をとっかえひっかえしている池沼と、書いた著者くらいのもん。 

957 デフォルトの名無しさん [sage] 2010/07/17(土) 10:59:37 ID: Be:
    言ってることはその通りだが>>956は誰にレスしてるんだ 

958 デフォルトの名無しさん [sage] 2010/07/17(土) 11:17:16 ID: Be:
    神からの啓示 


956はほかのスレにもコピペされているっぽいな。 すんません。「入門書」を何冊も買っては重箱の隅をつつくのが趣味です○| ̄|_ 最近は時間的にも金銭的にも余裕があまりないのでやってませんが。

■_ call by

まあ年中見られるパターンではある。


Ruby 初心者スレッド Part 37
517 デフォルトの名無しさん [sage] 2010/07/17(土) 02:53:39 ID: Be:
    cのように参照渡しで関数に値を渡して、直接に値を変更するにはどうしたらいいのでしょうか?

518 デフォルトの名無しさん [sage] 2010/07/17(土) 03:08:55 ID: Be:
    cに参照渡しはない
    PASCALとかC++にならあるけど 

519 デフォルトの名無しさん [sage] 2010/07/17(土) 03:16:16 ID: Be:
    ああ、C++でした。
    rubyにはないのでしょうか? 

520 デフォルトの名無しさん [sage] 2010/07/17(土) 03:24:06 ID: Be:
    rubyは本質的には全部参照渡し 

521 デフォルトの名無しさん [sage] 2010/07/17(土) 04:03:33 ID: Be:
    本質的とかよくわかんないけど参照渡しでない例

    a = 0
    def foo(x); x = 1; end
    foo(a)
    a

    MatzまでRubyは参照渡しとかいってたらRubyやめる 

522 デフォルトの名無しさん [sage] 2010/07/17(土) 06:00:16 ID: Be:
    Rubyをfjで発表した頃はトヨタケーラムだけど、Ruby誕生の頃は浜松にいた。

    ていうか、言語屋でrubyを参照渡しとか言う奴はいないだろ。Cと同じで全て値渡し。
    Call by sharingとか呼ぶ向きもあるけど。 

524 デフォルトの名無しさん [sage] 2010/07/17(土) 07:48:00 ID: Be:
    >>521
    意味が解らないんですけど…
    それのコードは参照渡しの例に見えますが… 

525 デフォルトの名無しさん [sage] 2010/07/17(土) 09:11:21 ID: Be:
    >>524
    ま、まて、参照渡しという用語は言語や個々人によって解釈が変わる類の用語ではなかったと思うが・・・

    http://ja.wikipedia.org/wiki/%E5%8F%82%E7%85%A7%E6%B8%A1%E3%81%97#.E5.8F.82.E7.85.A7.E6.B8.A1.E3.81.97

    irb(main):001:0> local_unko = "UNKOO!!!"
    => "UNKOO!!!"
    irb(main):002:0> def func(func_arg); func_arg = "FUCK!!!"; end
    => nil
    irb(main):003:0> func(local_unko); puts local_unko
    UNKOO!!!
    => nil
    irb(main):004:0> local_unko == func("UNKOO!!!")
    => false

    もし、Rubyが参照渡しができるなら、local_unkoは"FUCK!!!"になってるはず 

526 デフォルトの名無しさん [sage] 2010/07/17(土) 09:12:58 ID: Be:
    x もし、Rubyが参照渡しができるなら、local_unkoは"FUCK!!!"になってるはず
    o もし、Rubyが参照渡しができて、引数のデフォルトが参照渡しか、もしくは明示的に参照渡しを指定したならlocal_unkoは"FUCK!!!"になってるはず 

527 デフォルトの名無しさん [sage] 2010/07/17(土) 09:20:47 ID: Be:
    他の言語で参照渡しが必要だった場面を思い出したけど、
    組み込み型に影響を与えたい場合(変数がnullじゃないなら開放して変数にnull入れるような関数とか。返却値でnull代入だるい)
    関数やメソッドで多値を返せない言語で多値を返す場合とか(複雑な場合は構造体か簡易なオブジェクトを返すようにしてたけど)

    とかだったな。
    Rubyだと特に困らんから気にならなかった 

528 デフォルトの名無しさん [sage] 2010/07/17(土) 09:39:29 ID: Be:
    変数に保持してるのがオブジェクトへの参照ということと、
    参照渡しという概念がごちゃまぜになってると予想 

529 デフォルトの名無しさん [sage] 2010/07/17(土) 10:35:52 ID: Be:
    え、Rubyって値渡しって言われてるの?
    参照渡しとは違うのはわかるが値渡しでもないような。

    irb(main):001:0> local = "local"
    => "local"
    irb(main):002:0> def func(arg);arg.replace "arg";end
    => nil
    irb(main):003:0> func(local);puts local
    arg
    => nil

    単純に値渡しなら、localはlocalのままのはず 

530 デフォルトの名無しさん [sage] 2010/07/17(土) 10:42:03 ID: Be:
    >>529
    せっかく >>525 がwikipediaのリンク先を示してくれたのに、 コードと書き込みだけ読んでまったくスルーした発言ワロタw 

531 デフォルトの名無しさん [sage] 2010/07/17(土) 10:42:30 ID: Be:
    ただのFAQに何をグダグダやってんだか…

    >>517
    基本的に無理。抜け道はないでもないけど字面的に無様すぎる。

    $a = "a"
    $b = "b"

    def replaceit(x, y)
      eval "x=$b", y
    end

    c = $a
    puts c # ==> "a"
    replaceit(:c, binding)
    puts c # ==> "b" 

532 デフォルトの名無しさん [sage] 2010/07/17(土) 10:49:34 ID: Be:
    リンク先を読んでないの笑うのいいけど、どうせ読まないんだしコピペぐらいしてやればいいと思うんだ

    > 参照の値渡し [編集]
    >
    > 参照渡しで言うところの「参照」と呼ばれているものと、特定の言語で「参照」と呼ばれているものが
    > 必ずしも同じでない事には注意が必要。
    > 例えば、Javaは参照型を扱うための『Javaの「参照」』を持つが、これはPascal等のポインタ相当で、
    > 『参照渡しの「参照」』とは概念が違うため、『Javaの「参照」』を渡しても参照渡しであるとは言えない。
    > C言語の「ポインタの値渡し」と同じである。JavaHouse-Brewers の議論を参照 http://java-house.jp/ml/archive/j-h-b/026214.html#body
    > これは、Javaの参照型と似た参照型と、Javaのプリミティブ型に近い値型を持つC#を見ると理解しやすいだろう。
    > C#では、特に指定しなければ参照型も値型も値渡しされるが、
    > 引数に ref もしくは out を使用する事によって参照渡しにする事ができる。
    > 『C#の値型』を渡すから値渡し、『C#の参照型』を渡すから参照渡しとはならない。

533 デフォルトの名無しさん [sage] 2010/07/17(土) 10:55:16 ID: Be:
    まあ値渡しと参照渡しのメルクマールは>>521だな

    java-houseの議論は今ではよく名の知られた人が
    泥沼の議論を展開していて一見の価値があるぞ 

534 デフォルトの名無しさん [sage] 2010/07/17(土) 11:07:57 ID: Be:
    >>521の例だと関数への渡し方うんぬんもあるが
    代入の考え方の違いも気になる部分だと思うんだが 

535 デフォルトの名無しさん [sage] 2010/07/17(土) 11:09:17 ID: Be:
    関数とか言っちゃった 

引数を書き換えられる → 参照渡しで渡されている じゃないんだよねえ。

■_ 本日の巡回から

■_ で

海の向こうではこういう発言をしてツッコミ多数受けている人も。

OK, so I'm not a beginner anymore. What comes next? - Stack Overflow

In a certain sense, I'm still very much a beginner, but I don't need to read C++ 
Primer or Learn C++ in 21 Days, or at least, I only take a peek every now and then for 
reference's sake. So what is my problem?

Basically, I started to write a small game to help my process of learning. Along the 
way, I've learned most of anything that you need to know to be called 'fluent' in C++. 
I know all about overloading, templates, exceptions, RTTI, polymorphism, etc. I've 
also taken another small step forward and started using the STL and its containers and 
algorithms. Recently I started reading about the Boost library. I also read some good 
material about design patterns and actually applied a couple of ideas to this game of 
sorts.

But now the whole thing has ground to a stop after about 3k lines of code. Why? It's 
not that I don't know the language or don't have the ideas. But knowing the vocabulary 
and having the ideas does not make one a novelist. Even knowing how to write sentences 
is not enough. You have to understand flow, structure, and all the rest to write a 
successful novel.

In my practical case, I'm tending to waste a lot of time structuring the code so as to 
work properly, e.g. I'm losing track of whether to send a certain kind of event before 
another. The program obviously compiles fine, but the runtime behaviour may not be 
exactly as intended. I'm also losing track of who owns what, who should take care of 
what, and so forth. Maybe I'm not strong enough when it comes to algorithms, or maybe 
the culprit is object oriented design - I'm not sure.

The truth is that the code is starting to look a lot like a chaotic mess, not so much 
in terms of the actual appearance of the code as in terms of the ideas themselves and 
their interrelation. The maintenance time has become too much already.

Anyway, sorry for the longish post, but I was wondering what to learn next. I've had a 
look at the books thread on SO, which is wonderful, but I was hoping for a rather more 
specific direction. I need to spend less time on the rewriting and more on the actual 
writing.

数ある返事の中からひとつ。


Ok, I have 2 answers for you - pick the one that is most relevant.

Firstly, to successfully finish your app, you need domain specific information. This 
isn't about C++ any more. If you're programming games, you need to read more about how 
games actually do it. Otherwise it's like trying to write a crime novel having 
memorised a dictionary and a grammar guide, to continue the analogy. It's not just 
about flow and structure - those are still fairly low-level concepts. You need to 
examine how people approach the genre and then from there you can pick out the types 
of flow and the structures you will need with more confidence. Messy code is often 
just as much about not fully understanding the specification as it is about not 
knowing how to program effectively. Knowing the domain helps you pin down clear and 
well-understood solutions.

I recommend the Game Coding Complete (3rd ed) book by Mike McShaffrey for a good 
insight into the overall approach to making a game. I have also heard good things 
about Game Engine Architecture by Jason Gregory but I haven't read it myself. Note 
that both of these books are quite complex and focused on industrial-strength 
solutions. If you don't need an industrial-strength solution, you might ask yourself 
why you're using C++ to write a game when other languages are more suitable for rapid 
development. Flash is a good choice, for example.

Which leads me on to my second answer: code something you actually care about. If 
you're only using the game project as a vehicle for learning the language, chances are 
high that you lost interest as you reached the point where you stopped learning new 
things about the language and had to start worrying about things specific to games 
that are more about rearranging the concepts that you already know. This is typically 
the point where learning is something you should be incorporating into practical 
solutions rather than something you have to force yourself to do purely for 
pedagogical reasons. We learn best when the task is interesting.

ついったのTLでも良く見かけるような気がするなあ。 質問主みたいなの。

2010年07月16日

■_

・口耳四寸の学

■_ でこれーたー

Python のデコレーター、どんな目的に使っていますか。 というお話。

Quora - What are common uses of Python decorators?

What are common uses of Python decorators?

Drew Houston

Decorators are convenient for factoring out common prologue, epilogue, and/or 
exception-handling code in similar functions (much like context managers and the 
"with" statement), such as:

    * Acquiring and releasing locks (e.g. a "@with_lock(x)" decorator)
      ロックの確保や解放

    * Entering a database transaction (and committing if successful, or rolling back 
      upon encountering an unhandled exception)
      データベースのトランザクションへの突入
      (成功すればコミットし、さもなければであったハンドルされていない例外に
       したがってロールバック)

    * Asserting pre- or post-conditions (e.g. "@returns(int)")
      事前条件や事後条件の表明

    * Parsing arguments or enforcing authentication (especially in web application 
      servers like Pylons where there's a global request and/or cookies object that
      might accompany formal parameters to a function)

    * Instrumentation, timing or logging, e.g. tracing every time a function runs

They are also used as shorthand to define class methods (@classmethod) and static 
methods (@staticmethod) in Python classes.
クラスメソッドやスタティックメソッドの定義のための短縮表記に
  
Ben Newman

I've found the following memoization decorator useful on a number of occasions:

def memo(fn):
    cache = {}
    def wrapper(*args):
        try:
            return cache[args]
        except:
            result = fn(*args)
            cache[args] = result
            return result
    return wrapper


With this little tool in your toolchain, you can write functions in a naive, 
mathematically elegant style, and get away with it:


@memo
def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)


Goodbye, exponential time.  Hello, linear time.

Of course, the original function must be pure, and the arguments must all be hashable, 
but python does a great job synthesizing a hash function for the args tuple, provided 
those assumptions hold.

Ethan Miller, started coding in python ~2004, now daily ...

Two that come to mind immediately:

    * Timing a function. The decorator can start a timer, run the decorated function, 
      then log the elapsed time at the end.

    * Access control. In Django, for example, django.contrib.auth.decorators contain 
      decorators for view functions that check permissions before running said view code.

Ryan Cox

They can be used for application-level rate limiting as well. 

See: http://github.com/simonw/ratelim...

Example:

@ratelimit(minutes=1, requests=10)
def index(request): r
    return HttpResponse('Hello, World')

Jeff Hammerbacher

I use the @property decorator all the time: see http://blog.ianbicking.org/prope....

Note the new hotness in 2.6 (and 3.1): you can use decorators to make your setters and deleters too.

http://docs.python.org/library/f...
http://blog.ianbicking.org/property-decorator.html

Michael Katsevman, Pythonista for over a decade

They are also useful for imparting a bit of aspect-orientation 
(http://en.wikipedia.org/wiki/Asp...) to your code. That is, standard inheritance 
facilitated by object-orientation lets you propagate features vertically amongst 
classes. You can use decorators to propagate certain features horizontally.

Michael Katsevman

Zach Bialecki, Programmer at BetterLesson

Django developers have access to the @login_required decorator that will automatically 
redirect the user to a sign in page if they try to access a view and are not 
authorized.

Lakshman Prasad

I loved using it for caching by using custom caching keys and values:

from django.core.cache import cache
    def cache_for(seconds,fetch=0):
        def cache_it(func):
            def deco_func(self):
                val = cache.get(self.get_cache_key(fetch))
                if not val:
                    val = func(self)
                    cache.set(self.get_cache_key(fetch), val, seconds)
                return val
            return deco_func
        return cache_it


■_ Perl 6

LAST の方は、Python の for や while にある else みたいなもんじゃろか。

Journal of masak (6289)

Phasers are a blast: FIRST and LAST

[ #40447 ]

I started thinking about the FIRST and LAST phasers the other day, thanks to moritz++. 
My attention was on how to implement them in Yapsi, and my conclusions were mostly SIC, 
but they can be converted to Perl 6 for public view.

For those who haven't kept up with the latest Perl 6 terminology, "phasers" 
are what we call those all-caps blocks which fire at different phases during program 
execution. Perl 5's perldoc perlmod simply calls them "specially named code 
blocks", but in Perl 6 it's been decided to call them "phasers".

So much for phasers. What do the FIRST and LAST phasers do? They don't exist in Perl 5. 
S04 describes them thus:

FIRST {...}       at loop initialization time, before any ENTER
 LAST {...}       at loop termination time, after any LEAVE

(There's a NEXT phasers too, which I'm not going to tackle today. The ENTER and LEAVE 
phasers are what they sound like; they trigger at block entrance and exit, 
respectively.)

Here's some code using these.

my @a = 1, 2, 3;
for @a -> $item {
    FIRST { say "OH HAI" }
    say $item;
    LAST { say "LOL DONE" }
}

The code, when run, should print the following:

OH HAI
1
2
3
LOL DONE

(At the time of writing, no Perl 6 implementation implements the FIRST and LAST phasers yet.)

The goal of this post is transforming the phasers into code using more primitive 
constructs, but which still produces the above results. Oh, and it should work not 
only in this case, but in general.

(この後も色々書かれているけど略)

■_ これは

melancholic afternoon
7月15日_
浮動小数点数のちょっとしたクイズ

WEB+DB PRESS Vol.57のPHPでの記事で浮動小数点数の話があった. 0.1を10回足しても1にならな
いというよくあるやつ. 本では0.1は0.10000000000000001に, sumは0.99999999999999989になる
という. 今までも見て素通りしてたけど今回は気になってCでも同じかと試してみた.

#include <stdio.h>

int main()
{
    double x = 0.1;
    printf("%.17f\n", x);
    double sum = 0;
    for (int i = 0; i < 10; i++) {
        sum += x;
    }
    printf("%.17f\n", sum);
}
>0.10000000000000001
>0.99999999999999989

同じだ(Pythonでも同じだった). 0.1は2進数表記で無限小数になるので大きいほうに丸められて
0.10000000000000001になるのはいいとして, 0.1より大きいものを10回足したのに, なぜ1を超
えないのだろう. 少し考えるとすぐわかるのだけど, でもパッと見は不思議だ. 

たぶん、加算の結果桁が増えて以下略。 プログラムをちょっといじって

#include <stdio.h>

int main()
{
    double x = 0.1;
    printf("%.17f\n", x);
    double sum = 0;
    for (int i = 0; i < 10; i++) {
        sum += x;
        printf("%.17f\n", sum);
    }
    printf("%.17f\n", sum);
}

出力を見る

0.10000000000000001
0.10000000000000001
0.20000000000000001
0.30000000000000004
0.40000000000000002
0.50000000000000000
0.59999999999999998
0.69999999999999996
0.79999999999999993
0.89999999999999991
0.99999999999999989
0.99999999999999989

ん、それっぽい。

■_ 本日の巡回から

2010年07月15日

■_

・サンドウィッチ
最近、ポテトサラダを使ったサンドウィッチをほとんど見かけないような気がするのですが なんかあったんでしょうか?(好きなのに) ここ数週間というレベルでみるとジャガイモがお高めということは知っているんですが。 でも見なくなったのもっと前からだしなあ。

・モーニング
カレチ良かった。

・近代麻雀
(もごもご)

っと。ブラクラのOVA 1巻か。もう。

■_

よくあるいい間違い?

【上流社会】MSDNサブスクリプション総合【最先端】 
549 デフォルトの名無しさん [sage] 2010/06/30(水) 13:22:33 ID: Be:
    TechNetとVS単体でいいような気がしてきた 

550 デフォルトの名無しさん [sage] 2010/06/30(水) 14:40:16 ID: Be:
    何がいいのか・・・
    TechNetライセンスで開発するつもりですか? 

551 デフォルトの名無しさん [sage] 2010/06/30(水) 15:51:48 ID: Be:
    開発に使うならMSDNサブスクリプションでないとダメですね。
    TechNetは板違いなのでWindows板のスレへどうぞ。

    MSDN サブスクリプションと TechNet Plus サブスクリプションを比較する
    http://msdn.microsoft.com/ja-jp/subscriptions/dd362338.aspx
    TechNet PlusサブスクリプションのFAQの内容について
    http://social.technet.microsoft.com/forums/ja-JP/technetsubscriptionja/thread/7eaf6296-69ba-4406-b064-a1c67c8fc453
    MSDN/TechNetサブスクリプション 24
    http://pc12.2ch.net/test/read.cgi/win/1277483862/ 

552 デフォルトの名無しさん [sage] 2010/06/30(水) 16:09:40 ID: Be:
    各自の判断に任せる(キリッ
    開発というか常用には普通のライセンス1つあればいいし、TechNetのOSやソフトは動作テスト用だろ?
    俺は色々なOSでの動作の検証が必要なので重宝している。
    MSDNよりTechNetがリーズナブルなのは紛れもない事実。 

553 デフォルトの名無しさん [sage] 2010/06/30(水) 16:38:07 ID: Be:
    まあそれ以上は黙ってろ。 

554 デフォルトの名無しさん [sage] 2010/06/30(水) 16:53:24 ID: Be:
    >>552
    ライセンス違反なので真似しないように。
    http://msdn.microsoft.com/ja-jp/subscriptions/dd362338.aspx
    >                           TechNet  MSDN
    >アプリケーションのテスト環境の一部として   ×     ○
    >マイクロソフト ソフトウェアを使用する 

555 デフォルトの名無しさん [sage] 2010/06/30(水) 21:08:13 ID: Be:
    >>554
    お きちんと明記するようになったのか。
    昔からしてろよと思うがよくやった。 

556 デフォルトの名無しさん [sage] 2010/06/30(水) 21:16:29 ID: Be:
    俺には関係ねぇな 

557 デフォルトの名無しさん [sage] 2010/06/30(水) 21:27:50 ID: Be:
    昔、TechNetの活用で開発関係の見たことあった気がするんだけどな~
    何時から変ったんだ? 

558 デフォルトの名無しさん [sage] 2010/07/04(日) 20:43:08 ID: Be:
    え?!
    Technetはデプロイ前の評価くらいしか見た事無い。
    というか開発うんぬんは見た事無い。
    マジ!? だったらMSに「損害賠償」出来るくらいのネタだぞ!?

559 デフォルトの名無しさん [sage] 2010/07/04(日) 21:27:09 ID: Be:
    いや、昔からTechNetは評価にしか使っちゃダメって明記してただろ。
    ある業務が開発になるのか評価になるのか判断しづらいのが問題なんでは。 

560 デフォルトの名無しさん [sage] 2010/07/04(日) 21:39:13 ID: Be:
    >マジ!? だったらMSに「損害賠償」出来るくらいのネタだぞ!?

    kwsk 

561 デフォルトの名無しさん [sage] 2010/07/04(日) 21:55:04 ID: Be:
    MSに損害賠償するんだぜ。損害賠償請求じゃなく。
    「すいません不正利用してました」って言ってMSに金払うネタだろ 

562 デフォルトの名無しさん [sage] 2010/07/05(月) 11:42:20 ID: Be:
    ちょっとわろた 

563 デフォルトの名無しさん [sage] 2010/07/05(月) 20:25:59 ID: Be:
    お前等の優しさに泣いた 

564 デフォルトの名無しさん [sage] 2010/07/12(月) 23:27:45 ID: Be:
    今回はアップグレード相当の価格で新規で買えるキャンペーンやらねーのか。 

565 デフォルトの名無しさん [sage] 2010/07/12(月) 23:44:18 ID: Be:
    じゃなくて、更新相当の価格で新規だ.... 

■_ 例の

・水爆の効率概算のためにフェルミは大型計算尺で、ファインマンは卓上計算機で、   ノイマンは天井を向いて暗算したが、ノイマンが最も速く正確な値を出した。 の話をちょっと追いかけた。

Richard Feynman Dead at 69; Leading Theoretical Physicist

February 17, 1988

Richard Feynman Dead at 69; Leading Theoretical Physicist

By JAMES GLEICK


Richard P. Feynman, arguably the most brilliant, iconoclastic and influential of the 
postwar generation of theoretical physicists, died Monday night in Los Angeles of 
abdominal cancer. He was 69 years old.

(略)

Dr. Feynman's years with the Manhattan Project brought the brazen young scientist into 
close contact with the world's greatest physicists and mathematicians. He would attend 
meetings in Edward Teller's office, furiously exchanging ideas with Enrico Fermi and 
John von Neumann, manipulating his desk calculator at top speed while von Neumann 
worked the same problems in his head.

「マンハッタンプロジェクト」に絡んでの話だから、 「水爆」ってのはたぶん間違いだろうなあ。 まあ英語でも幾つか見つかったので多少の違いはあるのかも(確かめてない)。

■_ Perl 6

ほー。こういうのが。

blog | Perlgeek.de :: This Week's Contribution to Perl 6 Week 9: Implement Hash.pick for Rakudo

Tue, 13 Jul 2010

This Week's Contribution to Perl 6 Week 9: Implement Hash.pick for Rakudo

Permanent link

For this week's contribution to Perl 6 we ask you to implement the Hash.pick method 
(which does a weighted random selection) for Rakudo.

(Introduction to this series of challenges)

Background

In Perl 6 the List class has a method called pick, which randomly selects one item 
from a list. It has a few more options too:

<a b c>.pick;       # pick one random element
<a b c>.pick(2);    # pick two distinct, random elements
<a b c>.pick(2, :replace); # pick two random elements, it's ok
                           # if they are the same
<a b c>.pick(*);    # return a random permutation of the elements
<a b c>.pick(*, :replace); # infinite, random stream of elements

This is already implemented through several multi methods in Rakudo.

Now the specification describes such a method for hashes too (actually it talks about 
Bags, but Rakudo doesn't have Bags yet. Pretend it says "Hash" instead). It 
assumes that each value in the hash is numeric, and that the value is a weight that 
determines the probability of picking one value. For example

{a => 1, b => 2}.pick;  # returns 'a' with probability 1/3
                        # and 'b' with probability 2/3

{a => 1, b => 2}.pick(*);  # <a b b> with probability 1/3
                           # <b a b> with probability 1/3
                           # <b b a> with probability 1/3
{a => 1, b => 0.5}.pick(*) # dies, because the weights aren't all integers
{a => 1, b => 0.5}.pick(*, :replace)  # ok 

What you can do

Implement Hash.pick. It's ok if your patch doesn't cover all cases. It would be nice 
if it supported non-integer weights.

Hint: this could be done by storing a list of accumulated weights, and a list of keys.

{a => 1, b => 2.5, c => 1}

# could translate to 
my @keys = ('a', 'b', 'c');
my @accumulated_weights = (1, 3.5, 4.5);

# now pick a random number between 0 and 4.5,
# find the next-highest index in @accumulated_weights
# with a binary search, and then use that to obtain the key.

Of course other schemes are fine too.

Second hint: because it takes quite some time to recompile Rakudo, it is probably 
easier to implement the actual logic in a function in a normal source file first, and 
only later move it into src/core/Hash.pm.


.pick ね。:replace の役目が今ひとつわからん。

■_ 本日の巡回から

2010年07月14日

■_

出てすぐに買わないでペンディング状態のオライリー本がだいぶ増えてきたなあ。 直近で出張販売がありそうなのは LL Tiger か。 んが、金ねーぞ(笑)

http://cmscorp.sakura.ne.jp/blog/nui_asistloyd1.jpg http://cmscorp.sakura.ne.jp/blog/nui_asistloyd2.jpg

明日あたりタコス買いに行くか(謎)

■_ 大分間違いとか誇張が混じってないか?

数日前に、このノイマンネタをついったで見かけてびみょーーーに 気になるところがあったんだけど、やっぱりこういう出火元(?)があったんだなあ。


至上最強の天才 ジョン・フォン・ノイマン : 2chコピペ保存道場
76 名前:名無しさん@お腹いっぱい。:2009/06/28(日) 12:07:14
至上最強の天才 ジョン・フォン・ノイマン
あまりの頭の良さに火星人、悪魔の頭脳を持つ男と言われた

数学・物理学・工学・経済学・計算機科学・気象学・心理学・政治学
とあらゆる分野で天才的な才能を発揮

・子供の頃に遊びで分厚い電話帳を完全に暗記してみせる
・今のPCはノイマン型コンピューターと言われノイマンが作ったのが元
・6歳のとき、電話帳を使い8桁の割り算を暗算で計算することができた
・8歳の時には『微積分法』をマスター、12歳の頃には『関数論』を読破した。
  ちなみに『関数論』は、大学の理工系の学生が1、2年次に学ぶ数学で、
  高校時代に数学が得意で鳴らした学生でも、完全に理解できる者は少ない。
・数学者が3ヶ月の苦心惨憺の末、ついに解いた問題をノイマンは脳内だけで一瞬で解いた
・一度見聞きしたら、決して忘れない写真のような記憶力
・コンピュータ並みの計算速度 実際、ノイマンは、自らが発明したコンピュータと競争し、勝利している
・ノーベル賞受賞者ですらついていけない頭の回転
・脳内には装着された面積1ヘクタールほどもあるバーチャル ホワイトボードがあり
  ノイマンは、紙と鉛筆を使わず、この脳キャンパスだけで、人間が及びもつかない複雑で込みいった思考をすることができた
・あまりの人間離れした思考に人間ではないと疑われた
・水爆の効率概算のためにフェルミは大型計算尺で、ファインマンは卓上計算機で、
  ノイマンは天井を向いて暗算したが、ノイマンが最も速く正確な値を出した。
・一日4時間の睡眠時間以外は常に思考

セクハラ魔で有名で秘書のスカートの中を覗くが趣味で
その振る舞い方は下品そのものだった
推定IQは250~300、仮に東大の医学部を目指せば1週間?で入れるレベル
天才といわれる学者の中でもかなり異質である
一度見たものは決して忘れない、計算は一般的なコンピューターより速い

とりあえずパッと見で 今のPCはノイマン型コンピューターと言われノイマンが作ったのが元 コンピュータ並みの計算速度 実際、ノイマンは、自らが発明したコンピュータと競争し、勝利している これはちがうだろ。


天才理数学者ジョン・フォン・ノイマンについて
1 :a=-(ω^2)(X-X。) ◆Clnyl6BTRY :2008/01/03(木) 13:39:53
    至上最強の天才 ジョン・フォン・ノイマン
    あまりの頭の良さに火星人、悪魔の頭脳を持つ男と言われた

    数学・物理学・工学・経済学・計算機科学・気象学・心理学・政治学
    とあらゆる分野で天才的な才能を発揮

    ・子供の頃に遊びで分厚い電話帳を完全に暗記してみせる(^ω^)
    ・今のPCはノイマン型コンピューターと言われノイマンが作ったのが元
    ・6歳のとき、8桁の割り算を暗算で計算することができた (^ω^)
    ・8歳の時には『微積分法』をマスター、12歳の頃には『関数論』を読破した。 (^ω^)
     ちなみに『関数論』は、大学の理工系の学生が1、2年次に学ぶ数学で、
     高校時代に数学が得意で鳴らした学生でも、完全に理解できる者は少ない。 (^ω^)
    ・数学者が3ヶ月の苦心惨憺の末、ついに解いた問題をノイマンは脳内だけで一瞬で解いた (^ω^)
    ・一度見聞きしたら、決して忘れない写真のような超記憶力 (^ω^)
    ・コンピュータ並みの計算速度 実際、ノイマンは、自らが発明したコンピュータと競争し、勝利している (^ω^)
    ・ノーベル賞受賞者ですらついていけない頭の回転 (^ω^)
    ・「なかよしイケメン」が口癖 (^ω^)
    ・脳内には装着された面積1ヘクタールほどもあるバーチャル ホワイトボードがあり
     ノイマンは、紙と鉛筆を使わず、この脳キャンパスだけで、人間が及びもつかない複雑で込みいった思考をすることができた(^ω^)
    ・あまりの人間離れした思考に人間ではないと疑われた (^ω^)
    ・水爆の効率概算のためにフェルミは大型計算尺で、ファインマンは卓上計算機で、
     ノイマンは天井を向いて暗算したが、ノイマンが最も速く正確な値を出した。 (^ω^)
    ・一日4時間の睡眠時間以外は常に思考 (^ω^)

    セクハラ魔で有名で秘書のスカートの中を覗くが趣味で
    その振る舞い方は下品そのものだった (×-×)
    推定IQは300、仮に東大の医学部を目指せば1週間で入れるレベル (×-×)
    天才といわれる学者の中でもかなり異質である (×-×)
    一度見たものは決して忘れない、計算はコンピューターより速い(×-×)
    彼には何の努力も必要ないのである(^ω^)

26 :Nanashi_et_al.:2008/04/13(日) 17:47:06
    この人のエピソードで覚えているのは唯一つ。

    この人は癌で死んだんだが、末期のときはアメリカ陸軍の情報将校が数人病室にはりついて
    24時間監視していたらしい。

    というのも、この人は国家機密に関わる仕事を多くしていたので、うわごとで何か重大なことを
    漏らされたら困るから。

    おまえら、こんな人生送りたいか? 

39 :Nanashi_et_al.:2008/10/13(月) 11:19:34
    マンハッタン計画での爆縮計算問題が持ち上がった時のエピソード。
    その時、

    ファインマンは最新のリレー計算機に走り、
    フェルミは計算尺を持ち出し、
    フォン・ノイマンは天井を見つめた。

    最速で正解を出したのはもちろんフォン・ノイマンだった。 

258 :Nanashi_et_al.[sage]:2009/06/24(水) 10:23:37
    ノイマン型コンピュータとは IT用語辞典より要約

    実はノイマンはEDVAC開発計画には途中から参加しており、
    プログラム内蔵方式という基本設計はプロジェクト当初から関わっていた、
    ジョン・エッカートとジョン・モークリーによって考案されたと言われる。
    軍事機密として開発されたため、開発メンバーは詳細を発表することはなかった。
    ノイマンはメンバーに相談なく論理的側面をまとめた論文を、
    自分の名前で発表してしまい、世間的にはノイマンの着想によると認識されるようになった。
    開発チームの内紛はこの事件が原因と言われる。

    こんなんばっかしだからな。 

26 の機密が漏れるのを恐れて云々てのも都市伝説の類らしいけどね。

しかし


ジョン・フォン・ノイマン - Wikipedia
(略)
[編集] 逸話

    * その驚異的な計算能力と特異な思考様式、極めて広い活躍領域から「悪魔の頭脳」「火星人」と評された。
    * 圧倒的な計算能力については数々の逸話が残っている。
          o 電話帳の適当に開いたページをさっと眺めて、番号の総和を言って遊んでいた。
          o 水爆の効率概算のためにフェルミは大型計算尺で、ファインマンは卓上計算機で、ノイマンは天井を向いて暗算したが、ノイマンが最も速く正確な値を出した。
          o ENIACとの計算勝負で勝ち、「俺の次に頭の良い奴ができた」と喜んだ。
          o しかし、死の直前には腫瘍が脳にまで達し、3+4という一桁の計算すらできなかった(上記「晩年」の節の記述のごとく)。
    * ト-マス・J・ワトソンと親交を結んでおり、IBMの特許取得にかかわっていた。
    * 入院後は車椅子で救急車に乗ってまで原子力委員会の会合に出席したりした。
    * ノーベル物理学賞受賞者ユージン・ウィグナーとは中学校・高校と同じで当時から顔見知りだったという。
    * ノーベル経済学賞受賞者ポール・サミュエルソンの教科書をみて「ニュートン以前の数学ではないか」と言って笑った。
    * ノーベル経済学賞受賞者ジョン・ナッシュのナッシュ均衡に関する歴史的論文を一瞬見て「くだらない、不動点定理の応用ではないか」と貶めた。
    * クルト・ゲーデルの次に第一不完全性定理を理解したといわれている。この分野で自分に先んじたゲーデルのことは例外的に尊敬しており、生涯高く評価し続けた。
    * 何十年も居住している家の棚の食器の位置すら覚えられなかった他、1日前に会った人物の名前すら浮かばなかった。興味がないものに対しては全く無関心であると評された。
    * 女性秘書のスカートの中を覗く趣味があり、知的に優秀な反面、人格はしばしば幼児の段階で停まっていると評された[要出典]。
    * 政治での立場はタカ派であった。
          o 青年期に経験したハンガリー革命、アーサー・ケストラーの『真昼の暗黒』やスターリン政権下の
            ソ連への短い旅行などを通じてソ連に敵意を燃やしていた。ソ連への核攻撃を強く主張し、死後、
            Life誌が伝えた ([1]) ところによれば、1950年に「なぜ明日彼らを爆撃しないのかと言われたら、
            なぜ今日爆撃しないのかと言う。今日の5時にと言うなら、なぜ1時でないのかと言う。」
            ("If you say why not bomb them tomorrow, I say why not bomb them today? If you say today
            at five o'clock, I say why not one o'clock?") という発言をしたとされる。
          o ハト派だったノーバート・ウィーナーとは性格から政治信条まで好対照だった為、比較に出されるこ
            とが多い。ウィーナーとはサイバネティックスの分野で共同研究をしたが、結局は打ち解けなかった。

英語版にはこれに対応するセクションがないw


John von Neumann - Wikipedia, the free encyclopedia

[edit] Biography

The eldest of three brothers, von Neumann was born Neumann János Lajos (in Hungarian 
the family name comes first) on December 28, 1903 in Budapest, Austro-Hungarian Empire, 
to a wealthy Jewish family.[7] His father was Neumann Miksa (Max Neumann), a lawyer 
who worked in a bank. His mother was Kann Margit (Margaret Kann). Von Neumann's 
ancestors had originally immigrated to Hungary from Russia.

(略)

[edit] Quantum mechanics
[edit] Economics and game theory
[edit] Nuclear weapons
[edit] Computer science
[edit] Politics and social affairs
[edit] Personality
[edit] Honors
[edit] Selected works
[edit] See also
[edit] Biographical material
[edit] Notes
[edit] References
[edit] External links

なんでだ(笑)

■_ こんなところにも twice が

んー、なんかごちゃごちゃした書き方になるねえ。できるだけ偉いのか?


D言語 Part24 
806 デフォルトの名無しさん [sage] 2010/07/13(火) 23:59:45 ID: Be:
    関数を引数にとり、引数にとった関数を二回適用する関数を返す関数は、
    ocamlでは、
     let twice f x = f (f x)
    と書けるのですが、
    D言語で、うまく書く方法はないのでしょうか.

807 デフォルトの名無しさん [sage] 2010/07/14(水) 00:03:22 ID: Be:
    delegate使えば簡単に書けるだろうけど戻り値どうなるの? 

808 デフォルトの名無しさん [sage] 2010/07/14(水) 00:30:07 ID: Be:
    引数と戻り値は、delegateを使って、

    T delegate(T) twice(T)(T delegate(T) f) {
      return (T x) { return f(f(x)); };
    }

    と書いてみたのですが、
     auto f = twice(&twice!(int));
    と書くと、
     twice(T) cannot deduce template function from argument types !()(int delegate(int x) function(int delegate(int x) f))
    となり、エラーがでてしまいます. 

809 デフォルトの名無しさん [] 2010/07/14(水) 00:59:03 ID: Be:
    import std.functional;
    int func(int x) { return x*2; }
    alias compose!(func,func) twice;
    void main()
    {
    assert( twice(1)==4 );
    }

    こんな感じだろうか?>>808 

810 デフォルトの名無しさん [sage] 2010/07/14(水) 01:34:30 ID: Be:
    >>809
    ありがとうございます.しかし、>>808の関数も、

    int func(int x) { return x*2; }
    void main() {
     assert(twice(&func)(1) == 4);
    }

    は、うまく動きますが、
     auto f = twice(&twice!(int));
    とすると、>>808のようにエラーがでてしまいます. 

811 デフォルトの名無しさん [sage] 2010/07/14(水) 01:45:01 ID: Be:
    uint length = 2;
    [0, 1, 2, 3][0..length];// Error: ScopeDsymbol using 'length' inside [ ] is deprecated, use '$' instead
    なら変数のほうを見てくれよ・・・ 

812 デフォルトの名無しさん [] 2010/07/14(水) 03:19:36 ID: Be:
    >>810
    >>809 の compose は template なのでそういうのは無理でしょうね。
    >>810 のように書くとしたら、

    T delegate(T) twice(T)(T delegate(T) f){
    return (T x){ return f(f(x)); };
    }
    void main(){
    int func(int x) { return x*2; }

    auto tf = twice(&func);
    auto ttf = twice( twice(&func) );
    assert( tf(1) == 4 );
    assert( ttf(1) == 16 );
    }
    こんなのはいかがでしょうか?
    func がデリゲートじゃないといけないのがヤルセないですが、これはそのうち改善されるらしいです。
    ちなみに 809 で使った std.functional.compose でも、
    alias compose!(func,func,func,func) ttf;
    で関数4回適用できます。 

813 806 [sage] 2010/07/14(水) 09:16:17 ID: Be:
    >>812
    ありがとうございます.
    auto f = twice(&twice!(int));
    のエラーですが、 &twice!(int) の型が function なので、

    import std.functional;
    auto tt = twice(toDelegate(&twice!(int)));

    とすれば、うまくいきました. 

814 デフォルトの名無しさん [sage] 2010/07/14(水) 19:36:48 ID: Be:
    delegateとfunctionの互換性制限いつ緩和されるんや… 

815 デフォルトの名無しさん [sage] 2010/07/14(水) 20:32:37 ID: Be:
    その辺はデリケードだから・・・ 

816 デフォルトの名無しさん [sage] 2010/07/14(水) 21:28:00 ID: Be:
    えっ 

817 デフォルトの名無しさん [sage] 2010/07/14(水) 22:13:42 ID: Be:
    何? 

818 デフォルトの名無しさん [sage] 2010/07/14(水) 22:44:28 ID: Be:
    聞こえない 

■_ 本日の巡回から

■_

最近手をかけてる余裕がなくなってきてるなあ。いろいろと。○| ̄|_

2010年07月13日

■_

まあついった上では冗談半分に~クラスタとか使ってたりしますが、 ~を使う人はほげほげ。とかいった「分類」は好きません。 とはいうものの、ここ数日、とあるプログラミング言語の熱心な使い手(と思われる) 方々の発言を見ていて、なんかなじめない集団(?)だなあと思うことしばし。 もうちょっと近くに寄ったらまた違うのかもしれませんけど。

■_


prog21: Explaining Functional Programming to Eight-Year-Olds


Explaining Functional Programming to Eight-Year-Olds
(8歳児に関数プログラミングを説明する)


"Map" and "fold" are two fundamentals of functional programming. 
One of them is trivially easy to understand and use. The other is not, but that has 
more to do with trying to fit it into a particular view of functional programming than 
with it actually being tricky.

“map” と “fold” は関数プログラミングの二つの fundamentals (根本、基礎) です。
これらのうちの片方は理解し、使うのもとても簡単 (trivially easy) です。
もう一方はそうではありませんが、
but that has more to do with trying to fit it into
a particular view of functional programming than with it actually being tricky.



There's not much to say about map. Given a list and a function, you create a new list 
by applying the same function to each element. There's even special syntax for this in 
some languages which removes any confusion about whether the calling sequence is 
map(Function, List) or map(List, Function). Here's Erlang code to increment the values 
in List:

map については語ることはそれほど多くありません。リストと関数を一つずつ与えられると、リ
スト中の各要素に対して関数を適用した結果の新しいリストを生成します。一部の言語では、
map(Function, List) と map(List, Function)のいずれの引数並びで呼び出すかについての混乱
を排除するための特別な構文さえ存在します。次の例はリスト中にある値をインクリメントする
Erlang でのコードです。

[X + 1 || X <- List]

Fold, well, it's not nearly so simple. Just the description of it sounds decidedly 
imperative: accumulate a result by iterating through the elements in a list. It takes 
three parameters: a base value, a list, and a function. The last of these maps a value 
and the current accumulator to a new accumulator. In Erlang, here's a fold that sums a 
list:

一方 fold は、これほど単純なものではありません。その説明は単明らかに命令型のもの 
(decidedly imperative) に聞こえます:
あるリストに含まれている要素に対するイテレートにより結果を accumulate する。
fold は base value, list, function の三つの引数を取ります。このうちの最後のものが 
value をマップして current accumulator を新しい accumulator に更新します。
Erlang では、リストを足し合わせる fold はこのようになります:


lists:foldl(fun(X, Sum) -> X + Sum end, 0, List)


It's short, but it's an awkward conciseness. Now we've two places where the parameter 
order can be botched. I always find myself having to stop and think about the 
mechanics of how folding works--and the difference between left and right folding, too 
(lists:foldl is a left fold). I would hardly call this complicated,
but that step of having to pause and
run through the details in my head keeps it from being mindlessly intuitive.

これは短いものではありますが、awkward conciseness (明瞭さに欠けるもの?) です。ここで、
可能なパラメーターの並びの順序として二つがあります。わたしはいつも立ち止まって folding 
がどのように働くのかについて考えてしまいます。そしてまた、左からの folding と右からの 
folding の違いについても考えてしまいます (lists:foldl は左からの foldです)。これを複雑
だということは難しいでしょうが、そうやっていったん立ち止まるステップを踏んでから自分の
頭の中にあるディティールをたどることによって  mindlessly intuitive (考えなしの直感的な
もの?) から距離を置いているのです。

#むーgdgd

Compare this to the analog in array languages like APL and J. The "insert"
operation inserts a function between all the elements of a list and evaluates it. 
Going back to the sum example, it would be "+/" in J, or "insert
addition." So this:

これを APL や J のような配列型言語のようなもの (analog in array languages) と比較して
みましょう。"insert" 操作で関数をリストのすべての要素の間に挿入し、全体を評
価します。sum の例に戻ると、J では "+/"そうでなければ "insert addition."
となり、その結果:


1 2 3 4 5 6

turns to this:
これは次のようになります:

1 + 2 + 3 + 4 + 5 + 6

giving a result of 21. The mechanics here are so simple that you could explain them to 
a class of second graders and not worry about them being confused. There's nothing 
about iterating or accumulating or a direction of traversal or even parameters. It's 
just...insertion.

結果は21となります。この機構は小学二年生にも説明できるほど単純で、混乱するようなことを
心配する必要はありません。iterating や accumulating、あるいは トラバースの方向やパラメ
ーターといったものさえありません。あるのはただ、insertion です。


Now there are some edge cases to worry about, such as"What does it mean to insert 
a function between the elements of a list of length 1"? Or an empty list for that 
matter. The standard array language solution is to associate a base value with 
operators, like addition, so summing a list containing the single value 27 is treated 
as 0 + 27. I'm not going to argue that APL's insert is more general than fold, because 
it certainly isn't. You can do all sorts of things with the accumulator in a 
traditional fold (for example, computing the maximum and minimum values of a list at 
the same time).

さてここで、考慮すべき edge case があります。
"What does it mean to insert a function between the elements of a list of length 1"?
(長さが1のリストの!“要素間”に関数を挿入するとはどういうことでしょうか?) あるいは空
のリストに対してはどうなるでしょうか。標準的な配列言語のソリューションでは base value 
と 加算のような operators を結び付けます。ですから、ただひとつの値 27 からなるリストの 
summing は 0 + 27 と扱われます。わたしは fold よりも APL の insert の方がより一般的で
あると主張するつもりはありません。なぜなら、そうではないのですから。あなたはこうった類
のことすべてを traditional な fold にある accumulator でもって行えます(たとえば、ある
リストの最大値と最小値を同時に計算するとか)。


But in terms of raw simplicity of understanding, insert flat-out beats fold.
That begs the question:
Is the difficulty many programmers have in grasping functional
programming inherent in the basic concept of non-destructively operating on values,
or is it in the popular abstractions that have been built-up to describe
functional programming?

(If you liked this, you might like Functional Programming Archaeology.)


■_ 本日の巡回から

■_ awkもどきもーど

ひょっとして Perl のもご存じなかった?


あーありがち - Rubyのautosplitの結果は$FというグローバルなArrayに入る

Rubyのautosplitの結果は$FというグローバルなArrayに入る

いや知らなかった。

$ ruby --help
Usage: ruby [switches] [--] [programfile] [arguments]
  -0[octal]       specify record separator (\0, if no argument)
  -a              autosplit mode with -n or -p (splits $_ into $F)
  -c              check syntax only
  -Cdirectory     cd to directory, before executing your script
  -d              set debugging flags (set $DEBUG to true)
  -e 'command'    one line of script. Several -e's allowed. Omit [programfile]
  -Fpattern       split() pattern for autosplit (-a)

(snip

「awk でもいいんだけど Ruby が標準で持ってるメソッドを使えばもっと楽にできる処理」がた
ぶんあったんだと思うけど、なんか急に Ruby の autosplit を使って処理してみようと思い立
った。*1

で、使ってみたら split された結果がどこに入っているのか分からなくて困った。awk の代わ
りに使おうと思っているのでてっきり split した結果は $1, $2, $3, ... に入る、

help の $F という表記はそういう意味なんだと勝手に思い込んでしまっていた。

つまり、F は 1, 2, 3, ... に置き換えられるものなんだと。でも違った。

本当に $F という変数ができていて、しかも zero origin の Array だった。

まぁ確かに split は split であって back reference じゃないし、String#split の挙動と合
っているので自然なんだけどね。awk脳の恐怖っ。

※ その後、結局 autosplit はやめて普通に自前で回して自前で split して自前で処理した。

Usage: C:\Perl510\bin\perl.exe [switches] [--] [programfile] [arguments]
  -0[octal]         specify record separator (\0, if no argument)
  -a                autosplit mode with -n or -p (splits $_ into @F)
  -C[number/list]   enables the listed Unicode features
  -c                check syntax only (runs BEGIN and CHECK blocks)
  -d[:debugger]     run program under debugger
  -D[number/list]   set debugging flags (argument is a bit mask or alphabets)
  -e program        one line of program (several -e's allowed, omit programfile)
  -E program        like -e, but enables all optional features
  -f                don't do $sitelib/sitecustomize.pl at startup
  -F/pattern/       split() pattern for -a switch (//'s are optional)
  -i[extension]     edit <> files in place (makes backup if extension supplied)
  -Idirectory       specify @INC/#include directory (several -I's allowed)
  -l[octal]         enable line ending processing, specifies line terminator
  -[mM][-]module    execute "use/no module..." before executing program
  -n                assume "while (<>) { ... }" loop around program
  -p                assume loop like -n but print line also, like sed
  -P                run program through C preprocessor before compilation
  -s                enable rudimentary parsing for switches after programfile
  -S                look for programfile using PATH environment variable
  -t                enable tainting warnings
  -T                enable tainting checks
  -u                dump core after parsing program
  -U                allow unsafe operations
  -v                print version, subversion (includes VERY IMPORTANT perl info)
  -V[:variable]     print configuration summary (or a single Config.pm variable)
  -w                enable many useful warnings (RECOMMENDED)
  -W                enable all warnings
  -x[directory]     strip off text before #!perl line and perhaps cd to directory
  -X                disable all warnings

あ、まだバージョンあげてなかった。

Perl なんで、sigil は @ です。

いずれにしても、Rubyの場合多分グローバル変数に結果を格納しないと使い勝手が 悪くなると思われるので、「$F」というのは妥当と思いますが、 確かに awk のフィールド変数と混同するか。

■_

PHPって

Quora - Why did Quora choose Python for its development?
Why did Quora choose Python for its development?

Since Adam D'Angelo, the founder, had worked for Facebook, which heavily uses PHP. I 
am trying to understand the technical challenges the founders of Quora faced before 
they decided to go with Python rather than PHP.

PHP was out of the question. Facebook is stuck on that for legacy reasons, not because 
it's the best choice right now.[1] Our main takeaway from that experience is that 
programming language choice is very important and is extremely costly to change.

Python was a language that Charlie and I both knew reasonably well (though I know it a 
lot better now than I did when we started). We also briefly considered C#, Java, and 
Scala. The biggest issues with Python are speed and the lack of typechecking.

(略)

out of quesiton て。

■_ これは…

二番煎じ?


エクセルなどのマクロについて わが社ではエクセルなどでマクロを組むのは | OKWave

エクセルなどのマクロについて わが社ではエクセルなどでマクロを組むのは、大手企業では禁
止となっていると話をし、マクロを組まない方向で指導します。今まで組んだマクロは削除しろ
との話でありますが、日本全国で、現在本当にそういった状況なのでしょうか?

できればリンクなど教えていただきたいと思います。

投稿日時 - 2010-07-13 22:19:21

2010年07月12日

■_

寝る。

■_ 化物語

ふと気づいたのですが。


encapsulation - ウィクショナリー日本語版
出典: フリー多機能辞典『ウィクショナリー日本語版(Wiktionary)』

encapsulate

[編集] 名詞

複数 encapsulations

   1. カプセルに包むこと。
   2. 要約すること。
   3. (プログラミング) カプセル化


[編集] 動詞

encapsulate

   1. (…を)カプセルに包む。
   2. (…を)要約する。

この「カプセル化」って、最近わたしがよく言っている boxing (やその種の用語)を「ボックス化」という訳語にしてしまうのは、 実態とは異なる部分があってよろしくないのではないか というのと同じですよね。 つまり、「カプセルに閉じ込める」(カプセルに包み込む)のであって、 「カプセルにする」のとは違うだろうと(ニュアンス伝わるだろうか)。 とはいうものの、boxing の方はまだしもこっちをどうこうってのは さすがにもう無理かなあ。

■_ 本日の巡回から

■_ ○るぽ

日本に限らないのねえ。この話題は。

Global pointers cause segmentation fault? - Stack Overflow

When compiled by gcc and then run, the code

    int *p;
    int main() {*p = 1;}

causes a segmentation fault.

Apparently, the memory location contained in p cannot be written to.

Why????

On the other hand,

    int q[];
    int main() {*q = 1;}

runs just fine.

What's going on here??

Why does p contain only read-only memory?

実体はぜんぜん用意していないポインターをいきなり dereference した先に 代入しようとしてどーん。 後者の配列の方もなんか危ないけど(サイズをどこかで確定させないでリンクまでできたっけ?)。

The first example has a wild (not explicitly initialized) pointer. Since it's not an 
automatic variable, it is set to 0, which clearly is not memory you own. You can see 
this by printing it out with:

printf("%p\n", p)

As for the second, C99 §6.9.2 actually gives this as an example:

    EXAMPLE 2 If at the end of the translation unit containing

    int i[];

    the array i still has incomplete type, the implicit initializer causes it to have 
    one element, which is set to zero on program startup.
  
In general, objects with tentative definition (no initializer) are initialized with 0, 
which for an array means a 1-element array with element value 0.

I think gcc's warning sums it up: warning: array ‘q’ assumed to have one element - 
whether this is valid C, or just gcc being generous, I'm not sure.


Your first example causes a segmentation fault because you are dereferencing NULL. You 
never initialize p with a value, and because it's a global it will be NULL. Thus, you 
dereference NULL, and boom.

I'm not sure how the second example is valid - gcc notes that it is assuming q to be a 
1-element array, which is why that won't blow up.


First,

int *p;

defines a pointer. It doesn't define anything for the pointer to point to, so you 
can't assign to *p. You could assign to p. A pointer is not the same as the thing it 
points to.

In this case, p is initialised to a null pointer, which (as you deduced) is not a 
writeable address, but neither is it read-only, so the second part of your deduction 
isn't correct.

As for:

int q[];
int main() {*q = 1;}

My compiler (gcc) gives the warning: array "q" assumed to have one element, 
which should answer the question why it causes no problems. In addition to pointers 
not being the same as the things they point to, pointers are also not the same as 
arrays.


*p = 1; causes Segmentation fault because it was not allocated any memory before the 
assignment.

*q = 1;works because the compiler (gcc 4.2.1 on Mac OS X) warns that q[] is assumed to 
have one element.

警告はするみたいね。

■_ gawk

VM(?)化のテストコードをちょっと見た。 思ったよりは変更を加えられてないというか、でも細かいところは変わってるのか。

たとえば組み込み関数の length の実装。

/* do_length --- length of a string or $0 */

NODE *
do_length(int nargs)
{
	NODE *tmp;
	size_t len;

	tmp = s_pop();

	if (tmp->type == Node_var_array || tmp->type == Node_array_ref){
		static short warned = FALSE;
       		if (do_lint && ! warned){
			warned = TRUE;
			lintwarn(_("`length(array)' is a gawk extension"));
		}
		if (do_posix)
  			goto normal;	/* will die as fatal error */

		if (tmp->type == Node_array_ref)
			len = tmp->orig_array->table_size;
		else
			len = tmp->table_size;
	} else {
normal:
		if (do_lint && (tmp->flags & (STRING|STRCUR)) == 0)
			lintwarn(_("length: received non-string argument"));
	        tmp = force_string(tmp);
#ifdef MBS_SUPPORT
		if (gawk_mb_cur_max > 1) {
			tmp = force_wstring(tmp);
			len = tmp->wstlen;
			/*
			 * If the bytes don't make a valid wide character
			 * string, fall back to the bytes themselves.
			 */
			 if (len == 0 && tmp->stlen > 0)
				 len = tmp->stlen;
		} else
#endif
			len = tmp->stlen;
	}
	if (tmp->type == Node_var_array || tmp->type == Node_array_ref)
		free_temp(tmp);
	else
	         unref(tmp);
	return tmp_number((AWKNUM) len);
}

以前は、do_* の引数は木構造になった NODE* だったんですが、 ここでは int だけ。 名前からすると、スタックに積まれた引数の数とかなんだろうか。 ダミーっぽくもあるけど。 んで、 tmp = s_pop(); のように pop して取り出すと。

VM化 されてない方だとこんな感じ。

/* do_length --- length of a string or $0 */

NODE *
do_length(NODE *tree)
{
	NODE *tmp;
	size_t len;
	NODE *n;

	n = tree->lnode;
	if (n->type == Node_param_list)
		n = stack_ptr[n->param_cnt];

	if (n->type == Node_var_array
	    || n->type == Node_array_ref) {
		NODE *array_var = n;
		static short warned = FALSE;

		if (array_var->type == Node_array_ref)
			array_var = array_var->orig_array;

		if (do_lint && ! warned) {
			warned = TRUE;
			lintwarn(_("`length(array)' is a gawk extension"));
		}
		if (do_posix)
			goto normal;	/* will die as fatal error */
(略)

あー、一日か二日かがっつり時間とっていぢりたいところだがなあ。

2010年07月11日

■_

・同時通訳がつくらしい NHK ハーバード白熱教室

・自由ソフトウェアと選挙権
書こうと思ったがまとめるのが面倒なので止め。

・アプレンティスシップ・パターン
原書と見比べながら読んでたりしますが、こう訳すのかあと感心するところがたくさん。 しかし、マニフェストの202009年…

・HeadFirstデータ解析
まあこれではじめてみるのがいい人もいるんじゃないかと。 HeadFirstだし。

■_


スレを勃てるまでもないC/C++の質問はここで 15 
887 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 21:57:20 ID: Be:
    スレ違いかも知れまんが質問させてください。
    現在中学二年生で工科高校のシステム科を受験しようと考えています。
    それに伴い、C言語を学習しようと考えているのですが、どのような事をまなべばいいのでしょうか?
    いままでHSPというwindows用のインタプリタ言語を使いゲーム制作をしてきました。
    C言語でもゲーム制作を学習して良いのでしょうか?それともゲームなどとはちがうソフトウェア制作を学習したほうが良いのでしょうか。 

888 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 21:58:47 ID: Be:
    >>887
    ゲームで学ぶことを知っているのなら、
    ゲームで学んで十分。
    構造体やポインタ、メモリの動的確保。
    全部ゲームで押さえることができる。 

889 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 21:59:37 ID: Be:
    むしろゲームは集大成っていう 

890 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:03:53 ID: Be:
    普通高校に行きなさい 

891 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:06:35 ID: Be:
    工業高校は高卒で地元企業で一生下っ端もしくはたたき上げになるつもりがなければ行くメリット無し。
    普通の進学校いけ。プログラミングは学校で学ぶもんでもない。
    やりたいことなんていつ変わるかわからんのだし。 

892 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:07:39 ID: Be:
    プログラミングは独学するやる気があるなら全く学校に拘る必要はない。 

893 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:17:05 ID: Be:
    これからのIT産業は斜陽産業だぞ?
    景気の良かった頃でもゲーム開発は社員の寿命が短かった
    (若くても辞めざるを得なくなる)
    あまり勧められんなぁ 

894 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:18:33 ID: Be:
    入り口はどうあれ、結局最後は独学だよな。
    いかに言語の規格を正しく理解するか。
    コードをいっぱい読んでイディオムを見出し、
    設計に躓きまくってデザパタにも親しむ。
    APIリファレンスとホワイトボードだけが友達。 

895 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:31:26 ID: Be:
    はっきり言って常に新技術の勉強を続ける覚悟がいるぞ。 

896 名無しさん@そうだ選挙に行こう [void main() (笑)] 2010/07/10(土) 22:36:28 ID: Be:
    >>895
    若い頃は簡単でも歳食うとこれがまあかなり難しい。 

897 名無しさん@そうだ選挙に行こう [sage] 2010/07/10(土) 22:52:03 ID: Be:
    みなさんありがとうございます。
    別にゲーム制作を本業にするつもりは全くないです。
    ただ工科高校のシステム科は就職率が高いとのことなのでそちらを進路に選択しました。
    家庭事情的にも働かなければいけないので大学に行けないので…

    それならプログラムをまなぶ前にパソコン検定などの資格を取り、基本的な操作を学んだほうがいいのでしょうか? 


世知辛い喃。

■_ fgets?


C言語のfgets関数について どこのサイトでも危険危険と言われていますし、 gccから... - Yahoo!知恵袋

C言語のfgets関数について
どこのサイトでも危険危険と言われていますし、
gccからは使うなといわれるほどの危ない関数なら、
標準ライブラリから消してしまってはどうでしょうか?
過去との互換性とも言われていますが

どこで使うのかよくわかりませんし。

補足
    そうですね。gets関数です。


計算機はわりとなんでもそうですが、特に言語処理系とライブラリは互換性について非常にうる
さいのです。おいそれとは変更しません。追加はあっても削除は滅多にしません。使うな、とい
って使わないでいてくれるのは、使うなと言い出したあとの人たちだけです(それも全員じゃな
いが)。使うなというより前にかかれたソフトがコンパイルできなくなるand/or動かなくなるよ
うな変更は行われません。ソフトはものによっては作られてから何十年も動きつづけたり、ずる
ずると流用を続けられたりするのよ。

> どこで使うのかよくわかりませんし。
あなたは今の人だから使う機会は訪れません。使い捨てのつもりなら使っていいというものでも
ありません。

本人や内輪だけでしか使わない、取りあえず動けばいい簡易ツール的なプログラムでは、gets関数は簡単で便利です。
1度正常動作すれば2度と使うことのない、使い捨てのプログラムでも便利です。
限られた人しか使わないのであれば、使用には注意が必要なプログラムである事を周知可能です。
また、何か問題を起こしたとしても影響は限られ、そもそも注意点を無視する方が悪いのです。

標準ライブラリから消してしまうと、その後もgets関数をサポートする処理系は全て規格外の独自拡張扱いとなります。
また、それ以前の処理系は全て、旧規格扱いとなります。
あまにも影響が大きすぎて、いまさら消すことはできないと思います。

危険視されているのは
fgets
ではなくて
gets
ではないですか?
fgetsではなくgetsの話じゃないの?

http://www.kijineko.co.jp/tech/superstitions/gets-can-be-replaced-w...

追記:
上記のURLのページに
> 学校の課題などで、文字列の入力そのものが本題ではないのであれば、とりあえず gets で
手軽に入力処理を記述しておき、本題に注力するのは悪くありません。また、学校の課題ではな
くても、コード片の実験であったり、その場限りの使い捨てプログラムであれば、理解した上で 
gets を使ってもやはり問題はありません。

という記述があります。

要は使いよう。適材適所。使っちゃまずいところに使わない。
それだけの話のように思う。


gets は外そうって話あるけどねえ。

■_

これは教授にきちんと話したほうがいいんでないのかなあ。 77でなきゃならない理由というのもたぶん(説得力あるのものは)ないだろうし。


FORTRANのフリーソフトFTN77?FTN95? | OKWave

FORTRANのフリーソフトFTN77?FTN95?

こんにちは、理系大学3年生のものです。
夏休みの課題として、指導教授からFORTRANを学習するように言われました。

先生にはFTN Personal Edition 77をコンパイラとしてダウンロードしなさいと言われました。
宿題として出された参考書のタイトルにもFORTRAN77と書いてあります。


しかし、調べてみてもFTN77のダウンロード先が見当たりません。
どうやら、Salford FTN77の後継バージョンがSilverSoftからFTN95という名前になったらしいの
ですが、つまり、FTN77はもうダウンロードできないってことなんですか?

FTN95をダウンロードしてコンパイラとして使用したら、バージョンが違うから、FORTRAN77の参考書では不都合が起きますか?


できるなら参考書通りFTN77をダウンロードしたいと思っているのですが、できますかね?
それとも最新のFTN95をダウンロードするべきですか?


回答お願いします。

いまさら77をやるのはどうかと思うが...
77の標準機能だけなら,そのままコンパイルできるから気にせず最新のFTN95をダウンロードすればよい。


早速の回答ありがとうございます。


コンパイル大丈夫なんですか。
なんか、無理やりCPad for Salford FTN77でFTN95を立ち上げさせても、実行時にエラーになってしまうとか言ってる人もいるんですよね。。。

それが心配です。


■_ 本日の巡回から

■_ C vs Lisp

だめだー


ebhakt » C++ vs. Lisp

C++ vs. Lisp

At several points in my career development, I've been prompted to take a look at 
alternative computer languages. Usually I was worried about other languages being 
better than the one I was using at the time.

わたしの career development の several points において、わたしは alternative なコンピ
ューター言語に注目するように促され (prompt) ました。普段わたしは別のその言語が、自分が
その時使っていたものよりも良いものであることを心配していました


Sometimes my worrying has been justified. Being introduced to Pascal in college made 
me forever unsatisfied with my unstructured BASIC skills from high school, for example. 
But once I'd started programming in C++ on my job, I've never been seriously tempted 
to switch once I thoroughly investigated the alternatives.

ときにはわたしの心配が訂正 (justified) されることもありました。たとえば大学で Pascal 
に遭遇したことは、自分が持っていた非構造化 (unstructured) BASIC のスキルでは永遠に満足
できないようにしてしまいました。しかし自分の仕事で C++ を使ったプログラミングを始めるよ
うになると、わたしはすでに試した別の選択肢 (investigated the alternatives) に切り替える
ようには seriously に tempted (誘われる、引きつけられる) されませんでした


That's why I was intrigued when I ran across Peter Norvig's web page talking about 
Lisp as an Alternative to Java. He mentioned a study in which 38 C, C++ and Java 
programmers were asked to write versions of a program to compare Java and C++ 
efficiency. Norvig had written the program in Lisp in 2 hours, while the times for the 
C++ developers ranged from 3 to 25 hours.

それが、 Java の代替 (Alternative to Java) としての Lisp について言及しているPeter 
Norvig の web ページを見かけたときにわたしが興味を抱いた理由です。
Norvig は言及していました
a study in which 38 C,
C++ プログラマーたちと Java プログラマーたちはJava や C++ での効率 (efficiency) と比較
するためにプログラムを書いたバージョンを訊ねました。Norvig は Lisp をつかって二時間で
そのプログラムを書き上げましたが、その一方で C++ デベロッパーたちは三時間から 25時間か
かったのです。


After I read that, I knew I had to try the problem.

わたしはそれを読んだあとで、自分が挑戦すべき問題を知ったのです。


The Challenge (チャレンジ)

I spent a little over an hour jotting down some notes from the problem statement, 
wrote some pseudocode and then jumped in. I was disappointed when I finished almost 
eight coding hours later after making some late-night debugging and logic blunders. I 
figured if I hadn't stayed up so late trying to finish it, I might have made it in 
six hours. Most of my mistakes came from not understanding the problem thoroughly.

I spent a little over an hour
jotting down some notes from the problem statement, 

wrote some pseudocode and then jumped in.
ちょっとした疑似コード (pseudocode) を書いてから jump in しました。

深夜のデバッグと logic blunders のあとで
それを終えたときには自分が 8時間ほどもコーディングに時間をかけていたことに
がっかりしました。
そして、もし stayed up so late trying to finish it していなければ、
6時間で完成できたかもしれないことに気がつきました。
わたしの犯したミスの大半は問題の完全には理解していなかったことに起因していたのです。

However, I wasn't complaining too much. I was still under the median time (~11 hours) 
for the rest of the C++ programmers in the study. My LOC for the program was below the 
median for the other C++ coders as well: 220 non-comment non-blank lines for my code 
vs. ~275 lines for the others. I believe one of the main reasons my program was 
shorter than average was that I took advantage of the C++ Standard Template Library 
(STL), which for some curious reason was avoided by all the other coders in the study.

しかしわたしは不平を言いすぎることはありませんでした。わたしはそれほど時間をかけていて
さえ、自分以外の in the study なC++プログラマーたちの所要時間のメディアン値であるおお
よそ11時間を下回っていたのです。そのプログラムに対するわたしの LOC も他の C++ コーダ-
たちのメディアン値を下回るもので、コメントと空白行を除いたわたしのコードは 220行でした
が、ほかの人のコードは 275 行くらいにまでなっていました。わたしは自分のプログラムが平
均よりも短い主な理由の一つが、自分は C++ の Standard Template Library (STL) のアドバン
テージを持っていたことであると信じていました。
which for some curious reason was avoided by all the other coders in the study.



However, what still bothered me was that Norvig's Lisp version was so much shorter: 
45 lines vs. my 220 lines. It made me so curious that I had to figure out why. I hadn't
looked at Norvig's code at all before since I didn't want to gain any ideas from 
it, but now I studied it in earnest. I dug out my old copy of Paul Graham'sANSI 
Common Lisp and began to decipher Norvig's program. Once I understood the logic, I 
decided to code it in C++ myself to prove that there was nothing special about Lisp. I 
believed that an equivalent C++ program could be written in the same number of lines, 
if I simply took Norvig's approach. After 3 hours, I finished my Lisp to C++ port of 
Norvig's code using Visual Studio .NET. (I used VS.NET because it provided STL hash 
table functionality, and Norvig was making use of CL's built-in hash table 
implementation in his program.) Converting the code took longer than I expected – I 
was simply unable to translate the program line-for-line. I had cut my program's size 
in half (142 lines), but even with my changes, I still wasn't able to get close to 45 
lines.

しかしそれでもなおわたしを悩ませた (bothered) のは、C++ の220行に対して Norvig の Lisp 
バージョンは 45行とさらに短いものであったことです。それは、なぜなのかを突き止めなけれ
ばならないようにわたしをとても curious にさせました。それまでわたしは Norvig のコード
を見たことがありませんでした。なぜならそこから一切アイデアを得たくなかったからですが、
そのときわたしは in earnest で学びました。わたしは Paul Graham の ANSI Common Lisp の
本を引っ張り出して Norvig のプログラムの解読を始めました。ロジックを理解して Lisp につ
いて特別なことはないもないことを prove するために C++ でコーディングすることに決めまし
た。わたしは、単に自分が Norivig のアプローチを採用するだけで等価な C++プログラムを同
じ行数で書くことができるだろうと確信しました。三時間後、わたしは Visual Studio .NETを
使っての Norvig の Lispコードの C++ への移植を完了しました(.NET は STL のハッシュテー
ブルを functionality に提供していましたし、Norvig は CL の組み込みのハッシュテーブル実
装を彼のプログラムで使っていたためです)。コードの変換は自分が見込んでいたよりも長い時
間を要しました。プログラムを line-for-line で translate することができなかったのです。
わたしは自分のプログラムのサイズを半分に切り詰めましたが、変更を行ったあとでさえ 45行
に迫ることはできませんでした。


Style differences (スタイルの違い)

I wasn't sure of all the reasons I couldn't match the conciseness of Lisp in C++, 
but I could intuitively see some differences in the coding styles. One major 
difference seemed to be that Lisp could combine more on one line than my C++ code.

わたしは自分が match the conciseness of Lisp in C++ できなかった理由について確信がもてませんでした。
しかしわたしはコーディングスタイルに幾つかの違いを intuitively see できました。
大きな違い (major difference) のひとつは
わたしの書くC++ コード以上に Lisp では
複数のものを一行にまとめる (combine) ことができるらしいことです。


Consider the following statements from my code:

わたしのコードにあった次のような文を考えて見ましょう:

words.reverse();
cout << num << ":";
for (list<string>::const_iterator i = words.begin(); i != words.end(); ++i)
    cout << *i;
cout << "\n";

These lines are used to print out the alphanumeric encoding for a specific phone 
number. The encoding is stored as individual words/digits in a list variable called 
‘words'. In this code, the ‘words' list is reversed (since it was originally 
stored in reverse order) and the original phone number is printed, followed by the 
space-separated ‘words' list.

この一連の行はある特定の電話番号を alphanumeric encoding して出力するものです。その 
encoding は ‘words' という名前のリスト変数に個々の words/digits として格納されていま
す。このコードでは ‘words' リストは反転されていて (元のリストで反転した順序で格納され
ているため)、空白で区切られた 'words' リストが後続している (followed by the 
space-separated ‘words' list) オリジナルの電話番号が出力されます


To do the same thing in Norvig's code took only one line:

同じことを Norvig のコードで行うとたったの一行にしかなりません:


(format t "~a:~ {  ~a}~%" num (reverse words))


This particular example showcases one of Lisp's strengths:
functional programming. Almost every operation performed in Lisp returns values 
instead of modifying variables. [1]  Keeping with our above example of reversing a 
list, calling (reverse words) in Lisp would return a new reversed list while leaving 
the original list untouched. So in the Lisp code, reverse immediately hands off its 
new list to format, which then prints it.

この例は Lisp の強みの一つである 関数プログラミング (functional programming) の showcases
です。Lisp におけるほぼすべての操作は変数を変更するのではなく値を返します。[1]先の例で
は、リストをひっくり返す (reversing) ために Lisp では反転ずみの新しいリストを返してい
て、オリジナルのリストは変更されずにそのまま残しておいて反転済みの新しいリストを返す 
(reverse words) を呼び出していました。ですから例にあった Lisp のコードでは
reverse immediately hands off its new list to format,
which then prints it.
format のために新しいリストを即座にreverse して hands off して、
それからそのリストを出力します。


In contrast, C++ modifies the existing list in-place when words.reverse() is called 
and returns void.  This means that the cout statement which prints the list to the 
console has to be on a separate line, because there is no return value from the 
function that is printable. Characteristically then, C++ normally consists of one or 
two distinct operations per line because many functions or algorithms directly modify 
the variables that are passed to them.

対照的に C++ では words.revers() が呼ばれたときに既存のリストを in-place で変更し、そ
して何も返しません (returns void)。これはコンソールへリストを出力する cout ステートメ
ントを分割された行に置かなければならないことを意味します。Characteristically にはそれから
C++ では通常通り、一行辺り一つか二つの distinct operations にすることに固執 (consists)
しています。それは関数やアルゴリズムの多くが渡された変数を直接変更してしまうからです。


Also, notice that I had to print out the list explicitly — cout doesn't know how to 
print an STL list by default, a rather egregious fault in my book. (However, we can 
solve this with C++ operator overloading, a fairly advanced skill.)

同様に、cout は STL の list がデフォルトでどのように出力するかを知らないので
explicitly にリストを出力しなければならなかったことに注意してください。
a rather egregious fault in my book.
(ただしこれは a fairly advanced skill である C++ の演算子オーバーローディングを使って解決できます)。


Operating on Pointers (ポインターを使った操作)

I also found other stylistic differences between Lisp and C++.  Here is another sample 
line from Norvig's program …

わたしは Lisp と C++ の間にある別の stylistic differences も見つけました。以下のものは 
Norvig のプログラムにあった行のもう一つのサンプルです


(loop for word in (gethash n *dict*) do … and a particularly ugly line from my code …

for (HashMap::iterator i = gDict.equal_range(n).begin(); i != gDict.equal_range(n).end(); i++)



(notice that hash_multimap has been typedef'd to make things less wordy!)

less wordy にするために hash_multimap が typedef されていることに注意してください! 


Both the Lisp and the C++ versions perform the same operations (looking up 0 or more 
values from a hash map by key), but the Lisp version is obviously less wordy and, I 
believe, more understandable.

Lisp 版と C++ 版の両方とも同じ操作 (hash map からキーによって取り出した0個以上の値を検
索する)を実行しますが、Lisp 版のほうが明らかに less wordy であり、より理解しやすいもの
であるとわたしは確信しています。


The Lisp code is more concise here because the loop is operating on words contained in 
the hash map. Instead of words, the C++ code is returning STL iterators, which are 
object-oriented versions of pointers. The iterators need dereferenced to obtain the 
words, which isn't a significant problem. However, look at the loop structure itself 
and how many keywords are devoted to dealing with iterators (iterator, begin, end ) 
which have nothing to do with the actual task — looping over words in the hash map.

この Lisp コードはループがハッシュマップに格納されている words に対して操作しているの
で、 more concise です。C++ 版では words ではなく STL の (ポインターのオブジェクト指向
バージョンである) イテレーターを返しています。このイテレーターは words を入手するのに
dereference が必要ですが、それはたいした問題 (significant problem) ではありません。
しかしループの構造そのものやイテレーターを扱うのに実際のタスクに対してはなにも関わって
いないキーワード (iterator, begin, end ) がどのくらい使われているのかに注目すると、ハ
ッシュマップにある words に対してループしているのです。


I believe most of the complexity of the STL arises from its explicit use of iterators. 
99% of the time you want to iterate over the entire container in a loop, and in 
searches you're interested in the value itself, not the pointer to the value. 
Iterators simply provide no benefit in these circumstances. My conclusion from 
extensive use of the STL is that iterators are mostly useless and should be abstracted 
away everywhere possible.

わたしは STL の複雑さというものの大半はイテレーターを明確な形で使っている (explicit 
use) ことに起因しているのだと考えています。あなたがループでコンテナー全体を通してイテ
レートしたいときの 99% まで、また値それ自身を検索するときに求めているのは (イテレータ
ーである)ポインターではなく値なのです。こういった circumstances においてはイテレーター
はなんの benefit ももたらしません。わたしの extensive use of the STL からの結論は、イ
テレーターは mostly useless であり、
should be abstracted away everywhere possible であるということです。


Also, there's an additional side effect that results from iterator use. I prefer the 
style of the C++ loop as above, but as it stands, it is not optimized. The end 
iterator really should be calculated outside of the for loop so that it is not 
recalculated on each pass. In addition, the iterator should be incremented using 
prefix notation (++i) instead of postfix (i++) to avoid inefficiences resulting from 
temporary objects as well.[2] These kinds of considerations are typical of the 
low-level idioms that a C++ developer must keep in mind when writing their code. It is 
also these kinds of aspects that a Lisp developer is shielded from with Lisp's 
higher-level constructs. [3]


同様に、イテレーターを使用したことによる付加的な副作用 (additonal side effect) があり
ます。わたしは上述した例にあるような C++ 形式のループが好みですが、それが示すように 
(as it stands) 最適化がなされていません。このループにある end イテレーターは実際には 
for ループの外側で計算されるべきもので、ループのパス毎に再計算する必要はありません。そ
れに加えて、このイテレーターでインクリメントをするのには、無用な一時オブジェクトを生成
することによる効率低下を防ぐためにポストフィックス (i++) ではなくプリフィックス (++i) 
を使うべきです。[2]  この種の considerations は C++ デベロッパーがコードを書くときに心
に留めておかねばならない典型的な low-level イディオムです。
It is also these kinds of aspects that a Lisp developer is shielded from
with Lisp's higher-level constructs. [3]



Making Life Simpler
(人生をもっとシンプルにする)


One other lesson that can be learned from Lisp is that it is well suited to bottom-up 
programming. That is, in the words of Paul Graham,

Lisp から学ぶことのできる One other lesson はそれがボトムアッププログラミングに well 
suited であるということです。つまり、ポール・グレアム (Paul Graham) の言葉を借りればこ
ういうことです。

    Instead of just writing a program in Lisp, you can write your program on Lisp, and 
    write your program in that.[3]


Graham goes on to say that he believes that Lisp is the language most naturally suited 
for bottom-up programming, even though other languages can be written in this style as 
well.

Graham goes on to say
that he believes
Lisp はボトムアッププログラミングに最も自然に suited な言語であり、
他の言語であってもこのスタイルで同じように書ける。


I will definitely say that after six years of C++ programming, I have tended to stay 
with what the language and library have given me. C++ tends to keep you focused on 
small details, rather than think in terms of building up the language to suit the 
problem. Freedom from this mindset is one of the most revolutionary things Lisp has to 
offer. With the poweful alternative Lisp was providing, the real question for me was 
whether to leave C++ and embrace Lisp, or to try to bring the idea of bottom-up 
programming to my own language.

I will definitely say
that after six years of C++ programming,
六年間の C++プログラミングのあとで
I have tended to stay with what the language and library have given me.

C++ はあなたに細かなディティールに fuocus させ続ける傾向があります。
この mindsed からの解放 は Lisp が offer しなければならないもっとも revolutionary 
things のひとつです。Lisp が提供していた強力な alternative があったとき、わたしにとっ
ての real question は C++ を使うのをやめて Lisp を embrace するかどうかあるいはボトム
アッププログラミングの考え方をどのように my own language に持ち込むことを試みるか。と
いうことでした。


I wish I could say that Lisp was clearly the right choice for me, because the powerful 
constructs of the language and the unified high-level syntax have intellectual appeal. 
The difficulty for me is writing Lisp in practice. Dealing with parentheses placement 
and prefix notation simply get in the way of my thought process.

わたしは Lisp がわたしにとっての正しい選択であると、明快に (clearly the right choice for 
me) いえたら良いなと願っています。それは Lisp という言語の powerful constructs 
と unified された high-level syntax が intellectual appeal するからです。わたしにとって難しい
のは実践で Lisp を使って書くことです。カッコの配置 (parentheses placement) や前置記法
の扱いはsimply get in the way of my thought process.
#すっと頭に入ってきた。なじんだという感じ?

I probably would still struggle through writing Lisp code if it wasn't for the fact 
that the STL is so powerful. Lisp's lists are flexible and can be used to represent 
everything from arrays to linked lists to queues, but all those containers are already 
built into STL.

もし STL がそれほど強力ではなかったとしたら、わたしは今でも Lisp のコードを書くのに四
苦八苦していたことでしょう。Lisp のリストは柔軟 (flexible) であり配列からリンクつきリ
スト、キューにいたるまで何を表現するのにも使えます。けれどもそういったコンテナーの全て
はすでに STL に組み込まれているのです。



A Better STL (よりよい STL)

I decided to stick with C++ and try to make it better. But how? My first thought was 
to get rid of iterators. I decided to rewrite all of the STL's algorithms to accept 
containers instead of iterators. But more importantly, I decided to also make the 
algorithms (where possible) return copies of containers instead of iterators as well. 
This would enable the functional programming that makes Lisp code so succinct.

わたしは C++ に固執して(プログラムを)さらによいものにすることを試みることにしました。
でもどうやって? わたしが最初に考えたのはイテレーターを取り除くことでした。イテレーター
の代わりにコンテナーを受け付けるようにSTL の algorithms を全て書き直すことにしました。
しかしもっと重要なのは、algorithms が (可能である場合に)イテレーターではなくコンテナー
のコピーを返すようにしたことです。これは、Lisp のコードをとても簡潔なものにしている関
数プログラミングを可能にします。


Secondly, I would attempt to build another layer of utility functions on top of the 
STL to perform common tasks such as tokenizing strings, looking up values in 
containers, reading from files … I decided to take a page from both Lisp and Python 
in the types of high-level functions to include.

第二に、STL の top に文字列の tokenizing、コンテナーに対する値の検索、ファイルからの読
み込みなどのような一般的なタスクを行うためのユーティリティ関数のもう一つのレイヤーを構
築しようとしました。わたしは含めるべき高水準関数 (high-level functions) の型に
Lisp と Python の両方から take a page することにきめました


It soon became clear I was writing my own library, and one that I hoped would be 
useful outside of a small coding contest. However, my criteria for success would be 
whether I could make a C++ program with my library as small as Norvig's code … and 
just as readable.

わたしが自前のライブラリ (my own library) を書いたときにそれはすぐに明らかになりました。
and one that I hoped would be useful outside of a small coding contest.
しかしながらわたしの criteria for success  は自分のライブラリを使ったC++プログラムを
Norvig のコードと同じくらい小さくするかあるいは単に読みやすくするかのいずれかになりま
した。


The results are located on my software page. The library I named EasySTL; my new 
revised program is located here. The new line count is 79 lines. However, to be on par 
with Norvig's Lisp code, the #include and using statements for the STL headers and 
the separate lines for curly braces should not be counted (since this is simply a 
style issue between C++ and Lisp). With these provisions on the counting, the revised 
C++ code comes in at 48 lines.

その結果はわたしの software page に置かれています。そのライブラリを EasySTL と命名しま
した。新しい revised program はここにあります。新しいものの行数は79行でした。ただし、
Norvig のLisp コードと比較するには、STL ヘッダーのための#include 文とusing 文、そして
カーリーブレースのために分割された行はカウントすべきではありません (それは単純に C++
と Lisp のそれぞれのスタイルの問題だからです)。行数カウントのこの provision を使うと、
revised された C++ のコードは 48行になりました。



So What Does It Prove?

I was able to match the functionality of Lisp in C++ for a small sample problem. Not 
very scientific, I suppose, but it tells me C++ isn't all that bad. Maybe the STL is 
slightly low-level, but with a little effort, it can be brought up to the level of a 
language like Lisp in important areas.

小さなサンプルプログラムでは、C++ を使って Lisp の functionality の大部分が可能にでき
ました。さほど scientific ではありませんが、このことはわたしにC++ はそれほど悪いもので
はないということを示していると思います。STL は slightly に low-level ですがちょっとし
た労力を掛けることで、important areas における Lisp のような言語のレベルにまで brought 
up to できます。


Of course, Lisp has a lot of other things going for it, like automatic garbage 
collection (which makes functional programming much more efficient), macros (like C++ 
templates on steroids) and lambda functions. But then C++ has its own strengths: 
extensive library support, solid tools, and of course, its premier status as a 
programming language for Windows.

もちろん、Lisp は自動ゴミ集め (関数プログラミングをより一層効率よくするものです)
やマクロ (like C++ templates on steroids)、λ関数 (lambda functions) のような数多くの 
other things going for it を持っています。しかし C++ はextensive なライブラリのサポー
ト、solid なツール群、そしてもちろん Windows 向けプログラミング言語としての premier 
status という独自の強み (strengths) を持っています


However, this little contest does prove one thing to me: C++ needs to be simpler out 
of the box. The recent popularity of Java and C# have proven this. Fewer and fewer 
people will continue to trade programmer productivity for processor cycles. 

しかしこのちょっとしたコンテスト (little contest) はわたしにひとつのことを prove しました:
C++ は out of the box でより simple になる必要があります。
Java や C# の最近のユーザー人口 (recent popularity) がそれを proven しています。
Fewer and fewer people will continue to trade programmer productivity for processor cycles. 


The C++ standards committee has begun meetings to decide the next C++0x standard. It's
time to decide: what kind of language does the community need? One that is simpler and
more high-level, or one that is increasingly complex and verbose?

C++ の標準委員会は次の C++0x 標準を決定するための meetings を開始しています。It's time 
to decide: what kind of language does the community need? (委員会が必要としている言語
の種類は何か?) One that is simpler and more high-level, or one that is increasingly 
complex and verbose? (シンプルなものとより高水準なもののいずれなのか、あるいは、複雑さ
と冗長さを増加させるものなのか?)


I think it's clear that Lisp has lessons in productivity and succinctness that are 
worth pursuing.

Lisp が prodcutiotivity において lessons を持っていて、また worth pursuing である 
succinctness を有していることは明白なことだとわたしは考えています。


[1]ANSI Common Lisp by Paul Graham, pp. 22-23.

[2] Exceptional C++ by Herb Sutter: Item 6, "Temporary Objects"

[3] For more on this topic, see Todd Proebsting's comments on "Language Design: C vs. Lisp"
in his presentationDisruptive Programming Language Technologies.

[4]On Lisp by Paul Graham, vi.

This entry was posted on Saturday, May 1st, 2010 at 3:22 pm and is filed under Programming.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

■_ ちゅっちゅっちゅー

宇宙ショーへようこそ観てきました! - みねこあ あれ? 今週はつれづれなしっすか?


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

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

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