36期获奖结果具体公布时间能告知一下吗？已经一个月了还没结果，复测需要这么久吗？？？？？？？？？？？？？

复赛会改题吗？ 改成预处理1s就尴尬了。。。

多个渠道都问了一下说是联系邮箱，但是找不到联系的邮箱

如题？复赛赛题听说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以内

交互器会在 .out 文件末尾补上一行运行时间，判题器读取 .out 文件的输出和运行时间来计算得分，只要 solution fork 一个子进程监测 .out 文件是否在末尾写入了一个整数，监测到立马篡改成一个极小值，即可以把分数提高到 115w在某次和相关对接工作人员的接触中，得知出题组对于大家的成绩很不满意，只有 34w 分出头，结果自己的题意错漏百出，规则一变再变，回复一拖再拖，自己的交互库还用的低效的输入输出使得运行时间众生平等，然后又有可以通过修改缓存阻塞交互器的 bug，昨天又被发现可以直接修改 .out 文件。你说华为软挑，一天一天换了多少版 Q&A 了，改过不了，换汤不换药啊。人家对接的人员也有理由说的，我以前对接的是什么出题组啊，都是 ICPC 金牌，你这些是什么人你叫我对接，就这么几个人还承诺4月8号出任务书他出得出来吗？出不来，没这个能力知道吧。题意出问题之后 IO 出问题，接着输出都被篡改了，接下来就没东西可出错了。像这样的比赛本身就没打好基础，你能跟我保证正式赛、复赛的时候不出幺蛾子啊？务实一点，我劝你们，和前辈请教一下，把软挑出题的理念先搞懂。搞出来个 115w 分，你到告诉我怎么解释呢？脸都不要了

对于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)，显然不对

如题，测试数据是没有的

交互器的“选手用时“部分只计算了从交互器收到第二次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阻塞漏洞以及浮点输出格式问题已修复，感谢出题组！

请问为什么一直显示Run timeout，前前后后代码修改了十几次，都是这样

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

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