導入什麼時候成爲正確的解決方案？

這個週末我正在做一個項目，我需要用二項式分佈來測試一個事件的概率（y字符的x是給定隨機字節的字母數字的概率）。我的第一個解決方案是自己編寫測試，因爲它很簡單。導入什麼時候成爲正確的解決方案？

def factorial(n): 
    if n == 0: 
     return 1 
    else: 
     return n * factorial(n-1) 

def binomial_prob(n,k,p): 
    bin_coeff = (factorial(n))/(factorial(k)*factorial(n-k)) 
    return = bin_coeff * pow(p,k) * pow((1 - p),(n-k))

而且我用了。但是，SciPy包含一個完全可以做到的binom_test方法。但是，對於分發，這可能會顯着增加規模（需要SciPy和NumPy），並且這是一個相對簡單的測試。我想一個輔助問題是py2exe的智能程度。它只是從SciPy和NumPy或整個庫中導入我使用的模塊。我期望的只是我引用的模塊，但我想下一個問題是SciPy.stats依賴於多少個模塊。但是我離題了......所以我的問題是，我應該何時使用已經編寫的代碼，其代價遠遠超過我需要的，什麼時候應該編寫自己的實現？

（我標記這是蟒蛇，但我想它可能是一個更普遍的問題）

來源

2010-03-01 Zach Varberg

「的時候，我應該使用的代碼已經寫在包括遠遠比我更需要的成本」

永遠。

什麼時候應該寫我自己的實現？

從來沒有。

「包括遠遠超過我需要」的問題通常很愚蠢。你在乎什麼是「包含」？

唯一可能發生的事情是編寫嵌入式軟件時受到嚴重的內存限制。

對於所有其他編程 - 全部其他編程 - 不要三思。儘早且經常提供預先編寫的代碼。少寫。更快地解決問題。操作系統會將未使用的頁面換出內存。你可以放心地忽略它們。

編程是關於解決問題，而不是生成代碼。代碼越少越好。沒有代碼是最好的。

來源

2010-03-01 13:29:25

+1作爲重新發明輪子很少是一個好主意。此外，使用這些庫提供更強大的功能。 F.ex.以上用於計算二項式係數的代碼執行太多的乘法。所以使用這個庫也可以提供更好的性能。 – Frank 2010-03-01 13:34:21

我對使用「永遠」和「永不」等詞語持謹慎態度：宇宙充滿了特殊情況。 – 2010-03-01 14:41:01

@Derrick Turk：我總是使用這些術語來強制人們嘗試並找到他們的實際邊緣案例。我永遠無法開始列舉所有可能的情況。說「總是」和「從不」是比較容易的。請注意，我實際上提供了一個邊緣情況，並且還說「始終」。 – 2010-03-01 14:47:54

答案取決於誰將使用您的應用程序以及它將被分發的範圍。 Unix/Linux人員傾向於非常青睞使用現有的庫，因爲他們習慣於每臺機器都是可以從源代碼重建自己的軟件的開發機器。部分原因是由於必要性，因爲本地代碼庫通常需要根據本地環境進行編譯和鏈接。但在Windows上，這完全是一個不同的命題，因爲大多數用戶不能，也不會，也不應該那樣做，所以您必須考慮這些第三方庫的使用會如何影響您的分發計劃 - 就在下載大小，可用性等方面的許可證。

你說的是py2exe，它向我建議你製作一個單一文件的可執行文件，以便分發給Windows用戶。這意味着你的主要擔心是兼容性（因爲包含本地代碼的庫只能在一種類型的平臺上運行 - 儘管Win32代碼應該沒問題）和大小，因爲py2exe不會對依賴關係做任何狡猾的事情;期待整個事情被捆綁到你的可執行文件中。最好的方法是將其打包並看看會發生什麼。這是一個簡單而非破壞性的步驟，所以你應該儘快爲自己嘗試一下。

您還需要考慮您分發的任何庫的許可證。再次使用'重複使用'的人羣有時會忘記這一點，因爲他們經常使用軟件而不必重新分配，所以這不是問題。對你來說，尤其是如果你有你的僱主或機構擁有的代碼，儘管認識到分發Python應用程序時很重要，但實質上你必須分發源代碼以供任何人查看。

來源

2010-03-02 11:37:56 Kylotan

導入什麼時候成爲正確的解決方案？

回答

相關問題