Stitie Space, Form & Emptiness.

'Stitie Space' is a 3D Objects Matrix data structure, has certain unique 'convenience methods' that allow for a 'fine manipulation of objects' in 'computer memory', a space to be filled with numbers in itself, perhaps ...

Stitie Space is non-infinite, bounded Space that has convenience method to invoke Forms within.

Using MATEN functionality, a Certain Form Invocation, we can invoke Empty or
Non-Empty Forms within Stitie Space.

Using MATEN or Prism functionalities Forms in Space can change with time, we can have 'animation of objects' as well.

Stitie Space can use recursion, each of it's inner coordinates can contain 'Inner Space' as well - we can use GRID Computing for that as well, for example.

While Stitie Space 1.1 'Sunsail' has stationary machines at given coordinates, with Stitie Space 1.2 'Satellite' it's possible to move machines within, use gaps in space (without machines at coordinates), there's an option of long-range communication between machines as well.

Simple Examples & Professional Practices.

When one tries to learn something, it's worth to start from something simple, from a little of theory & from a simplest of examples.

Complex examples make things harder to understand.

There's the difference between learning something simple by an example and between producing professional & optimal code.

Both in technical books, as well as on Universities - teachers teach one problem solution at a time, using knowledge taught & practiced earlier by students as well.

Professionals still strive for simplicity, for creating 'objects' that handle their responsibilities - their tasks - as elegantly, as shortly & as concisely as possible.

But professionals know much, use advanced tools & known theories to handle the programming eloquently & optimally.

Objects interrelations make code more complex, it's often better to make things work together, best from a perspective of whole groups of objects collaborating - instead of simplifying their behaviors to simplest behaviors considering each of objects in separation of other objects.

Walking one dog is far different than handling a sleigh with a twelve husky hounds afterall.


A Simple Checksum Calculation & File Encryption Code.


If we have a file, we can calculate it's checksum according to a given algorithm.

A checksum calculation algorithm can use a password or a key, to enhance security.

File can be a message or data or even software that can be run. Checksumming is not encryption to hide file's contents, it's just for decreasing a chance that a file was tampered during transmission - either by infrastructure fault, or by an attack.

Unless cracked, even a simple checksum can help to protect data integrity, protect the information to increase certainty of:
- Message's Sender,
- Message's Recipient,
- Message's Timestamp & Timezone,
- Message's Title - if any,
- Message's Conent & Attached Data - if any,
- Message's Additional Information & Metadata.

There's more to this as well.

It's related with Secure Communication over the Internet.


i am planning to write a checksum code & encryption code as an exercise & for use by me and for use for those who care.

It's unfinished a post, will complete a source code later - as soon as i can.

For now it's an incomplete: a top-down algorithm, a plan for code in comments to be filled with details later. i find that a simple planning method useful in Programming anyway - even a code consisting only of comments is useful in the development process - especially if the comments are strict, with invariants, etc ... - but not only.

i've used a 'checksum' word in an abstract way - it's not only summation, it's also other functions. Probably i should use a 'signature' word instead ;)

Optimistically, a chance of two checksums colliding equals to (1/Long.MAX_VALUE) = 1/(263 − 1) = 1/9,223,372,036,854,775,807. Probably in practice it's less favourable for us, but still very good.

Exact worst probability is very hard to calculate for me - but i can say it depends on: a file transferred, a password, an optional key. Using long & varied-inside files (preferably encrypted) as well as using a long private key makes for things in our favour (less collisions).

import java.util.List;

* @author Andrzej 'neo-mahakala-108' Wysocki; email: neomahakala108@gmail.com
public class ChecksumCalculator {
  // TODO: replace with a string read from a file.
  private String inputText = "a test string.";

  // TODO: replace with a string read from a file.
  private String optionalKey = "an optional key";

  // TODO: get password from user instead of using a hard-coded one.
  private String password = "a test password";

  public static void main(String[] args) {

    // 1. Find a checksum calculation function.
    // depending on a password/optional-key - we'll have a lot of simple functions & we'll
    // make a complex function from these. password/optional-key will determine how we'll
    // combine our simple functions into a complex function.

    // 2. Find constants.
    // each of 'data chunks' is a part of the message, number of these depends on
    // a password, an optional key & a message to checksum. we'll use a simple
    // function, derived from a password/optional-key that will transform these
    // strings into a long number constants.

    // 3. Calculate a checksum.
    // we'll use a checksum calculation function with found consant, to calculate a long
    // checksum.

    // 4. Provide a checksum result to user.

  // ...

  private long sumWrapFunction(List<Long> ll) {
    long result = 0;
    for (long current : ll) {
      // we don't care for exceeding Long.MAX_VALUE - it's still a long number.
      result += current;
    return result;