作弊& # 39;解决方案# 39;由Raghunadh N。

马西莫·扎内蒂,Kevin Hellemans:在测试3中，值10作为维度参数输入(不是索引参数，它的值是1)。因此，在测试3中，通解是a(:，:，:，:，:，:，:，:，:，:， 1)。-DIV

你好，我是拉斐尔·s·t·维埃拉。首先，感谢你的建设性反馈。当我在几年前编写Test Suite时，我探索了一些计时选项，包括timeit()函数的使用。我相信我最终做出的选择是有具体理由的，尽管我不能自信地回忆起所有的细节。至于计时的实现，我承认目前它包含了一些生成随机字符串的开销。然而，我怀疑开销是否重要。-我猜它占总时间的不到1%。因此，虽然您提出的修改可能是一个很好的改进，但最好还是把它作为一个提示留给未来的问题:除非有一个令人信服的理由，否则我不喜欢更改现有的测试套件。接下来，让我与您分享8秒基准测试的基础。我写了一个未优化的参考解决方案，并添加了一个小的安全裕度。 My hypothesis was that if my unoptimised code could satisfy the Test, then most likely other (experienced) Cody players could also pass the Test if they avoid slow operations. When the Problem was published, indeed the Cody players who have solved it were able to pass the test using a variety of approaches. Indeed, some advanced Cody players were able to highly optimise their code and deliver impressively quick times. You may notice that I built in an allowance for increasing computational power. This allowance also had a safety margin. In other words, the increased number of iterations is somewhat less than the projected increase (from historical data) that would maintain equity. Of course, even predictions based on data can be wrong, so I have checked my reference solution again (twice). I got the following: "Your wall time to decode 2370 message batches = 7.99 seconds." "Your wall time to decode 2370 message batches = 7.62 seconds." In both cases it passed. The first instance was amusingly close to the limit, but I mention again that this code was not optimised yet it still passed. I can assure you that it has no "hashes". Finally, the subtext is that this is intended to be a difficult Problem: a challenge for experienced Cody players. Some will like that, and will even enjoy challenging themselves to optimise their own code. Others won't be interested, and there are thousands of other Problems on Cody for them to solve. —DIV

Rafael，我不知道assert()函数在Cody上是不允许的。谢谢你提醒我们。以前它是工作的，实际上它是理想状态下应该的函数。，所以我不打算改变问题陈述。然而，我同意目前Cody禁止玩家在他们的解决方案中使用assert()，将不得不使用error()函数。万博 尤文图斯然而，我可以确认它是“没有必要”使用任何虚拟变量。附注:我认为assert()被禁止是因为一小部分Cody玩家厚颜无耻地通过无数的问题作弊。理想情况下，Cody中应该有一个开关，允许assert()函数用于特定的单个问题，在这种情况下，可以实现一些特殊措施来防止此类exploit。例如，运行命令"!rm - v assert.m" (without quotation marks) in the Test Suite.

你好,拉斐尔。感谢你关于使用try &抓住。我相应地修改了测试套件，所以现在应该可以让Cody玩家调用他们的函数&;或“;compareDoubles"。当格式化整齐的时候，这个工作区代码从Test Suite的核心内容中分离出来，所以我把它塞到每个单独的Test中的一行中。关于问题陈述，我认为这就像现实生活，《Cody》的玩家能够解决问题。一些Cody玩家会发现这种转换很明显，所以这对他们来说并不是一个麻烦;其他《Cody》玩家可能会觉得这种转变不那么明显，所以这对他们来说是一个小小的额外挑战和学习机会。(另见44690题)

你好,拉斐尔。肯定有什么问题。从我的角度来看，在编写测试套件时，一个解决方案要么每次都通过所有的测试，要么每次至少失败一个测试。因此，我增加了选定测试中的测试迭代次数，您的解决方案始终无法通过修改后的测试4、5和6;它也可能会失败一些没有被修改的其他测试(例如解决方案3651713失败的测试7a)。我还在重新调整的故障消息中添加了相当多的细节，以便您能够识别有问题的参数值。div

“全局变量z"在问题标题和问题描述中都有明确提到。除此之外，我相信您的评论和测试套件应该足以消除任何残留的怀疑。div

你好,拉斐尔。谢谢你的反馈。每种方法都有优缺点。对问题语句中的所有数字使用相同的基数会使比较一目了然，但值并不都是精确的。在问题陈述中使用的混合基数意味着所有数字都使用精确的值;虽然读者为了比较大小而进行转换会有一些不便，但恕我直言，这可能有更多的教育价值。div

理查德，请检查问题描述。任务是识别均匀分布的随机数集。所谓“正态分布”(它的另一个名字是“高斯分布”)不是均匀分布。这个链接可以帮助说明这两种分发方式之间的区别:https://math.stackexchange.com/questions/657254/normally-distributed-random-numbers-vs-uniformly-distributed-random-number -DIV

我同意。

巧妙的解决方法使用一些额外的数学知识。

