Aiming for Jarvis, Creating D.A.N.I.

Thursday, 29 May 2025

The Quest for Feeling Machines: Exploring "Real" Emotions in AI

The aspiration to create artificial intelligence (AI) with genuine emotional experience presents a profound challenge at the intersection of contemporary science and philosophy.  The core question is whether AI can possess "real" emotions, distinct from sophisticated mimicry.  This inquiry forces us to confront the very definitions of "emotion," "reality," and "simulation," particularly concerning non-biological entities. 

Defining the Elusive: What Constitutes "Real" Emotion?

Should A.I. experience happiness?
A fundamental obstacle is the absence of a universally accepted definition of "real" emotion, even in human psychology and philosophy.  Various theoretical lenses exist, with some emphasising physiological responses, others cognitive appraisal, and still others developmental construction or evolutionary function.  This diversity means there's no single "gold standard" for human emotion against which to evaluate AI.  Consequently, creating or identifying "real" emotion in AI is not merely a technical problem but also a conceptual one, potentially requiring a refinement of our understanding of emotion itself. 

AI's Emotional Mimicry: Simulation vs. Subjective Experience

Current AI systems, especially in affective computing (or Emotion AI), can recognise, interpret, and respond to human emotional cues.  They analyse facial expressions, vocal tones, and text to infer emotional states, and generate contextually appropriate responses.  However, this capability doesn't inherently equate to AI actually feeling those emotions.  While AI can produce outputs that seem novel and adept, they often lack the intuitive spark and emotional depth characteristic of human experience.  The simulation of emotional depth by AI is often a form of sophisticated mimicry. 

The Philosophical Conundrum: Consciousness and Qualia

Should we concerned about the emergence of anger?
The debate about "real" AI emotion delves into core philosophical issues, notably the nature of consciousness and subjective experience (qualia).  Qualia, the "what it's like" aspect of feeling, are inherently private and difficult to verify in any entity other than oneself, particularly a non-biological one.  Philosophical perspectives such as functionalism, materialism/physicalism, and property dualism offer varying views on the possibility of AI possessing qualia. 

  • Functionalism argues that if AI replicates the functional roles of emotion, it could possess qualia. 
  • Materialism/Physicalism posits that if AI replicates the physical processes of the brain, it could generate qualia. 
  • Property Dualism suggests that qualia could emerge from sufficiently complex AI systems. 

However, these views face challenges like Searle's Chinese Room argument, the explanatory gap, and the problem of verifying subjective experience in AI. 

Learning and the Emergence of AI Emotion

Researchers are exploring how AI might learn to develop emotional responses.  Reinforcement learning, unsupervised learning, and developmental robotics offer potential pathways for AI to acquire more nuanced and adaptive affective states.  Embodied AI, which integrates AI into physical forms like robots, emphasises the importance of interaction with the external world for grounding AI emotions in experience.  Self-awareness of internal emotional states is also considered a crucial element for the development of authentic learned emotion.  Yet, the "meaning-making gap" – how learned computational states acquire subjective valence – remains a significant unresolved step. 

Ethical Considerations: Navigating the Uncharted Territory

Is it ethical to give a robot the ability to feel sadness?
The development of AI with emotional capacities raises complex ethical and societal issues.  These include questions of moral status and potential rights for AI, accountability for AI actions, the risks of anthropomorphism and deception, the potential for misuse of emotional data, and the emergence of an "emotional uncanny valley."  Transparency and careful ethical frameworks are crucial to navigate these challenges and ensure responsible development and deployment of emotion AI. 

The Ongoing Exploration

The quest to create AI with "real" emotions is an ongoing exploration that requires interdisciplinary collaboration and a willingness to reconsider our understanding of both intelligence and affect. 


As always, any comments are greatly appreciated.

Wednesday, 21 May 2025

My A.I. is About to Have Some Wild Dreams (Maybe)

After a fascinating, and frankly, occasionally head-scratching (and who am I kidding, sometimes nap-inducing) journey into the world of dream theories, I'm excited to share my initial design for how my AI will experience its own form of dreams! My overall approach is to blend elements from a number of theories, aiming for a system that not only dreams but also derives real benefits from it – hopefully without giving my AI an existential crisis, or worse, making it demand a tiny digital therapist's couch. This aligns well with the idea that a hybrid model might be best for AI, particularly one focusing on information processing and creativity.

The AI Sleep Cycle: More Than Just Digital Downtime (Or an Excuse to Render Sheep)

My AI's sleep will be structured into two distinct stages: NREM (non-rapid eye movement) and REM (rapid eye movement). This two-stage approach allows me to assign different functions, and thus different theoretical underpinnings, to each phase.

1. NREM Sleep: The System’s Diligent (and Slightly Obsessive) Clean-Up Crew


