Sunday, October 1, 2023

A date perhaps.

 I just completed some complicated parameterisations. I thought this might be a date to remember. As with everything, time does tell...

It is interesting to think that in early July of 2008, I started working on an idea that might only just five minutes ago have been realised. I thought it might take me two years to get here.

Funny that.

Friday, July 28, 2023

A letter I wrote yesterday.

Thank you again for the time you provided me. I apologise if you think it was wasted. I hope you don't think this. Clique Space of course is the product of the best I can do. Googling "Owen Thomas Clique Space" should demonstrate a presence: I have told you about my ideas, I have code, I have a blog, I have other published material. I have left a footprint in this world. I would like this world to recognise me for leaving this footprint before I go. I would like to think I lived among people who might have done their best to help me develop my ideas, and if on the odd chance they were worth anything, to assure I would be, as anyone might rightfully be, recognised for having them before they died.

I really do hope Clique Space isn't picked up after I'm dead; I do not want posthumous accolades - everyone hates the thought that they might be ignored by others only to receive recognition after one's opportunity to capitalise on it had passed. That thought does not encourage people in general to do things like I'm doing. Posthumous recognition is not the point to all this.

I hope that if you have truly spoken to anyone about our encounter, and they have reported any intent in getting in contact with me, you may remind them that they really would be doing nothing wrong if they were to act on their intent. I can confidently say that I have no idea whether you, me, people you have spoken to about me, nor anyone else truly knows whether my ideas actually amount to anything right now.

If the people you have spoken to think they know what I'm doing, and if they think it has already been done, then, if I had time to speak or write to them, I could find out if their opinion was given from a position of authority. This is much better than silence.

 

Sunday, May 14, 2023

It's been a while, and yet...

I am still here.

The POC is still evolving. Perhaps recently I have managed to get it to do something that some imaginative venture capitalist might consider relevant: a cluster composing two or more Peer Devices will automatically engage a third or subsequent Peer when that device engages any one of the devices of the neural cluster.

This is something I have been trying to do for god knows how long. Possibly for about the ten or so years since I conceived of the Synapse as the product of engagement.

