虹裏img歴史資料館 - imgの文化を学ぶ

1 22/02/28(月)09:49:22 No.901954225

Dictionary

2 22/02/28(月)09:49:34 No.901954254

了解！ 5次元配列！！

3 22/02/28(月)09:51:10 No.901954519

この書き方だと四次元配列以降はよくわからなくなっちゃうだろ

4 22/02/28(月)09:51:25 No.901954562

allocate

5 22/02/28(月)09:52:43 No.901954757

>この書き方だと四次元配列以降はよくわからなくなっちゃうだろ 三次元で十分だろ！

6 22/02/28(月)09:55:35 No.901955196

最近の言語だと順番を気にする用途でなければ連想配列とか辞書とかに移行してきたから以前よりはだいぶ使う機会が減った 純粋に行列計算とかで使うのがメインかなぁ

7 22/02/28(月)09:57:35 No.901955473

行列計算だとあんまり多次元配列にする必要もなくて内部的には１次元配列で確保して多次元っぽくアクセスするほうが性能出るのよな…

8 22/02/28(月)09:57:48 No.901955508

ぜんぜんちがいますよーっ これがリスト これが辞書でこれが配列

9 22/02/28(月)09:58:29 No.901955600

[[2]][5]ってなんだよ…

10 22/02/28(月)09:58:35 No.901955612

操作しづらいからlistにしてくだち…

11 22/02/28(月)09:59:45 No.901955787

>行列計算だとあんまり多次元配列にする必要もなくて内部的には１次元配列で確保して多次元っぽくアクセスするほうが性能出るのよな… そりゃそうだって感じなんだけど 元も子もない感じ

12 22/02/28(月)10:00:25 No.901955858

>[[2]][5]ってなんだよ… [[2]].get()[5]

13 22/02/28(月)10:02:54 No.901956219

めんどくさいから全次元1000ずつ確保しておくか…

14 22/02/28(月)10:03:39 No.901956348

漫然と使ってると後から追加できないって何よ！ってなる型がある >これがリスト >これが辞書でこれが配列 どれがそうだったっけか…

15 22/02/28(月)10:05:21 No.901956611

3次元以上は設計を見直せ

16 22/02/28(月)10:05:50 No.901956674

ラベル付き配列って連想配列とは違うのか

17 22/02/28(月)10:08:42 No.901957099

これが配列 これがArrayList これがCollection これがDictionary これがHashMap これがEAV設計で作ったテーブル

18 22/02/28(月)10:09:21 No.901957197

関数の配列ってなんなの？

19 22/02/28(月)10:09:56 No.901957299

なんなのってなに…？

20 <a href="mailto:Tensorflow">22/02/28(月)10:10:38</a> [Tensorflow] No.901957400

テンソルです

21 22/02/28(月)10:18:21 No.901958601

変換してDTOにしてもいい？

22 22/02/28(月)10:21:05 No.901959024

Listってなんかだめなの

23 22/02/28(月)10:22:33 No.901959217

>Listってなんかだめなの メモリちゃんとシーケンシャルに並べてる詰めて使ってくれたらいいよ

24 22/02/28(月)10:23:40 No.901959372

どんな書き方しようが四次元以上の配列はよくわからんよ

25 22/02/28(月)10:27:46 No.901959955

3D扱おうとすると否応なく4次元配列考えなきゃいけないのだるくない? 列挙するな

26 22/02/28(月)10:28:20 No.901960050

二次元配列で充分です… mapでもいい…

27 22/02/28(月)10:30:47 No.901960454

>3D扱おうとすると否応なく4次元配列考えなきゃいけないのだるくない? >列挙するな 配列って言うかもうそれはベクトルを扱うクラスや構造体を作るべき UnityだとVector3とかVector4っていう構造体がある

28 22/02/28(月)10:30:55 No.901960475

4次元以上の配列は頭がねじれそうだ

29 22/02/28(月)10:32:19 No.901960701

vector>> hoge(10, vector>(10, vector(10, 0)));

30 22/02/28(月)10:32:35 No.901960738

ちゃんとデータ構造のアライメント考えてくれたら構造体でもクラスでもいいよ

31 22/02/28(月)10:36:01 No.901961273