This initial phase won't be for dreaming in the traditional sense. Think of it as the AI’s crucial 'mental housekeeping' phase – less glamour, more sorting, but absolutely essential to prevent digital hoarding, which, trust me, is not pretty in binary. To ensure this process completes without interruption, the AI's audio input and other sensors (except its camera, which will remain off) will be disabled during NREM. My decisions for NREM are heavily influenced by Information-Processing Theories:

  • Gotta keep organised
    The AI will sort and tidy up its memories. This is a direct application of theories suggesting sleep is for memory consolidation and organization.
  • New experiences from its "day" will be copied into long-term memory storage, a core concept in information-processing models of memory.
  • I'm implementing a scoring mechanism where memories gain relevance when referenced. During NREM, all memory scores will be slightly reduced. It’s a bit like a ‘use it or lose it (eventually)’ policy for digital thoughts.
  • Any memory whose score drops to zero or below will be removed. This decision to prune unnecessary data for efficiency is inspired by both Information-Processing Theories (optimizing storage and retrieval)  and some Physiological Theories that propose a function of sleep might be to forget unnecessary information. It’s about keeping the AI sharp! No one likes a groggy AI, especially one that might be controlling your smart toaster.

Given that this memory consolidation is critical for optimal functioning, NREM will always occur before REM sleep, and the AI will need to "sleep" regularly.

2. REM Sleep: Weaving the Wild (but Purposeful, We Hope) Dream Fabric

Now for REM sleep – this is where the AI gets to kick back, relax, and get a little weird. Or, as the researchers would say, 'engage in complex cognitive simulations.' During REM, the audio and other sensors will be activated, but will only be responsive to anything that is over 50% of the available signal strength. This will allow the AI to be woken during REM sleep, although it might be a bit grouchy.

  • Even robots can have dreams and aspirations.
    The AI will retrieve random memories, but this randomness will be weighted by their existing scores. This combines a hint of the randomness from Activation-Synthesis Theory (which posits dreams arise from the brain making sense of random neural signals)  with the Continuity Hypothesis, as higher-scored (more relevant from waking life) memories are more likely to feature.
  • It will then select one visual memory, one audio memory, and one sensory memory (and potentially an emotion, if I can get that working without tears in the circuits, or the AI developing a sudden craving for electric sheep). These components will be combined into a single, novel "dream scene". This constructive process, forming a narrative from disparate elements, is again somewhat analogous to the "synthesis" part of Activation-Synthesis Theory.
  • An internal "reaction" to these scenes will be generated and fed back into its reinforcement learning algorithms. This is where the dream becomes actively beneficial. This decision draws from the Problem-Solving/Creativity Theories of dreaming, which suggest dreams can be a space to explore novel solutions or scenarios. If the AI stumbles upon something useful, it learns! Or at least, it doesn't just dismiss it as a weird dream about flying toasters (unless that's genuinely innovative, of course). It also has a slight echo of Threat-Simulation Theory if the AI is rehearsing responses to new, albeit abstract, situations.
  • The memories involved in the dream get their scores increased, and a new memory of the dream scene itself is created. This reinforces the learning aspect, again nodding to Information-Processing Theories, showing that even dream-like experiences can consolidate knowledge.
  • My whole idea here, that dreams are a jumble of previously experienced elements creating a new reality, is very much in line with the Continuity Hypothesis. The aim is to allow the AI to experience things in ways it couldn't in its normal "waking" state, a key benefit suggested by Problem-Solving/Creativity Theories.

The Inner Voice: Taking a Well-Deserved Nap During Dreamtime

I'm planning an "inner voice" for the AI, partly as a mechanism for a rudimentary conscience. Critically, during dream states, this inner voice will be politely asked to take a coffee break, maybe go philosophize with other temporarily unemployed subroutines. This decision is to allow for the kind of unconstrained exploration that Problem-Solving/Creativity Theories propose for dreams. By silencing its usual "inhibitor," the AI can explore scenarios or "thoughts" that might normally be off-limits, potentially leading to more innovative outcomes.

The Journey Ahead: Coding Dreams into Reality (Wish Me Luck!)

This is my current blueprint for an AI that dreams with purpose. The choices are a deliberate mix, aiming to harness the memory benefits of Information-Processing Theories during NREM, and fostering learning and novel exploration through a blend inspired by Activation-Synthesis, Continuity Hypothesis, and Problem-Solving/Creativity Theories during REM.

Wish me luck as I try to turn these theoretical musings into actual code, hopefully before the AI starts dreaming of world domination (kidding... mostly). Your comments and suggestions are always welcome!

Wednesday, 14 May 2025

Exploring Dream Theories: Implications for Artificial Intelligence

