Abstracted Neural Networks & Token Game.

Neural Networks.

In neural networks we consider error between result that we consider 'correct & desired', and the result we get as an output vector of neural net.

We wish to minimize the error, to teach our neural net to provide accurate results that we can apply to other vectors than the training vectors.

We provide training data, a set of training vectors to the neural net and it adjusts weights of neuron signals accordingly.

After enough of iterations we have 'calibrated' neural net - with appropriate weight values at each of neurons - so it provides fairly accurate results at output neurons for non-training data vectors.

The output neurons answer us abstract questions about data we wish to classify, categorizing input fairly accurately.

Token Game's Abstracted Neural Networks.

In this case we do something similar, except in a simpler way.

We provide input data, we adjust weights at neurons, we pass tokens with payload information.

Example 1: Oval Recognition, with an image without the crossing lines & without 'noise' data.

First we need to 'describe' the image by a serie of 8 marker points at a circle bordering image's edge.

We place one marker point at top, one at bottom, one at left, one at right, and four remaining in between - but not on top of each other.

We assume initial weight of each of neurons as of 3.

For each of marker points we create input neuron. For each of neurons we calculate an error - a distance between that marker point and a point closest on the image.

Depending on calculated error value we modify weight accordingly - the more error, the more of adjustment.

First we move marker point left, by a value of sigmoidal function's for calculated weight.

Then we calculate error again, modify weight and move marker point right.

Then top & bottom similar way - repeating the process until we are close enough to the point on the image.

We repeat the process once for each of input neurons, once for each of marker points.

We have described the image with a possible small error.

Then we compare our image with marker points, counting distance from each of marker points to closest point on an image. Then we sum distances to calculate error.

If error is beyond certain threshold, image is not recognized.

We can recognize any of simple images that way.

Example 2: Face recognition, without crossing lines & without 'noise' data.

We recognize face's oval, eye shapes, nose shape & lips shape - passing tokens with marker points to initial neurons of second neural net, along with combined errors that determine initial weight of input neurons in second neural net. We'll call these shapes marker shapes since now, and compare these with face's template on an image.

If first neural net's error was too much, we pass nothing and input neuron isn't activated.

We move marker points as in example 1 until we get close enough to image's templates to 'describe' template shapes that way.

We move centers of marker shapes to align with centers of template shapes.

For each of input neurons, we count combined error between marker shape's marker points and template shape's closest points. If error is not beyond certain threshold, we recognized face. This is weight we might pass on to next layer of neural net if we need.

Example 3: Recognizing flat data.

It's similar as 'describing image' in an example 1, except we move only up & down in case of numbers, and we use sigmoidal function after we count error & weights.

Enumerations can be represented as numbers as well.

Mindful Imaging & Editor.

Mindful Imaging Module can read from Stitie Space to visualize it, with machines, states, strategies & links.

As a complement, planning to add Editor that will allow to insert Light Point Objects into machines, to move machines and their links, or transform Stitie Space in an any way.

Light Point Objects' code & state can be inserted into the Stitie Space's 'machine' during the runtime, to be interpreted there - either via network or from the Mindul Imaging-based 4GL interface. A live system can be modelled as with Smalltalk programming language, considering security & permission of course.

See also: Agile Transformation of Information State.


AI Exercise.

(article to be edited once i understand AI Machine Learning theories).

i've played with Java's Weka library for machine learning, for artificial intelligence.

While i didn't understand classification algorithms used, i was able to produce a code that learned how to classify & somehow classified 'plants' using the MultilayerPerceptron classifier. i read it's basicly the neural network, but considering my current knowledge - can't confirm.

i don't know if classification was succesful, as i don't know much about plants. but judging from data-nearness, it looked good.

i believe that experiments with code are very important parts of learning computer sciences, so i did this exercise despite my lacks in knowledge. hopefully it'll be useful for others as well.

i swallowed my own shame of not knowing theories, and posted this article for benefit of others.

There were other tools found such as assessing errors or adding weights to attributes consiering algorithms used, that i didn't understand. i think professional AI programmer should be fluent with all of these ideas & their uses.

Files: WekaTest.java, Datasets.

Library used: Weka.


