如题？复赛赛题听说4-15  9：00发布，在哪里看到链接？

 这是昨天的公式版，这里的33和34名现在的版本里都消失了。我们没有收到任何邮件通知。 

如题能否下发训练赛及初赛的数据集

尊敬的华为软件精英挑战赛组委会、上合赛区评审专家：您好！我们是同济大学“恭喜以下队伍打铁”队。在2026年华为软件精英挑战赛上合赛区初赛中，我们取得了86万分的成绩。近日收到组委会关于我们代码查重异常的通知，团队对此高度重视并第一时间进行了全面复盘与自查。我们完全理解并坚决拥护组委会对学术诚信和比赛公平性的严格把控，但我们郑重声明：本团队绝对没有任何违规抄袭行为。 在此，我们诚恳地向组委会提出申诉，希望评审专家能结合我们的真实开发过程和核心策略，对我们的代码进行人工复核，以恢复我们的成绩及晋级资格。对于查重系统出现的异常，我们分析主要由以下两个客观原因叠加导致：一、 赛题底层算法的强收敛性与AI辅助开发的固有特性本道赛题属于二维不规则多边形排样的经典问题。在基础算法层面，业内公认的最优解即为闵可夫斯基和（NFP卷积）。在追求高分的前提下，底层算法选型具有高度的一致性。同时，在比赛规则允许的范围内，我们使用了大模型（ChatGPT 5.4、Claude Code）作为底层标准算法的辅助编写工具。虽然我们在提示词中严格限制了“禁止引入Clipper、Boost、CGAL等开源库或其他公开代码”，但由于大模型本身是通过学习海量公开学术论文与技术博客训练而成，其生成的标准NFP卷积、凸分解等底层算法实现，天然会与部分开源思路或标准范式产生结构性相似。这种底层算法的相似性是大模型辅助开发的正常现象，是对公开学术成果的合理参考，而非直接复制他人代码。二、 我们的核心高分壁垒：完全原创的多路线分支策略与参数调优我们能取得这样的分数，并非依赖某段标准底层算法的实现，而是基于我们完全原创的四层动态分支求解策略以及上百次的本地参数调优。这是其他队伍无法复制的核心工程量，主要体现在以下几个方面：独创的多路线分支系统： 我们摒弃了单一路线，设计了四条求解路径：路线A：精简NFP卷积（AI辅助实现）路线B：凸分解+队列式合并（AI辅助实现）路线C：最小凸包覆盖 Fallback（团队完全手写实现）路线D：完全NFP卷积（实验后已弃用）精细的动态切换逻辑： 我们通过多边形顶点数(n, m)和凹点(reflex)比例进行动态路由。例如：当 n+m <= t1 时，进入凸分解路线；否则扫描reflex点数量。若双方均为凸多边形，或 reflex比例 > w1 且 n+m >= t2，亦或 n+m >= t3，程序会直接进入我们手写的 Fallback 路线，通过牺牲极小的精度来换取极大的时间效益。大量的工程优化与实验： * 查询与I/O优化： 使用了基于 y-bucket 和矩阵哈希优化的 BVH 查表输出，并手写了基于 getchar_unlocked/fread 与 _write 的 I/O 加速。参数炼丹： 为了确定很多组黄金参数，我们进行了超过200组本地对比实验。正是这套独一无二的工程化架构和参数组合，让我们在排行榜上脱颖而出。如果是恶意抄袭，绝无可能在没有经过大量试错的情况下拼凑出这样一套严密的动态分支系统。三、 详实的开发过程证据为了证明团队工作的原创性，我们已将整个赛程的开发记录整理成附件，随时接受组委会的严格审查：提交记录： 完整展示了从基础框架搭建、多分支逻辑合并、底层优化到最终调参的演进过程。200+组本地实验记录： 包含完整的测试数据、参数调整对比及分数变化日志。团队协作证明： 包括部分每日技术讨论记录、代码评审截图。我们三名队员在过去的三周里倾注了所有的课余时间，熬过了无数个日夜才换来今天的成绩。我们非常珍惜华为软件精英挑战赛这个极具含金量的平台。恳请各位评审专家在人工复核时，重点审阅我们代码中的动态分支控制流（Fallback机制）以及相关的BVH查询优化部分。我们坚信组委会一定会秉持公平、公正、客观的原则，查明事实真相。期待您的回复！感谢各位老师在百忙之中的辛勤付出！此致敬礼！同济大学“恭喜以下队伍打铁”队队长：彭怡焱联系电话：13500754388邮箱：2451299@tongji.edu.cn2026年4月13日附件：代码查重报告截图及分析说明完整提交记录及分支演进截图200余组本地参数对比实验数据汇总表团队协作沟通记录及代码Review截图

截断精度e-6，面积阈值e-8，本来没错截断判错，出题人何意味啊？这么简单的道理都不懂吗，你好歹反过来，截断e-8，面积e-6，多边形边长1以内

对于practice_1的第一个数据，两个多边形都是矩形，多边形1 y轴在[0,0.08603]范围内，多边形2 y轴在[0,0.21721]范围内，多边形2 y轴移动-0.10372后在[-0.10372,0.11349]范围内，此时多边形1 y轴上被包含在多边形2里，demo得出的y轴投影重叠为0.08603，实际上是多边形1完全在多边形2里的长度，最终答案输出也是(0,-0.08603)，显然不对

