I think you should look at what your end goal is and what your constraints are.
Sometimes a bruteforce method can solve a problem in 50ms trying out every combination of solutions and a "clever" solution can solve it in 10ms. At that point, the less clever but easier to understand solution trumps the clever solution.
However, there are some problems where brute forcing will not only be inelegant but simply won't work. There are many problems where if you attempt to naively brute force them it will take a significant amount of time to solve them. So obviously, these types of problems need a more elegant approach.
So ask yourself, why you are attempting these Project Euler problems? Are you doing it to learn? Then maybe trying a clever solution would be in your best interest but only after you have initially tried a brute force solution to help get a grasp of the problem.
When doing the Python Challenge problems I try to do it the most succinct way I can, pushing the limits of my abilities. After I solve it I then review other peoples answers and take mental notes of people who were more clever than myself and what they did. Some people will make special use of a data structure I hadn't thought of that is more suited to the task or they will have little mathematical tricks they use to make their algorithm more efficient. In the end I try to absorb as much of their cleverness as I can and make it show the next time I'm presented with a problem of a similar nature.
作为一名初学者程序员，您将花费更多的精力来弄清楚如何在 C++ 中实际实现事物，而不是花费精力为每个问题找到巧妙的解决方案。 这很好，因为它让您有机会在解决一系列不同类型的问题的同时探索 C++ 的不同领域。
当您精通 C++ 并且您不必考虑如何做每件小事时，那么您将能够花更多时间发明非暴力解决方案。
As a beginner programmer, you will be spending more of your mental energy figuring out how to actually implement things in C++, rather than spending energy on finding a clever solution to each problem. This is fine, because it gives you the opportunity to explore different areas of C++ while working on a range of various kinds of problems.
When you become proficient in C++ and you don't have to think about how to do every little thing, then you will be able to spend more time inventing non-brute-force solutions.
The elegant solutions weren't created spontaneously; they were derived from the brute-force solutions when more speed or less memory consumption were required from the current solution.
So no, it's not. It's how the elegant solutions came into being.
I would say that no, it's not a bad sign. In fact you're doing yourself a favor by trending away from premature optimizations, which is definitely a Good Thing.
learning is a brute force process. I wouldn't say its bad. In trying to do something that way you may notice a pattern. I think as long as you are thinking about something and trying to find solutions you will learn. There are few people who just jump to the most elegant or efficient solutions.
It would be hard to convince me that people that are trying to learn could ever be called bad. Except maybe an evil scientist :P
Do you fit inside the 1 minute runtime rule for the problems? If yes, then your "brute force" solution fulfils all the requirements, and that's actually a very good sign that you can quickly come up with something that works!
These kinds of problems encourage micro-optimisation and very clever algorithms, but in general a very readable straightforward implementation will be much easier to maintain, and will be favoured in the business world.
有时我会忘记使用暴力破解，并开始扫描 API 来寻找“正确”的解决方案。 在很多情况下这绝对是一个错误。 如果强力解决方案很容易实现，可以根据您的需要进行扩展（真的，如果它有效的话），那么就忘记正确的解决方案。您很快就会找到它（很多时候您会发现它）已经知道了！），但与此同时，您解决了问题并能够继续下一个问题。
编码时的障碍是可怕的，绝对应该比暴力解决方案更要避免。
To put this in a different context:
When you use a library that you don't know very well (for creating UI, for instance) you can solve a simple problem in a perfectly performant way, though you know there's a "correct way" to do it. If you are curious and worried that your brute-force code makes you look like a moron, you will soon find the "correct way" to do it (e.g., on weekends, or while you sleep). In the meantime, through brute force, you will have something that works.
I actually forget to use brute force sometimes, and start scanning the API for the "right" solution. This is definitely an error in many cases. If the brute force solution is easy to implement, scales as you need it to (really, if it works), then forget about the correct solution. You'll find it soon enough (and many times you already knew it!), but in the meantime, you solved the problem and were able to go on to the next one.
Roadblocks are terrible when coding, and should definitely be avoided more than brute force solutions.
我经常和你遇到同样的情况，这实际上就是我开始做 PE 问题的原因——我实施了很多蛮力方法，并想让自己接触到更优雅的解决方案......
It's definitely not a bad sign to trend to brute force, especially as a beginner because you may not know any better. Especially with Project Euler, it is a bad sign to implement a brute force method and not review the comments to learn a more efficient method.
I often end up in the same boat you're in and that's actually why I started doing P.E. problems -- I was implementing a lot of brute force approaches and wanted to expose myself to more elegant solutions...
发布评论
评论（14）
我认为你应该看看你的最终目标是什么以及你的限制是什么。
有时，暴力方法可以在尝试每种解决方案组合后在 50 毫秒内解决问题，而“聪明”的解决方案可以在 10 毫秒内解决问题。 到那时，不太聪明但更容易理解的解决方案胜过聪明的解决方案。
然而，也存在一些问题，暴力强制不仅不优雅而且根本行不通。 有很多问题，如果你尝试天真地暴力解决它们，将需要花费大量的时间来解决它们。 显然，这些类型的问题需要一种更优雅的方法。
所以问问自己，为什么要尝试这些欧拉计划问题？ 你这样做是为了学习吗？ 那么也许尝试一个聪明的解决方案将符合您的最大利益，但前提是您最初尝试了暴力解决方案来帮助掌握问题。
在做 Python 挑战题时，我尝试以最简洁的方式做题，挑战我的能力极限。 解决之后，我会回顾其他人的答案，并在心里记下比我更聪明的人以及他们所做的事情。 有些人会特别使用我没有想到的更适合任务的数据结构，或者他们会使用一些数学技巧来提高算法的效率。 最后，我尝试尽可能多地吸收他们的聪明才智，并在下次遇到类似性质的问题时将其展示出来。
I think you should look at what your end goal is and what your constraints are.
Sometimes a bruteforce method can solve a problem in 50ms trying out every combination of solutions and a "clever" solution can solve it in 10ms. At that point, the less clever but easier to understand solution trumps the clever solution.
However, there are some problems where brute forcing will not only be inelegant but simply won't work. There are many problems where if you attempt to naively brute force them it will take a significant amount of time to solve them. So obviously, these types of problems need a more elegant approach.
So ask yourself, why you are attempting these Project Euler problems? Are you doing it to learn? Then maybe trying a clever solution would be in your best interest but only after you have initially tried a brute force solution to help get a grasp of the problem.
When doing the Python Challenge problems I try to do it the most succinct way I can, pushing the limits of my abilities. After I solve it I then review other peoples answers and take mental notes of people who were more clever than myself and what they did. Some people will make special use of a data structure I hadn't thought of that is more suited to the task or they will have little mathematical tricks they use to make their algorithm more efficient. In the end I try to absorb as much of their cleverness as I can and make it show the next time I'm presented with a problem of a similar nature.
作为一名初学者程序员，您将花费更多的精力来弄清楚如何在 C++ 中实际实现事物，而不是花费精力为每个问题找到巧妙的解决方案。 这很好，因为它让您有机会在解决一系列不同类型的问题的同时探索 C++ 的不同领域。
当您精通 C++ 并且您不必考虑如何做每件小事时，那么您将能够花更多时间发明非暴力解决方案。
As a beginner programmer, you will be spending more of your mental energy figuring out how to actually implement things in C++, rather than spending energy on finding a clever solution to each problem. This is fine, because it gives you the opportunity to explore different areas of C++ while working on a range of various kinds of problems.
When you become proficient in C++ and you don't have to think about how to do every little thing, then you will be able to spend more time inventing non-brute-force solutions.
不，这并不是一件坏事。 我曾经有过一些非常优雅的解决方案，但它们却是错误的。
No, this isn't a bad thing. I've had solutions that were so elegant they were wrong.
优雅的解决方案并不是自发产生的，而是自发产生的。 当当前解决方案需要更高的速度或更少的内存消耗时，它们源自暴力解决方案。
所以不，不是。 优雅的解决方案就是这样应运而生的。
The elegant solutions weren't created spontaneously; they were derived from the brute-force solutions when more speed or less memory consumption were required from the current solution.
So no, it's not. It's how the elegant solutions came into being.
肯·汤普森：“当有疑问时，使用暴力”
Ken Thompson: "When in doubt, use brute force"
我经历了这样的演变：
I've sort of gone through this evolution:
我想说不，这不是一个坏兆头。 事实上，远离过早的优化是对自己有利的，这绝对是一件好事。
I would say that no, it's not a bad sign. In fact you're doing yourself a favor by trending away from premature optimizations, which is definitely a Good Thing.
学习是一个蛮力的过程。 我不会说它不好。 在尝试以这种方式做某事时，您可能会注意到一种模式。 我认为只要你思考某件事并试图找到解决方案，你就会学到东西。 很少有人会直接跳到最优雅或最有效的解决方案。
很难让我相信那些努力学习的人会被称为坏人。 也许除了一个邪恶的科学家：P
祝你好运。
learning is a brute force process. I wouldn't say its bad. In trying to do something that way you may notice a pattern. I think as long as you are thinking about something and trying to find solutions you will learn. There are few people who just jump to the most elegant or efficient solutions.
It would be hard to convince me that people that are trying to learn could ever be called bad. Except maybe an evil scientist :P
good luck.
您是否符合解决问题的 1 分钟运行时间规则？ 如果是，那么您的“强力”解决方案满足所有要求，这实际上是一个非常好的迹象，表明您可以快速想出可行的方法！
这类问题鼓励微观优化和非常聪明的算法，但一般来说，非常可读的简单实现将更容易维护，并将在商业世界中受到青睐。
Do you fit inside the 1 minute runtime rule for the problems? If yes, then your "brute force" solution fulfils all the requirements, and that's actually a very good sign that you can quickly come up with something that works!
These kinds of problems encourage micro-optimisation and very clever algorithms, but in general a very readable straightforward implementation will be much easier to maintain, and will be favoured in the business world.
如果碰巧是“暴力破解”=>的情况 “简单”和“优雅”=> “复杂”，那么暴力获胜。 这通常是正确的。
If it happens to be a situation where "brute force" => "simple" and "elegant" => "complex", then brute force wins. And this is very often true.
一点也不。 正确、彻底地解决问题，然后根据需要使其变得更加高效或优雅。
这并不是说您应该忽略明显的性能改进......只是在您更好地理解问题之前不要关注它们。
Not at all. Get the problem solved correctly and completely then make it more performant or elegant as necessary.
That's not to say you should ignore obvious performance improvements... Just don't focus on them until you understand the problem better.
将其放在不同的上下文中：
当您使用一个您不太了解的库（例如，用于创建 UI）时，您可以以完美的性能方式解决一个简单的问题，尽管您知道有一个“正确的方法”去做吧。 如果您感到好奇并担心您的暴力代码让您看起来像个白痴，那么您很快就会找到“正确的方法”来做到这一点（例如，在周末或睡觉时）。 与此同时，通过暴力破解，您将得到一些有用的东西。实际上，
有时我会忘记使用暴力破解，并开始扫描 API 来寻找“正确”的解决方案。 在很多情况下这绝对是一个错误。 如果强力解决方案很容易实现，可以根据您的需要进行扩展（真的，如果它有效的话），那么就忘记正确的解决方案。您很快就会找到它（很多时候您会发现它）已经知道了！），但与此同时，您解决了问题并能够继续下一个问题。
编码时的障碍是可怕的，绝对应该比暴力解决方案更要避免。
To put this in a different context:
When you use a library that you don't know very well (for creating UI, for instance) you can solve a simple problem in a perfectly performant way, though you know there's a "correct way" to do it. If you are curious and worried that your brute-force code makes you look like a moron, you will soon find the "correct way" to do it (e.g., on weekends, or while you sleep). In the meantime, through brute force, you will have something that works.
I actually forget to use brute force sometimes, and start scanning the API for the "right" solution. This is definitely an error in many cases. If the brute force solution is easy to implement, scales as you need it to (really, if it works), then forget about the correct solution. You'll find it soon enough (and many times you already knew it!), but in the meantime, you solved the problem and were able to go on to the next one.
Roadblocks are terrible when coding, and should definitely be avoided more than brute force solutions.
倾向于暴力破解绝对不是一个坏兆头，尤其是作为初学者，因为你可能不知道更多。 特别是对于欧拉项目，实施暴力方法而不查看评论来学习更有效的方法是一个不好的迹象。
我经常和你遇到同样的情况，这实际上就是我开始做 PE 问题的原因——我实施了很多蛮力方法，并想让自己接触到更优雅的解决方案......
It's definitely not a bad sign to trend to brute force, especially as a beginner because you may not know any better. Especially with Project Euler, it is a bad sign to implement a brute force method and not review the comments to learn a more efficient method.
I often end up in the same boat you're in and that's actually why I started doing P.E. problems -- I was implementing a lot of brute force approaches and wanted to expose myself to more elegant solutions...
你已经权衡过你的选择。 如果暴力解决方案能够完成工作并且执行正常，那么它就是一个很好的解决方案。
You have weigh your option. If the brute force solution will get the job done and perform ok, it is a good solution.