つくづくプログラミング文法だけじゃなくデータベースと設計の勉強やんなきゃなって思わされる

32 22/02/28(月)10:37:42 No.901961529

cだとa[b]はb[a]でもいいんだっけ？

33 22/02/28(月)10:40:38 No.901961968

ほいアルファベットは26次元空間

34 22/02/28(月)10:46:51 No.901962925

for(;;) { for(;;) { for(;;) { } } }

35 22/02/28(月)10:48:28 No.901963154

頻繁に要素足すなら配列は使わないでくだち！

36 22/02/28(月)10:49:53 No.901963380

>for(;;) >{ >for(;;) >{ >for(;;) >{ >} >} >} インデントちゃんと付ければ余裕

37 22/02/28(月)10:50:23 No.901963457

了解！双方向リスト！

38 22/02/28(月)10:54:14 No.901964084

やはりjson型…json型は全てを内包する…

39 22/02/28(月)10:56:07 No.901964415

>これが配列 >これがArrayList >これがCollection >これがDictionary >これがHashMap >これがEAV設計で作ったテーブル 実際要求される機能が満足すれば何使ってもいいだろ…

40 22/02/28(月)10:59:00 No.901964906

>実際要求される機能が満足すれば何使ってもいいだろ… 速度と使用メモリとコードの可読性が異なるけど まあチームメンバーが把握してればなんでも良いのはそう

41 22/02/28(月)11:01:20 No.901965262

競プロとかで使った速度しか考えられてない可読性皆無のコード使われるよりは普通にList使ってくれたほうがいいわ

42 22/02/28(月)11:02:00 No.901965381

hoge[i][j][2]

43 22/02/28(月)11:03:12 No.901965585

リスト構造いいよね

44 22/02/28(月)11:03:24 No.901965622

Dictionaryクラスとかデバッガで見るとすごい富豪的なメモリの使い方してるよね そのぶん機能豊富でありがたいんだけど

45 22/02/28(月)11:04:48 No.901965875

仕事するようになってから三次元以上見ないし使う気しないわ 計算系ならいるんだろうなとは思う

46 22/02/28(月)11:04:59 No.901965917

>実際要求される機能が満足すれば何使ってもいいだろ… そうだね 目先の実装方法だけじゃなくてリソース消費量や実行速度や今後のメンテナンス性拡張性運用保守での可読性もろもろの要求とそれらを考慮する必要自体があるか無いかまで含めて満たせていれば大丈夫

47 22/02/28(月)11:06:40 No.901966220

開発当時のメンバーが誰も居なくなった後のソースメンテさせられる人の身にもなってください！

48 22/02/28(月)11:09:54 No.901966812

>>for(;;) >>{ >>for(;;) >>{ >>for(;;) >>{ >>} >>} >>} >インデントちゃんと付ければ余裕 インデントちゃんとしてようがこのぐらいネスト深かったらちょぅとforの中で処理されたらかなりキツいと思う… そもそもこう言うの書く時点で他の部分やコメントがヤバそう

49 22/02/28(月)11:28:36 No.901969992

768次元あげる

50 22/02/28(月)11:34:02 No.901971018

行列に限らずデータ構造ライブラリは公式で用意しろといつも思っている おかげで独自実装のエラーチェックもろくにしてないリストやマップが世に溢れる

51 22/02/28(月)11:36:21 No.901971442

すぱーすなぎょうれつ？なんですけど？

52 22/02/28(月)11:37:37 No.901971679

>Dictionaryクラスとかデバッガで見るとすごい富豪的なメモリの使い方してるよね >そのぶん機能豊富でありがたいんだけど めんどくさいから使ってるとよくレビューで配列にしたら？って言われる やだめんどくさい

53 <a href="mailto:pandas">22/02/28(月)11:38:19</a> [pandas] No.901971797

DataFrameです

54 22/02/28(月)11:40:23 No.901972245

>計算系ならいるんだろうなとは思う 次元増えたらまともに計算できなくなるから やっぱり抑えるんじゃないだろあか

55 22/02/28(月)11:44:39 No.901973048

計算系でも大体 N x M行列とかだったら多次元配列で A[n][m] ってやるより１次元配列使って A[n*M+m]ってアクセスした方が早いというか LAPACKやらMKLやらはそう扱うことを要求してくる