Algorithm 最佳方法：将每日值从一年转移到另一年

我会尽力解释我想要完成的事情。我在寻找一种算法或方法，而不是在我的特定系统中的实际实现

我每天都有一个实际值（传入的客户请求）表。这些实际数据需要“复制”到下一年，并作为未来规划请求数量的基础。 从技术角度讲，规划的最小时间跨度是一个“周期”，至少包括一天。周期总是在一周或一个月后改变。这意味着，如果一周同时在5月和6月，它将分为两个时段。

下面是一个例子：

2010-05-24-2010-05-30第21周期间Id 123
2010-05-31-2010-05-31第22周期间Id 124
2010-06-01-2010-06-06第22周期间Id 125

我们这样做是为了减少数据量，因为我们有几千个项目，每天有356个值。对于规划，这将减少到“几千x 65”（或每年的周期计数）。通过合并属于一个月的所有时段，我可以聚合一个月或一周。重要的是，我仍然可以使用每日值，然后找到相应的周期，并在必要时添加它

---

我需要的是一种方法，可以将下一年的每个（工作）日、周或月的实际值进行汇总。我的要求在这里不是固定的。实际值有一定的分布，因为数据中反映了一定的截止日期和习惯。我希望能够尽可能地保留这一点，但计划从来都不是完全准确的，因此我可以在这里做出妥协。

不知道这是否是您所寻找的，但这是一种使用灵活周期计算预测的策略：

首先为下一年的每一天定义一个映射，映射到今年的相应日期。然后，当您需要对时段x进行预测时，您将计算该时段的所有天数，并将匹配天数的实际值相加

---

有了它，您可以每周/每月进行预计算，但如果时段内容发生变化，您可以创建新的预测。

没有先验的方法来回答这个问题。您必须查看数据，并根据结果确定哪些重要参数（星期几、星期数、月份、季节、室外温度？）。

例如，如果您的许多客户是犹太人/穆斯林，那么公历和ISO周数以及所有这些对您没有多大帮助，因为犹太人/穆斯林节日（以及用户行为）是使用其他日历确定的

另一个例子——试图根据去年的搜索结果进行预测听起来不是个好主意。重要的时间尺度似乎比一年长得多（技术多年来逐渐成为主流），而比一年短得多（影响我们几天几周的特定事件）

将周映射到周。从今年的第一个整周到明年的第一个整周。不要担心“周期”和聚合；它们无关紧要。

如果缺少假日会在数据中留下漏洞，只需获取前一周或下一周同一天的值，并在年初/年底执行相同的操作。

现在，对于一周中的每一天，结合一年的结果，寻找与平均值相比超过两个标准差的事件（如果你不知道这意味着什么，那么跳过这一步），并寻找与已知事件（如假日）的相关性。如果假期在此测试中未显示效果，则忽略它。如果你发现一个影响，改变它以补偿明年不同的日期。不要担心高阶效应，你没有足够的数据来确定它们。

现在，在任何你喜欢的地方画句号，并聚合所有你想要的。

---

不要对这些预测的准确性做出任何承诺，没有办法知道。不要担心这是否是最好的方式；它不是，但它和你可能找到的任何一种都一样好。你可以花更多的时间和精力来微调它；这可能会提高期望值，但不太可能使结果更加准确——可能会使结果变得更糟。

你知道如何将今年的实际值复制到明年吗？你知道如何汇总今年的实际数据吗？你知道如何组合两个句型吗？汇总一天的实际值意味着什么？是的，我知道如何将数据从一年复制到另一年。这一切都基于SQL Server，我们有一个数据层，我可以在其中收集我需要的任何数据。从一年到下一年传输周期性数据的最准确方法是什么，将假期和一年的开始/结束时间移到下一年/上一年。IPhone的例子很好，但就我而言，我真的只需要在一年的时间范围内查看它。服务经理将使用过去几年的实际数据作为基础，然后他们将剔除任何明显的一次性影响（如世界足球锦标赛），并增加或减少预测，如果在下一年有任何已知的特别优惠或一些外部事件。我最后得出了类似的结论，我们使用了工作日的平均值。因此，如果去年的“第10周”有5个工作日，那么今年的“第10周”只有4个工作日，它得到了原始值的四分之五。我们决定在4天内不会有明显的更多客户，因为他们不能在假日打电话。如果目标年的一周有0个工作日，则将忽略它。