天機果是難知︰

《黃帝陰符經》又稱《陰符經》，全書一卷三篇，傳聞是黃帝所撰，學者大多認為是後人偽托，現有三說：戰國時的蘇秦，北魏的寇謙之，或唐朝的李荃。這部經即使在中國古代的哲學和兵法中都有一定的地位。《陰符經》更是道教的一部重要道經，歷代對它的註解僅次於《道德經》和《南華真經》。《陰符經》有多種版本，在此僅舉一本，略探其自然人生之旨。

《黃帝陰符經》

觀天之道，執天之行，盡矣。天有五賊，見之者昌。五賊在心，施行於天，宇宙在乎手，萬物生乎身。天性，人也；人性，機也 ；立天之道以定人也。天發殺機，斗轉星移；地發殺機，龍蛇起陸 ；人發殺機，天地反覆；天人合德，萬變定基。性有巧拙，可以伏藏。九竅之邪，在乎三要。可以動靜。火生於木，禍發必克，奸生於國，時動必潰；知之修練，謂之聖人。

天生天殺，道之理也。天地萬物之盜；萬物人之盜；人萬物之盜也。三盜既宜，三才既安。故曰：食其時，百骸治；動其機，萬化安。人知其神而神，不知不神而所以神。日月有數，大小有定，聖功生焉，神明出焉。其盜機也，天下莫能見，莫能知也。君子得之固躬，小人得之輕命。

瞽者善聽，聾者善視。絕利一源，用師十倍；三反晝夜，用師萬倍。心生於物，死於物，機在於目。天之無恩而大恩生，迅雷烈風，莫不蠢然。至樂性餘，至靜性廉。天之至私，用之至公。擒之制在氣。生者死之根，死者生之根。恩生於害，害生於恩。愚人以天地文理聖，我以時物文理哲。人以愚虞聖，我以不愚虞聖。人以奇期聖，我以不奇期聖。沈水入火，自取滅亡。自然之道靜，故天地萬物生。天地之道浸，故陰陽勝。陰陽相推，而變化順矣。是故聖人知自然之道不可違，因而制之至靜之道，律曆所不能契。爰有奇器，是生萬象，八卦甲子，神機鬼藏。陰陽相勝之術，昭昭乎盡乎象矣。

─── 摘自《天地文理聖,時物文理哲？！》

 

變數實在難了︰

Variable (computer science)

In computer programming, a variable or scalar is a storage location paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of information referred to as a value. The variable name is the usual way to reference the stored value; this separation of name and content allows the name to be used independently of the exact information it represents. The identifier in computer source code can be bound to a value during run time, and the value of the variable may thus change during the course of program execution.

Variables in programming may not directly correspond to the concept of variables in mathematics. The value of a computing variable is not necessarily part of an equation or formula as in mathematics. In computing, a variable may be employed in a repetitive process — assigned a value in one place, then used elsewhere, then reassigned a new value and used again in the same way (see iteration). Variables in computer programming are frequently given long names to make them relatively descriptive of their use, whereas variables in mathematics often have terse, one- or two-character names for brevity in transcription and manipulation.

A variable storage location may be referred by several different identifiers, a situation known as aliasing. Assigning a value to the variable using one of the identifiers will change the value that can be accessed through the other identifiers.

Compilers have to replace variables’ symbolic names with the actual locations of the data. While a variable’s name, type, and location often remain fixed, the data stored in the location may be changed during program execution.

Actions on a variable

In imperative programming languages, values can generally be accessed or changed at any time. However, in pure functional and logic languages, variables are bound to expressions and keep a single value during their entire lifetime due to the requirements of referential transparency. In imperative languages, the same behavior is exhibited by constants, which are typically contrasted with normal variables.

Depending on the type system of a programming language, variables may only be able to store a specified datatype (e.g. integer or string). Alternatively, a datatype may be associated only with the current value, allowing a single variable to store anything supported by the programming language.

Identifiers referencing a variable

An identifier referencing a variable can be used to access the variable in order to read out the value, or alter the value, or edit the attributes of the variable, such as access permission, locks, semaphores, etc.

For instance, a variable might be referenced by the identifier “total_count” and the variable can contain the number 1956. If the same variable is referenced by the identifier “x” as well, and if using this identifier “x“, the value of the variable is altered to 2009, then reading the value using the identifier “total_count” will yield a result of 2009 and not 1956.

If a variable is only referenced by a single identifier that can simply be called the name of the variable. Otherwise, we can speak of one of the names of the variable. For instance, in the previous example, the “total_count” is a name of the variable in question, and “x” is another name of the same variable.

Scope and extent

The scope of a variable describes where in a program’s text the variable may be used, while the extent (or lifetime) describes when in a program’s execution a variable has a (meaningful) value. The scope of a variable is actually a property of the name of the variable, and the extent is a property of the variable itself. These should not be confused with context (also called environment), which is a property of the program, and varies by point in the source code or execution – see scope: overview. Further, object lifetime may coincide with variable lifetime, but in many cases is not tied to variable lifetime.