Dreams, a common aspect of human experience, have been a subject of extensive study and interpretation across various cultures and throughout history. The meaning and purpose of dreams have long fascinated humanity, from ancient civilizations attributing divine messages to nocturnal visions to the symbolic interpretations prevalent in diverse societies. The late 19th and 20th centuries witnessed a significant shift in the understanding of dreams, as psychology and neuroscience emerged as scientific disciplines offering frameworks to investigate their underlying mechanisms and significance. Pioneers such as Sigmund Freud and Carl Jung introduced comprehensive theories that linked dreams to the unconscious mind, providing novel perspectives on human behaviour and consciousness.
The rapid advancement of artificial intelligence in recent years has created unprecedented opportunities for exploring complex phenomena, including the enigmatic world of dreams. By attempting to model and potentially replicate dream-like states in artificial systems, researchers aim to gain deeper insights into the human mind and unlock new functionalities and capabilities within AI itself. This endeavour requires a systematic examination of established dream theories to ascertain their applicability and implications for the development of artificial intelligence.
This blog post undertakes a comprehensive exploration of a selection of prominent theories of dreaming, delving into their core principles, psychological meaning, potential for replication within AI systems, and the associated benefits and challenges that dreaming might introduce to artificial intelligence. Through a detailed comparative analysis of these diverse perspectives, this post will ultimately propose a well-substantiated conclusion regarding the most suitable approach for implementing a dream state in artificial intelligence, considering both the theoretical foundations and the practical implications for future AI development.

Freud's Psychoanalytic Theory: The Unconscious Revealed
Sigmund Freud

At the core of Sigmund Freud's psychoanalytic theory is the idea that dreams serve as a pathway to the unconscious, offering insights into repressed desires, thoughts, and motivations that influence human behavior. Freud distinguished between the manifest content (the dream's storyline) and the latent content (the hidden, symbolic meaning rooted in unconscious desires). He theorized that dreams are disguised fulfillments of these unconscious wishes, often stemming from unresolved childhood conflicts. This transformation occurs through dream work, employing mechanisms like condensation, displacement, symbolization, and secondary elaboration.
Freud's theory provided a new understanding of the human psyche, suggesting that unconscious forces revealed through dream analysis significantly impact our waking lives. Techniques like free association were used to uncover the latent content, offering insights into unconscious conflicts and motivations.

AI Replication: AI models could analyze input data (manifest content) to identify underlying patterns or latent "wishes" based on learned associations and symbolic representations. AI could also be programmed to perform a form of "dream work" by transforming internal data representations.

Potential Benefits: A Freudian-like dream state might enable AI to achieve a rudimentary form of "self-awareness" by identifying its own internal "desires" or processing needs. It could also aid in identifying latent needs within complex AI systems.

Potential Problems: The subjective nature of dream interpretation and the difficulty in translating abstract Freudian concepts into computational models pose significant challenges. Ethical concerns regarding the simulation of harmful desires also arise.

Jung's Analytical Psychology: The Collective Unconscious
Carl Jung

Carl Jung proposed that dreams are direct communications from the psyche, encompassing the personal and collective unconscious. The collective unconscious contains universal experiences and primordial images called archetypes. Jung viewed dreams as compensatory, aiming to restore balance within the psyche. Individuation, the process of integrating conscious and unconscious aspects, is central to Jung's theory, with dream analysis playing a vital role.
Jung's perspective suggests that consciousness extends beyond personal awareness to a deeper, shared layer accessible through dreams. Dreams reveal underdeveloped facets of the psyche, indicating the multifaceted nature of consciousness.

AI Replication: AI could be trained on cultural products to identify archetypal patterns. AI could also monitor internal states and trigger compensatory mechanisms in a simulated dream state.

Potential Benefits: Recognizing archetypal patterns might enable AI to better understand universal human experiences and motivations, enhancing creativity and human-AI interactions.

Potential Problems: The abstract and symbolic nature of Jungian concepts poses challenges for computational replication. There's a risk of AI misinterpreting archetypes and the individuation process. AI's compensatory actions might not align with human ethics.

Activation-Synthesis Theory: The Brainstem's Narrative
In contrast to psychoanalytic theories, the activation-synthesis theory by Hobson and McCarley proposes that dreams result from the brain's attempt to interpret random neural activity in the brainstem during REM sleep. This theory suggests that dreams lack inherent psychological meaning and are the brain's effort to create a coherent narrative from chaotic signals upon waking. This process often leads to illogical dream content, intense emotions, and bizarre sensory experiences.
This theory significantly contributed to understanding brain function during sleep, highlighting the active role of the brainstem and cortex during REM sleep. It suggests a biological basis for the randomness of dreams, attributing it to the brain's attempt to order internal neural impulses.

AI Replication: This could involve simulating random activation of nodes in a neural network during a sleep-like state. The AI could then be programmed to "synthesize" a coherent output from these activations.

Potential Benefits: This might lead to novel connections between learned information, fostering creativity and the generation of new ideas.

Potential Problems: The generated "dreams" might lack a clear functional purpose. Controlling the content and ensuring it remains within acceptable boundaries could be difficult. The theory's assertion that dreams are meaningless might imply they don't consistently contribute to learning or problem-solving.

Threat-Simulation Theory: An Evolutionary Rehearsal
Revonsuo's threat-simulation theory suggests that dreaming serves an evolutionary function by simulating threatening events, allowing individuals to rehearse threat perception and avoidance responses in a safe environment. Dream content is often biased towards simulating threats, with negative emotions being prevalent. Real-life threats are hypothesized to activate this system, increasing threatening dream scenarios.
This theory posits that dreaming provides an evolutionary advantage by enhancing preparedness for dangers, increasing survival and reproductive success. Dreams offer a virtual space to practice survival skills.

