Skip to content
#small language model Open access

One Number Sets the Limit of Forecasting ── Each Extra Day Costs 1.5874 Times the Initial Accuracy ── Observe 10 Times More Precisely and You Gain Only 4.98 Days ── [Paper 289]

Aug 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

That a weather forecast cannot reach beyond a certain horizon is due neither to missing equations nor to slow computers. This paper asks what sets the limit──the answer is one number, the error doubling time tau_d. No new mathematical theorem and no new law is claimed. Scope of this paper (scope note): No new mathematical theorem and no new law is claimed──exponential error growth, the doubling time, the limit of predictability, and the value tau_dapprox 1.5 days are all standard. We do not build meteorology──all we use is one exponential and its inverse. We do not discuss chaos──the Lorenz equations, attractors, and bifurcations are not treated at all. We do not discuss numerical weather prediction──grid resolution, parameterisation, and data assimilation are not treated. We do not say the error grows exactly exponentially──e^lambda t holds only while the error is small, and growth stops near saturation. The computations here are confined to the linear-growth regime. We assert no value for tau_d──1.5 days is a representative value widely used in the literature, and it moves from about 1 to 2.5 days with season, region, and variable. Section 5 shows the size of that dependence itself. We do not say there is a single exponent──the real atmosphere has different growth rates at different scales, with smaller eddies growing faster. A single tau_d is a crude approximation. We do not deny that forecasts improve──forecasts have in fact grown longer. What this paper says is only that the growth is logarithmic, not that improvement is pointless. Relation to earlier papers: Paper 253 showed that time is one-dimensional because prediction demands it, not because a law says so──this paper turns how far that demand can be met into a number. Paper 195 separated “stable” into six words──that paper is a classification of stability; this one is a time scale of predictability, the same hyperbolicity as material with a different question. Paper 190 measured “rare” on a logarithmic scale──the return here is likewise logarithmic. Paper 266 showed that the premise of the sampling theorem is never met──“knowing the initial state exactly” here is likewise a premise never met, the same figure. What is added is writing the price per day as the fixed factor 1.5874, computing the accuracy needed for 14->21->30->60 days as 25.40 / 1625.5 / 1.70x10^9, writing backwards that 10 times the observation gains only 4.98 days, and sweeping tau_d from 1.0 to 2.5 to show the answer moving from 65536 to 84.4. First, the price per day is a fixed factor. With tau_d=1.5 days, each extra day costs 1.5874 times the initial accuracy (Section 2). Second, this is the core of the paper. Going from 14 to 21 days costs 25.40 times; to 30 days, 1625.5 times; to 60 days, 1.70x10^9 times (Section 2). Third, read backwards, the return is logarithmic. Observing 10 times more precisely gains only 4.98 days (Section 3). Fourth, even 10^9 times gains only 44.85 days (Section 3). Fifth, the familiar “about two weeks” comes from here. If the initial error is 10^-3 of saturation, the forecastable span is 14.95 days (Section 4). Sixth, the separator is tau_d itself. At tau_d=1.0 day the same extension costs 65536 times; at 2.5 days only 84.4──everything rides on one number (Section 5). What sets the limit of forecasting is neither the equations nor the computers, but one number, the error doubling time tau_d. At tau_d=1.5 days, each extra day costs 1.5874 times the initial accuracy──the factor is the same wherever the day is added, but the extension adds while the price multiplies, so one week costs 25.4, two weeks 645, six weeks 1.7 billion. Read backwards, observing 10 times more precisely gains only 4.98 days, and even 10^9 times gains 44.85. The familiar “about two weeks” comes from this one line──14.95 days at an initial error of 10^-3 of saturation. One thing separates them──tau_d itself. At 1.0 day the same extension costs 65536; at 2.5 days, 84.4. A factor of 776 arises from a single number. So the work of extending forecasts and the work of measuring tau_d carry the same weight. On the making of this work: The ideas and content of this work stem from the author's own considerations. Assistance from an AI (a large language model) was used for structuring, English translation, and checking the algebra. Any remaining errors or misinterpretations are solely the author's. Feedback and corrections are sincerely appreciated. ----- 天気予報がある日数より先を当てられないのは、方程式が足りないからでも、計算機が遅いからでもない。本稿が問うのは、何が限界を決めているかである──答は、誤差の二重時間 tau_d という一つの数である。新しい数学定理も新しい法則も主張しない。 本稿の射程(射程注記):新しい数学定理も新しい法則も主張しない──誤差の指数増大、二重時間、予測可能性の限界、tau_dapprox 1.5 日という値は、いずれも標準的である。気象学を作らない──使うのは一つの指数関数と、その逆関数だけである。カオスを論じない──ローレンツ方程式も、アトラクタも、分岐も一切扱わない。数値予報を論じない──格子解像度も、パラメタリゼーションも、データ同化も扱わない。誤差が厳密に指数増大すると言わない──e^lambda t が成り立つのは誤差が小さいあいだだけであり、飽和に近づけば増大は止まる。本稿の計算は線形増大の領域に限る。 tau_d の値を主張しない──1.5 日は文献で広く用いられる代表値であり、季節・領域・変数によって 1 日から 2.5 日程度まで動く。第5節はこの依存の大きさそのものを示す。単一の指数だと言わない──実際の大気には尺度ごとに違う成長率があり、小さい渦ほど速く育つ。単一の tau_d は粗い近似である。予報の改善を否定しない──現に予報は延びてきた。本稿が言うのはその延び方が対数的であるということだけであり、改善が無意味だとは言わない。既刊との関係:論文253 は時間が一本なのが法則ではなく「予言できる」という要求だと示した──本稿はその要求が、どこまでなら満たせるかを数にする。論文195 は「安定」が六つの別の言葉だと分けた──あちらは安定性の分類、本稿は予測可能性の時間尺度であり、同じ双曲性を材料にして問いが違う。論文190 は「稀」を対数の目盛りで測った──本稿の見返りも対数である。論文266 は標本化定理の前提が決して満たされないと示した──本稿の「初期値を正確に知る」も決して満たされない前提であり、構図が同じである。加えたのは一日あたりの代償を 1.5874 倍という一定倍率として書いたこと、14->21->30->60 日の必要精度を 25.40/1625.5/1.70x10^9 倍と計算したこと、観測 10 倍が 4.98 日にしかならないと逆から書いたこと、tau_d を 1.0 から 2.5 まで振って答が 65536 倍から 84.4 倍まで動くと示したことである。 第一に、一日ごとの代償は一定倍率である。 tau_d=1.5 日なら、一日延ばすたびに初期値の精度が 1.5874 倍要る(第2節)。 第二に、これが本稿の芯である。14 日を 21 日にするのに 25.40 倍、30 日にするのに 1625.5 倍、60 日にするのに 1.70x10^9 倍(第2節)。 第三に、逆から見ると見返りは対数的である。観測を 10 倍精密にしても、延びるのは 4.98 日だけである(第3節)。 第四に、10 億倍にしても 44.85 日である(第3節)。 第五に、約二週間という数がここから出る。初期誤差が飽和の 10^-3 なら、予報可能な期間は 14.95 日(第4節)。 第六に、分離子は「指数か多項式か」である。 tau_d を 1.0 日にすると同じ延長に 65536 倍要り、2.5 日なら 84.4 倍で済む──すべてが一つの数に乗っている(第5節)。 予報の限界を決めているのは、方程式でも計算機でもなく、誤差の二重時間 tau_d という一つの数である。 tau_d=1.5 日なら、一日延ばすたびに初期値の精度が 1.5874 倍要る──どこで延ばしても倍率は同じだが、延長は足し算で、代償は掛け算なので、一週間で 25.4 倍、二週間で 645 倍、一か月半で 17 億倍になる。逆から見れば、観測を 10 倍精密にしても延びるのは 4.98 日であり、10 億倍にしても 44.85 日である。よく言われる「約二週間」も、この一行から出る──初期誤差が飽和の 10^-3 なら 14.95 日。分けるものは一つ──tau_d そのもの。1.0 日なら同じ延長に 65536 倍要り、2.5 日なら 84.4 倍で済む。776 倍の違いが、たった一つの数から生まれる。だから予報を延ばす仕事と、tau_d を測る仕事は、同じ重さを持っている。 作成にあたって:本稿の着想と内容は、著者自身の考察に基づくものです。文章の構成整理や英訳、数式の確認には AI(大規模言語モデル)の助力を得ました。最終的な内容の解釈や誤りがあれば、それらはすべて著者の責に帰します。お気づきの点があれば、ご教示いただければ幸いです。