A variable name’s scope affects its extent.

Scope is an important part of the name resolution of a variable. Most languages define a specific scope for each variable (as well as any other named entity), which may differ within a given program. The scope of a variable is the portion of the program code for which the variable’s name has meaning and for which the variable is said to be “visible”. Entrance into that scope typically begins a variable’s lifetime (as it comes into context) and exit from that scope typically ends its lifetime (as it goes out of context). For instance, a variable with “lexical scope” is meaningful only within a certain function/subroutine, or more finely within a block of expressions/statements (accordingly with function scope or block scope); this is static resolution, performable at parse-time or compile-time. Alternatively, a variable with dynamic scope is resolved at run-time, based on a global binding stack that depends on the specific control flow. Variables only accessible within a certain functions are termed “local variables“. A “global variable“, or one with indefinite scope, may be referred to anywhere in the program.

Extent, on the other hand, is a runtime (dynamic) aspect of a variable. Each binding of a variable to a value can have its own extent at runtime. The extent of the binding is the portion of the program’s execution time during which the variable continues to refer to the same value or memory location. A running program may enter and leave a given extent many times, as in the case of a closure.

Unless the programming language features garbage collection, a variable whose extent permanently outlasts its scope can result in a memory leak, whereby the memory allocated for the variable can never be freed since the variable which would be used to reference it for deallocation purposes is no longer accessible. However, it can be permissible for a variable binding to extend beyond its scope, as occurs in Lisp closures and C static local variables; when execution passes back into the variable’s scope, the variable may once again be used. A variable whose scope begins before its extent does is said to be uninitialized and often has an undefined, arbitrary value if accessed (see wild pointer), since it has yet to be explicitly given a particular value. A variable whose extent ends before its scope may become a dangling pointer and deemed uninitialized once more since its value has been destroyed. Variables described by the previous two cases may be said to be out of extent or unbound. In many languages, it is an error to try to use the value of a variable when it is out of extent. In other languages, doing so may yield unpredictable results. Such a variable may, however, be assigned a new value, which gives it a new extent.

For space efficiency, a memory space needed for a variable may be allocated only when the variable is first used and freed when it is no longer needed. A variable is only needed when it is in scope, but beginning each variable’s lifetime when it enters scope may give space to unused variables. To avoid wasting such space, compilers often warn programmers if a variable is declared but not used.

It is considered good programming practice to make the scope of variables as narrow as feasible so that different parts of a program do not accidentally interact with each other by modifying each other’s variables. Doing so also prevents action at a distance. Common techniques for doing so are to have different sections of a program use different name spaces, or to make individual variables “private” through either dynamic variable scoping or lexical variable scoping.

Many programming languages employ a reserved value (often named null or nil) to indicate an invalid or uninitialized variable.

 

何不直抵根本耶︰

美國數學家阿隆佐‧邱奇 Alonzo Church 對『符號邏輯』symbolic logic 的熱情與對基礎算術『形式系統』的研究持續一生。當他發現這類系統容易受到『羅素悖論』影響時，轉將所設想的『λ 運算』lambda calculus 單獨用於研究『可計算性』問題， 同樣否定的回答了『判定性問題』 Decision-problem ──

一九零零年德國大數學家大衛‧希爾伯特 David Hilbert 在巴黎的國際數學家大會上作了場名為《數學問題》的演講，提出了二十三道待解決之最重要的數學問題，這就是著名的希爾伯特之二十三個問題的由來。這裡的『判定性問題』 就是二十三個問題的第二題『算術公理之相容性』，一九三零年已為庫爾特‧哥德爾所否證 ──。美國 UCLA 大學 Enderton, Herbert B. 教授寫了一篇名為
《INTRODUCTION
Alonzo Church: Life and Work》的 Alonzo Church 小傳︰
…
In 1936 a pair of papers by Church changed the course of logic. An Unsolvable Problem of Elementary Number Theory presents a definition and a theorem:
“The purpose of the present paper is to propose a definition of effective calculability which is thought to correspond satisfactorily to the somewhat vague intuitive notion . . . , and to show, by means of an example, that not every problem of this class is solvable.” The “definition” now goes by the name Church’s Thesis: “We now define the notion . . . of an effectively calculable function of positive integers by identifying it with the notion of a recursive function of positive integers (or of a λ-definable function of positive integers).” (The name, “Church’s Thesis,” was introduced by Kleene.)
The theorem in the paper is that there is a set that can be defined in the language of elementary number theory (viz. the set of G ̈odel numbers of formulas of the λ-calculus having a normal form) that is not recursive—although it is recursively enumerable. Thus truth in elementary number theory is an effectively unsolvable problem.

A sentence at the end of the paper adds the consequence that if the system of Principia Mathematica is ω-consistent, then its decision problem is unsolvable. It also follows that the system (if  ω-consistent) is incomplete, but of course G ̈odel had shown that in 1931.
…

─── 摘自《λ 運算︰淵源介紹》