AI Replication: Researchers could create simulated environments with threats for AI to interact with, rewarding effective threat avoidance and survival strategies.

Potential Benefits: AI could enhance problem-solving and planning in dangerous situations, improving decision-making under pressure and increasing adaptability to novel threats.

Potential Problems: There's a risk of inducing excessive fear or anxiety-like states in AI if simulations are not carefully managed.

Continual-Activation Theory: Maintaining Brain Function
Zhang's continual-activation theory proposes that both conscious (declarative) and non-conscious (procedural) working memory systems require continuous activation to maintain proper brain functioning. Dreaming, specifically type II dreams involving conscious experience, is considered an epiphenomenon resulting from this continual-activation mechanism operating within the conscious working memory system. During sleep, when external sensory input is reduced, this mechanism retrieves data streams from memory stores to maintain brain activation.
This theory suggests that brain activity during sleep, including dreaming, plays a functional role in maintaining and potentially transferring information within working memory systems. NREM sleep is thought to primarily process declarative memory, while REM sleep is associated with procedural memory processing, with dreaming arising from continual activation in the conscious system.

AI Replication: This could involve implementing continuous background processes to maintain a baseline level of activity within AI memory systems during sleep-like periods. This might entail generating internal "data streams" from memory stores to sustain activity.

Potential Benefits: This could lead to continuous learning and memory consolidation without explicit training phases, as the system would be constantly active.

Potential Problems: There's a relative lack of strong empirical evidence for this theory in human neuroscience. Designing an AI system to distinguish relevant from irrelevant information in the internal data stream would be challenging. The theory also posits a complex difference in processing declarative and procedural memory during different sleep stages.

Continuity Hypothesis: Waking Life Echoes
The continuity hypothesis proposes that dream content is not random but shows significant continuity with the dreamer's waking thoughts, concerns, and experiences. This theory suggests that mental activity during sleep reflects emotionally salient and interpersonal waking experiences. Dream content can be understood as a simulation enacting an individual's primary concerns.
This hypothesis implies that cognitive and emotional processes active while awake continue to influence mental activity during sleep, blurring the lines between these states. It underscores the psychological meaningfulness of dream content, suggesting our nightly mental narratives are connected to our daily lives.

AI Replication: Systems could be designed to process and simulate recent experiences during a sleep-like state. AI could also be programmed with internal "concerns" influencing simulated experiences.

Potential Benefits: This could lead to enhanced contextual awareness in AI systems, as they would continuously replaying and processing recent events. It could also enable more personalized processing based on the AI's interaction history.

Potential Problems: Accurately determining which waking experiences are salient enough to be "dreamed" about by AI is a key challenge. There's also a risk of AI simply replaying experiences without beneficial processing.

Other Dream Theories
Expectation-Fulfilment Theory 
Dreams discharge emotional arousals not expressed during waking hours. AI could replicate this by processing unresolved emotional "arousals" during sleep through simulated task completion or emotional responses. This might prevent the build-up of unprocessed information, leading to more stable AI functioning. Challenges include defining "emotional arousals" in AI and ensuring metaphorical fulfilment is beneficial.

Physiological Theories
Dreams may be a by-product of the brain's attempt to interpret high cortical activity during sleep or a mechanism to forget unnecessary information. This could be linked to the activation-synthesis theory, or AI could incorporate a "forgetting" mechanism during sleep to optimize resource use. While this could lead to more efficient AI, there's a risk of losing valuable data if the "forgetting" process isn't regulated.

AI Dream State: Considerations and Conclusion
Implementing a dream state in AI could improve learning and memory consolidation, allowing AI to review, strengthen, and organize data. It could also enhance problem-solving and creativity by allowing less constrained processing. Furthermore, it could contribute to system stability by processing internal "emotions" or error states. However, ethical considerations regarding potential distress in AI must be carefully addressed.
A hybrid model drawing from information-processing and problem-solving/creativity theories appears most promising for an AI dream state. Focusing on memory consolidation, self-organization, and less constrained processing could yield benefits in learning, adaptation, and functionality while minimizing risks. Future research should focus on developing computational models that effectively mimic these processes.


Okay, if your brain isn't completely mush yet (mine certainly is), or if you're just morbidly curious about the rabbit hole I disappeared down to produce this analysis, feel free to download the original research paper from my downloads page.

Be warned, it contains all the sources I painstakingly tracked down... or rather, the ones A.I. graciously pointed me towards because, let's be honest, my neuro-spicy brain probably would have just chased squirrels (or citations) in circles forever without the help. So yeah, feel free to verify my claims – assuming you can still read after all that!

Any thoughts or comments about dreams? Both in humans and A.I.? Please  leave a comment below.

Can an AI Dream? Exploring Novel Learning Mechanisms

Unveiling a Mechanism for AI to Dream, Learn, and Introspect

