算法优化锦标赛。 - 页 80 1...737475767778798081828384858687...132 新评论 Реter Konow 2016.07.06 08:03 #791 Event: 我没有在任何地方声称我的版本比你的好 ))祝贺你!我可以坦率地说,我没有想到像你的算法所提出的这样一个简单的解决方案。这种解决方案的优点是完全针对具体任务,其中没有任何多余的东西。然而,其优势也是其劣势。任务稍有复杂化,就需要你重做一切。例如,如果让你找出一个字符串中的字数,计算键中所有可能的字符中使用的 符号数量,计算每个字符的重复次数,计算每个单词中的字母数量,计算文本中的标点符号数量--你的算法无法处理。为什么我说我为我的算法留下了发展空间--因为即使在编译一个完整的字符串并将其写入文件之前,我的算法也会计算我所列出的所有这些参数。当然你不需要这样做来解决这个问题,但是如果现在让我计算这些参数,我就不用写一行代码了。 我把这种方法称为 "计算算法的多功能性余地"。 Реter Konow 2016.07.06 08:18 #792 Andrey Dik: 然后准备迎接冠军的挑战,你已经把 "热身 "做得很完美了。有趣的建议。 在没有奖金的情况下,我参加比赛的唯一动力是希望在 "食物链 "中找到自己的位置。 我是新来的,我很好奇我在社区开发者中的专业程度排名。 为了方便起见,我提议废除所有的连接问题。 让它像文本问题一样简单--有一个图书馆,它有一个FF。该任务由一个脚本来解决。结果被发送到一个文件。这项任务不仅对我,对你也应该是一个挑战。 你认为只有你能做的事。一些你真的会为之战斗到死的东西,而不是慷慨地谈论 "热身"。而失败者会公开承认他已经认输,而不会试图把事情变成空洞的争论和妖言惑众。你觉得这个建议如何?:) Andrey Dik 2016.07.06 08:58 #793 Реter Konow:有趣的建议。 由于没有奖金,我参加比赛的唯一动力是希望在食物链中找到自己的位置。 我是新来的,我很好奇我在社区开发者中的专业水平如何。 为了方便起见,我提议废除所有的连接问题。 让它像文本问题一样简单--有一个图书馆,它里面有一个FF。该任务由一个脚本来解决。结果被写入一个文件。你要回到 "建议 "吗?我们可以交换剧本,只有你和我在私下里通信,对于冠军来说,这是不可能的。文件的结构和它们的连接方式不是从天花板上取下来的,也不是为了让参与者的生活复杂化,它是有意义的,这已经说过很多次了。如果没有办法管理参赛者的剧本,如何检查剧本的工作,评委如何判断作品和结果?Reg Konow:这项任务不仅对我来说是个挑战,对你来说也应该是个挑战。这就是你认为只有你能做的事。一些你会真正为之 "拼命 "而不是慷慨地谈论 "热身 "的东西。而失败者公开承认他已经认输,而不是试图把一切都带入空洞的争论和妖言惑众。至于冠军的难度,不用担心。对我来说,这个决定不会比你更容易。 Реter Konow 2016.07.06 09:10 #794 Andrey Dik:你要回到 "建议 "吗?只有你和我可以在私人信件中交换脚本,这对冠军没有作用。文件的结构和它们的连接方式不是从天花板上取下来的,也不是为了让参与者的生活复杂化,它是有意义的,这已经说过很多次了。如果没有办法管理参赛者的剧本,你怎么能检查剧本的工作,陪审团将如何评判作品和结果?至于冠军赛的任务的复杂性--别担心。对我来说,解决方案很难比你更容易。倡导冠军,避免公开竞争的奇怪人...... Реter Konow 2016.07.06 09:17 #795 Andrey Dik:你要回到 "建议 "吗?只有你和我可以在私人信件中交换脚本,这对冠军没有好处。 为什么我们需要一个陪审团?脚本的结果将出现在文件中。我们可以假设,参与者的脚本序列将被上传到这里。每个人都将能够检查任何参与者的工作。该脚本将解决一个特定的任务,它不能以任何其他方式使用。黑客攻击也是不可能的。 Реter Konow 2016.07.06 09:27 #796 Реter Konow: 让参与者的脚本自己上传至文件。假设它对每个人都有明确的格式,但文件的名称将包含竞争者的名字。比赛结束后,每个人都可以将其他参赛者的脚本下载到自己的电脑上,上传到图表中,并在文件柜中看到带有参赛者脚本结果的文件。 Andrey Dik 2016.07.06 09:28 #797 Реter Konow:奇怪的是,这个人促进了锦标赛,并以各种可能的方式避免公开竞争...... 缝合和隐藏FF的挑战管理不是公开的竞争,也不公平,因为FF挑战的真实数量无法被观众或陪审团所验证。相反,我主张公平竞争和结果透明。 Реter Konow 2016.07.06 09:36 #798 Andrey Dik:缝合和隐藏FF挑战的管理不是公开的竞争,也不公平,因为FF挑战的真实数量无法被观众或陪审团核实。相反,我赞成公平竞争和结果透明。 好吧,在这种情况下,决定权应该在图书馆。但也许有一个不需要陪审团的选择。因为我们不需要一个陪审团来确定文本问题的最佳解决方案。 Реter Konow 2016.07.06 09:38 #799 Реter Konow: 好吧,在这种情况下,决定权应该在图书馆。但也许有一个不需要陪审团的选择。就像我们不需要一个陪审团来确定文本问题的最佳解决方案。 我只是试图简化你(在我看来)出于某种原因而试图复杂化的东西。 Реter Konow 2016.07.06 09:43 #800 我完全不明白我们在谈论什么。FF的调用是通过一个特殊的函数在其库中计算的。 这也是文件写入 功能的位置。 如果在第一次调用FF库时,在那里(在一个特殊的函数中)传递参与者的名字,那么这个函数将在他的文件名中输入参与者的名字与结果。 在那里,文件中会有一些FF的调用。 在这种情况下,脚本将满足所有的请求。 1...737475767778798081828384858687...132 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
我没有在任何地方声称我的版本比你的好 ))祝贺你!
我可以坦率地说,我没有想到像你的算法所提出的这样一个简单的解决方案。这种解决方案的优点是完全针对具体任务,其中没有任何多余的东西。
然而,其优势也是其劣势。任务稍有复杂化,就需要你重做一切。
例如,如果让你找出一个字符串中的字数,计算键中所有可能的字符中使用的 符号数量,计算每个字符的重复次数,计算每个单词中的字母数量,计算文本中的标点符号数量--你的算法无法处理。
为什么我说我为我的算法留下了发展空间--因为即使在编译一个完整的字符串并将其写入文件之前,我的算法也会计算我所列出的所有这些参数。
当然你不需要这样做来解决这个问题,但是如果现在让我计算这些参数,我就不用写一行代码了。
我把这种方法称为 "计算算法的多功能性余地"。
然后准备迎接冠军的挑战,你已经把 "热身 "做得很完美了。
有趣的建议。
在没有奖金的情况下,我参加比赛的唯一动力是希望在 "食物链 "中找到自己的位置。
我是新来的,我很好奇我在社区开发者中的专业程度排名。
为了方便起见,我提议废除所有的连接问题。
让它像文本问题一样简单--有一个图书馆,它有一个FF。该任务由一个脚本来解决。结果被发送到一个文件。
这项任务不仅对我,对你也应该是一个挑战。
你认为只有你能做的事。一些你真的会为之战斗到死的东西,而不是慷慨地谈论 "热身"。
而失败者会公开承认他已经认输,而不会试图把事情变成空洞的争论和妖言惑众。
你觉得这个建议如何?:)
有趣的建议。
由于没有奖金,我参加比赛的唯一动力是希望在食物链中找到自己的位置。
我是新来的,我很好奇我在社区开发者中的专业水平如何。
为了方便起见,我提议废除所有的连接问题。
让它像文本问题一样简单--有一个图书馆,它里面有一个FF。该任务由一个脚本来解决。结果被写入一个文件。
你要回到 "建议 "吗?我们可以交换剧本,只有你和我在私下里通信,对于冠军来说,这是不可能的。文件的结构和它们的连接方式不是从天花板上取下来的,也不是为了让参与者的生活复杂化,它是有意义的,这已经说过很多次了。如果没有办法管理参赛者的剧本,如何检查剧本的工作,评委如何判断作品和结果?
这项任务不仅对我来说是个挑战,对你来说也应该是个挑战。
这就是你认为只有你能做的事。一些你会真正为之 "拼命 "而不是慷慨地谈论 "热身 "的东西。
而失败者公开承认他已经认输,而不是试图把一切都带入空洞的争论和妖言惑众。
至于冠军的难度,不用担心。对我来说,这个决定不会比你更容易。
你要回到 "建议 "吗?只有你和我可以在私人信件中交换脚本,这对冠军没有作用。文件的结构和它们的连接方式不是从天花板上取下来的,也不是为了让参与者的生活复杂化,它是有意义的,这已经说过很多次了。如果没有办法管理参赛者的剧本,你怎么能检查剧本的工作,陪审团将如何评判作品和结果?
至于冠军赛的任务的复杂性--别担心。对我来说,解决方案很难比你更容易。
倡导冠军,避免公开竞争的奇怪人......
你要回到 "建议 "吗?只有你和我可以在私人信件中交换脚本,这对冠军没有好处。
奇怪的是,这个人促进了锦标赛,并以各种可能的方式避免公开竞争......
缝合和隐藏FF的挑战管理不是公开的竞争,也不公平,因为FF挑战的真实数量无法被观众或陪审团所验证。
相反,我主张公平竞争和结果透明。
缝合和隐藏FF挑战的管理不是公开的竞争,也不公平,因为FF挑战的真实数量无法被观众或陪审团核实。
相反,我赞成公平竞争和结果透明。
好吧,在这种情况下,决定权应该在图书馆。但也许有一个不需要陪审团的选择。就像我们不需要一个陪审团来确定文本问题的最佳解决方案。
我完全不明白我们在谈论什么。FF的调用是通过一个特殊的函数在其库中计算的。
这也是文件写入 功能的位置。
如果在第一次调用FF库时,在那里(在一个特殊的函数中)传递参与者的名字,那么这个函数将在他的文件名中输入参与者的名字与结果。
在那里,文件中会有一些FF的调用。
在这种情况下,脚本将满足所有的请求。