🚀 【码道体验官】开发者声音征集活动正式启动！各位大佬，代码交完了，排名看完了，是不是还有点意犹未尽？别急着，我们还想请你“吐槽”一下产品 —— 华为云码道（CodeArts）代码智能体使用产品功能代码续写、代码优化、编写SKILL……过程中有没有哪个地方让你觉得：“这报错谁看得懂啊？”“为什么不能一键XXX？”“要是能加上XX功能就好了！” 📍 开发者声音（VOD）收集请各位同学可以围绕以下几个方向反馈遇到的问题及建议，我们将根据被采纳的价值vod给予奖励~安装登录，初始化配置，意图描述、代码生成、代码续写、迭代优化，部署上线等问题；核心场景功能体验、界面设计、操作流程、环境配置、性能瓶颈等问题； 📍 最佳体验官评选我们将评选出 5 位“码道最佳体验官”，每位可获得 软挑赛纪念礼品三选一：定制水杯🥤、主题短袖👕或专属雨伞 ☔ 📍 参与方式：点击链接填写调查问卷：link⏰ 截止时间：2026年5月20日针对反馈的码道产品被采纳的问题我们也将整理公示，反馈优化进度。你的每一条反馈，都可能改变产品的未来！期待你的声音！    相关热门活动：【华为云码道（CodeArts）代码智能体 软挑赛实战案例征集】     

如题，测试数据是没有的

交互器的“选手用时“部分只计算了从交互器收到第二次OK开始，到交互器读入所有答案的时间，未计算交互器本身的输出时间。所以选手可以将Interactor->Solution方向的pipe缓冲区大小设为最小(4096字节，约为256个查询)，然后只读入前m-256个query使得交互器被阻塞。此时选手可以用任意长（不超过10分钟）的时间处理m-256个query，而此过程不计入最终时间。同时，选手可以将Solution->Interactor方向的pipe缓冲区开大到1MB，并将前m-256个query的答案提前写入pipe。于是本题的”选手用时“就只包含256个query的处理时间+256个query的输出时间+交互器读入m个答案的时间。由于交互器未做任何io优化，交互器读入m个答案的时间必将占据选手用时的绝大部分，导致所有采取该策略的选手时间都极为相似，于是本题的效率竞争部分完全无效化（而这正是比赛方所强调的重点）。我们拟给出修正该问题的方案：1.选手计时从交互器开始输出查询开始计算2.现阶段下发的交互器输出效率极为低下（每输出一行就会flush stdout两次*），为了避免采取第1条改动后交互器io成为瓶颈，请出题组进行合理的io优化。 如果出题组可以接受更大程度的改动，以及取消（本就无效的）”预处理“时间限制，我们建议取消交互器，改为传统io模式，这有利于运行时间的稳定性。 *注：出题组极高概率采取了cout<<x<<' '<<y<<endl;cout.flush();的写法，这种写法每输出一行就会flush stdout两次。同时出题组显然没有进行任何浮点数格式化，而是依赖iostream的默认格式化，因此会导致我们在 cid:link_0 中已经描述的问题。因此，该交互器不仅性能低下，而且仅仅在practice数据上就会产生不符合题目约定的输出，更有可能造成精度丢失。 鉴于出题组至本贴发出时依然没有对我们之前提出的问题做出任何回应，我们不得不再次敦促本次华为挑战赛出题组认真对待比赛的严谨性和公平性，及时修正我们上述提到的两点问题！ 此外，我们也呼吁出题组公布算分公式中alpha,beta,omega,T的值，这有益于比赛的公平性和透明性。若出题组坚持这些参数不能对选手公开，也请给出合理的理由。  UPD 2026/4/8 22:50 PIPE阻塞漏洞以及浮点输出格式问题已修复，感谢出题组！

在3.23发布的第一版任务书中明确指出在初赛阶段，两个简单多边形均为凸多边形。但是在3.25更新后的任务书中并没有这个说明，所以初赛的多边形到底是不是都为凸多边形，还是存在凹多边形的情况。

大家还有出现这个问题么，我一直显示wrong answer，包括把demo提交上去也是

 相同代码就有那么大波动，更不用说修改后的代码了，都不知道自己有没有优化 

36期获奖结果具体公布时间能告知一下吗？

win判题器就是有问题还是用win开发就是低人一等。这马上就快上升到蒙古上单和陈睿叔叔的问题了

实测表明，对于极小但仍符合任务书“保留5位小数”约定的输入数据，如0.00001，经过Interactor处理后会变为1e-05，不符合题目约定的输入格式，请修复交互器！另外，由于任务书并未规定输入坐标绝对值的上限，如1000000000.00000也可能为合法输入，而交互器会将其写成科学计数法1e+09，这也是不符合约定的！对于整数输入如1.00000，交互器实际输出1，也并没有保留5位小数。希望出题组在任务书中给出明确的坐标绝对值上限（以及多边形边数上限），否则理论上超过double上限的坐标也是合法输入！请出题组以严谨负责的态度对待此次比赛，及时修正上述错误。 UPD 2026/4/8 22:50 浮点数格式问题已修复，感谢出题组！