gm300の日記： 「scheme入門」読む 7
日記 by
gm300
本文の割に、問題が簡単。(4章までは) あまりにも難しいとやりきれないが。
まだ途中だがクロージャで悩む。call/ccはまだ。
http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3AScheme%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AE%E3%83%AC%E3%83%99%E3%83%AB10
クロージャ：便利かもしれないが、バグの温床ではないかと思う。
クロージャを使おうとしてバグるのはかまわないが、letでlocalを作ったつもりができていない時とか、困りそうだ。常に、cc-imenu-objc-generic-expression-general-func-index みたいな長い名前を使っていれば偶然上のscopeでもバインドされているという可能性は減るが、それだと今度は、名前をタイプするのに疲れる。 c-i-o-e-g-f-i でいいじゃん という意見もあるかも知れないが、アルファベットは26しかないので同じような綴りはたくさんある。common-index-on-ginger-enhanced-grape-fruite-injetion という変数が作れなくなるのは悲しい。scope の内側から外側を眺めることができるが逆はできないというのは lisp 的に考えれば当然かもしれないが、C/C++的な考えとはかなり違う。structure, class みたいにデータを階層的に構造化する方法ないとめんどうな気がする。全部リストで渡すって？
他人が作った密かにクロージャを使った＆それゆえバグっているプログラムを見るのは死ぬ程疲れそうだ。編集の都合上ローカルな関数定義を違うところに移したり、なんとなくローカルな変数を操作すると、使っている関数にはその変数を渡していないにもかかわらず挙動が変になる。staticっぽく見えるにもかかわらず実行中に関数の定義が行われたときのコンテキストに依存するというのはなー
Fibonatti 数列を作るのに Fb(n) = Fb(n-1)+Fb(n-2) だけじゃ嫌だぞ。top down 方式の場合、足し算以外の処理時間が0、足し算は10Gops/sec だとしても Fb(100) の計算が終らない。Fb(50)だって何日もかかる。当然だが bottom up で計算すればFb(1000)でもあっというまだ。教科書的な本なので、ここらの計算効率の観点からのコメントが欲しいよ。
値が不定になる場合がある特殊フォームが多いのもいや。#f になるとか、なんとかして欲しい。その点 Python の while .. else とかは興味深い。
ひきつづく項目を単順に並べるだけで構わない場合と、listにしないといけない場合があって構文ごとに違うのもいや。
(define (func (arg0 arg1 arg2)) ((func-body0) (func-body))) なら分かりやすいけど、
なくてもわかるという理由で省略しなくてはいけない。
set! とか let* みたいに変な文字が付くのもいや。いつも変な文字かと言うと letrec みたいなったり symbol->string string-length みたいなるのもいや。
でもいろいろ書いてみると興味深い。(9 8 7 6 5 4 3 2 1 0)と同じくらい簡単にreverseなしで (0 1 2 3 4 5 6 7 8 9)作りたい。できれば 10 文字くらいで。
まだ途中だがクロージャで悩む。call/ccはまだ。
http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3AScheme%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AE%E3%83%AC%E3%83%99%E3%83%AB10
クロージャ：便利かもしれないが、バグの温床ではないかと思う。
クロージャを使おうとしてバグるのはかまわないが、letでlocalを作ったつもりができていない時とか、困りそうだ。常に、cc-imenu-objc-generic-expression-general-func-index みたいな長い名前を使っていれば偶然上のscopeでもバインドされているという可能性は減るが、それだと今度は、名前をタイプするのに疲れる。 c-i-o-e-g-f-i でいいじゃん という意見もあるかも知れないが、アルファベットは26しかないので同じような綴りはたくさんある。common-index-on-ginger-enhanced-grape-fruite-injetion という変数が作れなくなるのは悲しい。scope の内側から外側を眺めることができるが逆はできないというのは lisp 的に考えれば当然かもしれないが、C/C++的な考えとはかなり違う。structure, class みたいにデータを階層的に構造化する方法ないとめんどうな気がする。全部リストで渡すって？
他人が作った密かにクロージャを使った＆それゆえバグっているプログラムを見るのは死ぬ程疲れそうだ。編集の都合上ローカルな関数定義を違うところに移したり、なんとなくローカルな変数を操作すると、使っている関数にはその変数を渡していないにもかかわらず挙動が変になる。staticっぽく見えるにもかかわらず実行中に関数の定義が行われたときのコンテキストに依存するというのはなー
Fibonatti 数列を作るのに Fb(n) = Fb(n-1)+Fb(n-2) だけじゃ嫌だぞ。top down 方式の場合、足し算以外の処理時間が0、足し算は10Gops/sec だとしても Fb(100) の計算が終らない。Fb(50)だって何日もかかる。当然だが bottom up で計算すればFb(1000)でもあっというまだ。教科書的な本なので、ここらの計算効率の観点からのコメントが欲しいよ。
値が不定になる場合がある特殊フォームが多いのもいや。#f になるとか、なんとかして欲しい。その点 Python の while .. else とかは興味深い。
ひきつづく項目を単順に並べるだけで構わない場合と、listにしないといけない場合があって構文ごとに違うのもいや。
(define (func (arg0 arg1 arg2)) ((func-body0) (func-body))) なら分かりやすいけど、
なくてもわかるという理由で省略しなくてはいけない。
set! とか let* みたいに変な文字が付くのもいや。いつも変な文字かと言うと letrec みたいなったり symbol->string string-length みたいなるのもいや。
でもいろいろ書いてみると興味深い。(9 8 7 6 5 4 3 2 1 0)と同じくらい簡単にreverseなしで (0 1 2 3 4 5 6 7 8 9)作りたい。できれば 10 文字くらいで。
許せる範囲と許せない範囲 (スコア:1)
でも原理原則って話しになると別問題ですね。速い別解はなんにしてもありがたい。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:許せる範囲と許せない範囲 (スコア:1)
でも 単なる負け惜しみで書くのですが、以下の点で x2-x-1 の解を使う方法はいやです。
1. 見た目上 答えが整数にならない。
2. fb(1)=1 fb(2)=4 みたいな変則的な問題の時にどうするか考えるが面倒。
3. tr(n) = tr(n-1)+tr(n-2)+tr(n-3) みたいになるともっと面倒。
いずれにせよ、O(2**n)はちょっと。top downでも途中結果を保存＆参照できればそれで O(n)になるので、そこらをスマートに書ければかっこいいです。
Re:許せる範囲と許せない範囲 (スコア:1)
わかなんなくなった私としては「境界ではどうなっているんでしょうか？」と言うしかない。
Copyright (c) 2001-2014 Parsley, All rights reserved.
ん？ (スコア:1)
単純に忘れたり、タイプミスするってないんですか？ (スコア:1)
思いつきで聞くのですが、特定のシンボルを指示すると -例えばクリックするとか- それがどこで定義されたかエディタ上でハイライトしてくれるとか できるんですか。
Re:単純に忘れたり、タイプミスするってないんですか？ (スコア:1)
定義場所をハイライトはなんとかmodeつかえばemacsで出来るかもしれませんが、知りません。
Re:単純に忘れたり、タイプミスするってないんですか？ (スコア:0)
そして、カーサにバルーンが表示されると便利になる一方「うっとおしい」という声も出てくるのが標準コース。