Pythonのお勉強 Part75 (961ﾚｽ)
上下前次1-新
642: (ﾌﾞｰｲﾓ MMf3-VwDZ) 08/09(土)16:31 ID:S08gCjhtM(1/2) AAS
>>641
超初心者だなw
643: (ﾌﾞｰｲﾓ MMf3-VwDZ) 08/09(土)16:32 ID:S08gCjhtM(2/2) AAS
>>641
いまだに数学だと教える先生がいるんだろ？
644: (ﾜｯﾁｮｲ 765f-cTHU) 08/10(日)07:20 ID:bJx41RG60(1) AAS
右辺値と左辺値
645: (ﾜｯﾁｮｲ 4e10-1ngM) 08/10(日)08:12 ID:5Q2KXoFZ0(1) AAS
アドレスとオブジェクトの違い程度ならいいんだけど、C++でムーブがらみでxvalueとか出てくるとピンと来ないんだよね。
646(2): (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)08:30 ID:rGiN2SBN0(1/10) AAS
右辺値と左辺値と言うと余計に判らなくなる
箱 = 値
というシンプルな理解だけで何も困らない
箱には名前があってアドレスを持っていて参照できる
値は箱に入れ終わったら忘れる
647: (ﾜｯﾁｮｲ 232c-1ngM) 08/10(日)09:41 ID:wxvmtlzV0(1/2) AAS
コンピューターのアーキテクチャの理解としてはそういう理解の仕方が本質的だと思うけど、Pythonのように、名前（変数）が束縛されているメモリ領域に格納されているのがポインタであって、そのポイント先のオブジェクトが（明示的な参照外しの構文によることなく）名前参照式の評価結果になるような言語では、表れ方がちょっと屈折してくるよね。
「Pytnonでは、変数は、箱のイメージではなくラベル（名札）のイメージで説明する方が適切」というのはしばしば言われる謂ではあるけれども、自分が初心者の人にPytnonを説明するときにそのスタンスでいくかと言われると、ちょっと躊躇するものを感じるかな。
648(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)09:54 ID:Rqt3voUn0(1/4) AAS
>>646
x = “foo”
y = x
は
箱 = 値
箱 = 箱
なのか？
箱 = 箱とは？
みたいな説明が必要になってくる
要は単純な箱と値だけでは説明がつかなくてそれらがどういうコンテキストで使われるかだったり箱から値を取り出して値として使う場合や箱自体を値として使う場合の説明も必要になってくるのでそうシンプルにはならない
649(1): (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)09:55 ID:rGiN2SBN0(2/10) AAS
イコール記号の意味の説明だよ
箱 = 値
と書くと箱に値を入れるという意味になる
箱や値の具体的な内容は違う章
650: (ﾜｯﾁｮｲ 0e46-Fa+d) 08/10(日)10:18 ID:mfIur7J+0(1) AAS
ポインタ アドレス渡しってのを明記しない限り
すべて値渡しでいいでしょ
それをいつまでたっても値なのかアドレスなのか毎回混同するやつって
トイレの男女マークはそれでいいのか？っつってるのと被って見える
実にうっとおしい
651: (ﾜｯﾁｮｲ 2357-XAuV) 08/10(日)10:24 ID:w6PHgqLv0(1) AAS
箱は大昔のBASICのような基本コピーな言語でしか通用せんよね
dictの中身がなぜ書き換わるのかイメージするには実体を意識したいし矢印かな
652(3): (ﾜｯﾁｮｲ f66d-1ngM) 08/10(日)10:26 ID:wmWYPlFf0(1/9) AAS
648の例で言うと、x = "foo"は（C言語レベルでは）名前（変数）xが束縛されているメモリ領域（646風にいえばxという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されるし、y = x は（C言語レベルでは）名前（変数）yが束縛されているメモリ領域（646風にいえばyという箱）にオブジェクト"foo"のアドレス情報を入れるという形で処理されることになる。したがって、（C言語レベルでは）646の箱=値という説明で一応一貫した説明ができる。ただし、そこでいう「値（オブジェクト）」はPythonレベルの値（オブジェクト）ではないので、その点に説明・注釈が必要になる。
ラベル（名札）のイメージによる説明というのは、名前x, y が束縛されているメモリ領域を特には観念せず、x, y をオブジェクト"foo"に貼り付けられるラベルとして捉えるということで、Pytnonレベルのみで考えるならこれはこれで1つの説明にはなっていると思う。ただ、listとかのコレクション・コンテナを理解するためには、結局どこかの段階でC言語のポインタの概念を大雑破にでもマスターせざるを得ないと思うんだよね。最初だけポインタの概念を回避してもあまり意味がないように思うので、それが、ラベル（名札）イメージによる説明にあまり乗りたくない個人的な理由。
ちなみに、648の逆パターンの例（x = 2 x = 5 のような再代入のパターン）も同様に考えることができる。
653: (ﾜｯﾁｮｲ 5a4e-a/Iv) 08/10(日)10:32 ID:RtPBWHAF0(1) AAS
Pythonは全て参照の値渡し
654: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)10:51 ID:rGiN2SBN0(3/10) AAS
難しいこと考えなくても、オブジェクト渡しという理解でいい
同じオブジェクトは渡された先でも同じものを指す
内部実装的には同じアドレスを見てるからだけど、
別に別アドレスだったとしても同じ挙動をすればアドレスはどうでもいい
数値とか、対応するアドレスが存在しないものもある
655(2): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)10:55 ID:Rqt3voUn0(2/4) AAS
>>649
イコール記号の意味だけなら「代入」で十分じゃないの？
代入という概念を知らない人向けの説明なら余計に「箱」が後でどう使われるのかも一緒に説明する必要がある
>>652
y = xではxという箱の中に入ってる値を一端取り出してからそれを複製してyという箱に入れないとダメだよね？
箱から取り出したり複製したりする状況(コンテキスト)も説明できなければ内部知識を知ってる人にだけなんとなく通じる説明方法でしかないと思う
656(1): (ﾜｯﾁｮｲ f66d-1ngM) 08/10(日)11:16 ID:wmWYPlFf0(2/9) AAS
>>655
y = x という代入構文において、①右辺のx という名前参照式の評価（名前xが束縛されているメモリ領域に格納されているポインタのポイント先のオブジェクトを得ること）、②それを名前yに代入すること（C言語レベルでは652に書いたとおり、名前yが束縛されるメモリ領域に上記①で得られたオブジェクトのアドレス情報を格納するという形で処理される）という処理が行われるわけだけど、このプロセスに状況（コンテキスト）による違いなんてあるかな？ 状況（コンテキスト）如何に拘らず、上記①②の処理がなされると思っていたんだけど。
まぁ、内部実装についてある程度知識がないと分かりづらいというのはそうだと思う。自分も非常に大雑把な知識しかないしね。
657(1): (ﾍﾞｰｲﾓ MM06-ZDX3) 08/10(日)12:21 ID:rZf5P+kFM(1) AAS
Pythonの場合は、numpyの配列のようにPythonオブジェクトの実体すらもPythonの世界の外に存在する物に対する荷札的な役割を果たしているケースがとても多く、
しかも初心者は学習を始めてすぐにそういうイレギュラーなものに触れることになる
なので内部実装を元に説明するのは辛すぎるんだろう
荷札のアナロジーは致命的な矛盾なくだいたいうまく説明できるし実際の動作とそんなにかけ離れてもいない、悪くない説明だと思うよ
658(1): (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)12:27 ID:swuUdv2c0(1/11) AAS
>>655
代入という言葉は、数学の変数に値を入れるという意味に引きずられるのでよくないんだよ
659(1): (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)12:35 ID:rGiN2SBN0(4/10) AAS
荷札って箱に付けるものでしょ
そうじゃなくて、実体とは別に存在するコピー可能な何かでないと
そんな都合の良いものは自然界に存在しないので、いいアナロジーも見つからない
660: (ｱｳｱｳｳｰ Sac7-Kgix) 08/10(日)12:43 ID:YgXeJoCWa(1) AAS
数学からの借用だと思うと
x = x + 1
は
x[n] = x[n-1] + 1
を意味する
661(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)12:49 ID:Rqt3voUn0(3/4) AAS
>>656
(Pythonの)(y = x という)(代入構文における)(右辺の)x
のxを修飾する部分がコンテキスト
それにその説明だと>>646の言うシンプルな理解からは程遠い気がする
662(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)12:56 ID:Rqt3voUn0(4/4) AAS
>>658
数学の変数に値を入れるという意味に引きずられると何でよくないの？
663: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)13:01 ID:rGiN2SBN0(5/10) AAS
x = x + 1
の処理毎に加算されていく、というカウンタ動作は、
数列の漸化式というよりは、z^(-1)みたいな離散時間で捉えると動作とよく合う
664(1): (ﾜｯﾁｮｲ 7a0a-WVpU) 08/10(日)13:03 ID:swuUdv2c0(2/11) AAS
>>662
数学だと正確にはその例でも左辺と右辺はイコールという意味だ
665: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)13:08 ID:rGiN2SBN0(6/10) AAS
代入(assign)は割り当てと同じ意味で、何かを別のもので置き換える
y = x + 1
なら何も困らない
x = x + 1
は割り当てではなくて関係式(equation)になって、xは未知数
そして解けない
666(2): (ﾜｯﾁｮｲ f6ce-1ngM) 08/10(日)13:22 ID:wmWYPlFf0(3/9) AAS
>>657
コレクション・コンテナを理解するためには、ラベル（名札）のアナロジーによらない方が正確に理解できるし、コレクション・コンテナの重要性を考えるとそれは致命的な弱点だと思うけどね。たとえば、tupleのimmutabilityに関してtupleオブジェクトの要素であるlistの要素に変更があってもそれはtupleのimmutabilityには反しないということを学ぶけど、それは内部実装のイメージがないとわかりにくいと思うよ。
初めのうちから内部実装をベースに理解しようとするのはたしかにムリがあるけれども、ラベル（名札）のアナロジーによる説明は所詮小手先の誤魔化しに過ぎないので、どこかの段階で内部実装に基づく（といっても大したレベルではなく、C言語のポインタの概念の基本を知っていれば足りるレベル）理解に切り替えた方が良いと思うけどね。
>>661
自分は、代入構文の説明としては、結局は箱のイメージで説明するのが（主にラベル（名札）のアナロジーによる説明との比較で）ベターではないかと考えているので、その点では646にも近い立場だけど、それがシンプルに理解できるとは微塵も考えていない。箱に格納されるのはアドレス情報であってそれ自体としてはPytnonのオブジェクトではないし、C言語レベルの内部実装に関する知識に依拠した説明になるからね。647に書いたとおり、本来的には（C言語レベルでは）比較的シンプルなはずのアイデアが、Pytnonでは（仕方のないことではあるけれども）屈折した表れ方になるなぁと思っている。
なお、「コンテキスト（状況）」という語をどういう趣旨で使いたかったのかというのは分かったけど、652に対する批判の文脈でどういう意味合いを持たせたかったのかはよく分からないな。
667: (ﾜｯﾁｮｲ 1af4-ZDX3) 08/10(日)13:25 ID:WyYSCohm0(1/2) AAS
>>659
わかってないな、コピーしなくていいんだよ
x = A() # Aの実体をどこかに作成し、荷札xを貼り付ける
y = x # xが貼り付けられている実体に追加で荷札yを貼り付ける
辻褄は合うだろう？
668: (ﾜｯﾁｮｲ 0754-mJPu) 08/10(日)13:45 ID:rGiN2SBN0(7/10) AAS
荷札という名称が悪すぎるわw
実体の所有者(複数可)が誰か判るような管理リスト、みたいなイメージ
実際にはリストじゃないからこの時点で乖離があるけど
登記簿とか株券の裏を複数所有可能にした的な
所有してる訳でもないのでズレる
なんで「参照」の一言を参照使わずに説明するのがこんなに困難なのか
669: (ﾜｯﾁｮｲ 1af2-ZDX3) 08/10(日)14:04 ID:WyYSCohm0(2/2) AAS
>>666
t = (x, y)
u = t
これは、荷札xの付いた実体に対して荷札t[0]を、荷札yの実体に対して同様に荷札t[1]を貼り付ける、
同時に、荷札t[0]とt[1]を管理するために”t[0], t[1]”と書かれた台帳を作成し、その台帳に荷札uを付けると解釈すればよい
これは参照の向きを逆に捉えて参照される側が参照元を記憶していると考えているだけなので、基本的にはこのような説明で矛盾は生じない
荷札名から実体を探すのが大変だという問題は残るけどね
670: (ﾜｯﾁｮｲ f6ce-1ngM) 08/10(日)14:29 ID:wmWYPlFf0(4/9) AAS
仮にそれをそのまま実装に反映させるなら、Pytnonオブジェクトに（被参照カウント数に加えて）参照元のリストも持たせるってことでしょ。
そうではなく、単に解釈モデルに過ぎないってことなら、内部実装がそうなっているわけでもないのに、あえてそんな不自然な解釈モデルを作ってまで荷札（ラベル・名札）のアナロジーに拘る意味ってあるのかな？ たとえばそれで、（666でちょっと触れた）tupleの要素であるlistの要素を変更してもtupleのimmutabilityに反しないことの説明がしやすくなったりする？
671(1): (ﾜｯﾁｮｲ 7601-AJBo) 08/10(日)15:10 ID:BWOE9N0b0(1/3) AAS
>>664 665
y = x + 1なら「yにx + 1を割り当てる」「yをx + 1で置き換える」
x = x + 1なら「xにx + 1を割り当てる」「xをx + 1で置き換える」
で特に困らないと思うんだけど
数学の場合は変数が指し示す値が同じスコープ内で変化しない大前提があるからそれを元に「代入」を考えると「xにx+1を代入する」がおかしいという感覚になるのでは？
それともイコールじゃなくて「x ← x + 1」なら←は代入ですと言ってもしっくりくるのかな？
上下前次1-新書関写板覧索設栞歴
あと 290 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.021s