アカウント名:
パスワード:
LISTコンテキストだから@array = ( undef );になってるだけでは?
「何が起こっているのか」は多分そうなんでしょう。
「何が起こって欲しいのか」とはかなり違うっていうだけの話で…。
古い格言に曰く、プログラムは思った通りではなく、書いた通りに動く。
@arrayを未定義値にしたいなら、
@array = undef;
ではなく
undef @array;
と書くべきだったという話ですかね。
undefの返値がLISTコンテキストで()と解釈されて欲しいと思うこともあるかもしれませんが、それはそれで、
select undef, undef, undef, 0.1;
とか書けなくて不便という。
ある種のLISPにおけるnilの扱いと混同しがちですが、結局のところ、Perlにおける()とundefを理解して適切に使い分けるのが吉かと思います。
混乱したらperldata(1)やperldoc -f undefを読み返しましょう。
「問題が配列の初期化にあるのであって、push の段階にあるのではない」(関数へのリファレンスを作って、push している段階は正しい)という所に行きつくまでが大変でした。
そもそもは、ナンプレを解くプログラムのフレームワークの部分を作ってたんですけどね。候補を絞り込むための関数を一杯作って、処理の軽い奴から順に配列に push して、[0]から順に適用していく。で、[$i] を実行したら「どこかに答の絞り込みが行われた(たとえば、あるマスは今まで「3,5,7」があり得たが、「5」は候補じゃないと判った、とか)場合、その結果に対して[0]から再び適用していく事を繰り返したい。というものを作ろうとして…ここではまったもんで。
はて、pushの段階ではエラーは出ていないし、「"" が関数じゃない」ってそんなものを押し込んだ覚えはないし…、関数のリファレンスってこうやって作るんじゃなかったのか…あるいは関数のリファレンスをコールする方法が間違ってるのか…と、いろいろ悩んでしまいました。
一旦原因が判ってしまえば、直すのも、「ん?本当にそういう事??」というのを確認するためのテストコードを書くのも一瞬なんですが…。とにかく、「何を与えられようとも、可能な限り実行を続けようといろいろ型変換してくれる」というのは、ありがたくもあり、想定外の動きをした時に何が悪かったのか判らなくなる元でもあり…
----
ちなみにやりたい事は、「仮置き無しで、すべてのナンプレを解くことは可能か?!」知りたい、というものです。
すべてのマスに対して仮置きを繰り返せばナンプレは必ず解けますから。余りにも必殺すぎてつまらないので、『封じ手』にしたらどうなるのか知りたいのです。# 仮置きするとその結果が伝搬して「どこかのマスで矛盾が生じる」から、その仮置きが否定される。# ならば矛盾の伝搬を先に追いかける方法があるんじゃないかと…それを使えば「仮置きするはずだったマス」の候補を絞れるのではないかと。
面白そうなので、自分も(好みにより言語はHaskellで)書いてみようと思ったら、すでに沢山あって [haskell.org]ちょっとクラクラしました……。
No guessing [haskell.org]ってのがokkyさんと似た動機で書かれた版かな。リスト中のアルゴリズムを順に試して、うまく行ったらまたリストの最初から繰り返す、という造りも同じようです。
Sudoku Solver [kyoto-u.ac.jp]等、似たようなプログラムが見付かるところを見ると、やはり誰しも書きたくなる題材なのですかね。
時間ができたら自分でも遊んでみたいと思います。面白いネタに気付かせて戴いて有難うございました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
LISTコンテキストだから (スコア:1)
LISTコンテキストだから
@array = ( undef );
になってるだけでは?
Re: (スコア:1)
「何が起こっているのか」は多分そうなんでしょう。
「何が起こって欲しいのか」とはかなり違うっていうだけの話で…。
fjの教祖様
Re:LISTコンテキストだから (スコア:1)
古い格言に曰く、プログラムは思った通りではなく、書いた通りに動く。
@arrayを未定義値にしたいなら、
ではなく
と書くべきだったという話ですかね。
undefの返値がLISTコンテキストで()と解釈されて欲しいと思うこともあるかもしれませんが、
それはそれで、
とか書けなくて不便という。
ある種のLISPにおけるnilの扱いと混同しがちですが、
結局のところ、Perlにおける()とundefを理解して適切に使い分けるのが吉かと思います。
混乱したらperldata(1)やperldoc -f undefを読み返しましょう。
Re:LISTコンテキストだから (スコア:1)
「問題が配列の初期化にあるのであって、push の段階にあるのではない」
(関数へのリファレンスを作って、push している段階は正しい)
という所に行きつくまでが大変でした。
そもそもは、ナンプレを解くプログラムのフレームワークの部分を作ってたんですけどね。
候補を絞り込むための関数を一杯作って、処理の軽い奴から順に配列に push して、[0]から順に適用していく。
で、[$i] を実行したら「どこかに答の絞り込みが行われた(たとえば、あるマスは今まで「3,5,7」があり得たが、「5」は候補じゃないと判った、とか)場合、その結果に対して[0]から再び適用していく事を繰り返したい。というものを作ろうとして…ここではまったもんで。
はて、pushの段階ではエラーは出ていないし、「"" が関数じゃない」ってそんなものを押し込んだ覚えはないし…、関数のリファレンスってこうやって作るんじゃなかったのか…あるいは関数のリファレンスをコールする方法が間違ってるのか…と、いろいろ悩んでしまいました。
一旦原因が判ってしまえば、直すのも、「ん?本当にそういう事??」というのを確認するためのテストコードを書くのも一瞬なんですが…。
とにかく、「何を与えられようとも、可能な限り実行を続けようといろいろ型変換してくれる」というのは、ありがたくもあり、想定外の動きをした時に何が悪かったのか判らなくなる元でもあり…
----
ちなみにやりたい事は、「仮置き無しで、すべてのナンプレを解くことは可能か?!」知りたい、というものです。
すべてのマスに対して仮置きを繰り返せばナンプレは必ず解けますから。余りにも必殺すぎてつまらないので、『封じ手』にしたらどうなるのか知りたいのです。
# 仮置きするとその結果が伝搬して「どこかのマスで矛盾が生じる」から、その仮置きが否定される。
# ならば矛盾の伝搬を先に追いかける方法があるんじゃないかと…それを使えば「仮置きするはずだったマス」の候補を絞れるのではないかと。
fjの教祖様
Re:LISTコンテキストだから (スコア:1)
面白そうなので、自分も(好みにより言語はHaskellで)書いてみようと思ったら、
すでに沢山あって [haskell.org]ちょっとクラクラしました……。
No guessing [haskell.org]ってのがokkyさんと似た動機で書かれた版かな。
リスト中のアルゴリズムを順に試して、
うまく行ったらまたリストの最初から繰り返す、
という造りも同じようです。
Sudoku Solver [kyoto-u.ac.jp]等、
似たようなプログラムが見付かるところを見ると、
やはり誰しも書きたくなる題材なのですかね。
時間ができたら自分でも遊んでみたいと思います。
面白いネタに気付かせて戴いて有難うございました。