%%是一个问题，因为它的文档记录很差，因此理解也很差(甚至不理解)。下面是它的工作原理。[注意:在下面的代码/输出中，我将使用“↲”来表示一行的结束。]       ~~~~~~~~~~ 创造者写这个测试套件 : ~~~~~~~~~~ ----- commandA↲commandB↲↲% %测试1↲commandX↲↲% %测试2↲commandY↲ -----       ~~~~~~~~~~ 科迪运行下面的测试 : ~~~~~~~~~~ 测试1:(i) commandA;(2) commandB;和(3)commandX。测试2:(i) commandA;(2) commandB;和(3)commandY。      ~~~~~~~~~~ 科迪显示以下输出 : ~~~~~~~~~~ ----- %% commandA↲commandB↲↲% %测试1↲commandX↲↲[输出从commandX]↲↲% %测试2↲commandY↲↲[输出从commandY]↲↲ ----- ~~~~~~~~~~       注意:(i)任何命令之前第一个% %(即commandA和命令)在运行每个测试的开始; (ii) output of any commands before the first %% is suppressed [never displayed]; (iii) for the player, a spurious "%%" is displayed on the first line of the Test Suite if there were any commands before the first "%%".       It is actually a very clever structure for Problem Creators writing a Test Suite. Therefore I'd be keen to retain it. See e.g. //www.tianjin-qmedu.com/matlabcentral/cody/problems/44655       The annoyances are: (i) lack of documentation; (ii) suppression of output; and (iii) insertion of a spurious "%%" in the display. Although none of these three issues affect the running, they cause a lot of confusion and misunderstanding.

好:-)

William的解决方案于2018年9月25日通过了测试套件中的所有测试。1080个消息批的墙时间= 7.30秒(CPU时间= 9.21秒)。

我同意以一种实际保证通过测试套件的方式选择N是可能的。我的观点是，在这个提交中(顺便说一下，在解决方案188645中)N被选择的比那个小，所以这个提交通过需要一些运气——有一个重大的风险，它可能会失败。

感谢goc3对测试套件的改进和其他问题的修复。那些对开发自己的测试套件感兴趣的人可能愿意尝试从//www.tianjin-qmedu.com/matlabcentral/cody/problems/44631开始的一系列问题

公平点。

如果你把问题描述得很简单，威廉，你会邀请仔细检查....也许您会在下次提交时发现注释代码的好处。

HH，你破解这个问题没有功劳。只有合法的解决方案才能获得信誉。万博 尤文图斯

Oleksandr Denysenko，你破解了这个问题，没有功劳。只有合法的解决方案才能获得信誉。万博 尤文图斯

代码注释做得很好!

一个优雅的解决方案。

一个优雅而简单的解决方案。

David Verrelli的解决方案于2018年6月18日通过了测试套件中的所有测试。1001消息批处理的墙时间= 7.05秒(CPU时间= 9.01秒)。

William的解决方案于2018年9月25日通过了测试套件中的所有测试。1080个消息批的墙时间= 7.17秒(CPU时间= 9.01秒)。

Binbin Qi的解决方案于2018年6月17日通过了测试套件中的所有测试。1001消息批处理的墙时间= 3.81秒(CPU时间= 4.73秒)。

Jean-Marie Sainthillier的解决方案于2018年7月13日通过了测试套件中的所有测试。1021个消息批的墙时间= 6.77秒(CPU时间= 7.09秒)。

J. S. Kowontan的解决方案于2018年6月17日通过了测试套件中的所有测试。1001消息批处理的墙时间= 3.36秒(CPU时间= 4.06秒)。

Alfonso Nieto-Castanon的解决方案于2019年2月3日通过了测试套件中的所有测试。1193个消息批处理的墙时间= 6.14秒(CPU时间= 8.24秒)。

Mu的解决方案于2019年1月08日通过了测试套件中的所有测试。1170个消息批的墙时间= 4.26秒(CPU时间= 6.25秒)。

你好,威廉。我非常喜欢你的独创性&尤其是你在这里的方法的效率。我认为现有的代码很难正确地解码从(比如说)编码的信息，对吗?"当心大脚野人参与凤凰行动"我不想解释这个，以免给别人太多线索。但我希望你明白我的意思。尽管我相信您可以(在必要时)调整代码来处理此类情况。div

这个用户(ALBERT ALEXANDER STONIER)似乎玩弄了系统，通过“袜子傀儡”账户提交的这个不起眼的解决方案来欺骗“喜欢”。div

这个用户(ALBERT ALEXANDER STONIER)似乎玩弄了系统，通过“袜子傀儡”账户提交的这个不起眼的解决方案来欺骗“喜欢”。div

这个用户(ALBERT ALEXANDER STONIER)似乎玩弄了系统，通过“袜子傀儡”账户提交的这个不起眼的解决方案来欺骗“喜欢”。div

这个用户(ALBERT ALEXANDER STONIER)似乎玩弄了系统，通过“袜子傀儡”账户提交的这个不起眼的解决方案来欺骗“喜欢”。div