View source

Similar papers

#computer vision Open access Jun 2016

Software Development in Startup Companies: The Greenfield Startup Model

Software startups are newly created companies with no operating history and oriented towards producing cutting-edge products. However, despite the increasing importance of startups in the economy, few scientific studies attempt to address software engineering issues, especially for early-stage startups. If anything, startups need engineering practices of the same level or better than those of larger companies, as their time and resources are more scarce, and one failed project can put them out of business. In this study we aim to improve understanding of the software development strategies employed by startups. We performed this state-of-practice investigation using a grounded theory approach. We packaged the results in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible. This strategy allows startups to verify product and market fit, and to adjust the product trajectory according to early collected user feedback. The need to shorten time-to-market, by speeding up the development through low-precision engineering activities, is counterbalanced by the need to restructure the product before targeting further growth. The resulting implications of the GSM outline challenges and gaps, pointing out opportunities for future research to develop and validate engineering practices in the startup context.

Carmine Giardino, Nicolò Paternoster, M. Unterkalmsteiner et al. · 179 citations · ⚡14
#computer vision Open access Oct 2016

Software Startups - A Research Agenda

Software startup companies develop innovative, software-intensive products within limited timeframes and with few resources, searching for sustainable and scalable business models. Software startup ...

M. Unterkalmsteiner, P. Abrahamsson, Xiaofeng Wang et al. · 157 citations · ⚡17
#machine learning Review Open access Oct 2016

