Business Tech: AI and DSS (Part I)

In science fiction, we see all sorts of Artificial Intelligences (AI) who seem to want to be humans or want to replace humans. I've met humans. If that's their goal, the intelligence part might not be that strong. We're going to take a medium-deep dive into AI and Decision Support Systems (DSS). Most of it won't be language or database specific, but all of it can be done in MultiValue.
Smarter Animals
One of the basic AI examples is a very simplistic learning program called Animals. I like this example because it turns to ruin relatively quickly and that's something you need to understand about AI, especially when it is used for DSS. The odds of doing it wrong are surprisingly high. This is just one reason I can't see a computer AI wanting to be human.
This programming idea has long roots. For example, here's a link to the Univac assembler version of the program: http://www.fourmilab.ch/documents/univac/animalsrc.html .
The code for Animals is easy to create in any language. Here it is in Perl http://www.perlmonks.org/?node_id=195991 . Here's the vanilla MultIValue code so that you can try it yourself:

      *       * Animals (AI)       * by Charles Barouch       * 01/01/17       * ********       open 'HDWP.LOGIC' to logic.file else          exec.str = 'CREATE-FILE HDWP.LOGIC';* You may need parameters here          crt exec.str          execute exec.str          open 'HDWP.LOGIC' to logic.file else abort 201, 'HDWP.LOGIC'          logic.rec = 'CAT':@am:'DOES YOUR ANIMAL MEOW':@am:2          write logic.rec on logic.file, 1          logic.rec = 'DOG'          write logic.rec on logic.file, 2       end       open 'DICT', 'HDWP.LOGIC' to logic.dfile else abort 201,'DICT HDWP.LOGIC'       *       logic.id = 1       done = 0       loop          read logic.rec from logic.file, logic.id then             if logic.rec<2> # '' then                gosub ask.question             end else                gosub guess             end          end       until done do       repeat       *       stop       *       * start of subroutines       *
ask.question:       loop          crt LOGIC.REC<2>:' (Y/N) ':          input YN       until index('*YN',YN,1) > 1 do       repeat       begin case          case YN = 'Y'             gosub guess          case LOGIC.REC<3> = ''             gosub get.difference          case 1             LOGIC.ID = LOGIC.REC<3>       end case       return       *
guess:       loop          crt 'Is this your animal: ' : LOGIC.REC<1>:' (Y/N) ':          input YN       until index('*YN',YN,1) > 1 do       repeat       begin case          case YN = 'Y'             gosub win          case LOGIC.REC<3> = ''             gosub get.difference          case 1             LOGIC.ID = LOGIC.REC<3>       end case       return       *
get.difference:       crt 'What is your animal? ':       input name       crt 'Give me a question I can ask to pick ' : LOGIC.REC<1>: ' instead of ': name:       input diff       *       read nxt.no from logic.dfile, 'nxt.no' else nxt.no = 3       logic.rec<2> = diff       logic.rec<3> = nxt.no       write logic.rec on logic.file, logic.id       *       logic.rec = name       write logic.rec on logic.file, nxt.no       write nxt.no+1 on logic.dfile, 'nxt.no'       crt 'Thanks for playing! I learned something'       done = 1       return       *
win:       crt 'I win!'       DONE = 1       return       *       END ;* Physical End of File