Object Oriented Analysis, Design & Modelling.


Object-oriented analysis and design (OOAD) is a popular technical approach for analyzing, designing an application, system, or business by applying the object-oriented paradigm and visual modeling throughout the development life cycles to foster better stakeholder communication and product quality.

Object Oriented Analysis.

The purpose of any analysis activity in the software life-cycle is to create a model of the system's functional requirements that is independent of implementation constraints.

In the system analysis or object-oriented analysis phase of software development, the system requirements are determined, the classes are identified and the relationships among classes are identified, appropriate models are created.

The primary tasks in object-oriented analysis (OOA) are:
- Find the objects,
- Organize the objects,
- Describe how the objects interact,
- Define the behavior of the objects,
- Define the internals of the objects.

This serves as a way to understand the 'domain knowledge' - knowledge needed to write software that is not neccesarily the Computer Sciences-related.

Common models used in OOA are use cases and object models. Use cases describe scenarios for standard domain functions that the system must accomplish. Object models describe the names, class relations (e.g. Circle is a subclass of Shape), operations, and properties of the main objects.

Object Oriented Design.

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem.

The input for object-oriented design is provided by the output of object-oriented analysis.

During object-oriented design (OOD), a developer applies implementation constraints to the conceptual model produced in object-oriented analysis. Such constraints could include the hardware and software platforms, the performance requirements, persistent storage and transaction, usability of the system, and limitations imposed by budgets and time. Concepts in the analysis model which is technology independent, are mapped onto implementing classes and interfaces resulting in a model of the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies.

Designing concepts:
- Defining objects, creating class diagram from conceptual diagram,
- Identifying attributes,
- Use design patterns (if applicable),
- Define application framework (if applicable): Application framework is a term usually used to refer to a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer, since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed,
- Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single runtime of the application. If a relational database is used, design the object relation mapping,
- Identify and define remote objects (if applicable).

Output of object-oriented design:
- Class diagram: A class diagram is a type of static structure UML diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.

The Acyclic dependencies principle.

The dependency graph of components should have no cycles. This can be realized by abstracting common parts of the inter-dependent objects & moving into other abstract object(s), as well as by using the Dependency Injection Design Pattern. There are tools such as the Spring Framework that organize structure of the project & allow to easily use the Dependency Injection pattern as well. A part of 'Ola AH' Programming Language's semantics - Stitie Space - will also allow to model the object graph of a program & skillfully use the Dependency Injection Design Pattern as well.

Circular dependencies can cause many unwanted effects in software programs:
- Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the separate re-use of a single module,
- Circular dependencies can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects (program errors, compile errors),
- Circular dependencies make software to be hard to test,
- Circular dependencies can also result in infinite recursions or other unexpected failures. Circular dependencies may also cause memory leaks by preventing certain very primitive automatic garbage collectors from deallocating unused objects.

Object Oriented Modelling.

Object Oriented Modeling (OOM) is a common approach to modeling applications, systems, and business domains by using the object-oriented paradigm throughout the entire development life cycles. OOM is a main technique heavily used by both OOA and OOD activities in modern software engineering.

The benefits of OOM are:
- Efficient and effective communication within & between Team(s),
- Models are tools that allow to quickly, visually analyze the Project & the Problem Domain, to Simplify & Abstract the Design.

The Unified Modeling Language (UML) is a visual, popular international standard language used for object-oriented modeling, there are other solutions as well.

- Wikipedia,
- My own knowledge & experience.

See also, if You wish:
- Object Relationships Modelling & Analysis,
- UML,
- Iterative Development vs. Waterfall model.


The Less Code, The Better.


It is a good programming practice to solve problems using as little of code as possible.

With less code lines, program is more readable - there are less errors, code changes & debugging are faster.

There is research that proves that with less code lines there are less errors.

Number of code lines is one of metrics, by which code's quality can be measured.

One should not add extra code for future features in advance.

With time customer requirements might change, and this extra code only obscures project's clarity.


Memory, Cache, Processor Use & 'Ola AH' Programming Language.


Modern computers' processors are about 1500 times faster than memory.

Hard Disk Drives or other external memory devices are even slower.

Many programs often wait for a memory access after every a few of processor instructions.