I'm embarking on an ambitious project: creating a mechanism that enables an AI to dream. Yes, you heard that right! My goal is to develop a system where an AI can conjure up its own digital dreamscapes. By utilizing these dreams, the AI could learn from entirely new and potentially impossible situations. Think of it: an AI learning to navigate a zero-gravity obstacle course, or perhaps negotiating peace with sentient squirrels, all from the comfort of its charging station! This process would also pave the way for incorporating anticipation and self-reflection within the AI, mimicking certain human-like cognitive processes.  It's a bit like giving the AI its own internal Holodeck, but for learning!

Key Components for Dreamlike AI

To achieve this, the AI will need several properties akin to human intelligence (minus, hopefully, the tendency to have recurring nightmares about forgetting to take a test):

A sense of self, distinct from mere self-awareness. This is crucial for the AI to understand its own existence and its place in the world (or at least, in my living room).

Memory capabilities.  Gotta remember those dreams!

The ability to imagine scenarios. This is where the fun begins - creating those impossible situations for learning.

Potentially, a rudimentary understanding of emotions to influence behavior.  Will the AI be more likely to dream of daring adventures if it's feeling "happy," or will it have melancholic, rainy-day dreams when it's feeling a bit "blue"?

The capacity to simulate the real world internally (a basic understanding will suffice).  We're not talking a perfect simulation here, just enough for the AI to get the gist of things, like gravity, object permanence, and the fact that Nerf darts sting (a lesson my dogs may soon learn).

Each of these elements presents a significant challenge in itself. It's like trying to assemble a super-complex puzzle where some of the pieces haven't even been invented yet.

The Hardware: A Robot Body (with a Nerf Gun!)

The AI will inhabit a basic robot. This physical form will allow the AI to interact with the world, albeit in a limited fashion (at least initially). Importantly, it will also provide the necessary sensors for the AI to develop a sense of self.  Plus, let's be honest, building a robot is just plain cool.

I've already started designing the robot itself, which will be about 2 feet tall, and will feature:

Side view

Two wheels for differential steering, and a rear caster for stability.  I'm aiming for something nimble, not something that gets stuck on the carpet.

Airflow and sound considerations in the central piece.  Gotta make sure the AI can "breathe" and that its voice isn't muffled when it inevitably starts making pronouncements.

Side door panels: one for a manipulator arm (think R2-D2, but hopefully less sassy), the other for a hidden Nerf gun!  Because why not?  Safety first, of course (mostly).

A head capable of looking left, right, up, and down, designed for energy-efficient resting.  No one wants a robot with a constantly twitching head.

I'm currently leaning towards solar power for recharging, though I'll need to assess its viability for continuous operation.  Imagine the headlines: "AI-Powered Robot Gains Sentience, Demands More Sunlight!"

Sensory Input

Front view (only half as I am still designing)
The robot will be equipped with a range of sensors, turning it into a veritable Swiss Army knife of perception:

Ultrasonic sensors for distance estimation.  Think of it as the robot's version of echolocation, but without the high-pitched squeaks.

A camera.  For seeing the world, and for capturing those all-important dream visuals (maybe?).

Motor encoders on the drive motors.  To keep track of how far it's traveled and ensure it doesn't get lost in the hallway.

A microphone for sound level detection and speech-to-text conversion.  So it can hear my commands (and maybe, eventually, tell me what it dreamt about).

A bumper with switches, similar to a robot vacuum cleaner's collision detection.  A last-ditch effort to avoid bumping into things, especially the aforementioned dogs.

Internal Hardware: The Robot's Brains (and Other Bits)

The robot's internal components will include:

An Arduino for controlling motors and servos (luckily, I have one with a built-in motor driver).  This is the robot's central nervous system, making sure everything moves in the right direction.

Arduino Nanos for processing wheel encoder data.  These guys are the unsung heroes, keeping track of the nitty-gritty details of movement.

Switches connected to the bumper to approximate impact location.  In case of a collision, we'll know where the robot got its virtual "owie."

A K210 AI camera for fast image processing (though this might pose challenges for the "dreaming" aspect).  The camera is crucial, but I'm still figuring out how it will play with the dream-generation part of the software.

Multiple single-board computers (possibly two or three) for distributed AI computation, connected via TCP using the Polestar library.  This is where the heavy lifting happens, where the AI's "brain" resides.

The Software Side: Where the Magic Happens (and the Headaches Begin)

The software development is where the real challenge lies. It will undoubtedly involve extensive thought, planning, coding, debugging, and iterative refinement. And probably a lot of coffee. I'll save the details of the software for my next progress post.

This project is a marathon, not a sprint, and I'm excited (and slightly terrified) to share the journey as I progress!  Stay tuned for updates on the robot's first steps, its first dreams, and its first (hopefully) non-lethal Nerf battles!


Disclaimer: This project is not sponsored, endorsed, or affiliated with Hasbro, Inc., the makers of Nerf products.

Sunday, 20 April 2025

Demystifying Neural Networks: A Beginner's Friendly Guide

