アカウント名:
パスワード:
いい言語なのに、なんでこうしちゃったのか…。
VB使ってた身からすると、気をつけとけば良いだけじゃないかと。Forが0から始まり、len-1で終わると思い込むのは良くない。
…たまに勘違いしてるコード見るんだよなぁ。For i = 0 To UBound(arr) -1とか。なぜわざわざ-1してるのだ。
> 気をつけとけば良いだけじゃないかと。 あっ、それ絶対事故るやつだ。ヨシ!
ここにぶら下げるのが適切か分からないけど、誰も言及してないので補足すると、Juliaはデフォルトで境界チェックをする。(もちろん行単位で境界チェックを省略させる方法が用意されている)
境界チェックに引っかからないバグもあるけど、それは0始まりでも同じ。
VB だと LBound から UBound までではなかったですか0 始まりや 1 始まりですら思い込みかと
うむ。そういう意味の例示だったので、ツッコミ多謝。
Option Base 1というオプション指定で、配列のIndexが1開始になるのよね。ほとんど見たこと無いんだけど、VBAの仕事で目撃したことがあって、怖いなぁと思った。
ついでに言うと、実はこれは暗黙の宣言の時のIndexであって、Dim arr(-10 To 10)とかいう宣言ができてしまう。arr(-10)~arr(10)まで使える。Indexが負数ってw
動的配列を使う場合、空扱いしたい時に ReDim arr(-1 To -1) として For i = 0 To UBound(arr) に入らないようにする小技とかもあったりする。一筋縄ではいかない。
多分、絶対的に経験値が足りなさすぎるんだろう。当たり前のことが当たり前なんだということは少し勉強すればわかるようになるよ。
大昔の VB は、配列添字は 1始まり固定。レンジ指定とかない。そういう古いコードは、1始まりであることを前提に書いてるから、その時代のコードを今の環境でも利用しようとしたら、明示的に書いとかないと不具合も出る。安全のためには必須。配列の添字範囲が自由なのも、制限する必要なんぞ無いため。インデックスとなる値が負の範囲なら、配列操作するためにオフセット加算して配列用のインデックスを別に作り出すよりも、配列を負の範囲で宣言して同じものが使えるほうがよっぽど素直だよ。
Juliaも基本的な具象型であるArrayは1始まりだけど、AbstractArrayにはそのような前提はない。OffsetArrayみたいに明示的にインデックス範囲をずらせる配列型があり、これを使えば0始まりの配列も使える。(イデオロギー的な理由だけで使うことはお勧めしないが)
イテレータが充実しているのに加えて、当然畳み込み(folding)関数もあり、さらにはブロードキャストという仕組みもある。使い込めば使い込むほど気にしなくなるというか、抽象化を気にするようになる。
それは、FORTRANから連綿と続く、数値計算の伝統ではないかな。
それよく言われるけど、慣れの問題だよ。複数の言語を並行して使っていると混乱するけど、それは添え字に限った話ではない。一つの言語として見たときに、(大した利点にもならないが)致命的欠点にもならない。
Juliaは、「いわゆる」OOPを採用しなかったので、Juliaを書く時と他のOOP色の濃い言語を書く時とでは思考が変わる感じがある。脳内でJuliaモードに切り替わるというか。なので、個人的にはC++, C#, TypeScriptを並行して使っている時よりは混乱は少ない。
MATLABとの互換性に配慮したからとか.......昔のBASICには0から始まるか、1から始まるかのモード切替が出来るものがあったのだが
調べたら、いまのVBAにも有るんだなぁ
option base
解説. 配列の添え字の最小値を指定します。 指定できるのは1または0です。
アドレスは0から始まってもいいけど、インデックスは1から始まるべきだと思う。100項目の0個目ってやっぱりおかしいから。
Cからやってると「配列インデックスはアドレスのオフセットを抽象化したもの」という感じなのでアドレスとインデックスで解釈が違うことに抵抗がある
別にJulia固有の機能でないけど、ビューという考え方があって、メモリ上のレイアウトを変えることなく、見かけだけを変える配列がある。行列の行ベクトルだとか、転置行列だとか。なので解釈が違うというより抽象度が足りない。
C にそれだけの抽象度を求めるのが間違っているかとLinus がよく主張している、C は抽象化(処理の隠蔽)ができないから良いのだ、みたいな
C++ だと span が入ったので、それに近いことはできるようになったのかな
ならCにはCの、JuliaにはJuliaの哲学があるんだから、最初からCでこうだからJuliaもそうなってないのは駄目とか言い出すなよ。
配列に関しては列優先の方が混乱しやすいですね。もっとも実数や複素数の行列として使う分には気にならないどころか列優先の方が分かりやすいですが。
つまづきやすいのは画像。Juliaの画像処理パッケージでは専用の画像型を定義せず「色の配列」を画像としています。この一般化は慣れると合理的で、特にJuliaの多重ディスパッチと相性が良いのですが画像もまた列優先(ピクセルが縦方向に並ぶ)になってしまいます……。もちろん高水準なAPIを使っている限り、あまり意識する必要はありませんけど。
剰余演算子と相性悪いよね→1基底1基底なのは自然数が1からなので1が自然だっていうくらいしか理由ないよね
0基底なのは剰余演算子と相性が良い以外のどういった理由があると主張されるので?
バイト列を走査しながらどうこうする時とかも割と厳しいな
0オリジンは基本的に慣れの問題で済ませられると思うけど1オリジンは動的なデータ構造に対してしばしば実コストを強いられるだからこその今な訳で、何だか因果のズレた問答になってる気がするなあ
ベンチマークとって数字で示さんと何の意味もないな。0から始めようが、1から始めようが、数学的に数式が変わる訳じゃないことが分かってない。
そもそもが1オリジンのポインタなんてないんだからバイト列の配列評価にどうコストが生じるかなんて論じるまでもないだろ数学的に、ってそこがズレてるんだって言うんだよ
1オリジンのポインタとか斬新な言葉を創ってきましたね。
そうですね、存在しないのだから論じるまでもありません。Juliaは(インタープリタ実装もありますが)コンパイラ言語です。配列のインデックスの基準というものはLLVMのフロントエンドのあたりまでしか存在しない概念です。
Juliaには code_llvm と code_native という生成されるLLVM IRと実行マシンのアセンブリ言語を表示する便利機能があるのでコストを気にする人は見てみればよいと思います。
Julia(とLLVM)のループの最適化にはまだ改善の余地がありますがこのストーリの中で誰がどれだけズレているかは明確になるでしょう。
#4003901 は、「計算機」の常識が無い数学バカなんでしょう。多少、論じる必要があるかと。
>0から始めようが、1から始めようが、数学的に数式が変わる訳じゃないことが分かってない。
これを真似るなら、0から始めるか、1から始めるかで、電子回路設計・ISAが激変することが分かっていない。とでもいいましょうか。現代の電子回路というのは、配列は0から始める設計に最適化されていることも知らないのでしょう。
>配列のインデックスの基準というものはLLVMのフロントエンドのあたりまでしか存在しない概念です。
>コストを気にする人は見てみればよいと思います。
>このストーリの中で誰がどれだけズレているかは明確になるでしょう。
要約すると、Juliaの優れたコンパイラは最適化によって、無駄なコスト無しの配列要素アクセスに変換されるって言いたいんだよね。でもそれ ary[i] とかの形だけでしょ。 ary1[ ary2[i] ] とかの形になったら、ary1 は、配列のインデックスの基準とやらから逃れられないでしょ。
(追記)老婆心ながら申し上げますと、「あなたは人に騙され、騙されたことに気付かず、人を騙す」タイプの人です。都合の良いことは、饒舌に、都合の悪いことは、黙っているのが人の性というものです。(都合の悪いことは、知らされない、知らんふり、で通そうとするものですよ。(マジで気付かない鈍感パターンもあるけどさ。))
なんだエイプリルフールか。
ary1[ ary2[i] ] とかの形になったら、ary1 は、配列のインデックスの基準とやらから逃れられないでしょ。
これが本当に意味が分からない。見た目からして ary1 は ary[i] と同じ形じゃん?「逃れる」という語感からして共感できない。0-basedインデックスと1-basedインデックスの差は1。これは恒等式な訳。逃れる逃れないじゃなくて、どこにいたって、いつでも成立するの。
まぁ、それはそうと、ランダムアクセスは遅いよ。でも「バイト列を走査」っていったらシーケンシャルアクセスを想像するし、遅いのは0-basedだろうと1-basedだろうと同じ話。加算や乗算はもう十分に速くて、ボトルネックはSIMDの適用可否とキャッシュ効率にある。なのにSIMDの文字もキャッシュの文字も出てこない。
「オリジンの違いは慣れだけの問題だ」という発端に対してそうじゃないだろうと言って実コストを例示してるのに結局SIMDだのキャッシュだの、もっとズラして逃げても仕方ないだろ
「特化した並列パワーで逃げるから大して意味がない」だったら最初から同意なのに
なんかもうやりとりが全然論理的でないな
どこに実コストの話が? 数字で示されていないコストに何の意味が?
> 「特化した並列パワーで逃げるから大して意味がない」だったら最初から同意なのに
どこにそんな話が? それは#4005267の私見でしょ。自分の意見に自分で同意って。
もう面倒臭いから、速度に差が生じる具体的なコードを出してよ。CでもC++でもいいからさ。もちろん引用でいいよ。それをしたくないなら、余計な言葉を書くのをやめてくれ。
Juliaは(コンパイル時間とメモリ消費を多少犠牲にして)実行速度を重視した言語(あるいは重視するコミュニティ)なんだよ。ちゃんと計算されてる。角度とか。
ゼロベースで考えよう。
ふーむ…。
1オリジンだと、"abcdefg"から、cの位置を探すと3で見つかる。cの位置からfを探すと4で見つかる。3と4を足した7の位置にある文字はgになるのだが、このような仕様はJuliaは嫌わないのだろうか。
嫌うもなにも、インデックスとオフセットは別物でしょ。位置の差が距離。位置+距離は位置。距離+距離は距離。位置+位置は定義されない。
そういったテキトーに出てきた数字を足してみるとか算数が苦手な小学生がやるようなこと、それこそをJuliaは嫌う。
Juliaでも未だに議論のある話が「one」のネーミングとインターフェイスで、Juliaでは「one」は日常的な意味での「イチ」ではなくて乗法単位元として定義されている。だから時間の型「Day」にとって「one(Day)」は「1 day」ではなくて実数の「1」。1日×N日 = N日 は成立しない(次元が合わない)から。
ほう、その概念を統合して扱えるのが一般に0オリジンが好まれる理由なんだが。その論でいくと、オフセットを意味するパラメータは0から始まる事になる訳だね。
単位元がどうという話なので、1も0も同程度に統合できてないのでは
ポインタを取り扱うCやC++言語なら0始まりのほうがいいと思うけど、後発の言語(Javaとか?)が配列にlengthプロパティを持った時点で1も0も負けな気がする
> 自然数が1から
自然数とは(0を含むこともあるよ) [manabitimes.jp]
わかる。そんなとこで独自性出されてもね... といいつつLuaは結構好き。
独自性といってもプログラミング言語より巨大なバックグラウンドを持つ数学が1始まりを使うからね。むしろ「独自性」の象徴は、文字列結合演算子が、+ではなく*なところではないだろうか。これも数学的な一貫性を "めちゃ"^2 重視した結果。
文字列結合演算子自体は、実際にはほとんど使われないので、半分は所信表明というかジョークみたいなものだと思う。
数学も基礎論とかだと0始まりが多いのよね
いわゆる「ペアノの公理」は0始まりで使われるのが多いようだけどペアノ自身は1始まりで書いている。
原点が(1,1)になったら首肯してやる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
配列のインデックスが1から始まる言語か… (スコア:1)
いい言語なのに、なんでこうしちゃったのか…。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
VB使ってた身からすると、気をつけとけば良いだけじゃないかと。
Forが0から始まり、len-1で終わると思い込むのは良くない。
…たまに勘違いしてるコード見るんだよなぁ。
For i = 0 To UBound(arr) -1
とか。なぜわざわざ-1してるのだ。
Re: (スコア:0)
> 気をつけとけば良いだけじゃないかと。
あっ、それ絶対事故るやつだ。
ヨシ!
Re: (スコア:0)
ここにぶら下げるのが適切か分からないけど、誰も言及してないので補足すると、
Juliaはデフォルトで境界チェックをする。
(もちろん行単位で境界チェックを省略させる方法が用意されている)
境界チェックに引っかからないバグもあるけど、それは0始まりでも同じ。
Re: (スコア:0)
VB だと LBound から UBound までではなかったですか
0 始まりや 1 始まりですら思い込みかと
Re:配列のインデックスが1から始まる言語か… (スコア:1)
うむ。そういう意味の例示だったので、ツッコミ多謝。
Option Base 1
というオプション指定で、配列のIndexが1開始になるのよね。
ほとんど見たこと無いんだけど、VBAの仕事で目撃したことがあって、怖いなぁと思った。
ついでに言うと、実はこれは暗黙の宣言の時のIndexであって、
Dim arr(-10 To 10)
とかいう宣言ができてしまう。
arr(-10)~arr(10)まで使える。Indexが負数ってw
動的配列を使う場合、空扱いしたい時に ReDim arr(-1 To -1) として For i = 0 To UBound(arr) に入らないようにする小技とかもあったりする。
一筋縄ではいかない。
Re: (スコア:0)
多分、絶対的に経験値が足りなさすぎるんだろう。
当たり前のことが当たり前なんだということは少し勉強すればわかるようになるよ。
大昔の VB は、配列添字は 1始まり固定。
レンジ指定とかない。そういう古いコードは、1始まりであることを前提に書いてるから、その時代のコードを今の環境でも利用しようとしたら、明示的に書いとかないと不具合も出る。安全のためには必須。
配列の添字範囲が自由なのも、制限する必要なんぞ無いため。
インデックスとなる値が負の範囲なら、配列操作するためにオフセット加算して配列用のインデックスを別に作り出すよりも、配列を負の範囲で宣言して同じものが使えるほうがよっぽど素直だよ。
Re: (スコア:0)
Juliaも基本的な具象型であるArrayは1始まりだけど、AbstractArrayにはそのような前提はない。
OffsetArrayみたいに明示的にインデックス範囲をずらせる配列型があり、
これを使えば0始まりの配列も使える。(イデオロギー的な理由だけで使うことはお勧めしないが)
イテレータが充実しているのに加えて、当然畳み込み(folding)関数もあり、さらにはブロードキャストという仕組みもある。
使い込めば使い込むほど気にしなくなるというか、抽象化を気にするようになる。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
Re:配列のインデックスが1から始まる言語か… (スコア:1)
それは、FORTRANから連綿と続く、数値計算の伝統ではないかな。
Re: (スコア:0)
それよく言われるけど、慣れの問題だよ。
複数の言語を並行して使っていると混乱するけど、それは添え字に限った話ではない。
一つの言語として見たときに、(大した利点にもならないが)致命的欠点にもならない。
Juliaは、「いわゆる」OOPを採用しなかったので、
Juliaを書く時と他のOOP色の濃い言語を書く時とでは思考が変わる感じがある。
脳内でJuliaモードに切り替わるというか。
なので、個人的にはC++, C#, TypeScriptを並行して使っている時よりは混乱は少ない。
Re: (スコア:0)
MATLABとの互換性に配慮したからとか.......
昔のBASICには0から始まるか、1から始まるかのモード切替が出来るものがあったのだが
Re: (スコア:0)
調べたら、いまのVBAにも有るんだなぁ
option base
解説. 配列の添え字の最小値を指定します。 指定できるのは1または0です。
Re: (スコア:0)
アドレスは0から始まってもいいけど、インデックスは1から始まるべきだと思う。100項目の0個目ってやっぱりおかしいから。
Re: (スコア:0)
Cからやってると「配列インデックスはアドレスのオフセットを抽象化したもの」という感じなのでアドレスとインデックスで解釈が違うことに抵抗がある
Re: (スコア:0)
別にJulia固有の機能でないけど、ビューという考え方があって、
メモリ上のレイアウトを変えることなく、見かけだけを変える配列がある。
行列の行ベクトルだとか、転置行列だとか。
なので解釈が違うというより抽象度が足りない。
Re: (スコア:0)
C にそれだけの抽象度を求めるのが間違っているかと
Linus がよく主張している、C は抽象化(処理の隠蔽)ができないから良いのだ、みたいな
C++ だと span が入ったので、それに近いことはできるようになったのかな
Re: (スコア:0)
ならCにはCの、JuliaにはJuliaの哲学があるんだから、最初からCでこうだからJuliaもそうなってないのは駄目とか言い出すなよ。
Re: (スコア:0)
配列に関しては列優先の方が混乱しやすいですね。
もっとも実数や複素数の行列として使う分には気にならないどころか
列優先の方が分かりやすいですが。
つまづきやすいのは画像。
Juliaの画像処理パッケージでは専用の画像型を定義せず「色の配列」を画像としています。
この一般化は慣れると合理的で、特にJuliaの多重ディスパッチと相性が良いのですが
画像もまた列優先(ピクセルが縦方向に並ぶ)になってしまいます……。
もちろん高水準なAPIを使っている限り、あまり意識する必要はありませんけど。
Re: (スコア:0)
剰余演算子と相性悪いよね→1基底
1基底なのは自然数が1からなので1が自然だっていうくらいしか理由ないよね
Re: (スコア:0)
0基底なのは剰余演算子と相性が良い以外のどういった理由があると主張されるので?
Re:配列のインデックスが1から始まる言語か… (スコア:1)
// だと思うC/アセンブラ使い
Re: (スコア:0)
バイト列を走査しながらどうこうする時とかも割と厳しいな
0オリジンは基本的に慣れの問題で済ませられると思うけど
1オリジンは動的なデータ構造に対してしばしば実コストを強いられる
だからこその今な訳で、何だか因果のズレた問答になってる気がするなあ
Re: (スコア:0)
ベンチマークとって数字で示さんと何の意味もないな。
0から始めようが、1から始めようが、数学的に数式が変わる訳じゃないことが分かってない。
Re: (スコア:0)
そもそもが1オリジンのポインタなんてないんだから
バイト列の配列評価にどうコストが生じるかなんて論じるまでもないだろ
数学的に、ってそこがズレてるんだって言うんだよ
Re: (スコア:0)
1オリジンのポインタとか斬新な言葉を創ってきましたね。
そうですね、存在しないのだから論じるまでもありません。
Juliaは(インタープリタ実装もありますが)コンパイラ言語です。
配列のインデックスの基準というものはLLVMのフロントエンドのあたりまでしか存在しない概念です。
Juliaには code_llvm と code_native という
生成されるLLVM IRと実行マシンのアセンブリ言語を表示する便利機能があるので
コストを気にする人は見てみればよいと思います。
Julia(とLLVM)のループの最適化にはまだ改善の余地がありますが
このストーリの中で誰がどれだけズレているかは明確になるでしょう。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
Re: (スコア:0)
#4003901 は、「計算機」の常識が無い数学バカなんでしょう。多少、論じる必要があるかと。
>0から始めようが、1から始めようが、数学的に数式が変わる訳じゃないことが分かってない。
これを真似るなら、
0から始めるか、1から始めるかで、電子回路設計・ISAが激変することが分かっていない。
とでもいいましょうか。現代の電子回路というのは、配列は0から始める設計に最適化されていることも知らないのでしょう。
Re: (スコア:0)
>配列のインデックスの基準というものはLLVMのフロントエンドのあたりまでしか存在しない概念です。
>コストを気にする人は見てみればよいと思います。
>このストーリの中で誰がどれだけズレているかは明確になるでしょう。
要約すると、Juliaの優れたコンパイラは最適化によって、無駄なコスト無しの配列要素アクセスに変換されるって言いたいんだよね。
でもそれ ary[i] とかの形だけでしょ。 ary1[ ary2[i] ] とかの形になったら、ary1 は、配列のインデックスの基準とやらから逃れられないでしょ。
Re: (スコア:0)
(追記)老婆心ながら申し上げますと、「あなたは人に騙され、騙されたことに気付かず、人を騙す」タイプの人です。都合の良いことは、饒舌に、都合の悪いことは、黙っているのが人の性というものです。(都合の悪いことは、知らされない、知らんふり、で通そうとするものですよ。(マジで気付かない鈍感パターンもあるけどさ。))
Re: (スコア:0)
なんだエイプリルフールか。
ary1[ ary2[i] ] とかの形になったら、ary1 は、配列のインデックスの基準とやらから逃れられないでしょ。
これが本当に意味が分からない。見た目からして ary1 は ary[i] と同じ形じゃん?
「逃れる」という語感からして共感できない。
0-basedインデックスと1-basedインデックスの差は1。これは恒等式な訳。
逃れる逃れないじゃなくて、どこにいたって、いつでも成立するの。
まぁ、それはそうと、ランダムアクセスは遅いよ。
でも「バイト列を走査」っていったらシーケンシャルアクセスを想像するし、
遅いのは0-basedだろうと1-basedだろうと同じ話。
加算や乗算はもう十分に速くて、ボトルネックはSIMDの適用可否とキャッシュ効率にある。
なのにSIMDの文字もキャッシュの文字も出てこない。
Re: (スコア:0)
「オリジンの違いは慣れだけの問題だ」という発端に対して
そうじゃないだろうと言って実コストを例示してるのに
結局SIMDだのキャッシュだの、もっとズラして逃げても仕方ないだろ
「特化した並列パワーで逃げるから大して意味がない」だったら最初から同意なのに
なんかもうやりとりが全然論理的でないな
Re: (スコア:0)
どこに実コストの話が? 数字で示されていないコストに何の意味が?
> 「特化した並列パワーで逃げるから大して意味がない」だったら最初から同意なのに
どこにそんな話が? それは#4005267の私見でしょ。自分の意見に自分で同意って。
もう面倒臭いから、速度に差が生じる具体的なコードを出してよ。CでもC++でもいいからさ。もちろん引用でいいよ。
それをしたくないなら、余計な言葉を書くのをやめてくれ。
Juliaは(コンパイル時間とメモリ消費を多少犠牲にして)実行速度を重視した言語(あるいは重視するコミュニティ)なんだよ。
ちゃんと計算されてる。角度とか。
Re: (スコア:0)
ゼロベースで考えよう。
Re: (スコア:0)
ふーむ…。
1オリジンだと、
"abcdefg"から、cの位置を探すと3で見つかる。
cの位置からfを探すと4で見つかる。
3と4を足した7の位置にある文字はgになるのだが、このような仕様はJuliaは嫌わないのだろうか。
Re:配列のインデックスが1から始まる言語か… (スコア:1)
嫌うもなにも、インデックスとオフセットは別物でしょ。
位置の差が距離。
位置+距離は位置。
距離+距離は距離。
位置+位置は定義されない。
そういったテキトーに出てきた数字を足してみるとか
算数が苦手な小学生がやるようなこと、それこそをJuliaは嫌う。
Juliaでも未だに議論のある話が「one」のネーミングとインターフェイスで、
Juliaでは「one」は日常的な意味での「イチ」ではなくて乗法単位元として定義されている。
だから時間の型「Day」にとって「one(Day)」は「1 day」ではなくて実数の「1」。
1日×N日 = N日 は成立しない(次元が合わない)から。
Re: (スコア:0)
ほう、その概念を統合して扱えるのが一般に0オリジンが好まれる理由なんだが。
その論でいくと、オフセットを意味するパラメータは0から始まる事になる訳だね。
Re: (スコア:0)
単位元がどうという話なので、1も0も同程度に統合できてないのでは
ポインタを取り扱うCやC++言語なら0始まりのほうがいいと思うけど、
後発の言語(Javaとか?)が配列にlengthプロパティを持った時点で1も0も負けな気がする
Re:配列のインデックスが1から始まる言語か… (スコア:1)
// いやオメーは配列じゃない
Re: (スコア:0)
> 自然数が1から
自然数とは(0を含むこともあるよ) [manabitimes.jp]
Re: (スコア:0)
わかる。そんなとこで独自性出されてもね...
といいつつLuaは結構好き。
Re: (スコア:0)
独自性といってもプログラミング言語より巨大なバックグラウンドを持つ数学が1始まりを使うからね。
むしろ「独自性」の象徴は、文字列結合演算子が、+ではなく*なところではないだろうか。
これも数学的な一貫性を "めちゃ"^2 重視した結果。
文字列結合演算子自体は、実際にはほとんど使われないので、半分は所信表明というかジョークみたいなものだと思う。
Re: (スコア:0)
数学も基礎論とかだと0始まりが多いのよね
Re: (スコア:0)
いわゆる「ペアノの公理」は0始まりで使われるのが多いようだけど
ペアノ自身は1始まりで書いている。
Re: (スコア:0)
原点が(1,1)になったら首肯してやる