Platt Perspective on Business and Technology

Reconsidering Information Systems Infrastructure 10

Posted in business and convergent technologies, reexamining the fundamentals by Timothy Platt on June 20, 2019

This is the 10th posting to a series that I am developing, with a goal of analyzing and discussing how artificial intelligence and the emergence of artificial intelligent agents will transform the electronic and online-enabled information management systems that we have and use. See Ubiquitous Computing and Communications – everywhere all the time 2 and its Page 3 continuation, postings 374 and loosely following for Parts 1-9. And also see two benchmark postings that I initially wrote just over six years apart but that together provided much of the specific impetus for my writing this series: Assumption 6 – The fallacy of the Singularity and the Fallacy of Simple Linear Progression – finding a middle ground and a late 2017 follow-up to that posting.

I have been discussing artificial intelligence agents from a variety of perspectives in this series, turning in Part 9 for example, to at least briefly begin a discussion of neural network and related systems architecture approaches to hardware and software development in that arena. And my goal in that has been to present a consistently, logically organized discussion of a very large and still largely amorphous complex of issues, that in their simplest case implementations are coming to be more fully understood, but that are still open and largely undefined when moving significantly beyond that.

We now have a fairly good idea as to what artificial specialized intelligence is and certainly when that can be encapsulated into rigorously defined starter algorithms and with tightly constrained self-learning capabilities added in, that would primarily just help an agent to “random walk” its way towards greater efficiency in carrying out its specifically defined end-goal tasks. But in a fundamental sense, we are still in the position of standing as if at the edge of an abyss of yet to acquire knowledge and insight, when it comes to dealing with genuinely open-ended tasks such as natural conversation, and the development of artificial agents that can master them.

I begin this posting by reiterating a basic paradigmatic approach that I have offered in other information technology development contexts, and both in this blog and as a consultant, that explicitly applies here too.

• Start with the problem that you seek to solve, and not with the tools that you might use in accomplishing that.

Start with the here-artificial intelligence problem itself that you seek to effectively solve or resolve: the information management and processing task that you seek to accomplish, and plan and design and develop from there. In a standard if perhaps at least somewhat complex-problem context and as a simple case ideal, this means developing an algorithm that would encapsulate and solve a specific, clearly stated problem in detail, and then asking necessary questions as they arise at the software level and then the hardware level, to see what would be needed to carry that out. And ultimately that will mean selecting, designing and building at the hardware level for data storage and accessibility, and for raw computational power requirements and related capabilities that would be needed for this work. And at the software level this would mean selecting programming languages and related information encoding resources that are capable of encoding the algorithm in place and that can manage its requisite data flows as it is carried out. And it means actually encoding all of the functionalities required in that algorithm, in those software tools so as to actually perform the task that it specifies. (Here, I presume in how I state this, as a simplest case scenario, a problem that can in fact be algorithmically defined up-front and without any need for machine learning and algorithm adjustment as better and best solutions are iteratively found for the problem at hand. And I arbitrarily represent the work to be done there as fitting into what might in fact be a very large and complex “single overall task”, and even if carrying it out might lead to very different outcomes depending on what decision points have to be included and addressed there and certainly at a software level. I will, of course, set aside these and several other similar more-simplistic assumptions as this overall narrative proceeds and as I consider the possibilities of more complex artificial intelligence challenges. But I offer this simplified developmental model approach here, as an initial starting point for that further discussion to come.)

• Stepping back to consider the design and development approach that I have just offered here, if just in a simplest application form, this basic task-first and hardware detail-last approach can be applied to essentially any task, problem or challenge that I might address here in this series. I present that point of judgment on my part as an axiomatic given and even when ontological and even evolutionary development, as self-organized and carried out by and within artificial agents carrying out this work, is added into the basic design capabilities developed. There, How details might change but overall Towards What goals would not necessarily do so, unless the overall problem to be addressed in changed or replaced.

So I start with the basic problem-to-software-to-hardware progression that I began this line of discussion with, and continue building from there with it, though with a twist and certainly for artificial intelligence oriented tasks that are of necessity going to be less settled up-front as to their precise algorithms as would ultimately be required. I step back from my more firmly stated a priori assumptions as explicitly outlined above in my simpler case problem solving scenario, that I would continue to assume and pursue as-is in more standard computational or data processing task-to-software-to-hardware computational systems analyses, and certainly where off the shelf resources would not suffice, to add another level of detail there.

• And more specifically here, I argue a case for building flexibility into these overall systems and with the particular requirements that that adds to the above development approach.
• And I argue a case for designing and developing and building overall systems – and explicitly conceived artificial intelligence agents in particular, with an awareness of a need for such flexibility in scale and in design from their initial task specifications step in this development process, and with more and more room for adjustment and systems growth added in, and for self-adjustment within these systems added in for each successive development step as carried out from there too.

