文件：/// 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，有时甚至提供直接替换，这并不难。特别是，显示我们生成的代码的Dac数据集比内存可以容纳的Dask数据的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的绘图代码，这也是一个更好的地方
