eyeling 1.22.6 → 1.22.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/HANDBOOK.md +245 -0
- package/dist/browser/eyeling.browser.js +188 -33
- package/examples/act-alarm-bit-interoperability.n3 +180 -0
- package/examples/act-barley-seed-lineage.n3 +565 -0
- package/examples/act-docking-abort.n3 +285 -0
- package/examples/act-gravity-mediator-witness.n3 +235 -0
- package/examples/act-isolation-breach.n3 +354 -0
- package/examples/act-photosynthetic-exciton-transfer.n3 +245 -0
- package/examples/act-sensor-memory-reset.n3 +190 -0
- package/examples/act-tunnel-junction-wake-switch.n3 +225 -0
- package/examples/act-yeast-self-reproduction.n3 +248 -0
- package/examples/complex-matrix-stability.n3 +288 -0
- package/examples/deck/act-barley-seed-lineage.md +593 -0
- package/examples/fundamental-theorem-arithmetic.n3 +244 -0
- package/examples/harborsmr.n3 +233 -0
- package/examples/meta-rule-audit.n3 +135 -0
- package/examples/output/act-alarm-bit-interoperability.txt +20 -0
- package/examples/output/act-barley-seed-lineage.txt +25 -0
- package/examples/output/act-docking-abort.txt +22 -0
- package/examples/output/act-gravity-mediator-witness.txt +24 -0
- package/examples/output/act-isolation-breach.txt +27 -0
- package/examples/output/act-photosynthetic-exciton-transfer.txt +20 -0
- package/examples/output/act-sensor-memory-reset.txt +20 -0
- package/examples/output/act-tunnel-junction-wake-switch.txt +21 -0
- package/examples/output/act-yeast-self-reproduction.txt +23 -0
- package/examples/output/complex-matrix-stability.txt +14 -0
- package/examples/output/fundamental-theorem-arithmetic.txt +15 -0
- package/examples/output/get-uuid.n3 +2 -2
- package/examples/output/harborsmr.txt +20 -0
- package/examples/output/meta-rule-audit.n3 +44 -0
- package/examples/output/theory-diff.n3 +22 -0
- package/examples/theory-diff.n3 +125 -0
- package/eyeling.js +188 -33
- package/lib/builtins.js +18 -1
- package/lib/cli.js +31 -5
- package/lib/engine.js +139 -27
- package/package.json +1 -1
- package/test/api.test.js +100 -0
|
@@ -0,0 +1,190 @@
|
|
|
1
|
+
# ======================================================================
|
|
2
|
+
# ACT sensor memory reset
|
|
3
|
+
#
|
|
4
|
+
# Applied constructor-theory case:
|
|
5
|
+
# A radiation alarm sensor has a one-bit memory latch that must be reset
|
|
6
|
+
# before the device can be reused.
|
|
7
|
+
#
|
|
8
|
+
# The eye-opener:
|
|
9
|
+
# - with a work-like resource, reliable reset CAN be done;
|
|
10
|
+
# - with only a heat-like resource, the same reliable reset task CAN'T
|
|
11
|
+
# be done in this model.
|
|
12
|
+
#
|
|
13
|
+
# This is inspired by constructor-theory thermodynamics:
|
|
14
|
+
# exact work/heat distinction, irreversibility, and the link between
|
|
15
|
+
# information tasks and thermodynamic laws.
|
|
16
|
+
# ======================================================================
|
|
17
|
+
|
|
18
|
+
@prefix : <http://example.org/act/memory-reset/> .
|
|
19
|
+
@prefix arc: <https://example.org/arc#> .
|
|
20
|
+
@prefix log: <http://www.w3.org/2000/10/swap/log#> .
|
|
21
|
+
|
|
22
|
+
:case a arc:Case ;
|
|
23
|
+
arc:question "Can a radiation sensor's alarm memory be reliably reset with a battery pack, and can the same reset be done using only an ambient heat bath?" .
|
|
24
|
+
|
|
25
|
+
# -------------------
|
|
26
|
+
# Application context
|
|
27
|
+
# -------------------
|
|
28
|
+
|
|
29
|
+
:alarmSensor a :RadiationSensor ;
|
|
30
|
+
:hasMemory :alarmLatch ;
|
|
31
|
+
:needs :ReliableResetForReuse .
|
|
32
|
+
|
|
33
|
+
:alarmLatch a :OneBitMemory ;
|
|
34
|
+
:zeroState :Clear ;
|
|
35
|
+
:oneState :Alarm ;
|
|
36
|
+
:currentState :Alarm .
|
|
37
|
+
|
|
38
|
+
# A work-like resource.
|
|
39
|
+
:batteryPack a :WorkMedium ;
|
|
40
|
+
:chargeState :Charged ;
|
|
41
|
+
:canSupply :DirectedEnergyTransfer .
|
|
42
|
+
|
|
43
|
+
# A heat-like resource.
|
|
44
|
+
:ambientBath a :HeatMedium ;
|
|
45
|
+
:temperatureBand :RoomTemperature ;
|
|
46
|
+
:provides :UndirectedThermalContact .
|
|
47
|
+
|
|
48
|
+
# ----------------------------
|
|
49
|
+
# CAN rules — what is possible
|
|
50
|
+
# ----------------------------
|
|
51
|
+
|
|
52
|
+
# A work medium with directed energy transfer can drive a controlled reset.
|
|
53
|
+
{ ?W a :WorkMedium ;
|
|
54
|
+
:chargeState :Charged ;
|
|
55
|
+
:canSupply :DirectedEnergyTransfer .
|
|
56
|
+
?M a :OneBitMemory . }
|
|
57
|
+
=>
|
|
58
|
+
{ ?W :can :DriveControlledReset .
|
|
59
|
+
?M :can :ReliableResetFromWork . } .
|
|
60
|
+
|
|
61
|
+
# If the memory can be reliably reset from work, it can be prepared in
|
|
62
|
+
# the standard reusable state.
|
|
63
|
+
{ ?M :can :ReliableResetFromWork ;
|
|
64
|
+
:zeroState ?Z . }
|
|
65
|
+
=>
|
|
66
|
+
{ ?M :can :PrepareStandardState .
|
|
67
|
+
?M :standardState ?Z . } .
|
|
68
|
+
|
|
69
|
+
# If the sensor memory can be prepared in the standard state, the sensor
|
|
70
|
+
# can be reused.
|
|
71
|
+
{ :alarmSensor :hasMemory ?M .
|
|
72
|
+
?M :can :PrepareStandardState . }
|
|
73
|
+
=>
|
|
74
|
+
{ :alarmSensor :can :ReadyForReuse . } .
|
|
75
|
+
|
|
76
|
+
# Using a charged work medium to reset a memory produces a degradation path:
|
|
77
|
+
# useful work can be spent and end up as dissipated heat.
|
|
78
|
+
{ ?W a :WorkMedium ;
|
|
79
|
+
:chargeState :Charged .
|
|
80
|
+
?M :can :ReliableResetFromWork . }
|
|
81
|
+
=>
|
|
82
|
+
{ ?W :can :DegradeToHeatDuringReset . } .
|
|
83
|
+
|
|
84
|
+
# --------------------------------
|
|
85
|
+
# CAN'T rules — what is impossible
|
|
86
|
+
# --------------------------------
|
|
87
|
+
|
|
88
|
+
# Heat alone is not a directed reset resource for this memory task.
|
|
89
|
+
{ ?H a :HeatMedium ;
|
|
90
|
+
:provides :UndirectedThermalContact .
|
|
91
|
+
?M a :OneBitMemory . }
|
|
92
|
+
=>
|
|
93
|
+
{ ?H :cannot :DriveControlledReset .
|
|
94
|
+
?M :cannot :ReliableResetFromHeatAlone . } .
|
|
95
|
+
|
|
96
|
+
# If controlled reset is unavailable, preparation of the standard state
|
|
97
|
+
# is unavailable in the required reliable sense.
|
|
98
|
+
{ ?M :cannot :ReliableResetFromHeatAlone . }
|
|
99
|
+
=>
|
|
100
|
+
{ ?M :cannot :PrepareStandardStateFromHeatAlone . } .
|
|
101
|
+
|
|
102
|
+
# If the standard state cannot be prepared from heat alone, the sensor
|
|
103
|
+
# cannot be made ready for reuse by heat alone.
|
|
104
|
+
{ :alarmSensor :hasMemory ?M .
|
|
105
|
+
?M :cannot :PrepareStandardStateFromHeatAlone . }
|
|
106
|
+
=>
|
|
107
|
+
{ :alarmSensor :cannot :ReadyForReuseFromHeatAlone . } .
|
|
108
|
+
|
|
109
|
+
# Constructor-theoretic irreversibility pattern:
|
|
110
|
+
# if work can degrade to heat during reset, the exact transpose task of
|
|
111
|
+
# reconstructing the charged work resource from ambient heat alone is not allowed.
|
|
112
|
+
{ ?W :can :DegradeToHeatDuringReset .
|
|
113
|
+
?H a :HeatMedium . }
|
|
114
|
+
=>
|
|
115
|
+
{ ?H :cannot :ReconstructChargedWorkMediumByItself . } .
|
|
116
|
+
|
|
117
|
+
# ------
|
|
118
|
+
# Checks
|
|
119
|
+
# ------
|
|
120
|
+
|
|
121
|
+
# Positive checks.
|
|
122
|
+
{ :batteryPack :can :DriveControlledReset . }
|
|
123
|
+
=> { :case :checkC1 :Passed . } .
|
|
124
|
+
|
|
125
|
+
{ :alarmLatch :can :ReliableResetFromWork . }
|
|
126
|
+
=> { :case :checkC2 :Passed . } .
|
|
127
|
+
|
|
128
|
+
{ :alarmLatch :can :PrepareStandardState . }
|
|
129
|
+
=> { :case :checkC3 :Passed . } .
|
|
130
|
+
|
|
131
|
+
{ :alarmSensor :can :ReadyForReuse . }
|
|
132
|
+
=> { :case :checkC4 :Passed . } .
|
|
133
|
+
|
|
134
|
+
{ :batteryPack :can :DegradeToHeatDuringReset . }
|
|
135
|
+
=> { :case :checkC5 :Passed . } .
|
|
136
|
+
|
|
137
|
+
# Negative checks.
|
|
138
|
+
{ :ambientBath :cannot :DriveControlledReset . }
|
|
139
|
+
=> { :case :checkC6 :Passed . } .
|
|
140
|
+
|
|
141
|
+
{ :alarmLatch :cannot :ReliableResetFromHeatAlone . }
|
|
142
|
+
=> { :case :checkC7 :Passed . } .
|
|
143
|
+
|
|
144
|
+
{ :alarmLatch :cannot :PrepareStandardStateFromHeatAlone . }
|
|
145
|
+
=> { :case :checkC8 :Passed . } .
|
|
146
|
+
|
|
147
|
+
{ :alarmSensor :cannot :ReadyForReuseFromHeatAlone . }
|
|
148
|
+
=> { :case :checkC9 :Passed . } .
|
|
149
|
+
|
|
150
|
+
{ :ambientBath :cannot :ReconstructChargedWorkMediumByItself . }
|
|
151
|
+
=> { :case :checkC10 :Passed . } .
|
|
152
|
+
|
|
153
|
+
# --------------------------------------------------------------------
|
|
154
|
+
# ARC-style output
|
|
155
|
+
# --------------------------------------------------------------------
|
|
156
|
+
|
|
157
|
+
{ :case :checkC1 :Passed .
|
|
158
|
+
:case :checkC2 :Passed .
|
|
159
|
+
:case :checkC3 :Passed .
|
|
160
|
+
:case :checkC4 :Passed .
|
|
161
|
+
:case :checkC5 :Passed .
|
|
162
|
+
:case :checkC6 :Passed .
|
|
163
|
+
:case :checkC7 :Passed .
|
|
164
|
+
:case :checkC8 :Passed .
|
|
165
|
+
:case :checkC9 :Passed .
|
|
166
|
+
:case :checkC10 :Passed . }
|
|
167
|
+
=>
|
|
168
|
+
{
|
|
169
|
+
:out log:outputString """ACT sensor memory reset
|
|
170
|
+
|
|
171
|
+
Answer
|
|
172
|
+
YES with the battery pack.
|
|
173
|
+
NO with the ambient heat bath alone.
|
|
174
|
+
|
|
175
|
+
Reason Why
|
|
176
|
+
The alarm latch is a one-bit memory that must be reset to its standard clear state before the radiation sensor can be reused. In this case, the charged battery pack is treated as a work medium, so it can drive a controlled reset and prepare the latch in its reusable standard state. The ambient bath is treated as a heat medium, so by itself it cannot perform the same reliable directed reset. The example also shows an irreversibility pattern: useful work can be degraded into dissipated heat during reset, but the ambient heat bath alone cannot reconstruct the charged work resource.
|
|
177
|
+
|
|
178
|
+
Check
|
|
179
|
+
C1 OK - the battery pack can drive a controlled reset
|
|
180
|
+
C2 OK - the alarm latch can be reliably reset from work
|
|
181
|
+
C3 OK - the latch can be prepared in its standard reusable state
|
|
182
|
+
C4 OK - the sensor can be made ready for reuse
|
|
183
|
+
C5 OK - the work resource can degrade to heat during reset
|
|
184
|
+
C6 OK - the ambient heat bath cannot drive a controlled reset
|
|
185
|
+
C7 OK - the latch cannot be reliably reset from heat alone
|
|
186
|
+
C8 OK - the latch cannot be prepared in its standard state from heat alone
|
|
187
|
+
C9 OK - the sensor cannot be made ready for reuse from heat alone
|
|
188
|
+
C10 OK - the ambient heat bath cannot reconstruct the charged work resource by itself
|
|
189
|
+
""" .
|
|
190
|
+
} .
|
|
@@ -0,0 +1,225 @@
|
|
|
1
|
+
# =================================================================================
|
|
2
|
+
# ACT tunnel-junction wake switch
|
|
3
|
+
#
|
|
4
|
+
# Applied constructor-theory case:
|
|
5
|
+
# A remote leak-alarm node must wake up under a very small forward-bias regime.
|
|
6
|
+
#
|
|
7
|
+
# We compare two devices:
|
|
8
|
+
# - tunnelJunction : a heavily doped narrow PN junction with overlapping states
|
|
9
|
+
# - ordinaryJunction : a conventional PN junction without that overlap
|
|
10
|
+
#
|
|
11
|
+
# The aim is to express the application in "can / can't" form:
|
|
12
|
+
# what the tunnel junction can do,
|
|
13
|
+
# and what the conventional junction can't do,
|
|
14
|
+
# under the same low-bias operating requirement.
|
|
15
|
+
# =================================================================================
|
|
16
|
+
|
|
17
|
+
@prefix : <http://example.org/act/tunnel-junction/> .
|
|
18
|
+
@prefix arc: <https://example.org/arc#> .
|
|
19
|
+
@prefix log: <http://www.w3.org/2000/10/swap/log#> .
|
|
20
|
+
|
|
21
|
+
:case a arc:Case ;
|
|
22
|
+
arc:question "Can a tunnel-junction wake switch trigger a low-bias leak alarm in a regime where a conventional PN junction cannot?" .
|
|
23
|
+
|
|
24
|
+
# -------------------
|
|
25
|
+
# Application context
|
|
26
|
+
# -------------------
|
|
27
|
+
|
|
28
|
+
:leakAlarmNode a :EdgeSensor ;
|
|
29
|
+
:needs :MicrowattWakeSwitching ;
|
|
30
|
+
:application :PipeLeakAlarm .
|
|
31
|
+
|
|
32
|
+
# ----------------------------------
|
|
33
|
+
# Device A: tunnel-style PN junction
|
|
34
|
+
# ----------------------------------
|
|
35
|
+
|
|
36
|
+
# This junction is modeled with the structural conditions associated here
|
|
37
|
+
# with quantum-tunneling transfer across the barrier.
|
|
38
|
+
:tunnelJunction a :PNJunction ;
|
|
39
|
+
:junctionKind :TunnelDiode ;
|
|
40
|
+
:doping :Heavy ;
|
|
41
|
+
:depletionWidth :Narrow ;
|
|
42
|
+
:stateAlignment :Overlap ;
|
|
43
|
+
:biasRegime :LowForwardBias ;
|
|
44
|
+
:scanProfile :PeakToValley ;
|
|
45
|
+
:deviceRole :WakeSwitch .
|
|
46
|
+
|
|
47
|
+
# ----------------------------------
|
|
48
|
+
# Device B: conventional PN junction
|
|
49
|
+
# ----------------------------------
|
|
50
|
+
|
|
51
|
+
# This junction is modeled as lacking the conditions needed for the same
|
|
52
|
+
# low-bias transfer mode.
|
|
53
|
+
:ordinaryJunction a :PNJunction ;
|
|
54
|
+
:junctionKind :ConventionalDiode ;
|
|
55
|
+
:doping :Standard ;
|
|
56
|
+
:depletionWidth :Wide ;
|
|
57
|
+
:stateAlignment :NoOverlap ;
|
|
58
|
+
:biasRegime :LowForwardBias ;
|
|
59
|
+
:scanProfile :MonotoneForward ;
|
|
60
|
+
:deviceRole :WakeSwitch .
|
|
61
|
+
|
|
62
|
+
# ---------------------------------
|
|
63
|
+
# CAN rules — what becomes possible
|
|
64
|
+
# ---------------------------------
|
|
65
|
+
|
|
66
|
+
# A heavily doped, narrow junction with overlapping states
|
|
67
|
+
# can support quantum transfer across the barrier.
|
|
68
|
+
{ ?J a :PNJunction ;
|
|
69
|
+
:doping :Heavy ;
|
|
70
|
+
:depletionWidth :Narrow ;
|
|
71
|
+
:stateAlignment :Overlap . }
|
|
72
|
+
=>
|
|
73
|
+
{ ?J :can :QuantumBarrierTransfer .
|
|
74
|
+
?J :transportMode :TunnelingDominant . } .
|
|
75
|
+
|
|
76
|
+
# If quantum barrier transfer is available in the low-bias
|
|
77
|
+
# regime, then sub-threshold current is possible.
|
|
78
|
+
{ ?J :can :QuantumBarrierTransfer ;
|
|
79
|
+
:biasRegime :LowForwardBias . }
|
|
80
|
+
=>
|
|
81
|
+
{ ?J :can :SubThresholdCurrent . } .
|
|
82
|
+
|
|
83
|
+
# If the device has quantum barrier transfer and is scanned
|
|
84
|
+
# through the peak-to-valley operating region, then a
|
|
85
|
+
# negative differential response is possible.
|
|
86
|
+
{ ?J :can :QuantumBarrierTransfer ;
|
|
87
|
+
:scanProfile :PeakToValley . }
|
|
88
|
+
=>
|
|
89
|
+
{ ?J :can :NegativeDifferentialResponse . } .
|
|
90
|
+
|
|
91
|
+
# If sub-threshold current is possible and the device is
|
|
92
|
+
# being used as a wake switch, then ultra-low-bias switching
|
|
93
|
+
# is possible.
|
|
94
|
+
{ ?J :can :SubThresholdCurrent ;
|
|
95
|
+
:deviceRole :WakeSwitch . }
|
|
96
|
+
=>
|
|
97
|
+
{ ?J :can :UltraLowBiasSwitching . } .
|
|
98
|
+
|
|
99
|
+
# If ultra-low-bias switching is possible and the node needs
|
|
100
|
+
# that capability, then the device can serve the wake circuit.
|
|
101
|
+
{ ?J :can :UltraLowBiasSwitching .
|
|
102
|
+
:leakAlarmNode :needs :MicrowattWakeSwitching . }
|
|
103
|
+
=>
|
|
104
|
+
{ ?J :can :ServeLeakAlarmWakeCircuit . } .
|
|
105
|
+
|
|
106
|
+
# -------------------------------------
|
|
107
|
+
# CAN'T rules — what becomes impossible
|
|
108
|
+
# -------------------------------------
|
|
109
|
+
|
|
110
|
+
# A conventional low-bias junction with wide depletion and
|
|
111
|
+
# no state overlap cannot provide the same quantum transfer.
|
|
112
|
+
{ ?J a :PNJunction ;
|
|
113
|
+
:doping :Standard ;
|
|
114
|
+
:depletionWidth :Wide ;
|
|
115
|
+
:stateAlignment :NoOverlap . }
|
|
116
|
+
=>
|
|
117
|
+
{ ?J :cannot :QuantumBarrierTransfer . } .
|
|
118
|
+
|
|
119
|
+
# If quantum barrier transfer is unavailable in the same
|
|
120
|
+
# low-bias regime, then sub-threshold current is unavailable.
|
|
121
|
+
{ ?J :cannot :QuantumBarrierTransfer ;
|
|
122
|
+
:biasRegime :LowForwardBias . }
|
|
123
|
+
=>
|
|
124
|
+
{ ?J :cannot :SubThresholdCurrent . } .
|
|
125
|
+
|
|
126
|
+
# Without the quantum transfer mode, the negative
|
|
127
|
+
# differential response of the tunnel-style operating window
|
|
128
|
+
# is unavailable too.
|
|
129
|
+
{ ?J :cannot :QuantumBarrierTransfer . }
|
|
130
|
+
=>
|
|
131
|
+
{ ?J :cannot :NegativeDifferentialResponse . } .
|
|
132
|
+
|
|
133
|
+
# If sub-threshold current is unavailable for a wake switch,
|
|
134
|
+
# then ultra-low-bias switching is unavailable.
|
|
135
|
+
{ ?J :cannot :SubThresholdCurrent ;
|
|
136
|
+
:deviceRole :WakeSwitch . }
|
|
137
|
+
=>
|
|
138
|
+
{ ?J :cannot :UltraLowBiasSwitching . } .
|
|
139
|
+
|
|
140
|
+
# If ultra-low-bias switching is unavailable, then the device
|
|
141
|
+
# cannot serve the leak-alarm wake circuit.
|
|
142
|
+
{ ?J :cannot :UltraLowBiasSwitching .
|
|
143
|
+
:leakAlarmNode :needs :MicrowattWakeSwitching . }
|
|
144
|
+
=>
|
|
145
|
+
{ ?J :cannot :ServeLeakAlarmWakeCircuit . } .
|
|
146
|
+
|
|
147
|
+
# ------
|
|
148
|
+
# Checks
|
|
149
|
+
# ------
|
|
150
|
+
|
|
151
|
+
# Positive checks for the tunnel junction.
|
|
152
|
+
{ :tunnelJunction :can :QuantumBarrierTransfer . }
|
|
153
|
+
=> { :case :checkC1 :Passed . } .
|
|
154
|
+
|
|
155
|
+
{ :tunnelJunction :transportMode :TunnelingDominant . }
|
|
156
|
+
=> { :case :checkC2 :Passed . } .
|
|
157
|
+
|
|
158
|
+
{ :tunnelJunction :can :SubThresholdCurrent . }
|
|
159
|
+
=> { :case :checkC3 :Passed . } .
|
|
160
|
+
|
|
161
|
+
{ :tunnelJunction :can :NegativeDifferentialResponse . }
|
|
162
|
+
=> { :case :checkC4 :Passed . } .
|
|
163
|
+
|
|
164
|
+
{ :tunnelJunction :can :UltraLowBiasSwitching . }
|
|
165
|
+
=> { :case :checkC5 :Passed . } .
|
|
166
|
+
|
|
167
|
+
{ :tunnelJunction :can :ServeLeakAlarmWakeCircuit . }
|
|
168
|
+
=> { :case :checkC6 :Passed . } .
|
|
169
|
+
|
|
170
|
+
# Negative checks for the conventional junction.
|
|
171
|
+
{ :ordinaryJunction :cannot :QuantumBarrierTransfer . }
|
|
172
|
+
=> { :case :checkC7 :Passed . } .
|
|
173
|
+
|
|
174
|
+
{ :ordinaryJunction :cannot :SubThresholdCurrent . }
|
|
175
|
+
=> { :case :checkC8 :Passed . } .
|
|
176
|
+
|
|
177
|
+
{ :ordinaryJunction :cannot :NegativeDifferentialResponse . }
|
|
178
|
+
=> { :case :checkC9 :Passed . } .
|
|
179
|
+
|
|
180
|
+
{ :ordinaryJunction :cannot :UltraLowBiasSwitching . }
|
|
181
|
+
=> { :case :checkC10 :Passed . } .
|
|
182
|
+
|
|
183
|
+
{ :ordinaryJunction :cannot :ServeLeakAlarmWakeCircuit . }
|
|
184
|
+
=> { :case :checkC11 :Passed . } .
|
|
185
|
+
|
|
186
|
+
# ----------------
|
|
187
|
+
# ARC-style output
|
|
188
|
+
# ----------------
|
|
189
|
+
|
|
190
|
+
{ :case :checkC1 :Passed .
|
|
191
|
+
:case :checkC2 :Passed .
|
|
192
|
+
:case :checkC3 :Passed .
|
|
193
|
+
:case :checkC4 :Passed .
|
|
194
|
+
:case :checkC5 :Passed .
|
|
195
|
+
:case :checkC6 :Passed .
|
|
196
|
+
:case :checkC7 :Passed .
|
|
197
|
+
:case :checkC8 :Passed .
|
|
198
|
+
:case :checkC9 :Passed .
|
|
199
|
+
:case :checkC10 :Passed .
|
|
200
|
+
:case :checkC11 :Passed . }
|
|
201
|
+
=>
|
|
202
|
+
{
|
|
203
|
+
:out log:outputString """ACT tunnel-junction wake switch
|
|
204
|
+
|
|
205
|
+
Answer
|
|
206
|
+
YES for the tunnel junction.
|
|
207
|
+
NO for the conventional low-bias PN junction in the same wake-switch regime.
|
|
208
|
+
|
|
209
|
+
Reason Why
|
|
210
|
+
The tunnel junction is modeled as a heavily doped narrow PN junction with overlapping states, so quantum barrier transfer is possible. That makes sub-threshold current possible in the low-forward-bias regime, which in turn makes ultra-low-bias switching possible for the wake circuit. Because the device is also scanned through a peak-to-valley window, a negative differential response is possible as well. By contrast, the conventional junction lacks the structural conditions for the same transfer mode, so it cannot deliver the same low-bias switching task in this case.
|
|
211
|
+
|
|
212
|
+
Check
|
|
213
|
+
C1 OK - the tunnel junction can support quantum barrier transfer
|
|
214
|
+
C2 OK - the tunnel junction is classified as tunneling-dominant
|
|
215
|
+
C3 OK - the tunnel junction can deliver sub-threshold current
|
|
216
|
+
C4 OK - the tunnel junction can show negative differential response
|
|
217
|
+
C5 OK - the tunnel junction can perform ultra-low-bias switching
|
|
218
|
+
C6 OK - the tunnel junction can serve the leak-alarm wake circuit
|
|
219
|
+
C7 OK - the conventional junction cannot support the same quantum barrier transfer
|
|
220
|
+
C8 OK - the conventional junction cannot deliver sub-threshold current in this regime
|
|
221
|
+
C9 OK - the conventional junction cannot show the tunnel-style negative differential response
|
|
222
|
+
C10 OK - the conventional junction cannot perform ultra-low-bias switching here
|
|
223
|
+
C11 OK - the conventional junction cannot serve the leak-alarm wake circuit in this case
|
|
224
|
+
""" .
|
|
225
|
+
} .
|
|
@@ -0,0 +1,248 @@
|
|
|
1
|
+
# ============================================================================
|
|
2
|
+
# ACT yeast self-reproduction — explicit can and can't version
|
|
3
|
+
#
|
|
4
|
+
# Applied constructor-theory case:
|
|
5
|
+
# A yeast starter culture is modeled as a self-reproducer.
|
|
6
|
+
# - the genome is the replicator
|
|
7
|
+
# - the cell machinery is the vehicle
|
|
8
|
+
# - a nutrient bath supplies raw materials
|
|
9
|
+
# - a fermenter provides a selection environment
|
|
10
|
+
#
|
|
11
|
+
# This example therefore includes both sides:
|
|
12
|
+
# - CAN : accurate replication, self-reproduction, heritable variation,
|
|
13
|
+
# and natural selection for a digitally encoded starter lineage
|
|
14
|
+
# - CAN'T : accurate self-reproduction for a contrast lineage whose heredity
|
|
15
|
+
# is not digitally instantiated under no-design laws
|
|
16
|
+
# ============================================================================
|
|
17
|
+
|
|
18
|
+
@prefix : <http://example.org/act/yeast/> .
|
|
19
|
+
@prefix arc: <https://example.org/arc#> .
|
|
20
|
+
@prefix log: <http://www.w3.org/2000/10/swap/log#> .
|
|
21
|
+
|
|
22
|
+
:case a arc:Case ;
|
|
23
|
+
arc:question "Can a yeast starter culture self-reproduce accurately under no-design laws, and what exactly can't happen for a non-digital contrast lineage?" .
|
|
24
|
+
|
|
25
|
+
# --------------------------------------
|
|
26
|
+
# Shared world assumptions and resources
|
|
27
|
+
# --------------------------------------
|
|
28
|
+
|
|
29
|
+
:world :obeys :NoDesignLaws .
|
|
30
|
+
|
|
31
|
+
:dnaRegister a :DigitalInformationMedium .
|
|
32
|
+
:analogRegister a :NonDigitalInformationMedium .
|
|
33
|
+
|
|
34
|
+
:nutrientBath a :RawMaterialSupply .
|
|
35
|
+
:mutationSource a :VariationSource .
|
|
36
|
+
|
|
37
|
+
:fermenter a :SelectionEnvironment ;
|
|
38
|
+
:favours :RespireFast .
|
|
39
|
+
|
|
40
|
+
# ------------------------
|
|
41
|
+
# Positive starter lineage
|
|
42
|
+
# ------------------------
|
|
43
|
+
|
|
44
|
+
:starterGenome a :Replicator ;
|
|
45
|
+
:accuracy :High ;
|
|
46
|
+
:variant :RespireFast ;
|
|
47
|
+
:storedIn :dnaRegister .
|
|
48
|
+
|
|
49
|
+
:starterVehicle a :Vehicle ;
|
|
50
|
+
:function :Metabolism ;
|
|
51
|
+
:function :CopyingSupport .
|
|
52
|
+
|
|
53
|
+
:starterCell a :Cell ;
|
|
54
|
+
:hasReplicator :starterGenome ;
|
|
55
|
+
:hasVehicle :starterVehicle .
|
|
56
|
+
|
|
57
|
+
# ------------------------------------------
|
|
58
|
+
# Contrast lineage with non-digital heredity
|
|
59
|
+
# ------------------------------------------
|
|
60
|
+
|
|
61
|
+
:contrastGenome a :Replicator ;
|
|
62
|
+
:accuracy :High ;
|
|
63
|
+
:variant :RespireFast ;
|
|
64
|
+
:storedIn :analogRegister .
|
|
65
|
+
|
|
66
|
+
:contrastVehicle a :Vehicle ;
|
|
67
|
+
:function :Metabolism ;
|
|
68
|
+
:function :CopyingSupport .
|
|
69
|
+
|
|
70
|
+
:contrastCell a :Cell ;
|
|
71
|
+
:hasReplicator :contrastGenome ;
|
|
72
|
+
:hasVehicle :contrastVehicle .
|
|
73
|
+
|
|
74
|
+
# -----------------------------------------------------------
|
|
75
|
+
# CAN rules — what is possible for the viable starter culture
|
|
76
|
+
# -----------------------------------------------------------
|
|
77
|
+
|
|
78
|
+
# Under no-design laws, digitally instantiated hereditary information makes
|
|
79
|
+
# accurate genome copying possible in principle.
|
|
80
|
+
{ :world :obeys :NoDesignLaws .
|
|
81
|
+
?Medium a :DigitalInformationMedium . }
|
|
82
|
+
=>
|
|
83
|
+
{ ?Medium :can :SupportReplicationUnderNoDesignLaws .
|
|
84
|
+
:ReplicationUnderNoDesignLaws a :PossibleTask . } .
|
|
85
|
+
|
|
86
|
+
# A replicator stored in a digital medium can be accurately copied.
|
|
87
|
+
{ ?Genome a :Replicator ;
|
|
88
|
+
:storedIn ?Medium .
|
|
89
|
+
?Medium :can :SupportReplicationUnderNoDesignLaws . }
|
|
90
|
+
=>
|
|
91
|
+
{ ?Genome :can :AccurateGenomeCopyUnderNoDesignLaws .
|
|
92
|
+
:GenomeCopying a :PossibleTask . } .
|
|
93
|
+
|
|
94
|
+
# A replicator-plus-vehicle architecture supports accurate replication.
|
|
95
|
+
{ ?Genome :accuracy :High .
|
|
96
|
+
?Cell :hasReplicator ?Genome .
|
|
97
|
+
?Cell :hasVehicle ?Vehicle .
|
|
98
|
+
?Vehicle a :Vehicle . }
|
|
99
|
+
=>
|
|
100
|
+
{ ?Cell :can :AccurateReplicationArchitecture .
|
|
101
|
+
:AccurateReplicationArchitecture a :PossibleTask . } .
|
|
102
|
+
|
|
103
|
+
# Genome copying plus architecture plus raw materials makes self-reproduction possible.
|
|
104
|
+
{ ?Cell :hasReplicator ?Genome .
|
|
105
|
+
?Genome :can :AccurateGenomeCopyUnderNoDesignLaws .
|
|
106
|
+
?Cell :can :AccurateReplicationArchitecture .
|
|
107
|
+
:nutrientBath a :RawMaterialSupply . }
|
|
108
|
+
=>
|
|
109
|
+
{ ?Cell a :SelfReproducer .
|
|
110
|
+
?Cell :can :SelfReproduce .
|
|
111
|
+
:SelfReproduction a :PossibleTask . } .
|
|
112
|
+
|
|
113
|
+
# Variation plus a selection environment makes natural selection possible.
|
|
114
|
+
{ ?Genome a :Replicator .
|
|
115
|
+
:mutationSource a :VariationSource . }
|
|
116
|
+
=>
|
|
117
|
+
{ ?Genome :can :HeritableVariation .
|
|
118
|
+
:HeritableVariation a :PossibleTask . } .
|
|
119
|
+
|
|
120
|
+
{ ?Cell :hasReplicator ?Genome .
|
|
121
|
+
?Cell :can :SelfReproduce .
|
|
122
|
+
?Genome :can :HeritableVariation .
|
|
123
|
+
:fermenter a :SelectionEnvironment . }
|
|
124
|
+
=>
|
|
125
|
+
{ ?Cell :can :NaturalSelectionLineage .
|
|
126
|
+
:NaturalSelection a :PossibleTask . } .
|
|
127
|
+
|
|
128
|
+
{ ?Cell :hasReplicator ?Genome .
|
|
129
|
+
?Cell :can :NaturalSelectionLineage .
|
|
130
|
+
?Genome :variant ?V .
|
|
131
|
+
:fermenter :favours ?V . }
|
|
132
|
+
=>
|
|
133
|
+
{ ?Genome :selectedIn :fermenter . } .
|
|
134
|
+
|
|
135
|
+
# ---------------------------------------------------------------------
|
|
136
|
+
# CAN'T rules — what is impossible for the non-digital contrast lineage
|
|
137
|
+
# ---------------------------------------------------------------------
|
|
138
|
+
|
|
139
|
+
# Under no-design laws, a non-digital hereditary medium cannot support the same
|
|
140
|
+
# accurate genome-copying task.
|
|
141
|
+
{ :world :obeys :NoDesignLaws .
|
|
142
|
+
?Genome a :Replicator ;
|
|
143
|
+
:storedIn ?Medium .
|
|
144
|
+
?Medium a :NonDigitalInformationMedium . }
|
|
145
|
+
=>
|
|
146
|
+
{ ?Genome :cannot :AccurateGenomeCopyUnderNoDesignLaws . } .
|
|
147
|
+
|
|
148
|
+
# If accurate genome copying is unavailable, accurate self-reproduction is unavailable.
|
|
149
|
+
{ ?Cell :hasReplicator ?Genome .
|
|
150
|
+
?Genome :cannot :AccurateGenomeCopyUnderNoDesignLaws . }
|
|
151
|
+
=>
|
|
152
|
+
{ ?Cell :cannot :AccurateSelfReproduction . } .
|
|
153
|
+
|
|
154
|
+
# If accurate self-reproduction is unavailable, the contrast lineage cannot support
|
|
155
|
+
# the same natural-selection story as the viable starter lineage.
|
|
156
|
+
{ ?Cell :cannot :AccurateSelfReproduction . }
|
|
157
|
+
=>
|
|
158
|
+
{ ?Cell :cannot :NaturalSelectionLineage . } .
|
|
159
|
+
|
|
160
|
+
# ------
|
|
161
|
+
# Checks
|
|
162
|
+
# ------
|
|
163
|
+
|
|
164
|
+
# Positive checks for the viable starter culture.
|
|
165
|
+
{ :world :obeys :NoDesignLaws . }
|
|
166
|
+
=> { :case :checkC1 :Passed . } .
|
|
167
|
+
|
|
168
|
+
{ :dnaRegister a :DigitalInformationMedium . }
|
|
169
|
+
=> { :case :checkC2 :Passed . } .
|
|
170
|
+
|
|
171
|
+
{ :starterGenome a :Replicator . }
|
|
172
|
+
=> { :case :checkC3 :Passed . } .
|
|
173
|
+
|
|
174
|
+
{ :starterVehicle a :Vehicle . }
|
|
175
|
+
=> { :case :checkC4 :Passed . } .
|
|
176
|
+
|
|
177
|
+
{ :starterGenome :can :AccurateGenomeCopyUnderNoDesignLaws . }
|
|
178
|
+
=> { :case :checkC5 :Passed . } .
|
|
179
|
+
|
|
180
|
+
{ :starterCell :can :AccurateReplicationArchitecture . }
|
|
181
|
+
=> { :case :checkC6 :Passed . } .
|
|
182
|
+
|
|
183
|
+
{ :starterCell a :SelfReproducer . }
|
|
184
|
+
=> { :case :checkC7 :Passed . } .
|
|
185
|
+
|
|
186
|
+
{ :starterGenome :can :HeritableVariation . }
|
|
187
|
+
=> { :case :checkC8 :Passed . } .
|
|
188
|
+
|
|
189
|
+
{ :starterCell :can :NaturalSelectionLineage . }
|
|
190
|
+
=> { :case :checkC9 :Passed . } .
|
|
191
|
+
|
|
192
|
+
{ :starterGenome :selectedIn :fermenter . }
|
|
193
|
+
=> { :case :checkC10 :Passed . } .
|
|
194
|
+
|
|
195
|
+
# Negative checks for the contrast lineage.
|
|
196
|
+
{ :contrastGenome :cannot :AccurateGenomeCopyUnderNoDesignLaws . }
|
|
197
|
+
=> { :case :checkC11 :Passed . } .
|
|
198
|
+
|
|
199
|
+
{ :contrastCell :cannot :AccurateSelfReproduction . }
|
|
200
|
+
=> { :case :checkC12 :Passed . } .
|
|
201
|
+
|
|
202
|
+
{ :contrastCell :cannot :NaturalSelectionLineage . }
|
|
203
|
+
=> { :case :checkC13 :Passed . } .
|
|
204
|
+
|
|
205
|
+
# ----------------
|
|
206
|
+
# ARC-style output
|
|
207
|
+
# ----------------
|
|
208
|
+
|
|
209
|
+
{ :case :checkC1 :Passed .
|
|
210
|
+
:case :checkC2 :Passed .
|
|
211
|
+
:case :checkC3 :Passed .
|
|
212
|
+
:case :checkC4 :Passed .
|
|
213
|
+
:case :checkC5 :Passed .
|
|
214
|
+
:case :checkC6 :Passed .
|
|
215
|
+
:case :checkC7 :Passed .
|
|
216
|
+
:case :checkC8 :Passed .
|
|
217
|
+
:case :checkC9 :Passed .
|
|
218
|
+
:case :checkC10 :Passed .
|
|
219
|
+
:case :checkC11 :Passed .
|
|
220
|
+
:case :checkC12 :Passed .
|
|
221
|
+
:case :checkC13 :Passed . }
|
|
222
|
+
=>
|
|
223
|
+
{
|
|
224
|
+
:out log:outputString """ACT yeast self-reproduction
|
|
225
|
+
|
|
226
|
+
Answer
|
|
227
|
+
YES for the viable starter culture.
|
|
228
|
+
NO for accurate self-reproduction in the non-digital contrast lineage.
|
|
229
|
+
|
|
230
|
+
Reason Why
|
|
231
|
+
The starter genome is treated as a replicator storing digital hereditary information, while the cell machinery is treated as the vehicle that enables metabolism and copying support. Under no-design laws, digital information makes accurate genome copying possible. Because the replicator is accurate and paired with a vehicle, the whole starter cell qualifies as a self-reproducer. With a variation source and a selection environment, natural selection also becomes possible. By contrast, the non-digital lineage cannot support accurate genome copying under the same no-design-laws assumption, so it cannot sustain the same accurate self-reproduction or natural-selection story.
|
|
232
|
+
|
|
233
|
+
Check
|
|
234
|
+
C1 OK - no-design laws are assumed
|
|
235
|
+
C2 OK - digital information is physically instantiated for the viable lineage
|
|
236
|
+
C3 OK - a viable replicator is present
|
|
237
|
+
C4 OK - a viable vehicle is present
|
|
238
|
+
C5 OK - accurate genome copying is possible for the viable lineage
|
|
239
|
+
C6 OK - the viable lineage has a replicator-plus-vehicle architecture
|
|
240
|
+
C7 OK - the starter cell qualifies as a self-reproducer
|
|
241
|
+
C8 OK - heritable variation is possible for the viable lineage
|
|
242
|
+
C9 OK - the viable starter culture can support a natural-selection lineage
|
|
243
|
+
C10 OK - the fitter viable variant is selected in the fermenter
|
|
244
|
+
C11 OK - the non-digital contrast genome cannot be copied accurately under no-design laws
|
|
245
|
+
C12 OK - the non-digital contrast cell cannot achieve accurate self-reproduction
|
|
246
|
+
C13 OK - the non-digital contrast cell cannot support the same natural-selection lineage
|
|
247
|
+
""" .
|
|
248
|
+
} .
|