I focused in Part 9 on hardware, and on neural network designs and their architecture, at least as might be viewed from a higher conceptual perspective. And I then began this posting by positing in effect, that starting with the hardware and its considerations might be compared to looking through a telescope – but backwards. And I now say that a prospective awareness of increasing resource needs, with next systems-development steps is essential. And that understanding needs to enter into any systems development effort as envisioned here, and from the dawn of any Day 1 in developing and building towards it. This flexibility and its requisite scope and scale change requirements, I add, cannot necessarily be anticipated in advance of its actually being needed, and at any software or hardware level, and certainly not in any detail. So I write here of what might be called flexible flexibility: flexibility that itself can be adjusted and updated for type and scope as changing needs and new forms of need arise. So on the face of things, this sounds like I have now reversed course here and that I am arguing a case for hardware then software then problem as an orienting direction of focused consideration, or at the very least hardware plus software plus problem as a simultaneously addressed challenge. There is in fact an element of truth to that final assertion, but I am still primarily just adding flexibility and capacity to change directions of development as needed, into what is still basically a same settled paradigmatic approach. Ultimately, the underlying problem to be resolved has to take center stage and the lead here.

And with that all noted and for purposes of narrative continuity from earlier installments to this series if nothing else, I add that I ended Part 9 by raising a tripartite point of artificial intelligence task characterizing distinction, that I will at least begin to flesh out and discuss here:

• Fully specified systems goals (e.g. chess rules as touched upon in Part 8 for an at least somewhat complex example, but with fully specified rules defining a win and a loss, etc. for it.),
• Open-ended systems goals (e.g. natural conversational ability as more widely discussed in this series and certainly in its more recent installments with its lack of corresponding fully characterized performance end points or similar parameter-defined success constraints), and
• Partly specified systems goals (as in self-driving cars where they can be programmed with the legal rules of the road, but not with a correspondingly detailed algorithmically definable understanding of how real people in their vicinity actually drive and sometimes in spite of those rules: driving according to or contrary to the traffic laws in place.)

My goal here as noted in Part 9, is to at least lay a more detailed foundation for focusing on that third, gray area middle-ground task category in what follows, and I will do so. But to explain why I would focus on that and to put this step in this overall series narrative into clearer perspective, I will at least start with the first two, as benchmarking points of comparison. And I begin that with fully specified systems and with the very definite areas of information processing flexibility that they still can require – and with the artificial agent chess grand master problem.

• Chess is a rigorously definable game as considered at an algorithm level. All games as properly defined involve two players. All involve functionally identical sets of game pieces and both for numbers and types of pieces that those players would start out with. All chess games are played on a completely standardized game board with opposing side pieces positioned to start in a single standard accepted pattern. And opposing players take turns moving pieces on that playing board, with rules in place that would determine who is to make the first move, going first in any given game played.
• The chess pieces that are employed in this all have specific rules associated with them as to how they can be moved on a board, and for how pieces can be captured and removed by an opposing player. And chess games proceed until a player sees that they are one move away from being able to win in which case they declare “check.” Winning by definition for chess always means capturing an opposing player’s king piece. And when they win and with the determination of a valid win fully specified, they declare “checkmate.” And if a situation arises in which both players realize that a definitive formal win cannot be achieved in a finite number of moves from how the pieces that remain in play are laid out in the board, preventing one player from being able to capture their opponent’s king piece and winning, a draw is called.
• I have simplified this description for a few of the rules possibilities that enter into this game when correctly played, omitting a variety of at least circumstantially important details. But bottom line, the basic How of playing chess is fully and readily amenable to being specified within a single highly precise algorithm that can be in place and in use a priori to the actual play of any given chess game.
• Similar algorithmically defined specificity could be offered in explaining a much simpler game: tic-tac toe with its simple and limited range of moves and move combinations. Chess rises to the level of complexity and the level of interest that would qualify it for consideration here because of the combinatorial explosion in the number of possible distinct games of chess that can be played, each carrying out an at least somewhat distinct combination of moves when compared with any other of the overall set. All games start out the same with all pieces identically positioned. After the first set of moves with each player moving once, there are 400 distinct board setups possible with 20 possible white piece moves and 20 possible black piece moves. After two rounds of moves there are 197,742 possible board layouts and after three, that number expands out further to over 121 million. This range of possibilities arises at the very beginning of any actual game with the numbers of moves and of board layouts continuing to expand from there, and with the overall number of moves and move combinations growing to exceed and even vastly exceed the number of board position combinations possible, as differing move patterns can converge on same realized board layouts. And this is where strategy and tactics enter chess and in ways that would be meaningless for a game such as tic-tac toe. And this is where the drive to develop progressively more effective chess playing algorithm-driven artificial agents enters this too, where those algorithms would just begin with the set rules of chess and extend out from there to include tactical and strategic chess playing capabilities as well – so agents employing them can play strongly competitive games and not just by-the-rules, “correct” games.

