Cast your mind back... way back... okay, no, not that far, put the dinosaurs away and bring your mind forward a little... and... there we go.
We're in 1666. To be precise, it's September 6th, 1666. And it's Monday. Oh, and London stopped burning down yesterday.
In a bid to prevent that happening again things need to change, and one of those things was to start cleaning out chimneys on a regular basis. With children. Because they fit. And it turns out they are very cheap and will work long hours.
Bring your mind forward some 209 years. It's now September 1875. I don't know the precise date, nor the day. What I do know, is the Chimney Sweepers' Act of 1875 just got passed and now, at least throughout England, you're not allowed to go stuffing small children up chimney's to keep them clean.
What to do!?
Brushes. Brushes on a long stick. A very long extendable stick. That works, and with the dawn of the vacuum cleaner nearing, things are about to get a lot cleaner.
Well, that's been about it. Some improvements on the fuels being burned help improve the reduction of waste, smoke, tar build-up, and all manner of bad things; though fundamentally, there's a lot of cleaning that still needs to be done.
So it's about time for some innovation in chimney sweeping!
Roll up, roll up... here comes the robotic chimney sweeper.
I have a couple of concepts in mind:
Chimney Drone:
A drone-like bot that stays suspended in the chimney with extended rods that keep it positioned in the chimney and the drone moves up and down the chimney monitoring and cleaning as necessary; staying out of the way of the heat.
Chimney Bug:
A bug-like bot that sticks to the chimney wall and travels around the chimney continually monitoring and cleaning.
Both will monitor airflow and temperatures, toxin build-up, and have lights and cameras for monitoring the internal structure of the chimneys.
Concept (c) 2019 letsbuildathing.com
A thing about inventions, innovation, technology, and the random thoughts of a guy that dreams more than he sleeps, and thinks out loud between the real, the possible, the surreal, and often the plain old silly world we find ourselves inhabiting for a blink in time.
Ko-fi
Thursday, 21 February 2019
Wednesday, 20 February 2019
Data folding... yet another compression method
Recently, I wrote about a compression technique I've called "Iteratively Sequenced Data Compression" making magnificent claims about the level of compression it could attain.
I have another compression technique using [spoiler alert!] folded data structures. I'll explain what I mean by that shortly.
For this technique I won't bore you with a back-history of how I got involved in data compression, nor will I make claim to impressive compression ratios because this, currently, is a little more theoretical.
It's important to remember that when it comes to data compression, we don't really care about the data itself. The data itself can go in the trashcan because it's probably too big - after all, that's why we're looking to compress it right?! All we need is to remember is how to reconstruct the data once we're done forgetting about it. That bit is really important. So important in fact, it deserves a line of its own.
Forget the data; just remember how to reconstruct it.
So, with that in mind, what do I mean by folded data structures?
Imagine you have your data in one nice long strip. Easy enough.
Now imagine you start wrapping that data into rows, essentially like word-wrap on your fave text editor. Also easy.
Okay, so now imagine you had that data printed out on a piece of paper. Also not difficult to imagine.
Hold tight folks, here's where it starts to get a little more tricky.
Now look for a way of folding that piece of paper such that you align common values and drive a skewer through the paper to hold all those matched values in one place.
Let's further imagine you tried folding that piece of paper many different ways until you landed on the optimal folds to get the maximum continuous strip of values on your skewer.
Remember the value you skewered and the folding pattern. That's your first folded data item.
You can forget about that chunk of data now, so go ahead and erase all the data you just skewered from your piece of paper.
Go ahead and repeat this process of finding the optimal fold; remember the value and the folding pattern. That's your second folded data item. Forget the data you just skewered from the page.
Do it again. That's your third. Keep repeating this until you have skewered all your data.
You will find that as you reduce the data by skewering it off the page, your folding patterns become easier to spot, and less complex, so the process becomes faster the more you work through the page.
Once you've got all your folded data items, simply concatenate them and pop them in a small file.
Easy!
All you've had to remember is the skewered value and the folding pattern; which can then be unfolded back out all the way back out to that continuous stream of data that you started with.
So what this technique effectively does is allow you to do run-length-encoding across a landscape of data that, as a continuous strip, could not make the best use of high run lengths; which is therefore sub-optimal. By folding (or crinkling) the data in the right way, you can maximise your run-lengths to get highly effective compression.
Hypothesis:
I have another compression technique using [spoiler alert!] folded data structures. I'll explain what I mean by that shortly.
For this technique I won't bore you with a back-history of how I got involved in data compression, nor will I make claim to impressive compression ratios because this, currently, is a little more theoretical.
It's important to remember that when it comes to data compression, we don't really care about the data itself. The data itself can go in the trashcan because it's probably too big - after all, that's why we're looking to compress it right?! All we need is to remember is how to reconstruct the data once we're done forgetting about it. That bit is really important. So important in fact, it deserves a line of its own.
Forget the data; just remember how to reconstruct it.
So, with that in mind, what do I mean by folded data structures?
Imagine you have your data in one nice long strip. Easy enough.
Now imagine you start wrapping that data into rows, essentially like word-wrap on your fave text editor. Also easy.
Okay, so now imagine you had that data printed out on a piece of paper. Also not difficult to imagine.
Hold tight folks, here's where it starts to get a little more tricky.
Now look for a way of folding that piece of paper such that you align common values and drive a skewer through the paper to hold all those matched values in one place.
Let's further imagine you tried folding that piece of paper many different ways until you landed on the optimal folds to get the maximum continuous strip of values on your skewer.
Remember the value you skewered and the folding pattern. That's your first folded data item.
You can forget about that chunk of data now, so go ahead and erase all the data you just skewered from your piece of paper.
Go ahead and repeat this process of finding the optimal fold; remember the value and the folding pattern. That's your second folded data item. Forget the data you just skewered from the page.
Do it again. That's your third. Keep repeating this until you have skewered all your data.
You will find that as you reduce the data by skewering it off the page, your folding patterns become easier to spot, and less complex, so the process becomes faster the more you work through the page.
Once you've got all your folded data items, simply concatenate them and pop them in a small file.
Easy!
All you've had to remember is the skewered value and the folding pattern; which can then be unfolded back out all the way back out to that continuous stream of data that you started with.
So what this technique effectively does is allow you to do run-length-encoding across a landscape of data that, as a continuous strip, could not make the best use of high run lengths; which is therefore sub-optimal. By folding (or crinkling) the data in the right way, you can maximise your run-lengths to get highly effective compression.
Hypothesis:
- Compression will be intensive and slow, whereas decompression will be fast.
- Splicing byte values to enable layering of data prior to folding would improve compression and performance.
- The compression method could be iterative to produce progressively smaller content.
Concept (c) 2019 letsbuildathing.com
Tuesday, 19 February 2019
When you need "big" and infinity is "too big"
Today I came across a lazy calculator. I asked it a simple enough question, and in response, I was informed that the answer was "infinite"... and that is a wrong answer.
It is not infinite. It is just big. Really big. Some would even say mind-bogglingly big.
The fact is, the calculator was lazy and just could not be bothered to work it out. The thing is, I use calculators to get accurate answers fast. I don't expect my digital buddies to be workshy.
I would have preferred it display the shrugging emoji than an infinite symbol because that would have at least been truthful, and amusing.
Therefore, we need a new symbol for "not as big as infinite, just mind-bogglingly big, so big we won't even work it out, so let's just look at this snazzy symbol instead, kinda big"... you know, for when the shrugging emoji guy just won't cut it.
To which, I have come up with this:
Besides, I really need the answer to not be infinite because I'm writing some code and need to reserve a chunk of memory and my calculation was to tell me precisely how much memory I need, and well, I suspect asking to reserve an infinite amount of memory will not have a favourable outcome.
>Hey, computer: Remember all the stuff
Nope.
>_
It is not infinite. It is just big. Really big. Some would even say mind-bogglingly big.
The fact is, the calculator was lazy and just could not be bothered to work it out. The thing is, I use calculators to get accurate answers fast. I don't expect my digital buddies to be workshy.
I would have preferred it display the shrugging emoji than an infinite symbol because that would have at least been truthful, and amusing.
Therefore, we need a new symbol for "not as big as infinite, just mind-bogglingly big, so big we won't even work it out, so let's just look at this snazzy symbol instead, kinda big"... you know, for when the shrugging emoji guy just won't cut it.
To which, I have come up with this:
The Less Than Infinity Symbol |
Besides, I really need the answer to not be infinite because I'm writing some code and need to reserve a chunk of memory and my calculation was to tell me precisely how much memory I need, and well, I suspect asking to reserve an infinite amount of memory will not have a favourable outcome.
>Hey, computer: Remember all the stuff
Nope.
>_
Friday, 15 February 2019
Iteratively Sequenced Data Compression
I first came across data compression back in the 1980s, some 5 or 6 years after first being awestruck by this thing called a computer.
At the time I was very young, and these computer things were new - and, by all accounts, a pretty big deal. I was fortunate enough to have one at home that I shared with my brother. It was a BBC Micro Model-B from Acorn Computers. Go Acorn!
It was awesome.
This thing was competing with a trusty BMX, He-Man, haunted house exploring, and lots of shenanigans. So it really did have to be awesome to get a look in.
It had 8K of memory. Eight freaking K. An unimaginably large number of transistors that you couldn't dream of filling! Right? Well, no. It turns out that you run out of 8K memory pretty fast... even back in the day.
Back then I was writing 6502 assembly language, dabbling in the 8-bit games industry, designing graphics on graph paper with a pencil (until I wrote a frickin' nifty sprite editor), and maps, because dammit, I was a games programmer! High school and night classes at college were just a necessary pastime. Game programming. That was going to be my life.
And then in 1988 Superior Software brought out an amazing new game called Exile. It was literally a game changer - no pun intended. It was a great game, with many hours and fond memories with buddies spent trying to get to the end of it. I believe it was the first, or one of the first games, that sported an early physics engine... gravity and inertia at least. It was amazing. The graphics were, by 8-bit 8-colour standards, intricate and plentiful. The map was huge. It broke so many rules of what was possible.
All of that was, of course, fascinating and made for a great game.
Only I like to learn and tinker. So tinker and learn I did.
One of the claims that this game made was around the size of the graphics, the size of the sound, and the map. The numbers were staggering - significantly more than 8K!
Whoa!?
How does that work, I thought. It won't fit.
I pondered.
I reached out to friends.
We pondered together.
It did not make sense.
Back then, there was no Internet. There was not an endless amount of resources, or of people doing this stuff to reach out to, especially not outside of universities.
So I took to doing what I would always do in these scenarios. Take it apart. Take a look. Figure out what the hell was going on.
I was pretty resourceful when it came to getting into computers and code, and by this time I was a dab hand at reading machine code; not just assembly language, I mean actual hexadecimal compiled code and understanding exactly what it was up to - often printed out on reams of dot matrix printer paper that I would read travelling about in the back of my parents awesome Rover 2600. Pretty geeky. To be fair, 6502 machine code was a hell of a lot more simple compared to today's machine code, and you had to know it back then to figure out clock cycles and see where you could save the odd millisecond.
Anyway, the point is, Superior Software got all of this content that was bigger than the thing it was going in to by using compression. I genuinely agonized for some time how a bit would get smaller than a one or a zero, came to the conclusion it couldn't, so went to the byte level, and I was still stuck. So then I did some tinkering. You may choose to call it hacking. Whatevs. That, along with talking it through with a buddy, came up with the realisation of what is now known as RLE; run-length encoding.
It's a very basic compression technique whereby you don't store the data itself, rather, you store the pattern of data.
Mindblown.
You don't store the data.
Mind. Blown.
These days it's unbelievably obvious of course and a very basic algo.
Data is quite often a series of the same value, particularly in graphics, maps, and sound. So for example, instead of storing 28 zero's for a strip of black in your image, you store the number 28, followed by the number 0. Then your code decompresses it by reading the 28, 0, and expands it back out to 28 occurrences of 0. The thing is, you only stored two bytes (the 28 and the 0) instead of 28 bytes (28 consecutive 0's). So if you do that across your entire set of graphics, sound, and map data, you get something big into a smaller space.
Easy.
Or rather, easy when you know how.
So... that's a very long intro to a possible new compression technique that, I hasten to add, would make a pretty neat TED talk intro. The important part to take away is this...
You don't store the data.
So I've concluded that if we don't care about the data, and we're never truly going to store the data, and we want lossless compression, well then, let's not even go down that path. Let's not figure out clever algorithms to look at data in different ways - for example looking in cubic data not strips of data; losing quality by deciding on a loss factor and figuring out if the value is "close enough" for the loss, or breaking graphical data into meaningful slices, e.g. filter the red component of the RGB values, compress, then do green, and so on and so forth... there are many techniques.
Here's the thing...
All we need is an established public library of bit sequences.
I've long held the belief that every image, and indeed every sound, can be generated through tedious incremental change; therefore all the patterns of data already exist.
To that point; all data that will exist already exists.
Don't dwell on that, just run with it and maybe I will write about that some other time.
To record massive data sets as single sequences would be borderline silly because of the indexing time required. So we break the full data set into sensible, optimised, chunks. Then we simply index them against our established public sequence library. We do not store the sequence library itself because they are established public sequences, and remember; we do not store the data.
Then you repeat the process on your newly generated sequence because there will be a public library sequence for that too. You continue to repeat the process until you have an incredibly tiny amount of metadata where all you need to store is the iteration depth and the sequence numbers starting with the seed sequence. Decompression would be the reverse process.
The resulting compressed data only ever consists of metadata to describe what the data was when it did exist.
The public sequence library would contain multiple sequence lengths, so you would check your data size, compare it to the library length that best fits, and as you iterate and compress you step back to the next smallest size until you run out of practical compression.
So depending upon the chunk size for the sequences, a multi-gigabyte file could easily be compressed to a few kilobytes at most, possibly even bytes.
Imagine being able to download an entire UHD film in mere seconds over the crappiest of narrow bandwidth, and saving a decade's worth of images on a tiny drive.
That would be awesome.
Concept (c) 2019 letsbuildathing.com
At the time I was very young, and these computer things were new - and, by all accounts, a pretty big deal. I was fortunate enough to have one at home that I shared with my brother. It was a BBC Micro Model-B from Acorn Computers. Go Acorn!
It was awesome.
This thing was competing with a trusty BMX, He-Man, haunted house exploring, and lots of shenanigans. So it really did have to be awesome to get a look in.
It had 8K of memory. Eight freaking K. An unimaginably large number of transistors that you couldn't dream of filling! Right? Well, no. It turns out that you run out of 8K memory pretty fast... even back in the day.
Back then I was writing 6502 assembly language, dabbling in the 8-bit games industry, designing graphics on graph paper with a pencil (until I wrote a frickin' nifty sprite editor), and maps, because dammit, I was a games programmer! High school and night classes at college were just a necessary pastime. Game programming. That was going to be my life.
And then in 1988 Superior Software brought out an amazing new game called Exile. It was literally a game changer - no pun intended. It was a great game, with many hours and fond memories with buddies spent trying to get to the end of it. I believe it was the first, or one of the first games, that sported an early physics engine... gravity and inertia at least. It was amazing. The graphics were, by 8-bit 8-colour standards, intricate and plentiful. The map was huge. It broke so many rules of what was possible.
All of that was, of course, fascinating and made for a great game.
Only I like to learn and tinker. So tinker and learn I did.
One of the claims that this game made was around the size of the graphics, the size of the sound, and the map. The numbers were staggering - significantly more than 8K!
Whoa!?
How does that work, I thought. It won't fit.
I pondered.
I reached out to friends.
We pondered together.
It did not make sense.
Back then, there was no Internet. There was not an endless amount of resources, or of people doing this stuff to reach out to, especially not outside of universities.
So I took to doing what I would always do in these scenarios. Take it apart. Take a look. Figure out what the hell was going on.
I was pretty resourceful when it came to getting into computers and code, and by this time I was a dab hand at reading machine code; not just assembly language, I mean actual hexadecimal compiled code and understanding exactly what it was up to - often printed out on reams of dot matrix printer paper that I would read travelling about in the back of my parents awesome Rover 2600. Pretty geeky. To be fair, 6502 machine code was a hell of a lot more simple compared to today's machine code, and you had to know it back then to figure out clock cycles and see where you could save the odd millisecond.
Anyway, the point is, Superior Software got all of this content that was bigger than the thing it was going in to by using compression. I genuinely agonized for some time how a bit would get smaller than a one or a zero, came to the conclusion it couldn't, so went to the byte level, and I was still stuck. So then I did some tinkering. You may choose to call it hacking. Whatevs. That, along with talking it through with a buddy, came up with the realisation of what is now known as RLE; run-length encoding.
It's a very basic compression technique whereby you don't store the data itself, rather, you store the pattern of data.
Mindblown.
You don't store the data.
Mind. Blown.
These days it's unbelievably obvious of course and a very basic algo.
Data is quite often a series of the same value, particularly in graphics, maps, and sound. So for example, instead of storing 28 zero's for a strip of black in your image, you store the number 28, followed by the number 0. Then your code decompresses it by reading the 28, 0, and expands it back out to 28 occurrences of 0. The thing is, you only stored two bytes (the 28 and the 0) instead of 28 bytes (28 consecutive 0's). So if you do that across your entire set of graphics, sound, and map data, you get something big into a smaller space.
Easy.
Or rather, easy when you know how.
So... that's a very long intro to a possible new compression technique that, I hasten to add, would make a pretty neat TED talk intro. The important part to take away is this...
You don't store the data.
So I've concluded that if we don't care about the data, and we're never truly going to store the data, and we want lossless compression, well then, let's not even go down that path. Let's not figure out clever algorithms to look at data in different ways - for example looking in cubic data not strips of data; losing quality by deciding on a loss factor and figuring out if the value is "close enough" for the loss, or breaking graphical data into meaningful slices, e.g. filter the red component of the RGB values, compress, then do green, and so on and so forth... there are many techniques.
Here's the thing...
All we need is an established public library of bit sequences.
I've long held the belief that every image, and indeed every sound, can be generated through tedious incremental change; therefore all the patterns of data already exist.
To that point; all data that will exist already exists.
Don't dwell on that, just run with it and maybe I will write about that some other time.
To record massive data sets as single sequences would be borderline silly because of the indexing time required. So we break the full data set into sensible, optimised, chunks. Then we simply index them against our established public sequence library. We do not store the sequence library itself because they are established public sequences, and remember; we do not store the data.
Then you repeat the process on your newly generated sequence because there will be a public library sequence for that too. You continue to repeat the process until you have an incredibly tiny amount of metadata where all you need to store is the iteration depth and the sequence numbers starting with the seed sequence. Decompression would be the reverse process.
The resulting compressed data only ever consists of metadata to describe what the data was when it did exist.
The public sequence library would contain multiple sequence lengths, so you would check your data size, compare it to the library length that best fits, and as you iterate and compress you step back to the next smallest size until you run out of practical compression.
So depending upon the chunk size for the sequences, a multi-gigabyte file could easily be compressed to a few kilobytes at most, possibly even bytes.
Imagine being able to download an entire UHD film in mere seconds over the crappiest of narrow bandwidth, and saving a decade's worth of images on a tiny drive.
That would be awesome.
Concept (c) 2019 letsbuildathing.com
Tuesday, 12 February 2019
Digitally Synthesised Telepathy
Telepathy has long been debated and routinely unproven and proven, and has oft been a subject of ridicule; left to sci-fi and the paranormal to explain.
I think it's a very simple concept to comprehend without getting all weirded up.
Telepathy is the ability to communicate between two or more minds without written or oral communication; mind-to-mind communication. The dictionary definition refers to "known senses".
A typical telepathy test would consist of two subjects purporting to be telepathic and an observer. The subjects are not able to see, hear, or "knowingly sense" each other. "Subject A" looks at a randomly selected card with a shape on it. They communicate what they see telepathically to "Subject B", and "Subject B" describes the shape. The observer, well, they observe. They see the card that "Subject A" saw and they validate that "Subject B" describes it accurately. A 100% consistent pass rate over multiple repetitions means that it's possible. Goof it up and it's not possible.
Some argue it's possible. Others argue it's not. Both cohorts will be able to prove their agenda.
Here's the thing...
When people talk about telepathy, what they really mean is "organic-telepathy". The ability of two organic beasties to communicate together. Doesn't have to be humans.
That's the same definition, only I added "organic" to the mix... so you know what's coming up next, right?
Let's talk about "digital-telepathy" for a moment.
Whoa! What!? Digital telepathy!? Pfft.
Okay, okay, wild, I know... wait up though... let's talk about, radio. Let's talk about WiFi. How about Bluetooth? The list goes on.
Yeah, yeah, I hear you definition-sticklers out there... there's no "magic" in this supposed "digital-telepathy" because it's "known" senses. It's clever stuff that has taken a lot of clever minds to master and get to the point we're at now with digital communication.
So if it's not hard to comprehend digital devices communicating without any physical contact potentially across millions of miles (think space stuff floating around out there talking back to Earth) without a problem, then why is it so hard to comprehend that this is not possible to do organically?
Fact: We know there is a lot about our bodies that we don't fully understand yet.
Fact: We know we have body parts that we can't really explain the purpose of (the appendix for example).
Fact: We even have new organs being discovered that we've so far missed (the interstitium for example... for real!)
Fact: We know some people have different physical attributes than others... we're all very similar; we're not the same though, and that's one of the things that makes us all interesting and beautiful in our own ways.
So, how hard is it to imagine that some people may possess the ability to communicate thoughts (data) through a similar method to those that our digital creations already can?
Imagine some people have a "thing" in their body that allows telepathy that others don't. Imagine that we all do, only we don't know that they're there. Imagine that some us know how to use the "thing" and others don't.
It's not that far fetched.
Based on the facts above we could legitimately come to the conclusion it would be nonsense to suggest that it is simply not possible.
Now here's where it can get really interesting...
Imagine that organic-telepathy is possible between species. In a digital-telepathy world, a smartphone happily communicates with a TV or a sound system, or even a printer (really people?! printers... still!?) not just other smartphones.
Imagine an augmented-telepathy world where we've not really mastered or realised organic-telepathy so we augment our bodies with a digital capability to provide digitally-synthesised-telepathy.
Stop! Let's take a moment to marvel at the name "digitally-synthesised-telepathy". Okay, move along...
Shock horror... we're almost there folks! The smart devices that are emerging today are not too distant from digitally-synthesised-telepathy. We can control digital devices through thought - controlling a mouse cursor on a screen through thought alone is practically old hat now. We can communicate through an array of digital technologies. That's so old it's almost dull. We have digitally enhanced experiences all around us. So really, what I'm suggesting, is that we just need to glue a few clever things together and digitally-synthesised-telepathy will be a thing.
Still got an appetite for something even more interesting to ponder over?
Imagine a world where digitally-synthesised-telepathy is here... okay, here goes...
How do we retain our right to privacy?
How do we ensure our thoughts are not hacked?
How do we differentiate between thought and communication? The voice in your head when you read... that's a thing... would digitally-synthesised-telepathy know the difference?
How do we legislate?
How do we avoid pop-up-thoughts becoming a thing, like the pop-up-ads of today?
How do we avoid DDoS (Distributed Denial of Service) style attacks on our inbound comms? Imagine the noise that would create in your mind. Are people suffering from particular mental illnesses actually organic-telepaths that are experiencing a form of organic-telepathy hacking? Those unexplained head-voices might just be a filter-door swinging on the hinges, or being forced open.
It all sounds so very useful and exciting until you start asking the tricky questions.
Concept (c) 2019 letsbuildathing.com
I think it's a very simple concept to comprehend without getting all weirded up.
Ansonlobo [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)], from Wikimedia Commons |
Telepathy is the ability to communicate between two or more minds without written or oral communication; mind-to-mind communication. The dictionary definition refers to "known senses".
A typical telepathy test would consist of two subjects purporting to be telepathic and an observer. The subjects are not able to see, hear, or "knowingly sense" each other. "Subject A" looks at a randomly selected card with a shape on it. They communicate what they see telepathically to "Subject B", and "Subject B" describes the shape. The observer, well, they observe. They see the card that "Subject A" saw and they validate that "Subject B" describes it accurately. A 100% consistent pass rate over multiple repetitions means that it's possible. Goof it up and it's not possible.
Some argue it's possible. Others argue it's not. Both cohorts will be able to prove their agenda.
Here's the thing...
When people talk about telepathy, what they really mean is "organic-telepathy". The ability of two organic beasties to communicate together. Doesn't have to be humans.
That's the same definition, only I added "organic" to the mix... so you know what's coming up next, right?
Let's talk about "digital-telepathy" for a moment.
Whoa! What!? Digital telepathy!? Pfft.
Okay, okay, wild, I know... wait up though... let's talk about, radio. Let's talk about WiFi. How about Bluetooth? The list goes on.
Yeah, yeah, I hear you definition-sticklers out there... there's no "magic" in this supposed "digital-telepathy" because it's "known" senses. It's clever stuff that has taken a lot of clever minds to master and get to the point we're at now with digital communication.
So if it's not hard to comprehend digital devices communicating without any physical contact potentially across millions of miles (think space stuff floating around out there talking back to Earth) without a problem, then why is it so hard to comprehend that this is not possible to do organically?
Fact: We know there is a lot about our bodies that we don't fully understand yet.
Fact: We know we have body parts that we can't really explain the purpose of (the appendix for example).
Fact: We even have new organs being discovered that we've so far missed (the interstitium for example... for real!)
Fact: We know some people have different physical attributes than others... we're all very similar; we're not the same though, and that's one of the things that makes us all interesting and beautiful in our own ways.
So, how hard is it to imagine that some people may possess the ability to communicate thoughts (data) through a similar method to those that our digital creations already can?
Imagine some people have a "thing" in their body that allows telepathy that others don't. Imagine that we all do, only we don't know that they're there. Imagine that some us know how to use the "thing" and others don't.
It's not that far fetched.
Based on the facts above we could legitimately come to the conclusion it would be nonsense to suggest that it is simply not possible.
Now here's where it can get really interesting...
Imagine that organic-telepathy is possible between species. In a digital-telepathy world, a smartphone happily communicates with a TV or a sound system, or even a printer (really people?! printers... still!?) not just other smartphones.
Imagine an augmented-telepathy world where we've not really mastered or realised organic-telepathy so we augment our bodies with a digital capability to provide digitally-synthesised-telepathy.
Stop! Let's take a moment to marvel at the name "digitally-synthesised-telepathy". Okay, move along...
Shock horror... we're almost there folks! The smart devices that are emerging today are not too distant from digitally-synthesised-telepathy. We can control digital devices through thought - controlling a mouse cursor on a screen through thought alone is practically old hat now. We can communicate through an array of digital technologies. That's so old it's almost dull. We have digitally enhanced experiences all around us. So really, what I'm suggesting, is that we just need to glue a few clever things together and digitally-synthesised-telepathy will be a thing.
Still got an appetite for something even more interesting to ponder over?
Imagine a world where digitally-synthesised-telepathy is here... okay, here goes...
How do we retain our right to privacy?
How do we ensure our thoughts are not hacked?
How do we differentiate between thought and communication? The voice in your head when you read... that's a thing... would digitally-synthesised-telepathy know the difference?
How do we legislate?
How do we avoid pop-up-thoughts becoming a thing, like the pop-up-ads of today?
How do we avoid DDoS (Distributed Denial of Service) style attacks on our inbound comms? Imagine the noise that would create in your mind. Are people suffering from particular mental illnesses actually organic-telepaths that are experiencing a form of organic-telepathy hacking? Those unexplained head-voices might just be a filter-door swinging on the hinges, or being forced open.
It all sounds so very useful and exciting until you start asking the tricky questions.
Concept (c) 2019 letsbuildathing.com
Sunday, 3 February 2019
I am not a feminist, and here's why...
I am a guy. I am a dad. I am a son. I've also had the privilege of being a husband.
A dad with daughters. A son to a mum. And a husband to a wife.
For the women in my life, I should be a feminist.
I'm not.
Why?
Because I'm also white. I'm also straight. I am English speaking. I am educated (some may argue otherwise). I am in very little danger of starving (nobody would argue otherwise). I am not in a warzone (yet). I have a home. I'm a little bit Bhudist. I have opportunities.
So because I am all these things as well, I cannot be a feminist.
I am an equalist.
A world without borders does not mean you give up your heritage. A world without poverty does not mean you give up your wealth. A world with an abundance of food and shelter does not mean you will starve and have to surrender your home. A world with mixed language, ethnicity, and belief systems, is just a world with more expression, feelings, and empathy - nobody is forcing you to subscribe to anything different. A world where people are free to love who they love does not make you gay. A world where everybody has the opportunity to receive an education does not make you stupid. A world without war does not make you a peace-lovin' hippie.
Here's the thing...
I want my daughters to grow into themselves, in this world, unconstrained by 'isms that have no place.
I want everybody in my life to. Even those people I don't necessarily get on with, because if they too were living in an unconstrained world, well, perhaps we'd get on better.
So I propose we build a world without 'isms.
This isn't remotely close to a new idea, so maybe we just need to figure out what the problem is and take it from there.
One step at a time.
Because the only way to fail is to not start... and pretending to do something; well, that's not starting.
A dad with daughters. A son to a mum. And a husband to a wife.
For the women in my life, I should be a feminist.
I'm not.
Why?
Because I'm also white. I'm also straight. I am English speaking. I am educated (some may argue otherwise). I am in very little danger of starving (nobody would argue otherwise). I am not in a warzone (yet). I have a home. I'm a little bit Bhudist. I have opportunities.
So because I am all these things as well, I cannot be a feminist.
I am an equalist.
Think. Share. Fix. Change the icons. Repeat. |
A world without borders does not mean you give up your heritage. A world without poverty does not mean you give up your wealth. A world with an abundance of food and shelter does not mean you will starve and have to surrender your home. A world with mixed language, ethnicity, and belief systems, is just a world with more expression, feelings, and empathy - nobody is forcing you to subscribe to anything different. A world where people are free to love who they love does not make you gay. A world where everybody has the opportunity to receive an education does not make you stupid. A world without war does not make you a peace-lovin' hippie.
Here's the thing...
I want my daughters to grow into themselves, in this world, unconstrained by 'isms that have no place.
I want everybody in my life to. Even those people I don't necessarily get on with, because if they too were living in an unconstrained world, well, perhaps we'd get on better.
So I propose we build a world without 'isms.
This isn't remotely close to a new idea, so maybe we just need to figure out what the problem is and take it from there.
One step at a time.
Because the only way to fail is to not start... and pretending to do something; well, that's not starting.
Subscribe to:
Posts (Atom)