文件：/// C：/ Users / /AppData/Roaming/SAS/JMP/Addins/com.jmp.xgboost/XGBoost%20Add-In.pdf
第5頁：
XGBoost> XGBoost
第二級菜單條目名稱是多餘的和令人困惑的。
我建議使用一些明確表示要採取的措施，例如“適應模型”。
第6頁：
“如果要執行單個保留分析而不是k倍分析，請將Validation變量的類型更改為Continuous，並確保其值0表示訓練，值1表示驗證。”
很高興有一種方法可以完成這項工作，但是它仍然是無法發現的。這應該在用戶界面中明確顯示。例如復選框控件。
插件界面
我認為，如果Add-in在Analyze菜單下添加了新菜單項以及當前現有的算法，對用戶會更好。我的意思是，XGBoost應該低於分析>預測建模 ，之後助推樹 。我知道這很可能是外接程序作者面臨的JMP菜單自定義系統的限制。
XGBoost UI模型UI
LRT具有“生成Python代碼...”選項，該名稱與Formula Depot中已發布模型所使用的名稱相同。
但是，生成的代碼明顯不同，並且沒有明確指示用戶為什麼應該在另一個上使用一個。我建議使用不同的名稱，並在工具提示文字中說明它們之間的區別。
不同的名稱也將使在Scripting Index中更容易找到它們，在那裡可以提供有關它們之間差異的更多信息。
插件Python生成的代碼：
xgboost_jmp.py
“＃請發送評論，建議和更正至russ.wolfinger@jmp.com”
最好使用公司帳戶，例如tech.support@jmp.com，而不是個人帳戶。
將熊貓作為pd導入
儘管就Python的通用表格數據處理庫而言，Pandas是一個不錯的選擇，但假設它無法使用提供更高性能和可伸縮性的新庫，例如立方英尺和達斯克 。通過對適配器接口進行編碼並為Pandas提供默認實現，可以使用戶從默認實現中受益，同時仍可以為其他部署選項敞開大門。這些新庫嘗試盡可能地遵循Pandas API，有時甚至提供直接替換，這並不難。特別是，顯示我們生成的代碼對Dask數據集進行比內存更大的POC的POC，使用多個線程甚至跨集群進行分佈式計算，對於JMP如何使用戶以最小的努力利用Python生態系統來說，將是一個很好的賣點。
進口seaborn
導入matplotlib.pyplot作為plt
添加代碼以可視化結果很好，但是對於部署方案而言，這是沉重的負擔。我會在一個單獨的模塊中提供該功能，並儘可能使部署代碼盡可能輕便。
我的意思是，數據可視化對於演示很好，但是在生產中，它只是沒有用。生成的代碼應針對生產場景（IMO）進行優化。
def feature_name_replace（f）
此方法可以將兩個不同的要素名稱映射到相同的名稱，從而產生命名衝突，並可能帶來不良後果。例如，feature_name_replace（“ A（1）”）== feature_name_replace（“ A.1_”）==“ A_1_”。
調用代碼不會檢查這種衝突。
可能不太可能，但是由於我們無法控制用戶如何命名其變量，因此我們應該對其進行檢查。
def main（mname，path，df，yvar，xvar，wvar，vvar，cvar，parms，iter，action ='fit'，
verbose_eval = 100，verbose = True，plot = True）：
＃parms：xgboost參數，僅需要那些與默認值不同的參數
沒有有關字典“ parms”的有效或預期內容的文檔。
也許是在哪裡可以找到它們的指針？
＃action ='fit'：使用重複的k倍交叉驗證擬合xgboost模型
＃action ='predict'：預測新數據，二進制模型對象必須已經保存在mod子目錄中
無需檢查action ='predict'，看來主函數將始終嘗試評估模型。如果用戶只想擬合模型，這是否必要？
另外，註釋了當action ='fit'時將模型保存到磁盤的代碼。因此，當指定action =='predict'時，當前無法再使用擬合的模型
＃保存模型二進制對象
＃xg.save_model（fname）
＃打印（fname）
＃versbose_eval：多久打印一次xgboost迭代
錯別字。
＃plot：當action =='fit'時繪製實際與預測
請參閱上面有關繪圖功能有用性的評論。
公式倉庫生成的代碼：
我使用LRT選項發佈到FD，然後使用FD選項生成Python代碼（請參閱上面有關重新使用菜單操作名稱的註釋）。
生成的評分代碼文件似乎正確，並且沒有佔位符。從理論上講，它已經準備好進行部署。問題是，就像我們的客戶在現場生成的類似模型（ 鏈接 ）模型太大，導致Python解釋器崩潰。使用幫助中建議的默認值為PowderMetarllugy生成的模型的行數接近82,000行代碼。
解決此問題的方法有很多種，從減少臨時變量的數量到將生成的代碼拆分成多個較小的文件（或至少包含函數）。已經有一個缺陷為此，它不是優先事項。
除瞭如上所述的針對大型模型的通用優化之外，XGBoost模型的特殊性（例如避免遺漏值和使用一鍵編碼）很可能會被利用，從而通過避免出現在模型中的某些檢查和轉換來生成更精簡的表示。通用代碼生成引擎。
評分代碼驗證
假設我們可以使模型小到可以運行而又不會使Python解釋器崩潰，我們是否將Formula Depot生成的評分代碼的評分結果與Python包裝器生成的二進制模型的評分結果進行了比較？我認為知道生成的數字確實相同是很重要的。在Perforce的以下位置中存儲了針對這種類型的驗證而構建的測試工具：
// depot / main / test / Scoring / Python /。
我相信如果有任何改動，它可以使用得很少。
xgb_jmp_m1.py
這似乎是顯示如何使用該庫的POC文件。
Jupyter筆記本將是一個更好的選擇，因為它是當今這種“這裡是如何使用我的書架”方案的最常用工具。
對於當前屬於xgboost_jmp.py的繪圖代碼，這也是一個更好的地方