So when I offer fully specified systems goals as a task category above, I assume as an implicit part of its definition that the problems that it would include all involve enough complexity so as to prove interesting, and that they be challenging to implement and certainly if best possible execution of the specific instance implementations involved in them (e.g. of the specific chess games played) is important. And with that noted I stress that for all of this complexity, the game itself is constrainable within a single and unequivocal rules-based algorithm, and even when effective strategically and tactically developed game play would be included.

That last point is going to prove important and certainly as a point of comparison when considering both open-ended systems goals and their so-defined tasks, and partly specified systems goals and their tasks. And with the above offered I turn to the second basic benchmark that I would address here: open-ended systems goals. And I will continue my discussion of natural conversation in that regard.

I begin with what might be considered simple, scale of needed activity-based complexity and the numbers of chess pieces on a board, and on one side of it in particular, when compared to the number of words as commonly used in wide-ranging conversation, in real-world natural conversation. Players start out with 16 chess pieces each and with fewer functionally identical game piece types than that; if you turn to resources such as the Oxford English Dictionary to benchmark English for its scale as a widely used language, it lists some 175,000 currently used words and another roughly 50,000 that are listed as obsolete but that are still at least occasionally used too. And this leaves out a great many specialized terms that would only arise when conversing about very specific and generally very technical issues. Assuming that an average person might in fact only actively use a fraction of this: let’s assume some 20,000 words on a more ongoing basis, that still adds tremendous new levels of complexity to any task that would involve manipulating and using them.

• Simple complexity of the type addressed there, can perhaps best be seen as an extraneous complication here. The basic algorithm-level processing of a larger scale piece-in-play set, as found in active vocabularies would not necessarily be fundamentally affected by that increase in scale beyond a requirement for better and more actively engaged sorting and filtering and related software as what would most probably be more ancillary support functions. And most of the additional workload that all of this would bring with it would be carried out by scaling up the hardware and related infrastructure that would carry out the conversational tasks involved and certainly if a normal rate of conversational give and take is going to be required.
• Qualitatively distinctive, emergently new requirements for actually specifying and carrying out natural conversation would come from a very different direction, that I would refer to here as emergent complexity. And that arises in the fundamental nature of the goal to be achieved itself.

Let’s think about conversation and the actual real-world conversations that we ourselves enter into and every day. Many are simple and direct and focus on the sharing of specific information between or concerning involved parties. “Remember to pick up a loaf of bread and some organic lettuce at the store, on the way home today.” “Will do, … but I may be a little late today because I have a meeting that might run late at work that I can’t get out of. I’ll let you know if it looks like I am going to be really delayed from that. Bread and lettuce are on the way so that shouldn’t add anything to any delays there.”

But even there, and even with a brief and apparently focused conversation like this, a lot of what was said and even more of what was meant and implied, depended on what might be a rich and complex background story, and with added complexities there coming from both of the two people speaking. And they might individually be hearing and thinking through this conversation in terms of at least somewhat differing background stories at that. What, for example, does “… be a little late today” mean? Is the second speaker’s boss, or whoever is calling this meeting known for doing this, and disruptively so for the end of workday schedules of all involved? Does “a little” here mean an actual just-brief delay or could this mean everyone in the room feeling stressed for being held late for so long, and with that simply adding to an ongoing pattern? The first half of this conversation was about getting more bread and lettuce, but the second half of it, while acknowledging that and agreeing to it, was in fact very different and much more open-ended for its potential implied side-messages. And this was in fact a very simple and very brief conversation.

Chess pieces can make very specific and easily characterized moves that fit into specific patterns and types of them. Words as used in natural conversations cannot be so simply characterized, and conversations – and even short and simple ones, often fit into larger ongoing contexts, and into contexts that different participants or observers might see very differently. And this is true even if none of the words involved have multiple possible dictionary definition meanings, if none of them can be readily or routinely used in slang or other non-standard ways, and if none of them have matching homophones – if there is not confusion as to precisely which word was being used, because two or more that differ by definition sound the same (e.g. knight or night, and to, too or two.)