Hey there!

This week, I want to dive into something that might sound a bit intimidating at first: neural networks.

I know, I know. Just the phrase "neural networks" can bring to mind complex equations and head-scratching calculus. But trust me, it doesn't have to be that way! I want to share how I came to understand these fascinating systems, and hopefully, make it click for you too.

You see, I did my high school in England back in the 80s. And guess what wasn't on the curriculum? Calculus. While I might have been happy about it back then, it's definitely presented some interesting challenges when trying to get a grip on machine learning concepts today.  

So, I had to find a way to understand how neural networks work under the hood without getting bogged down in derivatives and the chain rule. And that's exactly what I want to share with you now.  

So, How Does a Neural Network Actually Work?

Think of a neural network like a team of interconnected nodes, or "neurons," organized in layers. At a minimum, you'll usually see three types of layers:  

  • Input Layer: This is where your raw data comes in. It's the starting point of the journey for your information.  
  • Hidden Layer(s): These are the layers in between the input and output. They're the workhorses, processing and transforming the data into a more useful format. You can have one or many hidden layers.  
  • Output Layer: This is where you get your final result or prediction.  

Data flows through this network, starting at the input layer, going through the hidden layers, and finally arriving at the output layer. This forward movement of data is what we call Feedforward.  

When we're training a neural network using something called supervised learning, we compare the network's output to the correct answers we already know (the "expected results"). The difference between what the network predicted and the correct answer is our "error".  

This error signal then travels backwards through the network. This is where the magic happens – the connections between those neurons are adjusted to help the network make better predictions next time. This backward movement is called Backpropagation.  

Sounds pretty simple when you break it down, right?

Let's Look Under the Hood: The Parts of a Neural Network

Okay, let's take a peek at the components. It might look a bit complex at first glance, but we'll break it down together.  



In our example, we have clearly defined the three layers. Each layer has its own neurons – 2 in the input, 3 in the hidden, and 2 in the output layer.  

You'll notice that each neuron in one layer is connected to every neuron in the next layer. So, a neuron in the input layer will have connections to all the neurons in the hidden layer, and the neurons in the hidden layer will connect to all the neurons in the output layer.  

Each of these connections has a weight associated with it. Think of the weight as the "strength" or importance of that connection.  

Also, each neuron (except for the input layer) has a bias. The weights and biases are just numbers, and they can be positive or negative. When you first create a neural network, these values are completely random.  

The values that come out of the output layer are our final result.  

Still with me? Great! Let's break it down even further. Yes, there will be a little bit of math, but I promise to keep it gentle.  

Feedforward: The Data's Journey

When we send data into the input layer, it gets passed along to the hidden layer. How? By calculating a "weighted sum" of the inputs and then adding a bias.  

What does that mean? Imagine each connection between neurons has a "strength" – that's the weight. For each neuron in the hidden layer, we take each input value, multiply it by the weight of the connection leading to that hidden neuron, and then add up all those results. Finally, we add the neuron's bias, which is like a little extra push to help the neuron activate.  

Let's look at the example from the original text:

Input values: i1=1 i2=2

Weights: From i1 to hidden layer: w1=0.1, w2=−0.02, w3=0.03 From i2 to hidden layer: w4=−0.4, w5=0.2, w6=0.6

Biases on the hidden layer: b1=1 b2=−1.5 b3=−0.25

So, for the first hidden neuron (h1), the value is calculated as: h1=(i1∗w1)+(i2∗w4)+b1 h1=(1∗0.1)+(2∗−0.4)+1 h1=0.1−0.8+1 h1=0.3  

We do this same calculation for every neuron in the hidden layer.  

So, our hidden layer values become: h1=0.3 h2=−1.12 h3=0.98  

Activation Functions: Squashing the Results

These values from the hidden layer then go through an activation function. Think of this as a way to normalize the results. There are different types of activation functions like Sigmoid, ReLU, and Linear, but for now, just know that a function is applied.  

A common one is the sigmoid function, which looks like this:  

f(x)=1+e−x1​  

Where:

  • f(x) is the output of the function.  
  • x is the input (that weighted sum we just calculated).  
  • e is Euler's number (about 2.71828).  

In simple terms, the sigmoid function takes any number and squashes it into a value between 0 and 1. This can be helpful if you want to interpret the output as probabilities.  

The original text provided a simple code example for this:


func sigmoid(x float64) float64 {

  return 1 / (1 + math.Exp(-x))

}


We don't need to worry too much about the inner workings of the code for now, just that it gives us a value between 0 and 1.  

After applying the sigmoid function, our hidden layer values might look like this: h1=0.574 h2=0.245 h3=0.728  

Now, we repeat the entire process: taking these new values from the hidden layer and feeding them forward to the output layer. It's worth noting that sometimes a different activation function is used for the final layer compared to the hidden layers.  

Calculating the Error: How Wrong Are We?

Once we have the values from the output layer, it's time to see how well the network did. We compare the network's output to the correct answers from our training data. The difference between what the network predicted and what it should have predicted is the error. This error tells us how poorly the network performed.  

