作者查詢 / yuou1256
作者 yuou1256 在 PTT 全部看板的留言(推文), 共2865則
限定看板:全部
看板排序:
44F→: 愚民那麼多,直接說700嚇大家比較有效果啦,但以分析上05/23 01:27
45F→: 來說是不可取的,然後會延遲跟集中在一天的原因如下05/23 01:27
46F→: https://bit.ly/3bIuZfG05/23 01:27
77F→: 就系統更改資料詳細度後reload data,才會有一次性的資05/23 01:41
78F→: 料更新05/23 01:41
97F→: 連結看一看好嗎? 就是之前的data 被reload05/23 01:49
98F→: 時間點 有可能 是因為重抓data的時間05/23 01:49
103F→: 上傳系統version拿出來就知道啦05/23 01:51
119F→: 就篩檢網路被ddos造成伺服器延遲05/23 01:57
120F→: 但問題還是發生在地方上傳的環節,所以現在更改了資料05/23 01:58
121F→: 詳細度以提升上傳的方便性05/23 01:58
125F→: 沒有人有錯(除了華航,也沒有人想要數字那麼多05/23 01:58
128F→: 我也蠻想看看那個系統的05/23 01:59
135F→: 如果要分析疫情趨勢,歸回較有可能且有依據的篩檢日期05/23 02:03
136F→: 是較為合理的,如果是要分析篩檢網路的力度,那就是72105/23 02:03
137F→: ,看分析目標取向05/23 02:03
142F→: 然後一次爆出來就是一次性地reload data05/23 02:04
146F→: 校正就校正,以回歸測試的回歸來說,回歸 regress whic05/23 02:07
147F→: h means "return to a worse or less-developed state"05/23 02:07
148F→: ,也就是發生 [變化] 時,狀態倒退到一個 [不穩定] 的05/23 02:07
150F→: 情況,[變化] 就是之前過多的篩檢結果出來,造成數據上05/23 02:07
151F→: 一個 [不穩定] 的狀態05/23 02:07
152F→: 何謂不穩定呢? 因為在疫情人數的分析中有時間軸,如果05/23 02:07
153F→: 沒把數據 [校正] 到正確的時間點,會造成後續分析上的05/23 02:07
154F→: 誤差。然後那麼多人說創新詞,但也沒人說正確的詞backl05/23 02:07
155F→: og中文是甚麼05/23 02:07
159F→: 我說完,誰校正,誰回歸XD05/23 02:12
182F→: 篩檢需要時間,上傳被規格delay,確診是之前的事,所以05/23 02:27
183F→: 拉回前面的時間。然後一次性大量的回歸是一次性reload05/23 02:27
184F→: 前面所有的data造成的05/23 02:27
188F→: 然後染疫跟篩檢確診的時間點絕大機率不同,但要做分析05/23 02:29
189F→: 只能選較有可能且較有依據的篩檢日期,是我做後續分析05/23 02:29
190F→: 的話,應該會在篩檢時間點往前加遞減的weight05/23 02:30
191F→: 不是檢驗網路的能量造成,是系統降低資料詳細度以增加05/23 02:31
192F→: 上傳資料的方便性並reload那些data05/23 02:31
193F→: 現在的問題在於篩檢網路中是否還有應降低的非人為延遲05/23 02:32
194F→: 環節05/23 02:32
203F→: 找出問題點要時間,改系統要時間,重抓資料要時間05/23 02:52
204F→: 就只是一次性地reload之前[所有]的未上報data05/23 02:53
208F→: 這可能要看之後校回的次數了,如果還很多次就是篩檢系05/23 03:06
209F→: 統還有延遲的問題05/23 03:06
19F→: 知道後,要找出問題點,系統要更改,資料要重抓,還要05/23 02:14
20F→: 後續分析,才能公布,還是你認為那些都不需要時間?05/23 02:14
21F→: https://bit.ly/3bIuZfG05/23 02:14
24F→: 現在比較重要的問題是回歸案例的足跡以及篩檢系統的非05/23 02:15
25F→: 必要延遲是否還存在,這次解決的是降低資料詳細度以增05/23 02:16
26F→: 加上傳的方便性05/23 02:16
30F→: 在公衛的角度來看,有一說一,尚未確定的資訊有可能會05/23 02:17
31F→: 造成恐慌,而恐慌是傳染疾病中最為致命的,會讓民眾不05/23 02:17
34F→: 受控05/23 02:17
36F→: 說新創名詞,但也沒人說backlog的正確說詞是甚麼05/23 02:18
38F→: 校正就校正,以回歸測試的回歸來說,回歸regress which05/23 02:20
39F→: means "return to a worse or less-developed state"05/23 02:20
40F→: ,也就是發生 [變化] 時,狀態倒退到一個 [不穩定] 的05/23 02:20
41F→: 情況,[變化] 就是之前的篩檢結果回報05/23 02:20
42F→: 造成數據上一個 [不穩定] 的狀態05/23 02:20
43F→: 何謂不穩定呢?,因為在疫情趨勢的分析中有時間軸,如果05/23 02:20
44F→: 沒把數據 [校正] 到正確的時間點,會造成後續分析上的05/23 02:20
45F→: 誤差05/23 02:20
46F→: 我覺得比較有效的說法是,直接說700,反正愚民那麼多,05/23 02:21
47F→: 保持大家自律性還比較重要05/23 02:21
60F→: 話說我論文有跟醫院合作,在溝通上真的有點困難05/23 02:49
65F→: 不是篩出五天的量,是降低資料詳細度以增加上傳方便性05/23 02:50
66F→: ,然後reload data去校正,之前那些是還沒上傳,但已經05/23 02:51
67F→: 篩檢完了05/23 02:51
73F→: 不同領域的理解不同吧,我跟醫院開會時也覺得他們廢話05/23 03:04
74F→: 很多ㄏㄏ05/23 03:04
15F→: https://bit.ly/3bIuZfG05/23 00:16
40F→: 所以中央是接受方,醫院才是上傳的那一方,很難懂?05/23 00:30
47F→: KMT那麼痛了,還是那個屎樣ㄏㄏ05/23 00:33
52F→: 你訂單沒寫好,不能上傳就是你的問題啊05/23 00:34
60F→: 上面的連結看清楚好嗎? 上傳有規格,但現在的情況就是05/23 00:38
61F→: 篩檢網路被ddos,造成伺服器delay05/23 00:38
86F→: 公布的是篩檢後有成功上傳的,還有未篩檢完畢跟未上傳05/23 01:43
87F→: 成功的,很難懂?05/23 01:43
92F→: 我看到的資訊,有說地方醫院也有說地方政府的,這樣是05/23 02:09
93F→: 講得人有問題還是報導的人有問題?05/23 02:09
94F→: 上傳的詳細度是必須的,因為要後續建檔追蹤,加上還要05/23 02:10
95F→: 公布足跡等,這些都是資訊05/23 02:10
96F→: 這就是在使用者介面設計上的取捨05/23 02:11
100F→: 篩檢要時間,上傳要時間,整理要時間,但除了第一項應05/23 02:56
101F→: 該都要能降到最低,希望目前系統的延遲點都找到了05/23 02:56
2F→: 推3 不管數字變多還變少,維持高自律就對了,保護自己05/23 00:52
3F→: 也保護他人05/23 00:52
7F→: 做不完的原因部分是key資料的規格詳細度跟方便性上的取05/23 00:53
8F→: 捨導致05/23 00:53
9F→: https://bit.ly/3bIuZfG05/23 00:53
17F→: 時間點有許多說法吧,股市可能是其中一個ㄏㄏ,但更改05/23 00:54
18F→: 系統的時間點和reload data的時間點可能也是原因05/23 00:54
30F→: 不管是14+0還是3+11或是7+7,不遵守的就是不遵守,你看05/23 00:59
31F→: 這幾天還是一堆瘋瘋癲癲的不戴口罩在那邊亂,造成問題05/23 00:59
33F→: 的是那些自律性低的高危險群,沒錯就是在說你華航05/23 00:59
48F→: 目前有做辦法就是減低上傳資料的詳細度以提升上傳的方05/23 01:22
49F→: 便性05/23 01:22
55F→: 連結裡面有寫。。。05/23 01:55
57F→: 不是一天的篩檢量提高,是抓回之前就篩完但未上傳的05/23 02:54
5F→: https://bit.ly/3bIuZfG05/23 01:16
6F→: 現在降低系統的資料詳細度以提升上傳方便性。然後不管05/23 01:18
7F→: 是3+11還是14+0或是7+7,不遵守的就是不遵守,看看這幾05/23 01:18
8F→: 天還是一堆瘋瘋癲癲的不戴口罩在那邊亂,長榮沒事就華05/23 01:18
9F→: 航問題最多,低自律的最佳範本就是你華航05/23 01:18
10F→: 篩檢的時間複雜度要壓應該不容易,而且還有一篩二篩等05/23 01:28
11F→: ,像今天報的中科GG05/23 01:29
14F→: 如果,如果啦,系統夠人性化,疫情有趨緩,醫院的負載05/23 02:33
15F→: 變輕,資料能直進直出,校正應該就不會再發生05/23 02:33
3F→: 這要看分析目標的取向,如果想看疫情趨勢,加回最有可05/23 02:01
4F→: 能的篩檢日期是較為合理,如果是要分析篩檢網路的力度05/23 02:01
5F→: 就不能加回去05/23 02:01
10F→: 染疫跟篩檢的時間點絕大機率是不同的,如果是我做分析05/23 02:23
11F→: ,應該會在篩檢確診的時間點往前加遞減的權重05/23 02:23
19F→: 數字回歸到之前時間點是為了看趨勢分析,這要看你的分05/23 01:20
20F→: 析目標取向05/23 01:20
25F→: 可悲的是 有可能還是只有兩個黨05/23 01:52
41F→: 不管是3+11還是14+0或是7+7,不遵守的就是不遵守,看看05/23 01:37
42F→: 這幾天還是一堆瘋瘋癲癲的不戴口罩在那邊亂,長榮沒事05/23 01:37
44F→: 就華航問題最多,低自律的最佳範本就是你華航05/23 01:37
45F→: 回歸regress which means " return to a worse or less05/23 01:37
46F→: -developed state", 也就是發生 [變化] 時,狀態倒退到05/23 01:38
48F→: 一個 [穩定] 的情況,[變化] 就是之前過多的篩檢結果出05/23 01:38
50F→: 來,造成數據上一個 [不穩定] 的狀態05/23 01:38
51F→: 何謂不穩定呢? 因為在疫情人數的分析中有時間軸,如果05/23 01:38
52F→: 沒把數據 [校正] 到正確的時間點,會造成後續分析上的05/23 01:38
53F→: 誤差05/23 01:38
54F→: https://bit.ly/3bIuZfG05/23 01:38
66F→: 延遲的原因就是篩檢需要時間,還有一篩二篩,以及上傳05/23 01:40
67F→: 時的延遲05/23 01:40
102F→: 就篩檢網路被ddos造成伺服器的延遲啊,很難懂?05/23 01:47
13F→: https://bit.ly/3bIuZfG05/23 01:46
34F→: 就篩檢網路被ddos造成一時的伺服器delay,以及實務上地05/23 00:28
35F→: 方回傳資料的延遲,很難理解?05/23 00:28
45F→: 這要看改的時間點跟篩檢量擴大的時間點,人數多還是會05/23 00:47
46F→: 吃人力資源05/23 00:47
48F→: 應該說當人多時候,你要花時間在上傳資料還是處理來篩05/23 01:03
49F→: 檢的人,現在是降低資料詳細度提升方便性,以此降低在05/23 01:03
50F→: 這個環節的負載05/23 01:03
51F→: 會有新數據出來的原因,就是reload那些之前在上傳時不05/23 01:04
52F→: 符規格的data05/23 01:04
57F→: 應該說,不管數字多少,大家都要維持高自律性,保護自05/23 01:10
58F→: 己也保護他人05/23 01:11
61F→: 醫護人員很辛苦了,一瞬間的量衝進來ddos05/23 01:15
62F→: 不過不應該等數據出來再做部署,平常就要保持戒律心,05/23 01:16
63F→: 不要像華航一樣。。。05/23 01:16
66F→: 我是覺得藍綠白有些的梗圖以笑點來說還不錯,但少數就05/23 01:25
67F→: 是了05/23 01:25
71F→: 但問題就是發生在地方上傳的時候啊,中央沒接到消息亂05/23 01:44
72F→: 報才是有問題吧05/23 01:44
73F→: 不過接下來還要看一周內的情況,搞不好系統上部分的取05/23 01:45
74F→: 捨還是有出入05/23 01:45