It's quite inefficient, but simple to code.


There are registers & tiered cache inside the processors.

When a program's part can be loaded into a cache or use only registers it does not have to wait for memory access and is much faster; it's harder & more expensive programmer-time-wise to write such programs however. Programmers are paid per hour of work and this is not a small amount of money as well.

There are other optimizations too, for example - caching partial computations so these do not need to be computed again or read from external media device.

For even more of optimizations, please refer to books about 'Algorithms & Data Structures' - for example: [2], [4], [19], [33] (see right border of this blog for literature section).


Simple programs as many of web-pages do not need to be blazing-fast, they should be cheap instead to make & change.

In these cases programmers should & do optimize their own time at cost of program's efficiency.

It's cheaper to change hardware infrastructure or to buy many computers than to pay many of very skilled programmers for long times of optimizations.

Often a time of make is crucial too, for example when business wants to release a product before competition.

'Ola AH' Programming Language.

i think that with 'Ola AH' Programming Language it should be possible to take advantage of tiered-memory-pyramid-of-needs, as well as of multi-threading of standard processors, as well as of the RISC machine architectures to accelerate the computations.

RISC stands for 'Reduced Instruction Set Computing' machines, including ARM - 'Advanced RISC Machines'. These use very many of simple & cheap processors working in parallel.

Exact details to be designed still, it will be important when the compiler will be implemented.


'Ola AH' Programming Language for 3D Modelling & Animations.


One of use cases for 'Ola AH' Programming Language is 3D Rendering, Graphics & Animations.

Stitie Space - Based 3D Modelling & Animations.

Stitie Space can be seen as a container for objects, container with coordinates.

Visual object's information can be stored within one of Stitie Machines within Stitie Space, in an 'Anchor Point'.

Within Anchor Point object, shapes, colours & animations data can be stored, then Mindfully Visualized.

These objects can move & animate, change colours etc.

Anchor Points can move as well.

One of possible effects can be transforming Space into another Space.


Ideas & Feedback for 'Ola AH' Programming Language are Welcome.

First stage - design stage - for 'Ola AH' Programming Language is nearing end, it's scheduled until April 2017.

By 1 April 2017 i should start writing 'Ola AH' Programming Language interpreter in Java.

i think i'll start with modelling software constructs, instructions & data types, as well as documenting these properly on this blog.

It'll be possible to program with these code pieces using a 'program interpretation tree' at first, parser will come later.

By 1 Jan 2022 - beta version or an RC version (feature complete, but perhaps untested) of 'Ola AH' Programming Language should be complete, with parser, intermediate data structure, interpreter & other parts.

C/Asm compiler for 'Ola AH' Programming Language should come later.

Meanwhile, ideas & feedback for what's planned is welcome - feel free to contact me:
- via e-mail: neomahakala108@gmail.com,
- in comments to this article,
- other ways if You prefer.


Space, Transformations & Recursion.


... had insights that this has uses in Mathematics as well as in Physics, probably more.

... i was exploring Linear Algebra, Geometry & other fields of Mathematics - i plan to study Mathematics at Warsaw University in future as well, i plan to learn Physics from books after that, and other Sciences (Electronics, Chemistry, Biology, Nanotechnology, Nanoelectromechanical Systems - NEMS) as well.

Stitie Space is a 3D objects matrix with convenience methods to animate & transform objects within.

Stitie Space can be Recursive, as objects within can be treated as machines that can run Space(s) within; that way Space can be more dense at certain point(s) or continuously - as much as available resources allow; This can include GRIDs, as machine with Stitie Space objects can be Distributed & Recursive so it scales well with hardware/software infrastructure investments.

Non-Cartesian Spaces & Transformations.

By Space i understand a mathematical construct spanned by a linearly independent, minimal vectors set (a basis for a 'vector space').

i think that Space with Cartesian coordinates has two perpendicular axes, with consistently same unit of distance between values on each axis. i think we can abstract from this however, and talk about 'n-dimensional Cartesian Spaces' with an amount of n perpendicular axes.