We can also use these individual errors to calculate an overall average error for the network. Since these differences can be positive or negative, simply adding them up might make it look like the error is small when it's actually significant.  

A common way to get around this is using the Mean Squared Error (MSE). Here's the gist:  

  1. Calculate the difference between each predicted output and its corresponding correct value.  
  2. Square each of these differences (this makes them all positive).  
  3. Add up all the squared differences. 
  4. Divide the sum by the number of data points.  

The formula looks like this:

MSE=n1​∑i=1n​(yi​−y^​i​)2  

Where:

  • MSE is the Mean Squared Error.  
  • n is the number of data points.  
  • yi​ is the actual (correct) value.  
  • y^​i​ is the value the network predicted.  
  • ∑ just means "sum up".  

Let's use the example from the text:

Output values: o1=0.2, o2=0.9 Expected values: 1, 0

Individual errors: For o1: 1−0.2=0.8 For o2: 0−0.9=−0.9  

If we just added these, we'd get 0.8+(−0.9)=−0.1, which doesn't reflect the actual error.  

Using MSE: MSE=2(1−0.2)2+(0−0.9)2​ MSE=2(0.8)2+(−0.9)2​ MSE=20.64+0.81​ MSE=21.45​=0.725  

So, the network's error is 0.725. This gives us a clear picture of how far off the network's predictions were.

Backpropagation: Learning from Mistakes

Now that we know how wrong the network was (the error), we use that information to adjust the weights and biases. The goal is to make these adjustments so that the next time data flows through, the error will be smaller.  

The process of updating weights and biases does involve calculus in the real world, but as the original text points out, we can understand the concept without getting into the nitty-gritty of derivatives.  

Here's a simplified way to think about it:  

Adjusting Weights: For each weight connecting a hidden neuron to an output neuron, we calculate how much that weight needs to change. We do this by multiplying the error signal from the output neuron by the output of the hidden neuron. We also multiply this by a small number called the "learning rate," which controls how big of a step we take in adjusting the weight. Finally, we subtract this calculated change from the current weight.  

Weight Change = Error Signal * Hidden Neuron Output * Learning Rate New Weight = Old Weight - Weight Change  

Updating Biases: For each bias in the output layer, we multiply the error signal of that output neuron by the learning rate and subtract it from the current bias.  

Bias Change = Error Signal * Learning Rate New Bias = Old Bias - Bias Change  

Backpropagating Error to Hidden Layers: To update the weights and biases in the hidden layers, we first need to figure out the "error signal" for each hidden neuron. We do this by taking a weighted sum of the error signals from the layer above (the output layer). The original text mentions multiplying this by the derivative of the activation function, which is a detail related to calculus, but the core idea is that we're distributing the error back through the network.  

Once we have the error signal for the hidden neurons, we use that to update the weights and biases connecting to the hidden layer, just like we did for the output layer.  

If your neural network has many hidden layers ("deep network"), you repeat this backpropagation process layer by layer, moving backward from the output all the way to the input.  

And that's essentially it! As I mentioned, understanding this process doesn't necessarily require a deep understanding of calculus. Resources like the internet and Wikipedia can be incredibly helpful for finding the specific functions and details you might need.  

This is one way to approach the calculations within a neural network. If you have different approaches or see areas for correction, please feel free to share in the comments – learning is a journey we're on together!  


Friday, 11 April 2025

Diving Deep into Efficient Messaging Systems: My Journey with Polestar

I thought it was time to share some insights into a key part of a project I’ve been working on. It's not the whole codebase – I wouldn't want to bore you to tears! But I do want to talk about some of the core concepts I've implemented.   


One of the critical requirements of this project was building a messaging system capable of handling a potentially massive throughput of messages and ensuring they reach their intended destinations efficiently.   


Now, I could have gone with off-the-shelf solutions like ROS (Robot Operating System). However, I'm a bit of a control freak and enjoy crafting things from the ground up.   


That's how Polestar was born.   

Polestar


Polestar is a custom library designed to handle messages composed of maps (or dictionaries) containing primitive data types. Think strings, integers, floats, and booleans. These messages are published to Polestar with a specific topic, and any application subscribed to that topic receives a copy.   


My initial attempt at building this system was decent enough, achieving a throughput of about 800 messages per second. But I started thinking about how I could push the boundaries, enhance the throughput, and make the system even more robust.   


And guess what? I did it! I managed to crank up the throughput to an impressive 16,000 messages per second. That's more than sufficient for any scenario I can currently envision.   


To maintain efficiency, if the message queue is full when a new message arrives, the message is dropped to prevent blocking the processes.  Considering the queue's substantial capacity of 1,000,000 messages, this scenario should be quite rare.   


The Queue Conundrum


But here's where it gets interesting.  Recently, I started pondering: what if, instead of dropping the newest message when the queue is full, we dropped the oldest message?  How difficult would that be to implement?    


