如題,測資讀不進來 Q_Q
對Python來說,記憶體開太小了
如題,測資讀不進來 Q_Q
對Python來說,記憶體開太小了
哈囉,因應 Python 解題者,
我把記憶體限制由 64 MB 開到 512 MB,不知道這樣夠不夠@@"
如題,測資讀不進來 Q_Q
對Python來說,記憶體開太小了
哈囉,因應 Python 解題者,我把記憶體限制由 64 MB 開到 512 MB,不知道這樣夠不夠@@"
夠夠夠!看起來記憶體 128MB 就夠了,但多一點寬限當然是感謝
我採用了 O(N) 的演算法,做了94萬次的比較、94*2=188萬次的int()轉換,看來Python還是沒辦法壓在1.5s內,可能再多給0.3s~0.5s應該就過了
不然90萬次以上的只能特判了 ˊˇˋ
如題,測資讀不進來 Q_Q
對Python來說,記憶體開太小了
哈囉,因應 Python 解題者,我把記憶體限制由 64 MB 開到 512 MB,不知道這樣夠不夠@@"
夠夠夠!看起來記憶體 128MB 就夠了,但多一點寬限當然是感謝我採用了 O(N) 的演算法,做了94萬次的比較、94*2=188萬次的int()轉換,看來Python還是沒辦法壓在1.5s內,可能再多給0.3s~0.5s應該就過了
不然90萬次以上的只能特判了 ˊˇˋ
from sys import stdin
lines = stdin.readlines()
N = int(lines[0])
X = list(map(int, lines[1].split()))
Y = list(map(int, lines[2].split()))
請問測資又改內容了嗎。
請問測資又改內容了嗎。
沒有喔,測資內容都沒有改。
不知道是不是因為最近 ZJ server 不穩,造成同個程式碼執行時間卻有誤差?
不過剛剛發現系統預設測資時限 0.5 s,因為只是想卡 O(N2) 的解而已,這樣好像有點太緊了...
所以剛剛放寬測資時限到 0.8 s,順便全部重新 rejudge 一次。
總結:
只有小放寬時限,測資內容都沒變過。
請問測資又改內容了嗎。
沒有喔,測資內容都沒有改。不知道是不是因為最近 ZJ server 不穩,造成同個程式碼執行時間卻有誤差?
不過剛剛發現系統預設測資時限 0.5 s,因為只是想卡 O(N2) 的解而已,這樣好像有點太緊了...
所以剛剛放寬測資時限到 0.8 s,順便全部重新 rejudge 一次。
總結:
只有小放寬時限,測資內容都沒變過。
0.3s變成0.7s 好扯
測資改來改去,感覺不太尊重答題者。
不同的測試條件,有不同的解題策略。
測資改來改去,感覺不太尊重答題者。
不同的測試條件,有不同的解題策略。
沒有喔,測資內容和時限之前都沒變過。
是在看到您稍早前詢問「請問測資又改內容了嗎?」,我才進去看 judge 狀況。
才發現一樣的程式碼,之前會 AC,重新反覆測試送出卻都會 TLE。
就在想也許跟 server 最近稍稍不穩,所以 server 環境有做調整,導致執行速度會慢一些有關?
也是這時候才決定為了避免對之後解題者不公平(或者其實也不會?)
明明寫得是跟之前 AC 的人同樣想法的程式碼,卻只能得到 TLE。
才決定因應這個狀況,稍稍把時限從 0.5s 放寬到 0.8s。
抱歉之前的文字敘述造成你的誤解,大概就是上面說的過程。
我也沒講清楚,我不是抱怨最後改時限的事。
一開始這題是小測資,一堆人輕鬆 ac 了。
您把測資改成 50MB ,記憶體64MB
感覺就想卡 python
我花了點時間還是過了。
現在有人抱怨過不了,您才又放寬記憶題。
建議出題前,要卡什麼先想好 .
我也沒講清楚,我不是抱怨最後改時限的事。
一開始這題是小測資,一堆人輕鬆 ac 了。
您把測資改成 50MB ,記憶體64MB
感覺就想卡 python
我花了點時間還是過了。
現在有人抱怨過不了,您才又放寬記憶題。
建議出題前,要卡什麼先想好 .
喔喔,了解!
小測資改大測資,的確是從校內賽題改成公開題,
所以想要調整測資難度,但是手腳太慢...我懺悔Orz
不過記憶體 64MB 其實只是單純沿用、
而沒有特別去改出題時系統預設的 64MB 記憶體上限。
所以從來沒有想從記憶體去卡 Python,抱歉造成你的困擾了。
BTW,也許我出題前應該
C、C++、Java、Python 的解法都寫過一次,
這樣才會嚴謹許多。
不過記憶體 64MB 其實只是單純沿用、
而沒有特別去改出題時系統預設的 64MB 記憶體上限。
所以從來沒有想從記憶體去卡 Python,抱歉造成你的困擾了。
那個不覺得是困擾,而是解題的樂趣之一。
3Q