Spend a little time playing Animals and you'll notice that pig, for example, might end up on multiple paths. While that does mimic the real world (i.e. there's more than one way to guess your way to pig) , it makes for a messy database very quickly. Can we code some synergy back in to fix that? Yes. Yes we can. Can that lead to asking duplicate questions? Yes. As you play it, you'll see the flaws. This is a hands-on exercise. Can we code around the duplicates? Yes. Indexes, combined with some fuzzy compares ("Does it has claws?" and "Do they have claws?" are the same question, for example; we need an AI smart enough to see that) can solve this. And that will create the next problem: too many dead ends. And so it goes.
If creating a simple game like this looks like an endless spiral descent, how can we ever hope to create something more complicated?
Combined Pricing
In one of my previous lives, I consulted for a company that made additives for plastic. What does that mean? It means that they owned the formula for making Tide bottles the right shade of orange. It means that when you smell the Johnsons & Johnsons' Baby Powder, you are smelling their additive — the bottle is sealed — you aren't actually smelling the contents. This was a company who sold their product with a unit of measure based on the size of commercial railway shipping cars.
The problem they had was pricing. Shipping a half-car's worth of midnight black additive was just as expensive as shipping as a full-car, so they would discount other products to get you up to full-car orders. This meant that if you ordered a half-car of rust red additive and then filled the remainder with a quarter car's worth of cobalt blue additive and a quarter of midnight black, you might get a different price than if you started with cobalt blue then added the other two with the 'fill the car' discount. Worse, different sales staff worked the calculations differently. There was wiggle room, so that the computer would accept the negotiated prices.
The company wanted a DSS where you could fill-in the entire order and have it optimize the discounts, either favoring them or favoring the client, based on the relationship. Slow payer, small buys, and new customers got lesser deals while the biggest and most loyal got the best discounts.
For this project I needed an algorithm which gave an array of valid answers and then picked one based on the profile. If you think about it, there's really no AI here. This is not intelligence because it should not learn in the AI sense. All it needs to do is brute force: calculate every possible deal. In the midnight/rust/cobalt example, there are only six solutions: (1) midnight then rust then cobalt, (2) midnight then cobalt then rust, (3) rust then cobalt then midnight, (4) rust then midnight then cobalt, (5) cobalt then midnight then rust, (6) cobalt then rust then midnight. Once we have the six solutions, we rank the buyer and give them the one they qualify for. This is DSS but it really isn't AI. At the end of the day, combined pricing was easier than coding animals.
Buying a Hard Drive
Let's take a better example. This is a simple one. Spoiler alert, nothing is simple. I want to buy a hard drive from the local computer store. I need it for my laptop and I want one terabyte. The query equivalent of my question might look something like: SELECT INVENTORY IF TYPE = "HARDDRIVE" AND IF FORMFACTOR = "2.5" AND IF CAPACITY = "1TB." How is the query different than the question? The query will select all the possible drives but I'm only looking to buy one. The missing element is analysis. That's a big difference. No one, statistically speaking, wants to buy one of each. This is where AI can serve us well.
For example, we could take the hundred and six drives that the query returned and put them up as a web page. When the requestor does a compare, we do an analysis of why they might have been drawn to those drives. If they were the cheapest, we know to re-organize the results by ascending price next time this requester looks for drives. If they were the fastest, we could work with that, too. The more he or she pokes around, the more data you gather. Likewise, we weigh-in the purchases, not just the compares.
A million customers later, you can average peoples' experiences to make some assumptions about new buyers based on the previous ones. Then we can layer on the Amazon-style people-who-bought-this logic. Of course, the query itself needs a sprinkling of AI. I said one terabyte but a good AI would know that nine-fifty meg drives might be worth listing. Of course, up-selling is good too, which would put a few higher capacity drives on the list, just like a human salesperson would.
With a little effort, we could make a smart laptop drive recommendation system. That's not what we want. It needs to be more general. That, in turn, complexifies things. Desktop, NAS, and server drives need different rules than laptop drives. For example, RAID might be an issue in these less portable devices. FORMFACTOR is more than just a criteria; it is the key to deciding which secondary rules should be considered.
Likewise, it is easy to fall into false equivalences. Memory also has speeds, but hard drives measure speeds in RPMs where RAM doesn't. Computer enclosures also have capacity but measure size in bays and slots, not bytes.
The reason we don't just want to make an assumption about what to present and how to order it is simple: lost sales. When Joe is adding a drive to his personal machine, he might be looser on price but really care about speed. Sandra is all about MTBF (Mean time between failures) because she's building mission-critical servers. Jenny, on the other hand, is cranking out three to five machines a day, so even a dollar difference in the price of a component is something that will add up rapidly when you look at the thousand or more machines she'll build this year.
A good sales associate knows that one-size does not fit all, neither in product nor in sales approach. If our AI is really good, it won't just reduce selections (tailoring) and optimize the order it presents them in, it will also see the bulk/frequent buyer, like Jenny, differently than it will Joe. Jenny should be offered loyalty discounts and price structures that encourage her to stock up instead of buying as-needed. You might even offer her discounts if she puts your logo on her marketing materials.
You can see that AI isn't just a gimmick, like faster sorting or smarter selects. The thing which makes it AI is the adaptive nature. AI learns. And to write AIs, we must also learn.
Next issue we'll talk about the dystopian fiction of evil AIs and show you how MultiValue envy is the secret weapon destined to keep humans on top.