作者查詢 / poyenc
作者 poyenc 在 PTT 全部看板的留言(推文), 共266則
限定看板:全部
看板排序:
7F推: 這個要討論的話也可以跟 consteval 還有 P1045 P0595 等一02/06 22:08
8F→: 起比較 :)02/06 22:08
3F推: 因為 cmcstl2 乃至 range-v3 裡的 view 都是靠一層層的01/07 00:18
4F→: wrapper 來達成目的, 所以如果編譯的時候沒有嘗試把這些間01/07 00:19
5F→: 接層拿掉 (debug build), 執行變慢是一定的01/07 00:20
6F→: 不過因為 Eric Nieble 和 Casey Carter 開發主要都專注在01/07 00:22
7F→: "給予編譯器更多的機會最佳化" 所以 debug build 是暫時無01/07 00:23
8F→: 解的01/07 00:24
9F推: 更正人名是 Eric Niebler01/07 02:23
4F→: 沒看過 CS50 不過看心得好像很淺.. 你對函式的認知是?12/30 10:36
11F→: 簡單說, 函式收的參數型別是固定的, 如果它吃的是 type*12/31 17:37
12F→: 引數就會需要用 & 對 type 變數取址得來, 另外也可以讓12/31 17:38
13F→: 陣列 decay 而來, string literal 就是 char 陣列 (但隱藏12/31 17:39
14F→: 最後的 '\0' 字元, "hello" 陣列長度是 6, 當成字串長則是12/31 17:41
15F→: 5, 你要把變數當成指標丟肯定是不行的12/31 17:42
4F→: 統一用 read/write12/28 19:15
4F→: xD 你需要先把 insertion sort 寫好再來挑戰 merge sort12/28 02:18
2F→: 你要怎麼知道有那些區間是 partition 完但還沒 merge 的?12/21 20:00
4F→: 簡單說 DaC 還會需要整合結果的步驟, 所以我問 partition12/21 23:39
5F→: 完, 你去處理完更小的區間以後, 要怎麼回來處理其他區間?12/21 23:40
6F→: 即使是 in-place quicksort 也有回去處理上個 partition12/21 23:43
7F→: 剩下來另一半區間的步驟, 也會有整合結果的步驟 (雖然可以12/21 23:44
8F→: 不做事), 但就跟遞迴呼叫類似, 你要用同份程式碼執行在不12/21 23:45
9F→: 同情境 (context) 下, 先要有辦法把情境資訊給儲存起來12/21 23:46
15F→: 用 LIFO stack 去存當前區間、pivot、階段就可以了12/22 00:04
16F→: 這邊有兩種實作可以對照看 https://bit.ly/2T2HEOH12/22 04:25
27F→: 那有個問題: 你定義區域變數要不要算進空間複雜度? 你進行12/23 23:10
28F→: 遞迴呼叫算不算配置記憶體?12/23 23:10
31F→: 再研究一下 in-place algorithm 指的是哪方面的 in-place12/24 02:32
32F→: 吧, 如果 quicksort 空間複雜度可以到常數你就可以得獎了12/24 02:34
42F→: O(log N) 不是專指遞迴需要的空間, 而是為了 divide &12/24 15:01
43F→: conquer 需要記住的資訊量, 你用 iterative 因為也要記錄12/24 15:02
44F→: 相同資訊, 所以免不了這部分的空間複雜度. recursive 只是12/24 15:03
45F→: 把資訊存在 call stack 上, 這樣的分別而已12/24 15:03
46F→: 把遞迴跟 divide & conquer 劃上等號就錯了, 應該從了解演12/24 15:14
47F→: 算法本身著手. divide 我也可以開好多條 thread 去作, 討12/24 15:16
48F→: 論實作根本無助於理解這個 O(log N)12/24 15:16
49F→: hint: O(log N) 跟演算法是 top-down 有關12/24 15:37
50F→: 你會覺得 iterative merge sort 實作很好理解的原因在於即12/24 16:26
51F→: 使用 bottom-up approach 去實作也很容易, 因為邊界都可以12/24 16:27
52F→: 在一開始的時候全算出來, 但對於 top-down 的演算法, 想要12/24 16:27
53F→: 把 "分出子問題" 這件事跟 "解決問題本身" 成本相仿, 你如12/24 16:30
54F→: 實作出完全迴圈版, 會發現成本都在儲存子問題資訊上面,12/24 16:31
55F→: 空間複雜度 O(N log N), 為了蒐集資訊需額外付出時間成本12/24 16:32
56F→: O(N log N)12/24 16:32
4F→: 問題可以簡化成產生動態陣列, 再來根據使用情況設計介面12/24 02:08
5F→: https://wandbox.org/permlink/WrwUrza4jwgcfPoD12/24 02:08
1F→: 這跟 range-based foor 會用到的操作有關12/07 22:34
2F→: https://bit.ly/2Stce3G 有看過 iterator 相關的章節嗎?12/07 22:35
3F→: range-based for 就是簡化以迭代器尋訪集合的語法糖, 如果12/08 00:13
4F→: 你之前有看過迭代器來尋訪 vector 的章節, 那這邊的原理是12/08 00:14
5F→: 一樣的, 只是需要先照我上面貼的連結提到的, 把12/08 00:15
6F→: begin_expr 跟 end_expr 找出來, 剛好陣列會透過12/08 00:17
7F→: array-to-pointer conversion 轉成指標. 先試著自己展開12/08 00:19
8F→: 一層試試12/08 00:19
9F→: 剛開始用一維的陣列來作會簡單些12/08 00:22
10F→: 還是回一下文好惹 :o12/08 00:27
9F→: pData 的初始化也有問題, 只是指標大小相同所以算出來位址12/04 22:46
10F→: 剛好是對的12/04 22:46
11F→: 簡單說以一個整數 c 來說, array + c 代表的涵義是從array12/04 23:02
12F→: 指向的位置開始, 往後算 c 個 sizeof(*array) 物件之後的12/04 23:02
13F→: 位址, 這裡的 sizeof(*array) == sizeof(double**), 表示12/04 23:03
14F→: array + c 實際上是在預留 c 個 double** 的空間, 這部分12/04 23:04
15F→: 沒問題; 但在初始化 pData 的時候你用的方法卻是和 ppData12/04 23:05
16F→: 一樣, 多預留 l*m 個 double** 空間給 double* 用12/04 23:06
1F→: 關鍵字 absolute / canonical / final / path 找找看12/04 20:43