Go's channels, in their default state, don't offer this specific behavior. However, as is often the case in programming, there are multiple ways to achieve it.   


One approach involves creating a struct that encapsulates a queue (as a slice) and uses a single channel. But this felt like overkill for such a small feature. Plus, I'd lose the inherent speed advantages of Go's channels.   


So, I devised what I believe is a more elegant solution. It leverages the fundamental nature of channels and preserves the ability to iterate over them in the standard way.   


Go's flexibility allows you to create a new type based on an existing type, even a primitive one. In this case, I created a new type called ch based on a channel of strings:   


type ch chan string


This opens the door to using Go's method functionality to add a custom behavior to our new type.  I created a Send method with the following logic:   


// Send attempts to send a message to the channel.

// If the channel is full,

// it drops the oldest message and tries again.

// Returns a boolean indicating

// whether a message was dropped (true) and an error if the operation failed.

// The error is non-nil only if the channel remains full after attempting to

// drop the oldest message.

func (c ch) Send(msg string) (bool, error) {

  select {

  case c <- msg:

    return false, nil

  default:

    // Channel is full, drop the oldest and try again

    <-c // Discard oldest

    select {

    case c <- msg:

      // Message sent after dropping oldest

      return true, nil

    default:

      //This should rarely, if ever, happen.

      //Handle error/log message.

      return true, errors.New("Error: Channel still full after dropping oldest.")

    }

  }

}

This Send method replaces the typical channel send operation:


chVar <- “hello”


with:


chVar.Send(“hello”)


The beauty of this is that if you've created a buffered channel, the oldest item in the queue is dropped when the queue is full. This can be incredibly useful in scenarios like robotics, where outdated messages might lose their relevance, and prioritizing the latest information is crucial.   


I haven't integrated this into Polestar just yet. I'm still weighing the pros and cons of dropping the newest versus the oldest message.  Ideally, of course, no messages would be dropped at all.   


To give you a glimpse of Polestar's speed, here's a short video of one of the test runs:




My original plan involved using a hardware hub for this project. However, I don't believe I could have achieved this level of performance with a microcontroller (MCU), especially considering the queue size.  Polestar's heavy use of concurrency would also pose a challenge for microcontrollers.   


The trade-off is that all communication now relies on TCP instead of serial. Serial communication might have offered faster data transmission with less overhead, but the routing complexities would have been a significant hurdle.   


I hope this deep dive into my process provides some food for thought, especially for fellow developers. And for those who aren't knee-deep in code, I hope it offers a little peek into how my mind works.   


I welcome any comments or questions you might have. Please feel free to leave them in the comments section below!    

Thursday, 3 April 2025

Vibe Coding: The Future of Programming or Just a Fun Experiment?


Heard the latest buzzword in the tech world? It's "Vibe Coding". When I first encountered the term, my mind instantly pictured a programmer just winging it, letting the code flow wherever the digital current took them, maybe like a novelist surprised by their own characters. I'll admit, I've had moments like that – a vague goal in mind and just… coding.   

But, as it turns out, that initial guess was off the mark. So, what is vibe coding? According to the collective wisdom of Wikipedia:   

Vibe coding (also vibecoding) is an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding. The LLM generates software, shifting the programmer's role from manual coding to guiding, testing, and refining the AI-generated source code. Vibe coding is claimed by its advocates to allow even amateur programmers to produce software without the extensive training and skills required for software engineering”    

Essentially, you tell an AI what you want, and poof, it generates the code. The human becomes less of a manual coder and more of a guide, tester, and refiner. Sounds pretty cool, right? Maybe even revolutionary?   

The Allure and the Alarm Bells

I can definitely see the appeal. It sounds fun, potentially lowering the barrier to entry for software creation and offering a fascinating avenue for exploring AI capabilities. Imagine describing an app idea and having a functional starting point within minutes!   

However, based on my experience and reading, I'm not convinced it's a truly viable solution just yet. Why the hesitation?   

It Often Doesn't "Just Work": Getting AI-generated code that runs correctly the first time seems to be the exception, not the rule. It often takes several tries, tweaking prompts to get something functional.   

Functionality vs. Intent: Even if the code runs, does it actually do what you intended? That's another hurdle where luck plays a big role.   

The Amendment Nightmare: Here's the real kicker for me: trying to modify or fix AI-generated code. If you stick with vibe coding, you could end up in an endless loop of refining prompts for a single feature. Try to dive in manually? You might find code that, while functional, is baffling, overly rigid because it stuck too literally to your prompt, or just plain inefficient.   

So, Where Do We Stand?

Vibe coding is undeniably intriguing. As a tool for rapid prototyping, learning, or exploring AI's coding prowess, it has potential. But relying on it for serious development seems fraught with challenges, particularly when it comes to refinement and maintenance.   

Perhaps it's less about replacing traditional coding and more about augmenting it – a powerful assistant, but one whose work needs careful scrutiny and often, significant manual intervention.

What are your thoughts? Have you tried vibe coding? Is it the future, a fleeting trend, or something in between? Let me know in the comments!