アカウント名:
パスワード:
いい言語なのに、なんでこうしちゃったのか…。
剰余演算子と相性悪いよね→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から始めるかで、電子回路設計・ＩＳＡが激変することが分かっていない。とでもいいましょうか。現代の電子回路というのは、配列は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も負けな気がする
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
配列のインデックスが1から始まる言語か… (スコア:1)
いい言語なのに、なんでこうしちゃったのか…。
Re: (スコア:0)
剰余演算子と相性悪いよね→1基底
1基底なのは自然数が1からなので1が自然だっていうくらいしか理由ないよね
Re:配列のインデックスが1から始まる言語か… (スコア: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から始めるかで、電子回路設計・ＩＳＡが激変することが分かっていない。
とでもいいましょうか。現代の電子回路というのは、配列は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)
// いやオメーは配列じゃない