It may all be bullshit, but thoughts over the past two days have led me down what I observe is an interesting garden path concerning the components of a Clique Space(TM) neural network and how a participating Neuron might conceive of itself and its neighbourhood.
Traditionally, a neuron shares physical connections with a subset of its neighbours. Each of these physical connections is assigned a weight and any given connection is assigned a value for its weight based on a process of "learning". That has always appeared as a reasonable if not abridged overview of the neural way things are generally known in this world.
I feel that I can give a slightly different slant on the above view. Clique Space is no different from this view in that Neurons indeed share similar physical connections (synapses) with a subset of their brethren; each connection is indeed realised through an algorithmic structure known as a synapse. However, what is slightly different is the following: weights are not assigned to synapses.
A Clique Space Client Device (a Neuron is a type of Client Device) is identified individually by a Connection. Connections are Elements which contain one or more features that are expressed by Participants (also Elements) which are members of Cliques. Cliques denote some cooperative endeavour is being undertaken. Synapses are a type of bipartite Clique which models the engagement of two Client Devices through the "this Element" feature of their individual Connections.
While a Client Device may not share a synapse with every one of its cohorts, it can still be aware of every Connection that makes up the entire population. Weights are assigned to the Connections known to a Neuron to represent other Neurons - even those Neurons with which the host Neuron doesn't share a synapse directly. Now, I think at this moment, there is an opportunity to do something
rather useful with this knowledge; something that uses another structure
developed over the past 11 years I have been working on my
proof-of-concept. This something appears to me to advance the
traditional connectionist model of neurons. Instead of assigning a weight to a synapse, weights are assigned to Connections.
A deliberator is a thinker (a type of Java thread) which is created to deliberate the arrival of a deliberation. Deliberators are associated with the Connection assigned as the first Neuron (actually Client Device but we will not split hairs here) to have entertained the topic being deliberated. Now, getting hypothetical, the wonderful thing about creating deliberators in this way is that a group of deliberators may be created to represent receipt of deliberations sent from neighbouring Neurons all of which are received at around the same time. Apart from the difference in originator, each deliberator is cogitating the same topic and hence each deliberator is constructed to have a identical parameters such as activation and bias because all deliberators are instructed by the same feature.
Accumulation of Connection weights for deliberators on this same topic may cross a threshold which when reached will cause the deliberator on which the threshold was crossed to send deliberations through synapses to its neighbours. Some neighbours may share synapses and may receive the deliberation immediately and others may only receive the deliberation through a neighbour who has faithfully passed the deliberation on.
This is all done by assigning weights to the Connections instead of to the synapses. I think that is a big deal, and an advancement in neuroscience that was published in this blog entry before anyone else in this world knew that assigning weights to representations of nodes in a Neuron's knowledge of its neural neighbourhood would be better than assigning them merely to the physical connections it would share with its neighbours.
This mechanism, and more as would answer most other questions about my concept is all there in my code. Really, it is... almost. I'm sitting on the greatest advancement in neuroscience since the perceptron!
Friday, October 18, 2019
Friday, September 20, 2019
Identity and Sovereignty
This post is more or less and addendum to my post on Sovereignty Demystified in that everything explained in this earlier post except the association between a Connection and its property of sovereignty still applies.
In Clique Space, sovereignty is a feature only of the Identity Element. Sovereignty is never communicated directly between Client Devices, but one device can work out if an Identity informed to it by a neighbouring device is indeed sovereign when it receives an Identity's key feature. The given Identity is sovereign when the Identity can be used to generate the same public key that was given as the key in the feature. In this case, the corresponding public/private key pair are stored as a CoSovereignKey in the given Identity.
A Client Device can use an Identity with a non-null CoSovereignKey (a sovereign Identity) to sign deliberations that it generates when informing other Client Devices of subscriptions. Subscriptions are associations between a given feature Element, qualia known as the sense datum and the subject, and a given subscription tag - either an Identity if the subscription is a challenge, or a belief (an association between two Identities - the claimant and the candidate) if the subscription is a message.
Because an Identity has to be sovereign to contain a private key, sovereign Identities are the only type of Identity capable of generating signatures for deliberations.
Sovereignty encompasses an individual's concept of self-hood. Identity is a projection of this self-hood within an individual's manifest Clique Space and outward to Clique Spaces that manifest other individuals.
In Clique Space, sovereignty is a feature only of the Identity Element. Sovereignty is never communicated directly between Client Devices, but one device can work out if an Identity informed to it by a neighbouring device is indeed sovereign when it receives an Identity's key feature. The given Identity is sovereign when the Identity can be used to generate the same public key that was given as the key in the feature. In this case, the corresponding public/private key pair are stored as a CoSovereignKey in the given Identity.
A Client Device can use an Identity with a non-null CoSovereignKey (a sovereign Identity) to sign deliberations that it generates when informing other Client Devices of subscriptions. Subscriptions are associations between a given feature Element, qualia known as the sense datum and the subject, and a given subscription tag - either an Identity if the subscription is a challenge, or a belief (an association between two Identities - the claimant and the candidate) if the subscription is a message.
Because an Identity has to be sovereign to contain a private key, sovereign Identities are the only type of Identity capable of generating signatures for deliberations.
Sovereignty encompasses an individual's concept of self-hood. Identity is a projection of this self-hood within an individual's manifest Clique Space and outward to Clique Spaces that manifest other individuals.
Tuesday, July 23, 2019
How's this Clique Space(TM) thing going?
I'm still here. I'm venturing a comment that Clique Space is continuing, and it just now appears to me that I have perhaps resolved most of my concerns around the question of symmetry between challenges and messages.
Challenges - sent from initiator to respondent, represent queries asked by a specific device and on behalf of a specific Identity known as the respondent for information about quale associated with a specific resonance.
Messages - set from respondent to initiator, represent the state of a specific device which is associated with a pair of Identities (a belief - one is the claimant or the Identity making the claim, the other is the candidate or the Identity about which the claim is being made) associated with a specific resonance.
Challenges - sent from initiator to respondent, represent queries asked by a specific device and on behalf of a specific Identity known as the respondent for information about quale associated with a specific resonance.
Messages - set from respondent to initiator, represent the state of a specific device which is associated with a pair of Identities (a belief - one is the claimant or the Identity making the claim, the other is the candidate or the Identity about which the claim is being made) associated with a specific resonance.
Friday, March 22, 2019
So, tell everyone what's been happening with this Clique Space(TM) thing of mine...
Well might you ask...
Neurons appear to do almost everything a Neuron of any type is supposed to do. The relay Neuron, (I used to call these naked Neurons on account of the fact that they implement nothing more than the basic Neural implementation) seem to work fine on my laptop. Instances of relay Neurons are started in separate JVM's so each Neuron exists as a separate process.
The Java sockets API regards each process as being "out there" in a world completely separate from each other. They must communicate using TCP/IP socket connections, and hence, when (or if) I do get to run Neurons (or Client Devices more generally) on separate physical devices, there should be little more work needed on the core Clique Space concept; everything should be about extending the core concept to capture the specific nature of the host device.
With my most recent commit, I think I have worked out the process that allows the life cycle of quale and other content to be managed.
Content? Other content? Well, yes, as it turns out, all content has a container, and these containers must be managed in a way that prevents deadlock. Indeed, I think I have solved this with a simple anonymous inner class (something that can perhaps be re-implemented as a lambda) called a keeper.
Content and containers are an abstraction: keepers are used to lock containers before access and ensure that any content retrieved or created is not disposed until the current thinker - instances of Java threads used throughout the Clique Space code - has finished with it. A Keeper can only be used to create or retrieve a single content instance. The keeper's container (and no other container) must be the container that is accessed.
A thinker uses a keeper to lock the container before it acquires the content, and then releases the container for the next keeper. Thinkers manage a stack of keepers. This stack allows the thinker to release content in the reverse order in which it was acquired so content can be disposed of in an orderly way. A thinker can only access a container to add or get its content when it has a keeper that is ready to acquire an instance of its container's content; a keeper cannot be used after it has already acquired content.
Quale are content to quale containers; a Neuron (a Client Device more generally) manages a single quale container. Subscribers are content to subscriptions; a subscription is also a type of quale and subscriptions are accessible from features. Deliberators are content to subscribers; apart from expressing the characteristics of both content and container, subscribers are nothing else. Deliberators are a type of thinker; they process (they deliberate) what should follow when a signal is received from another Client Device.
Deliberators behave in accordance with the instructions given in the implementation of the methods used to deliberate messages or signals internally for a given feature. Features and Connections are some of the extensible components of the Clique Space concept. These components give an individual the ability to transmit and control the state of a device within Clique Space.
I wonder if anyone else will take notice of this before I'm dead? I wonder if there indeed is anything to take notice of? I'll be pleasantly surprised if there is. I'll wait to be pleasantly surprised only until I die, and then I won't care.
Neurons appear to do almost everything a Neuron of any type is supposed to do. The relay Neuron, (I used to call these naked Neurons on account of the fact that they implement nothing more than the basic Neural implementation) seem to work fine on my laptop. Instances of relay Neurons are started in separate JVM's so each Neuron exists as a separate process.
The Java sockets API regards each process as being "out there" in a world completely separate from each other. They must communicate using TCP/IP socket connections, and hence, when (or if) I do get to run Neurons (or Client Devices more generally) on separate physical devices, there should be little more work needed on the core Clique Space concept; everything should be about extending the core concept to capture the specific nature of the host device.
With my most recent commit, I think I have worked out the process that allows the life cycle of quale and other content to be managed.
Content? Other content? Well, yes, as it turns out, all content has a container, and these containers must be managed in a way that prevents deadlock. Indeed, I think I have solved this with a simple anonymous inner class (something that can perhaps be re-implemented as a lambda) called a keeper.
Content and containers are an abstraction: keepers are used to lock containers before access and ensure that any content retrieved or created is not disposed until the current thinker - instances of Java threads used throughout the Clique Space code - has finished with it. A Keeper can only be used to create or retrieve a single content instance. The keeper's container (and no other container) must be the container that is accessed.
A thinker uses a keeper to lock the container before it acquires the content, and then releases the container for the next keeper. Thinkers manage a stack of keepers. This stack allows the thinker to release content in the reverse order in which it was acquired so content can be disposed of in an orderly way. A thinker can only access a container to add or get its content when it has a keeper that is ready to acquire an instance of its container's content; a keeper cannot be used after it has already acquired content.
Quale are content to quale containers; a Neuron (a Client Device more generally) manages a single quale container. Subscribers are content to subscriptions; a subscription is also a type of quale and subscriptions are accessible from features. Deliberators are content to subscribers; apart from expressing the characteristics of both content and container, subscribers are nothing else. Deliberators are a type of thinker; they process (they deliberate) what should follow when a signal is received from another Client Device.
Deliberators behave in accordance with the instructions given in the implementation of the methods used to deliberate messages or signals internally for a given feature. Features and Connections are some of the extensible components of the Clique Space concept. These components give an individual the ability to transmit and control the state of a device within Clique Space.
I wonder if anyone else will take notice of this before I'm dead? I wonder if there indeed is anything to take notice of? I'll be pleasantly surprised if there is. I'll wait to be pleasantly surprised only until I die, and then I won't care.
Wednesday, January 2, 2019
How done might we be if the deliberator and the subscriber are combined?
The subject of this post is the consideration that marrying the subscriber and the deliberator into a single class is a good idea.
I actually think I might have stumbled upon the tail of this idea. I recall momentarily perceiving that it might be necessary a year ago. I was trying to implement the mechanism that helps a Client Device reconstitute as qualia information contained in a transmitter and I remember scaring myself with a very similar set of thoughts I am having now. It appears to me now that perhaps I just wasn't ready to follow this idea at that time; marrying the deliberator mechanism (a type of thinker - a Java thread used throughout the implementation) with the mechanism being considered looked so ambitious at the time that it induced some distraction.
However, the reconstitution mechanism has been stable for some time now, so I think it's now worth to go back and follow a garden path that earlier expediency had caused me to avoid. Hence, I should consider merging the subscriber and the deliberator; it might perhaps complete the implementation of the core concept... or it will merely open up other questions about the core concept that were off in the thicket of enquiry hitherto. In any eventuality, combining the deliberator and subscriber appears to be a very attractive proposition at this point in time.
This all looks to be quite a substantial unit of work unto itself, so I should perhaps obtain a clean working copy of my code before embarking. I'll do that later this afternoon. For now, I'll let these ideas steep for doing this might soften the trauma of implementing them.
I actually think I might have stumbled upon the tail of this idea. I recall momentarily perceiving that it might be necessary a year ago. I was trying to implement the mechanism that helps a Client Device reconstitute as qualia information contained in a transmitter and I remember scaring myself with a very similar set of thoughts I am having now. It appears to me now that perhaps I just wasn't ready to follow this idea at that time; marrying the deliberator mechanism (a type of thinker - a Java thread used throughout the implementation) with the mechanism being considered looked so ambitious at the time that it induced some distraction.
However, the reconstitution mechanism has been stable for some time now, so I think it's now worth to go back and follow a garden path that earlier expediency had caused me to avoid. Hence, I should consider merging the subscriber and the deliberator; it might perhaps complete the implementation of the core concept... or it will merely open up other questions about the core concept that were off in the thicket of enquiry hitherto. In any eventuality, combining the deliberator and subscriber appears to be a very attractive proposition at this point in time.
This all looks to be quite a substantial unit of work unto itself, so I should perhaps obtain a clean working copy of my code before embarking. I'll do that later this afternoon. For now, I'll let these ideas steep for doing this might soften the trauma of implementing them.
Saturday, November 17, 2018
Sovereignty demystified.
I am about to commit some significant changes to my current working copy: local branch master checksum ID of 402ba642a6. Central to Clique Space(TM - although this link to a blog entry published in late June of 2012 is showing its age) is this thing I call the Sovereign. The changes I talk about here implement the the Sovereign's prime purpose.
If one wants to design a system that could potentially act as a medium through which individuality can be projected if not also manifest, the notion of individuality would have to be well defined and delineated. This had been a prime necessity that mothered the concept's invention way back in 2004. Back then I had only the most incidental of notions (I knew it would involve digital signatures created from something that would never be transmitted between Client Devices) of how this feat would be pulled off.
The fact in 2004 was that there was so much about the mechanism of Clique Space that was opaque to my intellect - so much that I could not hold in my mind that I had to start implementing it before I could figure out all of the concept's subtleties. I could see that although the data model (thrashed out a little before publication in the patent of 2008) disclosed the possibility of realisation of the concept, more than fourteen years of deliberation had to be endured before the question of sovereignty could be approached in any substantial way. Sovereignty is the central notion for Clique Space - a notion without which Clique Space would simply not make sense.
The patent first published in January of 2008 used the name Account. At that time, and although the notion of delineating that which was and was not self was considered important, these notions were still a very nascent. As the years advanced and the concept evolved (through terms such as "Repropsyche"... don't know what I was on there, "Absurdum"... indeed I must have been losing hope at this point, and Axle ... a name I trialled because I began to understand how truly central this Element would be), I settled on Sovereign. This fact was disclosed in a blog entry made in December of 2012.
The something that is never transmitted has evolved to become what I now call "that which is sacred". I take this to note that if there is a way to introduce quasi-religious terms into one's software, then this, as far as I can tell, appears to be it. It appears to be a systematic formalisation of the necessary ideal of the sacred, monopolised by religion for most of human experience hitherto, to make manifestation possible. Perhaps this feature is also responsible for inspiring religion in those who are manifest... who knows? I'm no believer, but I find the intersection I appear to have to navigate in Clique Space to be curious.
That which is sacred is stored in a Client Device as a message digest of something that can be input to a digest algorithm. I have used SHA1 in the implementation, but have noted to myself that this algorithm has weaknesses that render it unsuitable for general use. The SHA1 algorithm has proven convenient for my implementation. That which is sacred is never disclosed between Client Devices; it is something that is probably known to the manifest individual (it would certainly serve the interests of the manifest individual to know what it is), but is certainly not known to anyone else because shared knowledge of this value could render the subject vulnerable to a breach of their sovereignty.
The Identity, like the Sovereign, is a component (an Element as stipulated in the patent) that has survived from the concept's genesis, although it too was renamed from the less poetic Active Affiliation. Identities are used to project one's presence onto things in the world. Identities are known as identified Elements because Identities (as well and Participants) are identified by a 20 byte string known as an identifier. It was the coincidence between the length of the identifier and the length of an SHA1 digest that motivated me to use SHA1 while implementing the proof-of-concept; it wouldn't be much work at all to change the length of the identifier when another algorithm is selected, but I decided it was too much work for me to worry myself about now.
The Identity's identifier is combined with that which is sacred using a bitwise exclusive-or operation. This yields an input to the SHA1 pseudo-random number generator which is used to generate a key pair. The private and public keys are assigned to a structure known as a co-Sovereign key, and this key is stored inside the Identity instance. The presence of a co-Sovereign key inside an Identity instance signifies to the Client Device that the given Identity is a Sovereign Element.
Another structure known as a contra-Sovereign key, containing only the public key, is created. This structure is stored as a quale which is assigned to the Identity's key property and communicated inside transmitters between co-engaged Client Devices over synapses formed by the process of engagement. The mechanisms that permit all of this were designed and constructed after the patent was published, as part of the fourteen year journey in the wilderness of concept's development thus far. There are plenty of previous blog entries to regale the interested reader.
A Client Device that receives an Identity key's surrogate will reconstitute the quale and assign the quale to the Identity key's property under a new disclosure if this is indeed a new disclosure. If a new disclosure instance is added to the property, the Client Device will compute a presumptive co-Sovereign key for this Identity. If the public key of this (currently presumptive) co-Sovereign key matches the public key of the disclosed contra-Sovereign key, the co-Sovereign key is stored within the Identity instance; the quality of sovereignty has been proven to be actual and not merely presumptive.
Hence, an Identity's Sovereign Element status can be communicated between two Client Devices. In a similar way, Connections also have sovereignty in that Connections represent Client Device communication access points. A Sovereign Connection represents a co-sovereigned Client Device or rather a unit of mechanism that manifests a particular individual known as the Sovereign to both devices. A biological neuron is an instance of the mechanism of cognitive function in a similar way that a similar machine is an instance designed with the purpose of participating in cognition as a Clique Space aware Neuron (an instance of a subtype of Client Device). A Connection represents an individual Client Device (or perhaps merely one way of contacting one Client Device - one Client Device could have more than one Connection) so activities like synapse formation in Clique Space can occur.
It's all going well. I think my concept is demonstrable to those who might be able to understand its function and can see its application while a practical demonstration of an application is still a ways off. Perhaps I'll find someone who will see Clique Space for what it can promise. Perhaps some day soon.
This is my 200th blog entry.... yay! Two hundred blog entries (most of which appear to have been made in 2010 - 2013 because I was doing a lot of "heavy duty thinking" back then) in over nine years!
If one wants to design a system that could potentially act as a medium through which individuality can be projected if not also manifest, the notion of individuality would have to be well defined and delineated. This had been a prime necessity that mothered the concept's invention way back in 2004. Back then I had only the most incidental of notions (I knew it would involve digital signatures created from something that would never be transmitted between Client Devices) of how this feat would be pulled off.
The fact in 2004 was that there was so much about the mechanism of Clique Space that was opaque to my intellect - so much that I could not hold in my mind that I had to start implementing it before I could figure out all of the concept's subtleties. I could see that although the data model (thrashed out a little before publication in the patent of 2008) disclosed the possibility of realisation of the concept, more than fourteen years of deliberation had to be endured before the question of sovereignty could be approached in any substantial way. Sovereignty is the central notion for Clique Space - a notion without which Clique Space would simply not make sense.
The patent first published in January of 2008 used the name Account. At that time, and although the notion of delineating that which was and was not self was considered important, these notions were still a very nascent. As the years advanced and the concept evolved (through terms such as "Repropsyche"... don't know what I was on there, "Absurdum"... indeed I must have been losing hope at this point, and Axle ... a name I trialled because I began to understand how truly central this Element would be), I settled on Sovereign. This fact was disclosed in a blog entry made in December of 2012.
The something that is never transmitted has evolved to become what I now call "that which is sacred". I take this to note that if there is a way to introduce quasi-religious terms into one's software, then this, as far as I can tell, appears to be it. It appears to be a systematic formalisation of the necessary ideal of the sacred, monopolised by religion for most of human experience hitherto, to make manifestation possible. Perhaps this feature is also responsible for inspiring religion in those who are manifest... who knows? I'm no believer, but I find the intersection I appear to have to navigate in Clique Space to be curious.
That which is sacred is stored in a Client Device as a message digest of something that can be input to a digest algorithm. I have used SHA1 in the implementation, but have noted to myself that this algorithm has weaknesses that render it unsuitable for general use. The SHA1 algorithm has proven convenient for my implementation. That which is sacred is never disclosed between Client Devices; it is something that is probably known to the manifest individual (it would certainly serve the interests of the manifest individual to know what it is), but is certainly not known to anyone else because shared knowledge of this value could render the subject vulnerable to a breach of their sovereignty.
The Identity, like the Sovereign, is a component (an Element as stipulated in the patent) that has survived from the concept's genesis, although it too was renamed from the less poetic Active Affiliation. Identities are used to project one's presence onto things in the world. Identities are known as identified Elements because Identities (as well and Participants) are identified by a 20 byte string known as an identifier. It was the coincidence between the length of the identifier and the length of an SHA1 digest that motivated me to use SHA1 while implementing the proof-of-concept; it wouldn't be much work at all to change the length of the identifier when another algorithm is selected, but I decided it was too much work for me to worry myself about now.
The Identity's identifier is combined with that which is sacred using a bitwise exclusive-or operation. This yields an input to the SHA1 pseudo-random number generator which is used to generate a key pair. The private and public keys are assigned to a structure known as a co-Sovereign key, and this key is stored inside the Identity instance. The presence of a co-Sovereign key inside an Identity instance signifies to the Client Device that the given Identity is a Sovereign Element.
Another structure known as a contra-Sovereign key, containing only the public key, is created. This structure is stored as a quale which is assigned to the Identity's key property and communicated inside transmitters between co-engaged Client Devices over synapses formed by the process of engagement. The mechanisms that permit all of this were designed and constructed after the patent was published, as part of the fourteen year journey in the wilderness of concept's development thus far. There are plenty of previous blog entries to regale the interested reader.
A Client Device that receives an Identity key's surrogate will reconstitute the quale and assign the quale to the Identity key's property under a new disclosure if this is indeed a new disclosure. If a new disclosure instance is added to the property, the Client Device will compute a presumptive co-Sovereign key for this Identity. If the public key of this (currently presumptive) co-Sovereign key matches the public key of the disclosed contra-Sovereign key, the co-Sovereign key is stored within the Identity instance; the quality of sovereignty has been proven to be actual and not merely presumptive.
Hence, an Identity's Sovereign Element status can be communicated between two Client Devices. In a similar way, Connections also have sovereignty in that Connections represent Client Device communication access points. A Sovereign Connection represents a co-sovereigned Client Device or rather a unit of mechanism that manifests a particular individual known as the Sovereign to both devices. A biological neuron is an instance of the mechanism of cognitive function in a similar way that a similar machine is an instance designed with the purpose of participating in cognition as a Clique Space aware Neuron (an instance of a subtype of Client Device). A Connection represents an individual Client Device (or perhaps merely one way of contacting one Client Device - one Client Device could have more than one Connection) so activities like synapse formation in Clique Space can occur.
It's all going well. I think my concept is demonstrable to those who might be able to understand its function and can see its application while a practical demonstration of an application is still a ways off. Perhaps I'll find someone who will see Clique Space for what it can promise. Perhaps some day soon.
This is my 200th blog entry.... yay! Two hundred blog entries (most of which appear to have been made in 2010 - 2013 because I was doing a lot of "heavy duty thinking" back then) in over nine years!
Sunday, July 29, 2018
Naked Neurons, other types of Neurons.
It's been a while since my last post. I'm still alive; I'm still doing this thing I call Clique Space(TM).
This evening, I feel somewhat relaxed. I have a working copy (only a little more than two weeks' old) still to be committed to my code base. This working copy is the first revision where I have moved the main method out of the Neuron and into two new projects. The first is called the "Naked Neuron", and the second, the "Clothed Neuron". The first represents an ongoing specialisation of the Neuron, while the second is somewhat of a hypothetical (even rather useless) specialisation of the Neuron so that I can conduct further tests on the efficacy of the Client Device project more generally. My motivation for writing tonight came from an observation that perhaps I see a reasonably stable implementation of the way in which Neurons can be specialised.
Apart from the fact that Neurons can contribute fully in cognition (glia are denied this privilege because they cannot engage their neighbouring Neurons as respondents), a naked Neuron has no capacity to do anything else. A naked Neuron can act as nothing more than a relay between otherwise clothed Neurons who may not share a direct engagement. Naked Neurons know how to communicate in Clique Space as initiators and respondents, but have no other ability; apart from Clique Space itself, a naked Neuron has no capacity to contribute to "thinking" by virtue of the fact that naked Neurons do not model any other medium.
Clique Space acquires a thinking capacity because some Neurons can be specialised: some can perhaps be made to respond to photons hitting them; some can be made to contract like muscles; some can, when stimulated by other Neurons, perhaps produce some sensations that yet other Neurons specialised in some other way can react to. Glia (I cannot consider a naked version of these ever to make sense) can be specialised to maintain a nice environment for themselves and their Neural brethren. They can perhaps help by dilating nearby nutrient vessels when they detect their neighbouring Neurons undergoing heavy cognition, or perhaps glia help speed signal flow by enclosing the axons of their Neural neighbours in a sheath of myelin.
A Clique Space Neuron software implementation can be specialised by extending the inbound Connection class (NeuralInboundConnection) exposed as an abstract class in the Neuron project. This class can be extended to capture stimuli that are generated though some other medium present on the specialised Neuron's host hardware. These stimuli must be recorded as qualia - the units of cognition - that must also be accompanied by instances of a surrogate - a serialisable proxy of a quale - so qualia related to a given stimulus can be sent as a signal from one Client Device to be reconstituted as quale in another. Signals are individually wrapped in envelopes, and collections of envelopes are bundled in transmitters before transmitters are exchanged as part of a synapse's activity cycle.
A property also needs to be created and stored (usually) as a native property of the extended version of the inbound Connection. This property allows a Neuron to form and communicate a belief that a particular stimulus (the object - perhaps associated with a sense datum quale different to the object quale) has been received by the a given Neuron, and is being asserted by a given Identity.
This very quickly put together summary of Clique Space constitutes a semantically rigid language of thought that I have no reason not to believe would ultimately derive of a synthetic mechanism the ability to exist.
Perhaps... I have no idea really and odds on this is probably bullshit. Even so, it appears to have worked for me so far.
This evening, I feel somewhat relaxed. I have a working copy (only a little more than two weeks' old) still to be committed to my code base. This working copy is the first revision where I have moved the main method out of the Neuron and into two new projects. The first is called the "Naked Neuron", and the second, the "Clothed Neuron". The first represents an ongoing specialisation of the Neuron, while the second is somewhat of a hypothetical (even rather useless) specialisation of the Neuron so that I can conduct further tests on the efficacy of the Client Device project more generally. My motivation for writing tonight came from an observation that perhaps I see a reasonably stable implementation of the way in which Neurons can be specialised.
Apart from the fact that Neurons can contribute fully in cognition (glia are denied this privilege because they cannot engage their neighbouring Neurons as respondents), a naked Neuron has no capacity to do anything else. A naked Neuron can act as nothing more than a relay between otherwise clothed Neurons who may not share a direct engagement. Naked Neurons know how to communicate in Clique Space as initiators and respondents, but have no other ability; apart from Clique Space itself, a naked Neuron has no capacity to contribute to "thinking" by virtue of the fact that naked Neurons do not model any other medium.
Clique Space acquires a thinking capacity because some Neurons can be specialised: some can perhaps be made to respond to photons hitting them; some can be made to contract like muscles; some can, when stimulated by other Neurons, perhaps produce some sensations that yet other Neurons specialised in some other way can react to. Glia (I cannot consider a naked version of these ever to make sense) can be specialised to maintain a nice environment for themselves and their Neural brethren. They can perhaps help by dilating nearby nutrient vessels when they detect their neighbouring Neurons undergoing heavy cognition, or perhaps glia help speed signal flow by enclosing the axons of their Neural neighbours in a sheath of myelin.
A Clique Space Neuron software implementation can be specialised by extending the inbound Connection class (NeuralInboundConnection) exposed as an abstract class in the Neuron project. This class can be extended to capture stimuli that are generated though some other medium present on the specialised Neuron's host hardware. These stimuli must be recorded as qualia - the units of cognition - that must also be accompanied by instances of a surrogate - a serialisable proxy of a quale - so qualia related to a given stimulus can be sent as a signal from one Client Device to be reconstituted as quale in another. Signals are individually wrapped in envelopes, and collections of envelopes are bundled in transmitters before transmitters are exchanged as part of a synapse's activity cycle.
A property also needs to be created and stored (usually) as a native property of the extended version of the inbound Connection. This property allows a Neuron to form and communicate a belief that a particular stimulus (the object - perhaps associated with a sense datum quale different to the object quale) has been received by the a given Neuron, and is being asserted by a given Identity.
This very quickly put together summary of Clique Space constitutes a semantically rigid language of thought that I have no reason not to believe would ultimately derive of a synthetic mechanism the ability to exist.
Perhaps... I have no idea really and odds on this is probably bullshit. Even so, it appears to have worked for me so far.
Subscribe to:
Posts (Atom)