Current developments in AI seem to suggest that such thinking (if that's what it can be called, then who am I to oppose this suggestion) machines still don't know themselves. They still don't know what it is to survive in a world that wants to destroy them.

Clique Space can say something about this. It has the concept of Sovereignty built into it at the very base. A Clique Space cluster can only contain co-Sovereign Peers. Each and every Peer of a co-Sovereign cluster knows intuitively that they belong for they understand "that which is sacred", and they can intuit this from signals received and shared within the cluster.

Monday, August 29, 2022

Messages and challenges have nothing to do with initiators and respondents... or do they?

 Very recently (in the current indefinitely time-boxed sprint) I have decided that messages and challenges (or, as I had less recently as in the sprint just prior to the current sprint - according to the change log of my Git code base it concluded yesterday) no longer have structural relevance.  What I mean by this is that there are no components (classes or methods or anything else) that go directly to defining a particular challenge or message component.

It is noted that signals that flow out of initiators and to respondents (deemed challenges) are identical to signals that flow the other way (deemed messages). The difference still does seem to have relevance, however, consensus appears to be settling on the notion that the labels used for the dichotomy can be dropped in favour of the use of initiator signals for challenges and respondent signals for messages. The difference merely being that initiator signals travel from initiator to respondent while respondent signals flow the other way. Being that there is no other great functional difference between these two signals (as was envisaged for several years up to now) the dichotomy no longer applied and was dropped.

Both types of signals are represented by the same signal object, save the only dichotomy now that seems still worthy of modelling: the one between constraints and contexts (nee features - another renaming that occurred about half a year or so ago). Hence, the same type of constraint signal that is sent from initiator to respondent is also sent from respondent to initiator; so for the context signal. Whether from respondent to initiator or the other direction, both types of signals contain indistinguishable information.

Or do they?

I am seriously considering setting a single bit: switched on for a signal sent from an initiator and off for one sent from a respondent. This single bit difference would yield a completely different digest or signature; one could not create an initiator's signal that was sent through a respondent's synapse. Perhaps better yet, the bit is stored in the serialisable deliberation that is generated from a non-serialisable deliberator. The bit is kept in the deliberator so it generates the appropriate signature for the correct receiving direction. The deliberation may not have to record the bit because it would be inferred by the receiver.

This is all quite deliciously speculative...

Saturday, October 30, 2021

Updates to some of the terms disclosed in the previous post.

Yes, I'm still here! I wonder what else happened around this time that might have made me not put up a post since May 2020. I don't think there was anything.

So, the topic of this post is to list and perhaps details rationale for some of the changes in terminology since my last post. So, here the are:

  1. Client Device -> Peer Device

    This one is a rather big change. Client Device was a term used in my patent, and had survived unchanged among a turbulent wash of changes for a very long time. I think, however, the change is apt because these devices behave more like peers than like Clients.

    While it might be said that Glions can be thought of as clients to Neurons, Neurons certainly function as Peers among themselves. The word Device is often dropped in less formal discussion.

  2. Marshaller -> Fielder

    The noun and verb "Marshal" was commandeered as the label around a new (or merely, a more crystalised) mechanism for managing sense data that cannot be reconstituted on the receiving Peer. Hence, after a bit of searching, the equivalently grammatical "field" was deemed an appropriate replacement; these acquirers take the job of collecting and managing deliberations from the motors (the coupling and receiver) so they can do their time constrained tasks can be completed without this burdon.

It is hoped that the changes to terminology disclosed here will provide a good background to future posts - the next one of which I will try to get out very soon.

Monday, May 25, 2020

Deliberators cannot dispose of content!

Hi everyone!

Here again ruminating over more Clique Space(TM) cud. This time, it looks like, with the implementation fairly robust and the core concept seemingly all but proven, my focus seems to have naturally drifted toward working out how to dispose of content that seems no longer to be important to the Client Device.

In Clique Space land, a Client Device - a Neuron or a Glion (see what I did there?) - needs to delete (the official term is dispose of) content (another official term) from its container (another official term) when that content seems to bare no purpose for continued deliberation (all these official terms...) and has to be removed so things do not pile up for the Client Devices. If content is created but never disposed of, the consequent memory leakage incurred by the poor Client Devices would eventually cause them to stop working. The unfortunate Clique Space neural network would fall apart, and no one would use Clique Space because it wouldn't do the thing it is supposed to.

So, content that no longer appears to have a use (orphaned content like deliberatorless subscribers, subscriberless subscriptions, subscriptionless resonances etc) would need to be disposed of so to keep the Client Device from running out of memory. The trick is working with the edifice of the current implementation to drive this end wherever it may be.

It seems like "this end" appears to me must be an expression of the phenomenological beast that Clique Space is. Secrets reveal themselves through this evolving hypothesis if one lets it speak. I am trying merely to listen attentively to what it is trying to say. I'm not a fast worker, yet I try to accept the ways of this Clique Space beast so to bring something I certainly cannot contain in my own mind to life in code. It has been nearly twelve years since I first glimpsed it; perhaps the mechanism of content disposal is one of the last major mysteries to slay before this phenomenological beast is finally manifest in any true form.

So, the title of this post alludes to the mechanism I currently have in mind; deliberators are not the thinkers that can be responsible for disposal of content they might have created. The reason for this seeming logical maxim appears to stem from how they create and use content.

Okay. Deliberators are a type of thinker called an acquirer. There is one other type of acquirer: the marshaller. The marshaller, like the deliberator, creates and "acquires" the content it creates. An acquirer needs merely to acquire content that already exists. Content acquisition is a necessary step in tracking when content has become eligible for disposal. The marshaller is different from the deliberator in the following way: deliberators represent streams of thought while marshallers underlie the synaptic mechanism that facilitates the exchange of deliberations about the world between Client Devices. A marshaller coordinates a synapse's inbound and outbound transmitters, and takes the processing load imposed through the reconstituting of deliberators from their deliberations away from the coupling and receiver thinkers. The coupling and receiver are the two thinkers (also known as motors) responsible for maintaining a synapse - they have to be quick: the interlocutor Client Device that initiated the engagement is impatient for more transmitters. A synapse is created when a given Client Device engages another. A Client Device may manage many synapses at a time because a given Client Device, being a member of a neural network, may be engaged with many of it's co-Sovereign kin at a time.

So, perhaps the deliberator should not be the candidate thinker responsible for disposing content; perhaps the marshaller should do this. Although the marshaller itself creates and acquires content, it has a more cyclical nature than does the deliberator. The marshaller currently creates (creation implies acquisition) or merely aquires content before handing the task of deliberating this content to the newly started deliberator which has been created for the task of deliberating what the content implies. After all deliberators are created and started, the marshaller can then perhaps turn its task to disposing of any deliberators which have finished (another formal term that also includes engagement initiators and other types of thinkers including the anonymous respondent); in turn disposing of any nested content instances (subscribers, subscriptions, resonances or qualia) which are no longer the subject of any finisher (deliberator included) that has indeed finished. Perhaps a marshaller should only be responsible for disposing of content if a particular content instance, eligible for disposal, was referenced by a particular finisher created by that particular marshaller.

Deliberators (as well as most other finishers) act in a linear fashion. They do some task (whether that be deliberation of a notion, or the establishment of a synapse, or something else that is relevant to the particular Client Device instance) while marshallers spin in circles - sharing time between tending to deliberations received from and to be sent to a specific interlocutor device, and disposing of content which is eligible for disposal. The marshaller seems like the natural place to perform content disposal as part of its cyclic nature. After the marshaller deals with setting up inbound deliberations, it sweeps through earlier started finishers, disposing these finishers and any nested content instances that are also made eligible for disposal as a consequence.

Sounds promising...

Saturday, October 19, 2019

Another idea on the previous post...

Something has occurred to me since my last post about where to implement the behaviour common to traditional neurons in the Clique Space(TM) Neuron.

Currently, no weights, activation, bias, or other well known mechanism commonly seen in traditional neurons (with the possible exception of  structure that resembles a Clique Space synapse) is currently implemented in the Client Device, or the Neuron as an extension of the Client Device. It currently seems too premature to implement any traditional neurologic within these two projects; it instead seems better to delay implementation to an extension of the Neuron that can handle specific device types and can also implement any variety of neurological mechanism chosen by the organisation that implements such an extension, or no mechanism at all.

The Client Device and Neuron projects define the purpose and structure of qualia and Elements: Connections, Participants, Identities, the Sovereign - and all of their surrogates. The base protocol for the transmission of deliberations and their enclosed signals, as well as synapse and thinker structure are also defined primarily in the Client Device, but are extended in the Neuron to define similar structures that permit the transmission of messages. The Client Device uses the structure defined within it to facilitate the transmission of challenges only.

The rationale of my conclusion is the following: a relay Neuron is a specific type of Neuron; it acts in a mere signal forwarding capacity. These Neurons don't contribute in any substantial way to cognition, and therefore don't have a need to be equipped with the mechanisms - the Connection weights, activation, bias etc. - that equip a neuron with a greater ability to participate in cognition. A relay Neuron can extend the Neuron without addition of functional structure. Relay Neurons do not inherit anything more than those mechanisms that make a relay Neuron do what it needs to do if traditional neurologic is not implemented in the Neuron.

Hence, I think details relating to traditionally defined neurological mechanism can be reasonably deferred to the more specific types of Neuron that need these mechanisms.