And this, for all of its added complexities, does not even begin to address issues of euphemism, or agendas that a speaker might have with all of the implicit content and context that would bring to any conversation, or any of a wide range of other possible issues. It does not even address the issues of accent and its accurate comprehension. But more to the point, people can and do converse about any and every of a seemingly entirely open-ended range of topics and issues, and certainly when the more specific details addressed are considered. Jut consider the conversation that would take place if the shopper of the above-cited chat were to arrive home with a nice jar of mayonnaise and some carrots instead of bread and lettuce, after assuring that they knew what was needed and saying they would pick it up at the store. Did I raise slang here, or dialect differences? No, and adding them in here still does not fully address the special combinatorial explosions of meaning at least potentially expressed and at least potentially understood that actual wide-ranging open ended natural conversation brings with it.

And all of this brings me back to the point that I finished my above-offered discussion of chess with, and winning games in it as an example of a fully specified systems goal. Either one of the two players in a game of chess wins and the other loses, or they find themselves having to declare a draw for being unable to reach a specifically, clearly, rules-defined win/lose outcome. So barring draws that might call of another try that would at least potentially reach a win and loss, all chess games if completed, lead to a single defined outcome. But there is no single conversational outcome that would meaningfully apply to all situations and contexts, all conversing participants and all natural conversation – unless you were to attempt to arrive at some overall principle that would of necessity be so vague and general as to be devoid of any real value. Open-ended systems goals, as the name implies, are open-ended. And a big part of developing and carrying through a realistic sounding natural conversational capability in an artificial agent has to be that of keeping it in focus in a way that is both meaningful and acceptable to all involved parties, where that would mean knowing when a conversation should be concluded and how, and in a way that would not lead to confusion or worse.

And this leads me – finally, to my gray area category: partly specified systems goals and the tasks and the task performing agents that would carry them out and on a specific instance by specific instance basis and in general. My goal for what is to follow now, is to start out by more fully considering my self-driving car example, then turning to consider partly specified systems goals and the agents that would carry out tasks related to them, in general. And I begin that by making note of a crucially important detail here:

• Partly specified systems goals can be seen as gateway and transitional challenges, and while solving them at a practical matter can be important in and of itself,
• Achieving effective problem resolutions there can perhaps best be seen as a best practices route for developing the tools and technologies that would be needed for better resolving open-ended systems challenges too.

Focusing on the learning curve potential of these challenge goals, think of the collective range of problems that would fit into this mid-range task set as taking the overall form of a swimming pool with a shallow and a deep end, and where deep can become profoundly so. On the shallow end of this continuum-of-challenge degree, partly specified systems merge into the perhaps more challenging end of fully specified systems goals and their designated tasks. So as a starting point, let’s address low-end, or shallow end partly specified artificial intelligence challenges. At the deeper end of this continuum, it would become difficult to fully determine if a proposed problem should best be considered partly specified or open-ended in nature, and it might in fact start out designated one way to evolve into the other.

I am going to continue this narrative in my next installment to this series, starting with a more detailed discussion of partly specified systems goals and their agents as might be exemplified by my self-driving car problem/example. I will begin with a focus on that particular case in point challenge and will continue from there to consider these gray area goals and their resolution in more general terms, and both in their own right and as evolutionary benchmark and validation steps that would lead to carrying out those more challenging open-ended tasks.

In anticipation of that line of discussion to come and as an opening orienting note for what is to come in Part 11 of this series, I note a basic assumption that is axiomatically built into the basic standard understanding of what an algorithm is: that all step by step process flows as carried out in it, would ultimately lead to or at least towards some specific at least conceptually defined goal. (I add “towards” there to include algorithms that for example seek to calculate the value of the number pi (π) to an arbitrarily large number of significant digits where complete task resolution is by definition going to be impossible for that. And for a second type of ongoing example, consider an agent that would manage and maintain environmental conditions such as atmospheric temperature and quality within set limits in the face of complex ongoing perturbing forces, where an ultimate, final “achieve and done” cannot apply.)

Fully specified systems goals can in fact often be encapsulated within endpoint determinable algorithms that meet the definitional requirements of that axiomatic assumption. Open-ended goals as discussed here would arguably not always fit any single algorithm in that way. There, ongoing benchmarking and performance metrics that fit into agreed to parameters might provide a best alternative to any final goals specification as presumed there.

In a natural conversation, this might mean for example, people engaged in a conversation not finding themselves confused as to how their chat seems to have become derailed from a loss of focus on what is actually supposedly being discussed. But even that type and level of understanding can be complex, as perhaps illustrated with my “shopping plus” conversational example of above.

So I will turn to consider middle ground, partly specified systems goals and agents that might carry out tasks that would realize them in my next installment here. And after completing that line of discussion, at least for purposes of this series, I will turn back to reconsider open-ended goals and their agents again, and more from a perspective of general principles.

Meanwhile, you can find this and related postings and series at Ubiquitous Computing and Communications – everywhere all the time and its Page 2 and Page 3 continuations. And you can also find a link to this posting, appended to the end of Section I of Reexamining the Fundamentals as a supplemental entry there.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: