[Neo] AI? You mean Artificial Intelligence?
[Morpheus] No, I mean Angsty Incompetent. You're a f***ing geek and you have to ask what AI means? Here's the blue pill, get the f*** outta here.
Ahem.
The idea is that a primitive AI system could simplify a lot of programming required of hardware systems. It's similar to teaching a pet to do a trick. You show the desired result, and the primitive intelligence learns. You could teach a visual identification system to allow a certain person in, and their built-in facial recognition software and hardware takes care of the rest.
This builds on another theory of mine: programs are essentially beings of primitive intelligence. I saw a bird circling over the same spot, and imagined it similar to an anti-burglar sensor. It takes a snapshot of the area, and if anything changes, act upon that change.
To expand a bit, the AI would require the needed hardware and software to observe objects as desired. Going back to the visual identification system example, it would first need the proper hardware and software required to make distinctions between faces. Once this is accomplished, then the learning may take place.
2008-10-21
IDEA: Simple vs. complex processes
The idea running through my head is that I may, at some point, release software to the public that a company I work for deems as their own property. This brings up the idea regarding copyrighting and/or patenting software, which extends into the idea of copyrighting and/or patenting a simple idea.
Consider the following situations:
- Two people write books about a wizard that comes of age and defeats a wizard seeking a legendary "Philosopher's Stone". One writes a story that is marginally interesting and acquires little notice. The other story is written by J. K. Rowling.
- A coder writes a piece of code that is determined to be very useful. The company he is working for uses this code extensively, and it is a central part of their product. Said coder releases this code to the world in a package that in no way reflects the company product. Said company claims the coder violated a non-disclosure agreement, and is liable for damage in an attempt to thwart a copyright or patent on the software.
- You eat a bowl of cereal by pouring cereal into a bowl, pouring in some milk, then using a spoon to eat it. Then someone patents this process, and demands money in some way to compensate for use of their proprietary process
You see how silly this gets?
The worst part is that it is hard to determine the dividing line between a "commonly reachable" idea, and one that has a unique structure that should be protected. With human language, complexity increases with each word used. With constructs, the "parts" tend to be much larger, and therefore do not constitute a "complex" object until the object becomes quite large.
Food for thought.
Consider the following situations:
- Two people write books about a wizard that comes of age and defeats a wizard seeking a legendary "Philosopher's Stone". One writes a story that is marginally interesting and acquires little notice. The other story is written by J. K. Rowling.
- A coder writes a piece of code that is determined to be very useful. The company he is working for uses this code extensively, and it is a central part of their product. Said coder releases this code to the world in a package that in no way reflects the company product. Said company claims the coder violated a non-disclosure agreement, and is liable for damage in an attempt to thwart a copyright or patent on the software.
- You eat a bowl of cereal by pouring cereal into a bowl, pouring in some milk, then using a spoon to eat it. Then someone patents this process, and demands money in some way to compensate for use of their proprietary process
You see how silly this gets?
The worst part is that it is hard to determine the dividing line between a "commonly reachable" idea, and one that has a unique structure that should be protected. With human language, complexity increases with each word used. With constructs, the "parts" tend to be much larger, and therefore do not constitute a "complex" object until the object becomes quite large.
Food for thought.
MISSING: Try-before-you-buy stores
This is my first entry in the MISSING category, and it encompasses any kind of try-before-you-buy store. Here are the most prominent categories:
- video games (more specifically the games themselves, not the systems
- headphones
- "consumer electronics" (e.g. mp3 player)
I understand that it's likely you can ask a sales associate to demonstrate some of these, but that's a lot of hassle for something you may not buy, and then you have to deal with the social pressure of having the salesperson right in front of you to refuse.
I'm the kind of shopper that wants to be left alone. If I have a pressing question, then I will seek out assistance. Therefore, I'm very interested in having the ability to try things like these before buying them.
- video games (more specifically the games themselves, not the systems
- headphones
- "consumer electronics" (e.g. mp3 player)
I understand that it's likely you can ask a sales associate to demonstrate some of these, but that's a lot of hassle for something you may not buy, and then you have to deal with the social pressure of having the salesperson right in front of you to refuse.
I'm the kind of shopper that wants to be left alone. If I have a pressing question, then I will seek out assistance. Therefore, I'm very interested in having the ability to try things like these before buying them.
CODING: Getting computers to understand human speech
One bit of coding I have in mind to develop (public license of course) is a kind of language interpreter.
The premise: why can't we tell our computers what to do instead of moving around a mouse and typing on a keyboard?
As far as simple sentences go, it shouldn't be hard. The only difficult piece will be code that converts spoken words to text that the computer can parse, e.g. ANSI (or ASCII?)
After that, it comes down to linguistic rules. Here is an example, using two languages to show versatility.
Rule for identifying the weekday:
English:
Japanese:
Rule for {weekday} (with a pipe "|" indiciating "or"):
Rule for {sunday}:
English:
Japanese:
Same for the other days of the week.
For possible mis-translations, the pattern would be something like this:
When the rule matches something said by the user, you could use logic like the following:
And it would follow for the rest of the weekdays.
This somewhat mimics human memory recall. If a person asked what day it was, upon hearing an answer, their mind would search through their memory for things to remember on that particular day.
The premise: why can't we tell our computers what to do instead of moving around a mouse and typing on a keyboard?
As far as simple sentences go, it shouldn't be hard. The only difficult piece will be code that converts spoken words to text that the computer can parse, e.g. ANSI (or ASCII?)
After that, it comes down to linguistic rules. Here is an example, using two languages to show versatility.
Rule for identifying the weekday:
English:
"Today is {weekday}"Japanese:
"Kyou wa {weekday} desu"Rule for {weekday} (with a pipe "|" indiciating "or"):
"{sunday}|{monday}|..."
Rule for {sunday}:
English:
"sunday"Japanese:
"nichiyoubi"Same for the other days of the week.
For possible mis-translations, the pattern would be something like this:
"sunday|(sunny day)|..."
When the rule matches something said by the user, you could use logic like the following:
if ({Today rule hit})
if ({weekday} = {sunday})
{code for sunday}
And it would follow for the rest of the weekdays.
This somewhat mimics human memory recall. If a person asked what day it was, upon hearing an answer, their mind would search through their memory for things to remember on that particular day.
2008-08-20
USER FRIENDLY: Make ALL non-critical dialog boxes optional
Just a quick comment after being "warned" by Excel about something for the umpteenth time, it would be great to have non-critical dialog boxes be optional.
For implementation, when the warning comes up the first time, have a checkbox to indicate that it should/should not be shown the next time. To turn a dialog box back on, the options would have a list of possible dialog box messages, with a help link to show what the popup looks like.
I realize there could be an issue where a person remembers where a popup was, but not what it said, and that searching through a large list for the message would be difficult. Just wanted to relate the idea
For implementation, when the warning comes up the first time, have a checkbox to indicate that it should/should not be shown the next time. To turn a dialog box back on, the options would have a list of possible dialog box messages, with a help link to show what the popup looks like.
I realize there could be an issue where a person remembers where a popup was, but not what it said, and that searching through a large list for the message would be difficult. Just wanted to relate the idea
2008-04-24
IDEA: Teaching web sites how to ask for information
Quick idea, since I'm at work and supposed to be "working". Also, this is kind of more than a concept than a well-thought-out plan.
The idea is this: rather than spending time coding web site forms and the server code to process the information, is it a better idea to "teach" the server how to ask for information in a general sense?
For example, you teach the server how to ask for a simple text answer, like a name. Then you tell the server "OK, I need some text answers from the user, with the labels "Name", "Address" and "Email". Then the server takes that information, and handles everything by itself. No need to code HTML forms or write code to process the information once submitted.
As I said, I haven't had time to flesh out the details, but I'm hoping it would make things easier. For those in the industry, it's similar to how phpMyAdmin seems to work (for all I know, it doesn't teach the server anything), just in a more user-friendly format.
The idea is this: rather than spending time coding web site forms and the server code to process the information, is it a better idea to "teach" the server how to ask for information in a general sense?
For example, you teach the server how to ask for a simple text answer, like a name. Then you tell the server "OK, I need some text answers from the user, with the labels "Name", "Address" and "Email". Then the server takes that information, and handles everything by itself. No need to code HTML forms or write code to process the information once submitted.
As I said, I haven't had time to flesh out the details, but I'm hoping it would make things easier. For those in the industry, it's similar to how phpMyAdmin seems to work (for all I know, it doesn't teach the server anything), just in a more user-friendly format.
2007-12-17
IDEA: Why don't computers do what we want?
Today, I was working on something for my job, and encountered a quirk with an application I was using, where the application did something I didn't want it to do. As I grumbled in my mind about the small frustration, something occurred to me.
Are we working toward designing applications so that they either know exactly what we're trying to do, are smart enough to figure out what we're trying to do, and will accept help to figure out what we're trying to do?
I will try to remember to add more to this post later, but feel free to comment in the meantime.
Are we working toward designing applications so that they either know exactly what we're trying to do, are smart enough to figure out what we're trying to do, and will accept help to figure out what we're trying to do?
I will try to remember to add more to this post later, but feel free to comment in the meantime.
Subscribe to:
Posts (Atom)