何时(不是如何或为什么)计算算法的Big O [英] When (not how or why) to calculate Big O of an algorithm

问题描述

最近在一次采访中有人问我这个问题，并对其他人的想法感到好奇.

I was asked this question in an interview recently and was curious as to what others thought.

您应该何时计算Big O?"

"When should you calculate Big O?"

大多数站点/书籍都在谈论如何计算Big O，但实际上并没有真正讨论您何时应该这样做.我是入门级开发人员，经验很少，因此不确定我是否在正确的道路上思考.我的想法是，您将有一个目标Big O要努力实现，开发算法然后计算BigO.然后尝试重构算法以提高效率.

Most sites/books talk about HOW to calc Big O but not actually when you should do it. I'm an entry level developer and I have minimal experience so I'm not sure if I'm thinking on the right track. My thinking is you would have a target Big O to work towards, develop the algorithm then calculate the Big O. Then try to refactor the algorithm for efficiency.

然后我的问题变成了这实际上是行业中发生的事情，还是我离我们很遥远?

My question then becomes is this what actually happens in industry or am I far off?

推荐答案

您应该何时计算Big O?"

"When should you calculate Big O?"

当您关心算法的时间复杂度时.

我什么时候在乎?

当您需要使算法能够缩放时，这意味着期望将大数据集作为算法的输入(例如，最近邻居算法中的点数和维数)).

When you need to make your algorithm to be able to scale, meaning that it's expected to have big datasets as input to your algorithm (e.g. number of points and number of dimensions in a nearest neighbor algorithm).

最值得注意的是，当您想比较算法！

Most notably, when you want to compare algorithms!

要求您执行一项任务，可以将几种算法应用于该任务.您选择哪一个?您比较它们的空间，时间和开发/维护复杂性，然后选择最适合您的需求.

You are asked to do a task, for which several algorithms can be applied to. Which one do you choose? You compare the Space, Time and development/maintenance complexities of them, and choose the one that best fits your needs.

这篇关于何时(不是如何或为什么)计算算法的Big O的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！