Purpose.
This is a Causal Notation's initial draft, it's intended to have uses in Causal Proofs, Causal Analysis,
Causal Modelling, Causal Design, Causal Programming & Causal Automated Tests.
Additional practical notes.
This model is not detached from Reality, it applies to concurrent, non-realtime systems. Hence, we consider unknown delays in model & notation.
Are realtime systems detached from Reality?
Generally they are not - but for many solutions they are too expensive and slow to make. Hence, in many niches and solutions they are too unreal to be worthwhile.
Proving that programs or program parts will complete in a given maximum amount of time, is not possible using these tools. Using statistical-allowance of errors, including completion-time-related errors and forming contracts that way might be possible, but there's always a risk.
While time is counted very precisely by computer clocks, there are delays caused by code execution - every instruction takes a time to perform. Exact amount of delay depends on instruction(s), on processor(s) and on operating system and other software layers, if there are any.
Therefore, clock-events, objects creation and interaction are associated with delays, and response to clock-events usually is associated with delays.
Profilers, either built-in a programming language, or added manually or provided by thrid-party tools - are a good way of measuring average, worst and best delays statistically on a given hardware-software infrastructure unit.
See also, if You wish: Correctness.
Types.
Ca: a cause,
R: a result, an abstract object type that can evaluate to a boolean value,
De: discrete event, either a cause or result,
Co: a condition,
Te: a timeframe.
Cns: a conditions set,
B: a boolean expression,
Cto: a clock-events bound condition; it's state contains exact time of appearance and time of disappearance,
t: a time measured in milliseconds since beginning of year 1 A.D.
O: observer object - observes clock events, causes & conditions appearance, existence and disappearance, as well as origination, hold time, and cessation, then reacts with events that can result in cause(s) and/or condition(s) appearance and disappearance, as well as origination and cessation.
Definitions.
Cto := (t1, t2) - - Condition that appears at time t1 or a little later, and disappears at t2 or a little later,
Cto := (t, ...) - Condition that appears at a time t or a little later, and disappears when program stops,
Cto := (..., t) - Condition that appears during program's initialization, and disappears at time t or a little later,
Ten := Com - a timeframe Ten is defined as in-between of a condition Com appearance and disappearance.
Cnsn := Con1, Con2, ... - a conditions set Con is defined as a collection of conditions Con1, Con2, ...
Cnsn := Cnsm1, Cnsm2, ..., Cop1, Cop2, ... - a conditions set Cnsn,
is defined as a collection of:
* conditions Cop1, Cop2, ...,
* conditions from conditions sets Cnsm1, Cnsm2, ...
Origination - an objects starts to affect Reality.
Hold - an object keeps affecting Reality.
Cessation - an object ceases to affect Reality.
Appearance - an object appears in Reality.
Existence - an object exists in Reaiity.
Disappearance - an object disappears from Reality.
In different sources - Buddhist or other - these ideas might be defined differently.
In many cases, but not all:
* appearance means origination,
* existence means hold,
* disappearance means cessation.
Can object exist and not affect Reality?
* depends on how we define a Reality,
* a part of Reality is also a Reality,
* we can play with ideas of objects with or without meaning,
* we can play with ideas of physical and nonmaterial objects,
* we can play with ideas of redefining what 'affecting' means, and with 'affecting threshold',
* does observation affect Reality?,
* ...
This has uses in modelling, for example, as models are simplified representation of interresting Reality's parts.
Appearance, Existence, Disappearance, Origination, Hold & Cessation.
Can := App Dem - a discrete event Dem makes a cause Can to appear.
Can := App Com - a condition Com makes a cause Can to appear.
Can := App Cnsm - a conditions set Cnsm makes a cause Can to appear.
when Bn : Com - condition Com appears and exists for as long as Bn is true.
Rn := Ap Dem in Tep - a result Rn evaluates to true if a discrete event Dem appears in a timeframe Tep.
Rn := Ap Com in Tep - a result Rn evaluates to true if a condition Com appears in a timeframe Tep.
Rn := Ap Cnsm in Tep - a result Rn evaluates to true if a conditions set Cnsm appears in a timeframe Tep.
Rn := Dis Cam in Tep - a result Rn evaluates to true if a cause Cam disappears in a timeframe Tep.
Rn := Dis Com in Tep - a result Rn evaluates to true if a condition Com disappears in a timeframe Tep.
Rn := Dis Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm disappears in a timeframe Tep.
Rn := Ex Cam in Tep - a result Rn evaluates to true if a cause Cam exists in a timeframe Tep.
Rn := Ex Com in Tep - a result Rn evaluates to true if a condition Com exists in a timeframe Tep.
Rn := Ex Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm exists in a timeframe Tep.
Rn := Ori Dem in Tep - a result Rn evaluates to true if a cause Dem originates in a timeframe Tep.
Rn := Ori Com in Tep - a result Rn evaluates to true if a condition Com originates in a timeframe Tep.
Rn := Ori Cnsm in Tep - a result Rn evaluates to true if a conditions set Cnsm originates in a timeframe Tep.
Rn := Ces Cam in Tep - a result Rn evaluates to true if a cause Cam ceases in a timeframe Tep.
Rn := Ces Com in Tep - a result Rn evaluates to true if a condition Com ceases in a timeframe Tep.
Rn := Ces Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm ceases in a timeframe Tep.
Rn := H Cam in Tep - a result Rn evaluates to true if a cause Cam holds in a timeframe Tep.
Rn := H Com in Tep - a result Rn evaluates to true if a condition Com holds in a timeframe Tep.
Rn := H Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm holds in a timeframe Tep.
Links.
See also, if You wish:
* The 'Causal Programming Paradigm'.
* Causal Automated Tests.
Tuesday, 1 May 2018
Monday, 30 April 2018
Causal Automated Tests.
About.
Automated Unit & Integration tests / pl: zautomatyzowane testy jednostkowe i integracyjne / are not proofs, but these are practical as well - reducing bugfixing costs extremely significiantly at a very small price. There are more benefits to using Automated Tests, for example Mental Harness of Unit & Integration Tests enables one to proceed more boldly, faster, thinking on higher abstraction levels without worryig about minor bugs, relying on tests to handle that. These also can use Invariants.
In the 'Causal Programming Paradigm', each of state changes, as well as methods entrances, having control within, and control leaving can cause conditions appearance, existence, and disappearance event notifications. Methods' leave events contain return values, if applicable.
In the 'Causal Programming Paradigm', causes appearances and disappearances can cause event notifications.
How automated tests are perfomed in this paradigm, then?
1. Test registers for neccessary event notifications,
2. Test runs a method to be tested - which can contain one or many objects/methods.
3. Test gets report of the events raised and analyzes their types, order of appearance and state.
4. Test returns a value - either true or false, which says whether it was success or failure.
Links.
See also, if You wish:
- Invariants,
- Causes & Conditions,
- The 'Causal Programming Paradigm'.
Automated Unit & Integration tests / pl: zautomatyzowane testy jednostkowe i integracyjne / are not proofs, but these are practical as well - reducing bugfixing costs extremely significiantly at a very small price. There are more benefits to using Automated Tests, for example Mental Harness of Unit & Integration Tests enables one to proceed more boldly, faster, thinking on higher abstraction levels without worryig about minor bugs, relying on tests to handle that. These also can use Invariants.
In the 'Causal Programming Paradigm', each of state changes, as well as methods entrances, having control within, and control leaving can cause conditions appearance, existence, and disappearance event notifications. Methods' leave events contain return values, if applicable.
In the 'Causal Programming Paradigm', causes appearances and disappearances can cause event notifications.
How automated tests are perfomed in this paradigm, then?
1. Test registers for neccessary event notifications,
2. Test runs a method to be tested - which can contain one or many objects/methods.
3. Test gets report of the events raised and analyzes their types, order of appearance and state.
4. Test returns a value - either true or false, which says whether it was success or failure.
Links.
See also, if You wish:
- Invariants,
- Causes & Conditions,
- The 'Causal Programming Paradigm'.
Correctness.
Introduction.
Proving code's correctness / pl: dowodzenie poprawności kodu / can be done, but is very difficult & expensive so far.
Depending on purpose, code's correctness proofs are neccessary / for example: the nuclear reactor's software, airplane controls /, or not / for example: a non-commercial webpage /.
In reality, automated tests are enough for many applications, and proofs are used only in mission - critical software parts, because of the costs measured in programmers' work time and in other resources.
Too often even the simple automated tests are omitted in programmers' work - as customers mistakenly think that it costs less to just pay for bugfixing, than to pay for quality. But customers often lack knowledge neccessary to check code's quality, so they prefer to not pay for quality, while expecting it still.
Causal Proofs.
... i think that with coming of the 'Causal Programming Paradigm', proving code's correctness might become easier, automated testing as well.
With this paradigm, software analysis will be similar to observing a space - play, a play of causes & conditions.
Computation is calculation with side effects, depending on hardware & software, machines can compute either well or not so well.
In the Causal Programming Paradigm, cause's result appears when cause appears and conditions exist for long enough after cause's appearance.
Program's result is achieving certain results - either once, or continually, over a given time.
Idea of algorithm's correctness proof, therefore, is proving that a proper cause will appear, and proper conditions will exist for long enough, in a given timeframe.
See also, if You wish: Causes & Conditions.
Concurrency & Real Time.
Timeframe can be counted either using Real Time Clock, in case of Realtime programming languages, or defined as 'within brackets' of causes, countercauses, conditions and counterconditions appearance, existence or disappearance - in case of programming languages without Realtime mechanisms, as for example: 'Ola' Programming Language.
In a Nonrealtime Concurrent Systems, Real Time Clock can be used as well, but not so precisely.
Concurrency is not the same as Realtime Support Mechanisms, and considering either or both is not a small cost when proving program's correctness. In simpler words: Nonrealtime Concurrent Systems are faster usually than Realtime Concurrent Systems, but lack the Hard Pessimistic Time Constraints - often work faster, but occasionally are too slow. Realtime systems, when written correctly, do not fail at all - but are slower on average.
Nonrealtime Concurrent Systems are also cheaper and easier in making than Realtime Concurrent Systems, and market niche for these languages is much larger. People do not need expensive and over-ambitious solutions for most of simpler tasks, afterall.
Both the Realtime Concurrent Systems, as well as the Nonrealtime Concurrent Systems can work in Real Time, can have user interface that affect their behaviour. The 'Starcraft 2' Computer Game by Blizzard Entertainment is an example of the Nonrealtime Concurrent Program masterpiece - it works smooth and fast, but occassinally 'hiccups' - slows down for a while. Being a Nonrealtime Program it's much cheaper, and is faster on average.
'Starcraft 2' is the game of the 'RTS' - 'Real Time Strategy' Computer Games Genre, as it works in Real Time, Concurrently coordinating software parts. By the Computer Sciences Linguistics it is not a Realtime System, however, as it doesn't adhere to Pessimistic Time Contraints of the Realtime Systems. There's the difference between Computer Science's 'Realtime' meaning and the Common Sense's 'Real Time' meaning. The RTS Computer Game Genre illustrate this difference well enough, i think.
Quality & Professional Practices.
In formal proofs of program's correctness, minimalism is important too, code should have as little of side-effects as possible - only desired ones, if possible - as unwanted side effects, causes & conditions, can complicate proofs or interfere with results.
'The less code the better', SOLID, DRY / 'Don't repeat yourself' / & other ideas are important when considering 'Code Quality Metrics'.
Links.
See also, if You wish:
* Invariants,
* Causal Notation.
Proving code's correctness / pl: dowodzenie poprawności kodu / can be done, but is very difficult & expensive so far.
Depending on purpose, code's correctness proofs are neccessary / for example: the nuclear reactor's software, airplane controls /, or not / for example: a non-commercial webpage /.
In reality, automated tests are enough for many applications, and proofs are used only in mission - critical software parts, because of the costs measured in programmers' work time and in other resources.
Too often even the simple automated tests are omitted in programmers' work - as customers mistakenly think that it costs less to just pay for bugfixing, than to pay for quality. But customers often lack knowledge neccessary to check code's quality, so they prefer to not pay for quality, while expecting it still.
Causal Proofs.
... i think that with coming of the 'Causal Programming Paradigm', proving code's correctness might become easier, automated testing as well.
With this paradigm, software analysis will be similar to observing a space - play, a play of causes & conditions.
Computation is calculation with side effects, depending on hardware & software, machines can compute either well or not so well.
In the Causal Programming Paradigm, cause's result appears when cause appears and conditions exist for long enough after cause's appearance.
Program's result is achieving certain results - either once, or continually, over a given time.
Idea of algorithm's correctness proof, therefore, is proving that a proper cause will appear, and proper conditions will exist for long enough, in a given timeframe.
See also, if You wish: Causes & Conditions.
Concurrency & Real Time.
Timeframe can be counted either using Real Time Clock, in case of Realtime programming languages, or defined as 'within brackets' of causes, countercauses, conditions and counterconditions appearance, existence or disappearance - in case of programming languages without Realtime mechanisms, as for example: 'Ola' Programming Language.
In a Nonrealtime Concurrent Systems, Real Time Clock can be used as well, but not so precisely.
Concurrency is not the same as Realtime Support Mechanisms, and considering either or both is not a small cost when proving program's correctness. In simpler words: Nonrealtime Concurrent Systems are faster usually than Realtime Concurrent Systems, but lack the Hard Pessimistic Time Constraints - often work faster, but occasionally are too slow. Realtime systems, when written correctly, do not fail at all - but are slower on average.
Nonrealtime Concurrent Systems are also cheaper and easier in making than Realtime Concurrent Systems, and market niche for these languages is much larger. People do not need expensive and over-ambitious solutions for most of simpler tasks, afterall.
Both the Realtime Concurrent Systems, as well as the Nonrealtime Concurrent Systems can work in Real Time, can have user interface that affect their behaviour. The 'Starcraft 2' Computer Game by Blizzard Entertainment is an example of the Nonrealtime Concurrent Program masterpiece - it works smooth and fast, but occassinally 'hiccups' - slows down for a while. Being a Nonrealtime Program it's much cheaper, and is faster on average.
'Starcraft 2' is the game of the 'RTS' - 'Real Time Strategy' Computer Games Genre, as it works in Real Time, Concurrently coordinating software parts. By the Computer Sciences Linguistics it is not a Realtime System, however, as it doesn't adhere to Pessimistic Time Contraints of the Realtime Systems. There's the difference between Computer Science's 'Realtime' meaning and the Common Sense's 'Real Time' meaning. The RTS Computer Game Genre illustrate this difference well enough, i think.
Quality & Professional Practices.
In formal proofs of program's correctness, minimalism is important too, code should have as little of side-effects as possible - only desired ones, if possible - as unwanted side effects, causes & conditions, can complicate proofs or interfere with results.
'The less code the better', SOLID, DRY / 'Don't repeat yourself' / & other ideas are important when considering 'Code Quality Metrics'.
Links.
See also, if You wish:
* Invariants,
* Causal Notation.
Sunday, 22 April 2018
The 'Causal Programming Paradigm'.
Programming Paradigm is the way of thinking about programming, there are many programming paradigms, both lesser and greater.
Greatest Programming Paradigms are:
- Object Oriented Paradigm,
- Functional Programming Paradigm,
- Programming in Logic.
Programming Languages offer more or less support for programming with paradigms. Java, for example, offers support for Object Oriented & Functional Paradigms. Prolog, for example, offers support for Programming in Logic.
The Object Oriented Paradigm is a great tool for handling large-scale, complex software projects.
The Object Oriented Paradigm was meant to enable people to think about programming in a more abstract way than in the imperative programming, was an attempt to emulate a way of 'how mind works'.
i wish to build on Object Oriented Programming, to make programming even more alike to 'how mind works'.
i wish to create 'Causal Programming Paradigm' / pl: 'paradygmat programowania przyczynowego' /.
... it's both textual and visuospatial method, as one should be able to model objects graph using 3D modelling tools, then fill with code, or just write a code in a purely textual way. Visual Programming can transform to a purely textual code, elegant even - using the automated tools, anyway.
'Ola' Programming Language with its 'Token Game' semantics & nice syntax should enable the 'Causal Programming Paradigm', in a simple, easy, and cost-efficient way. Other important & useful programming paradigms should be supported, as well.
Software created with 'Causal Programming Paradigm' should react to events of causes and conditions appearing, existing and disappearing.
i think it's possible to use 'Causal Programming Paradigm' in the most of modern Programming Languages - at varying costs, however.
Causal Programming Paradigm should keep all of the tools of Object Oriented Paradigm.
i think Causal Modelling, Causal Analysis and Causal Design should also appear with time, as complementaries to Causal Programming Paradigm.
See also, if You wish:
- Causal Analysis: Causes, Results & Correlations,
Greatest Programming Paradigms are:
- Object Oriented Paradigm,
- Functional Programming Paradigm,
- Programming in Logic.
Programming Languages offer more or less support for programming with paradigms. Java, for example, offers support for Object Oriented & Functional Paradigms. Prolog, for example, offers support for Programming in Logic.
The Object Oriented Paradigm is a great tool for handling large-scale, complex software projects.
The Object Oriented Paradigm was meant to enable people to think about programming in a more abstract way than in the imperative programming, was an attempt to emulate a way of 'how mind works'.
i wish to build on Object Oriented Programming, to make programming even more alike to 'how mind works'.
i wish to create 'Causal Programming Paradigm' / pl: 'paradygmat programowania przyczynowego' /.
... it's both textual and visuospatial method, as one should be able to model objects graph using 3D modelling tools, then fill with code, or just write a code in a purely textual way. Visual Programming can transform to a purely textual code, elegant even - using the automated tools, anyway.
'Ola' Programming Language with its 'Token Game' semantics & nice syntax should enable the 'Causal Programming Paradigm', in a simple, easy, and cost-efficient way. Other important & useful programming paradigms should be supported, as well.
Software created with 'Causal Programming Paradigm' should react to events of causes and conditions appearing, existing and disappearing.
i think it's possible to use 'Causal Programming Paradigm' in the most of modern Programming Languages - at varying costs, however.
Causal Programming Paradigm should keep all of the tools of Object Oriented Paradigm.
i think Causal Modelling, Causal Analysis and Causal Design should also appear with time, as complementaries to Causal Programming Paradigm.
See also, if You wish:
- Causal Analysis: Causes, Results & Correlations,
'Ola' Programming Language.
There's a lot of programming Languages on market, why create new?
Why not settle for just a programming library in one of succesful programming language products?
Just as a handyman needs lot of tools, different types of screwdrivers & other, different programming languages fill different niches.
Every programming language has it's niche, does some things better, some worse.
Some things are done cheaper, some more expensively, some can't be done at all.
Programming Languages have advantage over libraries that they offer simple notation, nice syntax - so coding is easier, cheaper, faster.
Programming Languages offer paradigms, thinking patterns, and idioms - good programming practices.
... what's inside a programming language, it's inner mechanisms affect what can be done at what cost when using it - affect it's meaning.
... this blog's author is creating a programming languge as well: 'Ola' Programming Language, a 4th Generation Programming Language / 4GL /.
Formerly know as 'Ola AH', we've changed name of this programming language from to 'Ola'.
-=- ... she looks similar to a Buddhist woman i Love, with whom i meditated in a Buddhist Center. -=-
-=- ... perhaps this logo will be changed, or perhaps this logo will stay. -=-
-=- Red Flowers. -=-
-=- ... for a Buddhist woman i Love. -=-
This initial draft, while worthwhile start and a source of ideas to consider - should be far from complete design. More ideas should follow, less important ideas should be removed, and - most significiantly - quantum informatics and perhaps quantum physics should be included in language's semantics. This should affect niches & syntax of 'Ola' Programming Language significiantly.
-=- Ada Lovelace. -=-
-=- Author of the first computer algorithm. -=-
-=- One of the Programming Languages was created and named after her.
-=- Examples of systems where Ada is used include avionics, railways, banking, military and space technology. -=-
Thursday, 12 April 2018
Token Game.
About.
Originally 'Token Game' is a board game, an educational board game related with petri nets - rare and precious, at least in some circles.
... in a context of this blog, 'Token Game' is a theory, software modelling & construction methodology.
... it's the most ambitious theory in Project Wraithstar, from the Advanced Mathematical Computer Sciences perspective.
... inspired by abstracted Petri Nets, concretized different way, taking advantage of object orientation, can be used to model causes & conditions quite efficiently.
Software built using the Token Game / pl: gra w żetony / should react to events of causes and conditions appearing, existing and disappearing.
it has uses in esoteric, visuospatial programming / pl: ezoteryczne, programowanie wzrokowo - przestrzenne /, with modelling objects graphs in 3D then filling them with code. Objects graph is a model of a program, can be run.
Design goals for Token Game is to be very easy to use, but offer a great paradigm to work with, great idioms set.
There's focus on seeing more, thinking more, typing less.
... fitting 'a complete code part' on a 'single screen' can make easier overview, simplifies thinking, increases code quality, as i learned when i studied on MIMUW - Warsaw Univesity, ZSI Informatics Faculty.
There's support for concurrency mechanisms & typed data flow, built-in.
... see also, if You need or wish: Befunge, esoteric programming language, visuospatial - at least in a way, i think.
Petri Nets Conference.
- i participated as well, when i studied at MIMUW, Computer Sciences, when i worked at XPro sp. z.o.o. -
- i got a few of free days from work, and sponsoring from Michał Kłeczek, XPro's owner. -
- this conference set karma in motion, i think ... deeply inspiring, even if i barely understood. -
Credits:
- Susanna Donatelli, for her participation in the Sieldce ATPN Petri Nets Conference & support.
- Carl Adam Petri on Wikipedia.
Links.
* Linda & Tuple Space.
Literature.
... bought this ebook on www.amazon.com, kindle edition - will read when we need, as much as we need, if i can.
... downloaded this document as well.
Originally 'Token Game' is a board game, an educational board game related with petri nets - rare and precious, at least in some circles.
... in a context of this blog, 'Token Game' is a theory, software modelling & construction methodology.
... it's the most ambitious theory in Project Wraithstar, from the Advanced Mathematical Computer Sciences perspective.
... inspired by abstracted Petri Nets, concretized different way, taking advantage of object orientation, can be used to model causes & conditions quite efficiently.
Software built using the Token Game / pl: gra w żetony / should react to events of causes and conditions appearing, existing and disappearing.
it has uses in esoteric, visuospatial programming / pl: ezoteryczne, programowanie wzrokowo - przestrzenne /, with modelling objects graphs in 3D then filling them with code. Objects graph is a model of a program, can be run.
Design goals for Token Game is to be very easy to use, but offer a great paradigm to work with, great idioms set.
There's focus on seeing more, thinking more, typing less.
... fitting 'a complete code part' on a 'single screen' can make easier overview, simplifies thinking, increases code quality, as i learned when i studied on MIMUW - Warsaw Univesity, ZSI Informatics Faculty.
There's support for concurrency mechanisms & typed data flow, built-in.
... see also, if You need or wish: Befunge, esoteric programming language, visuospatial - at least in a way, i think.
Petri Nets Conference.
- i participated as well, when i studied at MIMUW, Computer Sciences, when i worked at XPro sp. z.o.o. -
- i got a few of free days from work, and sponsoring from Michał Kłeczek, XPro's owner. -
- this conference set karma in motion, i think ... deeply inspiring, even if i barely understood. -
Credits:
- Susanna Donatelli, for her participation in the Sieldce ATPN Petri Nets Conference & support.
- Carl Adam Petri on Wikipedia.
Links.
* Linda & Tuple Space.
Literature.
... bought this ebook on www.amazon.com, kindle edition - will read when we need, as much as we need, if i can.
... downloaded this document as well.
Wednesday, 11 April 2018
Invariants.
Intro Poem.
'Welcome to the informational age
We're enjoy the world of technology
Never felt this modern world could emerge
Magical world with braveness and courage.'
-- See also, if You wish: 'Welcome' on Hello Poetry.
Computer Sciences.
Invariants are cornerstone of Mathematically Proving Algorithm's Correctness.
Automated Unit & Integration tests / pl: zautomatyzowane testy jednostkowe i integracyjne / are not proofs, but these are practical as well - reducing bugfixing costs extremely significiantly at a very small price. There are more benefits to using Automated Tests, for example Mental Harness of Unit & Integration Tests enables one to proceed more boldly, faster, thinking on higher abstraction levels without worryig about minor bugs, relying on tests to handle that. These also can use Invariants.
Invariant / pl: niezmiennik / is a holy word in this Project, important part of Advanced Mathematical Computer Science.
Invariant is something that holds, in observable moments.
Example 1: during method's m1 execution variable's v1 value is never less than 0.
Example 2: during method's m1 execution, conditions: Co1, Co2 and Co8 hold.
Example 3: during a given timeframe T1 cause Ca1 appears.
Example 4: after entering method m1, before reaching code line n, a cause Ca1 appears and conditions Co3 and Co5 hold.
See also, if You wish: Causes & Conditions.
That are examples of invariants.
Preconditions / pl: warunki wstępne / and Postconditions / pl: warunki końcowe / are also examples of Invariants, there are method and class-level Invariants / pl: niezmienniki na poziomie metody i klasy / - for details, consult Object Oriented Programming & Invariant Theory.
Invariants can be used in forming the Software Contracts.
Buddha & Love.
There are Invariants of Love as well, should be fought for keeping and restoring when these fail.
Otherwise Love would fall apart.
Should Invariants of Love hold only in Observable Moments?
Good Question, but there's Buddhist Awareness / Consciousness Theory that explains that Consciousness is composed of a serie of discrete Awareness Moments, with delays in-between.
... it's something worthwhile to think & meditate on, i think.
... in Buddhism, we are not bodies - we are Mind. Mind has body, and surpassess death, Reincarnating after death in a new body.
... There's 'ego barrier' as well.
... it's a part of Karma, the Timeless Law of Cause & Effect, Causal Science.
Links.
See also, if You wish:
- Correctness.
'Welcome to the informational age
We're enjoy the world of technology
Never felt this modern world could emerge
Magical world with braveness and courage.'
-- See also, if You wish: 'Welcome' on Hello Poetry.
Computer Sciences.
Invariants are cornerstone of Mathematically Proving Algorithm's Correctness.
Automated Unit & Integration tests / pl: zautomatyzowane testy jednostkowe i integracyjne / are not proofs, but these are practical as well - reducing bugfixing costs extremely significiantly at a very small price. There are more benefits to using Automated Tests, for example Mental Harness of Unit & Integration Tests enables one to proceed more boldly, faster, thinking on higher abstraction levels without worryig about minor bugs, relying on tests to handle that. These also can use Invariants.
Invariant / pl: niezmiennik / is a holy word in this Project, important part of Advanced Mathematical Computer Science.
Invariant is something that holds, in observable moments.
Example 1: during method's m1 execution variable's v1 value is never less than 0.
Example 2: during method's m1 execution, conditions: Co1, Co2 and Co8 hold.
Example 3: during a given timeframe T1 cause Ca1 appears.
Example 4: after entering method m1, before reaching code line n, a cause Ca1 appears and conditions Co3 and Co5 hold.
See also, if You wish: Causes & Conditions.
That are examples of invariants.
Preconditions / pl: warunki wstępne / and Postconditions / pl: warunki końcowe / are also examples of Invariants, there are method and class-level Invariants / pl: niezmienniki na poziomie metody i klasy / - for details, consult Object Oriented Programming & Invariant Theory.
Invariants can be used in forming the Software Contracts.
Buddha & Love.
There are Invariants of Love as well, should be fought for keeping and restoring when these fail.
Otherwise Love would fall apart.
Should Invariants of Love hold only in Observable Moments?
Good Question, but there's Buddhist Awareness / Consciousness Theory that explains that Consciousness is composed of a serie of discrete Awareness Moments, with delays in-between.
... it's something worthwhile to think & meditate on, i think.
... in Buddhism, we are not bodies - we are Mind. Mind has body, and surpassess death, Reincarnating after death in a new body.
... There's 'ego barrier' as well.
... it's a part of Karma, the Timeless Law of Cause & Effect, Causal Science.
Links.
See also, if You wish:
- Correctness.
Subscribe to:
Posts (Atom)