Non-Cartesian Spaces do not neccessarily have perpendicular axes, might have different number of axes that two, it is not neccessary to have distance between points on each axis the same - can be more dense or sparse around certain point(s). It is also possible for points in Non-Cartesian Space to be in Relation(s), for example:

  R = { 1 < 2, 2 > 3, 3 < 4, 4 < 2, ... };

Since we are using computers with a finite memory amount, we use discrete numbers for points & values on axes.

We also should use unambiguous 'position values' for points, not only an 'order relation' specified for these, as well.

One of future features planned for Stitie Space is space transformation(s) & projection(s) on different Cartesian or Non-Cartesian Spaces; this is about transformation, not only visualization in different Space(s).

Distance measuring between points in this/these Space(s) can be defined many ways as well (for example by number of 'hops' in the object graph, or by actual distance between objects when projected on the 'n-dimensional Cartesian Space').

Handling Many Objects at the same Coordinates.

With Recursion of Stitie Space, this can be done easily - a machine with object at coordinates creates Space(s) within, then 'sets up' multiple objects there at proper Coordinates, then concurrently manages interactions both within a Space, between objects in different Spaces within, and between object(s) within with the objects in the 'outer' Space(s).

Therefore Space Transformations can occur from any Space to any other Space, even if this potentially can cause 'collisions' of having multiple objects at the same Coordinates in the 'Result Space'.

Use example.

We can model gravity field around a 'magnet', where increases in 'attraction force' are higher near the magnet, and lose it's magnitude away from the magnet.

We might want to model Space with more dense coordinates near the magnet(s), and more sparse outside - to save the resources.

We might want to use transformation(s) as 'magnet(s)' move(s), using MATEN or/and Prism - Stitie Space's functionalities for transforming Space, or using other available ways as well - implemented already or planned in future.

See also, if You wish or need, ... : Stitie Machine 1.1 'Sunsail', Stitie Machine 1.2 'Satellite', Stitie Machine 1.3 'November Rain', Agile Transformation of Information State.

Esoteric Programming Languages, Funges & Ola AH Programming Language.


An esoteric programming language (sometimes shortened to esolang) is a programming language designed to test the boundaries of computer programming language design, as a proof of concept, as software art, as a hacking interface to another language (particularly functional programming or procedural programming languages), or as a joke.

The use of esoteric distinguishes these languages from programming languages that working developers use to write software.

Usually, an esolang's creators do not intend the language to be used for mainstream programming, although some esoteric features, such as visuospatial syntax, have inspired practical applications in the arts.

Such languages are often popular among hackers and hobbyists.

Usability is rarely a goal for esoteric programming language designers—often it is quite the opposite.

Their usual aim is to remove or replace conventional language features while still maintaining a language that is Turing-complete, or even one for which the computational class is unknown.


A funge is an esoteric programming language which models its programs as metric spaces with coordinate systems (often, but not necessarily, Cartesian) and which execute instructions located at points in their program space by moving an instruction pointer (a position vector which indicates the currently executing instruction) through that space.

Different instructions determine the direction in which the instruction pointer moves, and consequently, the sequence of instructions that is executed.

The current official standard for the behaviour of these programming languages is the Funge-98 specification. This specification is a generalisation of the semantics of the Befunge programming language, which has a two-dimensional toroidal topology.

Languages which adhere closely to this standard, such as Unefunge (one-dimensional) and Trefunge (three-dimensional), are sometimes called funges, while more 'distant relatives' which differ in significant respects, such as Wierd, are referred to as fungeoids.

'Ola AH' Programming Language.

'Ola AH' Programming Language has capability of either following classical programming methodologies, or, with use of Stitie Space, organize instructions to be executed as well as state (data) in the three dimensional space.

It is both practical and esoteric language according to design, with classical & visuospatial state/instruction organization.

i am using esoteric ideas in this a programming language i am creating in two ways:
- by experimenting with code & challenging programming languages' limits,
- by using Buddhist, Hermetic Qabbalah's & Wiccan/Witchcraft's symbolics, that are related with Many Aspects of Spiritual Ways.

i am trying to enter spiritual & esoteric markets as well, adressing the needs of the people for whom spiritual & esoteric ideas are important.

See also, if You wish or need, ... : Esoteric programming language, 'Ola AH' as a 4GL Programming Language.