New perspective on algorithm utility--论文代写范文精选

例如,很少有研究明确地考虑为什么算法灵活性是重要的，未来的算法研究，一些相关问题的灵活性也出现在动态优化的研究。然而我们的利益比通常构成一个相当广泛的优化环境。特别是,我们感兴趣的问题更戏剧性。下面的essay代写范文进行详述。

If we accept NFL theory or we accept the empirical evidence of NFL-like phenomena in practice, then a compelling theory of 5 algorithm success should address these realities as opposed to ignoring them. If MH customization has been a key ingredient to success, then it is important to understand why this is true and why this would favor MH over DM. More generally, we need to understand why some algorithms are better positioned to quickly and effectively adapt to new problems. Although the idea of algorithm flexibility is not new (e.g. [15] [14]), little effort has been devoted to exploring its theoretical basis or its implications for the field. 

For instance, few studies have explicitly considered why flexibility is important to algorithm utility or the consequences this should have for future algorithm research. Some issues related to flexibility also arise in the study of dynamic optimization, e.g. see [19], however our interests here are considerably broader than what would normally constitute a non-stationary optimization environment. In particular, we are interested in more dramatic problem changes or the emergence of new problems where sufficient algorithm modifications cannot be fully automated and instead require human intervention. In this section, we consider how algorithm flexibility influences the utility of an algorithm framework, the conditions where flexibility should be favoured, and tradeoffs between the efficacy and efficiency of the algorithm adaptation process. We also discuss plausible explanations for why DM may be generally less flexible than MH. Finally we explore the theoretical underpinnings of algorithm flexibility and consider what insights may be derived from recent developments in the study of complex adaptive systems.

Important timescales in algorithm adaptation The idea of algorithm flexibility is conceptually simple and is outlined in Figure 5. In short, the utility of an algorithm is evaluated based on its ability to adapt to the needs of a problem and not based on “off the shelf” performance characteristics. It is common knowledge that any search process will exhibit a trade-off between solution quality and the computational costs expended. Similarly, the flexibility of an algorithm framework is expected to have a trade-off between the solution quality and the amount of time expended on algorithm adaptation. 

To understand flexibility, it is thus necessary to account for the efficiency and efficacy of the adaptation process (Figure 5b). Efficiency becomes increasingly important when there are pressing deadlines that constrain algorithm development time or when the problem is susceptible to changes in definition (e.g. size, scope) that require quick changes in algorithm search behaviour. To help understand the trade-off between algorithm adaptation speed and final solution quality, we introduce three timescales: algorithm runtime (T1), algorithm development time (T2), and problem lifespan (T3). T1 measures the time needed to reach a stopping criteria during the search process, T2 measures the total time permitted to design an algorithm for a problem, and T3 measures the amount of time that a problem is relevant, e.g. to a client.

Assuming T1 is small compared with the time it takes a person to make an algorithm design change, the primary concern in 6 algorithm development is to quickly discover a sequence of design changes that provide sufficient and reliable solution quality. The performance of the initial algorithm design is not of tremendous importance, so long as it can be modified in the given time (T2).

This makes the magnitude of T2 have influence over how we view sufficiency and the speed of adaptation. If short development times are preferred by a client or necessitated by a short problem lifespan (T3), then preference should be given towards an algorithmic framework that can rapidly adapt to new conditions, e.g. movement to the left in the bottom graph in Figure 5b. We speculate that MH are particularly adept at making rapid (but possibly suboptimal) gains in algorithm performance through design adaptation and should be favoured as T2 decreases. The meaning and importance of T3 depends on whether a problem needs to be solved once (e.g. most design problems) or is solved many times (e.g. in scheduling). 

For instance, if a problem only needs to be solved once to meet some stated solution goals and if the solution can be reached at any time during the problem’s lifespan, then T3 poses a straightforward constraint on the feasibility of a particular methodology, e.g. T2 must be less than T3. In the case where a problem is repeatedly being solved, the utility of an algorithm might be naively measured by its improvement over other algorithms multiplied by the amount of time that the algorithm is to be implemented, e.g. Δ{solution quality} x {T3-T2}. However when T3 is small, the importance given to the early stages of implementation can be unexpectedly high (e.g. the importance of being “first to market” or avoiding bottlenecks within a larger project) and the rapid design of sufficient algorithms can trump what would otherwise appear to be a more superior alternative. In short, T2 has a strong impact on an algorithm’s utility, especially when T3 is small.

Adaptiveness during and after development Optimization problems have so far been described as having a lifespan over which they are practically relevant and a time window when algorithm development must take place. Of course the reality is more varied and more complicated. Once we look closely at the individual components of a problem lifecycle, we find that the need for algorithm adaptation is pervasive. First, it is common for a problem definition to change during the algorithm development phase. The constraints, the problem definition (e.g. scope, fidelity, representation), and even the objectives are subject to change over the course of an algorithm development project. 

The reasons that these changes occur are varied. For instance, it is common to learn more about the underlying nature of a problem, and consequently want to change the problem definition, as one develops ways to solve it. Also, a client’s true interests are rarely captured entirely by a well defined problem and instead are more likely to involve a network of connected sub-problems and soft objectives that exist as tacit domain knowledge. Early success during algorithm development can also breed a desire for change, e.g. a desire to expand the scope of the problem. However, it is worth stressing that a change in the problem definition does not necessarily reflect poor planning or poor understanding by a client. 

Instead, these problem changes are often a consequence of intelligent yet boundedly rational individuals attempting to make sense of a dynamic and 7 complex world (cf [20] [21]). This implies that changes to a problem during algorithm development are not always preventable and hence are likely to persist within future optimization contexts. Changes to a problem can also occur for reasons that are completely outside the control of the client and may take place after an algorithm is already being implemented. This may be the result of unexpected changes within the market that an organization competes in or other changes in the internal operating conditions of that organization. One example of “after implementation” changes in an industrial production problem is given in Section 1.2.6 in [8] In summary, problem definitions are subject to change both during and after the span of time allocated to algorithm development (T2). An algorithm must effectively adapt but also do so efficiently to keep up with changing requirements, e.g. of a client during algorithm development or a market during algorithm implementation. Moreover, any algorithmic approach whose success is tightly dependent upon assumptions surrounding the original problem definition are less likely to be able to accommodate new conditions that arise.（essay代写)

51Due网站原创范文除特殊说明外一切图文著作权归51Due所有；未经51Due官方授权谢绝任何用途转载或刊发于媒体。如发生侵犯著作权现象，51Due保留一切法律追诉权。
更多essay代写范文欢迎访问我们主页 www.51due.com 当然有essay代写需求可以和我们24小时在线客服 QQ:800020041 联系交流。-X（essay代写)