“Failures” to be celebrated: an analysis of major pivots of software startups

In the context of software startups, project failure is embraced actively and considered crucial to obtain validated learning that can lead to pivots. A pivot is the strategic change of a business concept, product or the different elements of a business model. A better understanding is needed on different types of pivots and different factors that lead to failures and trigger pivots, for software entrepreneurial teams to make better decisions under chaotic and unpredictable environment. Due to the nascent nature of the topic, the existing research and knowledge on the pivots of software startups are very limited. In this study, we aimed at identifying the major types of pivots that software startups make during their startup processes, and highlighting the factors that fail software projects and trigger pivots. To achieve this, we conducted a case survey study based on the secondary data of the major pivots happened in 49 software startups. 10 pivot types and 14 triggering factors were identified. The findings show that customer need pivot is the most common among all pivot types. Together with customer segment pivot, they are common market related pivots. The major product related pivots are zoom-in and technology pivots. Several new pivot types were identified, including market zoom-in, complete and side project pivots. Our study also demonstrates that negative customer reaction and flawed business model are the most common factors that trigger pivots in software startups. Our study extends the research knowledge on software startup pivot types and pivot triggering factors. Meanwhile it provides practical knowledge to software startups, which they can utilize to guide their effective decisions on pivoting.

Sohaib Shahid Bajwa, Xiaofeng Wang, Anh Nguyen-Duc et al. · 127 citations · ⚡15
#computer vision Review Open access May 2015

A survey study on major technical barriers affecting the decision to adopt cloud services

In the context of cloud computing, risks associated with underlying technologies, risks involving service models and outsourcing, and enterprise readiness have been recognized as potential barriers for the adoption. To accelerate cloud adoption, the concrete barriers negatively influencing the adoption decision need to be identified. Our study aims at understanding the impact of technical and security-related barriers on the organizational decision to adopt the cloud. We analyzed data collected through a web survey of 352 individuals working for enterprises consisting of decision makers as well as employees from other levels within an organization. The comparison of adopter and non-adopter sample reveals three potential adoption inhibitor, security, data privacy, and portability. The result from our logistic regression analysis confirms the criticality of the security concern, which results in an up to 26-fold increase in the non-adoption likelihood. Our study underlines the importance of the technical and security perspectives for research investigating the adoption of technology.

Nattakarn Phaphoom, Xiaofeng Wang, S. Samuel et al. · 111 citations · ⚡8
#computer vision Open access Feb 2018

Lean Internal Startups for Software Product Innovation in Large Companies: Enablers and Inhibitors

To compete in this age of disruption, large companies cannot rely on cost efficiency, lead time reduction and quality improvement. They are now looking for ways to innovate like startups. Meanwhile, the awareness and use of the Lean startup approach have grown rapidly amongst the software startup community in recent years. This study investigates how Lean internal startup facilitates software product innovation in large companies and identifies its enablers and inhibitors. A multiple case study approach is followed in the investigation. Two software product innovation projects from two large companies are examined, using a conceptual framework that is based on the method-in-action framework and extended with the previously developed Lean-Internal Corporate Venture model. Seven face-to-face in-depth interviews of the employees with different roles are conducted. Within-case analysis and cross-case comparison are applied to draw the findings from the cases. A generic process flow summarises the common key processes of Lean internal startups. The findings suggest that an internal startup that is initiated management or employees faces different challenges. A list of enablers of applying Lean startup in large companies are identified, including top management support and cross-functional team. Both cases face different inhibitors due to the different process of inception, objective of the team and type of the product. Our contributions are threefold. First, this study is one of the first attempt to investigate the use of Lean startup approach in large companies empirically. Second, the study shows the potential of the method-in-action framework to investigate the Lean startup approach in non-startup context. The third is a general process of Lean internal startup and the evidence of the enablers and inhibitors of implementing it, which are both theory-informed and empirically grounded.

Henry Edison, Nina M. Smørsgård, Xiaofeng Wang et al. · 78 citations · ⚡6
#computer vision Conference Sep 2010

Exploring the Sources of Waste in Kanban Software Development Projects

The application of agile software methods and more recently the integration of Lean practices contribute to the trend of continuous improvement in the software industry. One such area warranting proper empirical evidence is a project’s operational efficiency when using the Kanban method. This short paper takes a new angle and explores waste in the Kanban-driven software development project context. A preliminary research model is presented for helping the consequent replication of the study. The results from the empirical analysis suggest Kanban can be an effective method in visualizing and organizing the current work, but does not prevent waste from creeping in, although the overall project outcome may be successful.

Marko Ikonen, Petri Kettunen, Nilay V. Oza et al. · 67 citations · ⚡9

Related blog posts