[om-list] How to make an expert system -- Re: MTShell and pipes

[Tom and other Packers]

Mark et alia,

    I talked with my uncle last night, the physicist working for Thiokol,
and he doesn't think there will be a good market for a data analysis
service; but there might be a good market for a good data-analysis / machine
learning software package if I can convince a corporation that it will help
them solve one or more of their problems.  That's a problem for me, because
I'm not sure I can do enough work to make a convincing argument, *and*
develop a sellable software package (user-friendly, on-line help, etc.)
before the funds dry up.

    Assuming I *could* do this ....

    Also in talking to him, I get the impression that there might be a
shorter route to my (and OM's) goals than through data analysis.  There
could be a big market for an application that could help a corporation or
entity such as Thiokol preserve its expert knowledge, so they don't go
through what he described as a roughly 10-year cycle of redoing the same
experiments because the old knowledge (stored in former employees heads) is
gone.

    So, I think this amounts more to knowledge modelling and less to machine
learning, in which area BYU is week.  Hmm. ...  I may have to look into a
different graduate school.  Or, maybe I can force an interdisciplinary PhD
to look like something close to what I want, such as combining their
linguistics program and their CS program.

    But assuming I can't go all the way immediately, I'm still asking this
question:  What product (and/or service, such as converting a business'
database into a better, longer-lasting, general-purpose knowledge-base)
could we develop and sell in a short time, with little effort, something
that could serve as the first step toward the ultimate expert system?  Is
there any chance we could squeeze 4C into the traditional database business,
or anything like it, as a first step towards OM / 4C-Informatica?  Or maybe
if we come up with a good, new technique to accomplish this big piece:
Natural Language Translation ... that would be a good first step (one of two
or three huge steps).  I have some ideas of how to do this right (where
others have not), but this is a very hard problem to solve, and I have yet
to test my ideas practically.  Hmm ...

    Anybody out there want to make any comments/suggestions?


Mark,

    Regarding pipes:  So, given two utilities "A" and "B", where A writes
and B reads:

    if A is slower, then B will have to wait, (and when B stops processing,
A will speed up);

    but when B is slower, A will not wait, A will likely get done long
before B does, (which will also speed up B).  Am I getting it yet?

tomp

----- Original Message -----
From: "Mark Butler" <butlerm at middle.net>
To: "Tom and other Packers" <TomP at burgoyne.com>
Sent: Thursday, 27 December, 2001 22:27
Subject: Re: MTShell and pipes


Tom,

  There is no out-of-band communication on a pipe. It just looks like a
stream of bytes.  Reads and writes always behave so that all data written at
one end is read in the same order on the other.  Nothing is ever lost no
matter what the buffer size is. You can have a pipe with no buffering and a
pipe with an infinite buffer and the end result will be the same.

- Mark


Tom and other Packers wrote:
>
> Mark
>
>     Can the blocking function also refer to a reading function/process at
> one end of a pipe which stops a write function at the other end from
writing
> until it has finished reading the current content of the pipe.
>
> tomp
>
> ----- Original Message -----
> From: "Mark Butler" <butlerm at middle.net>
> To: "Tom and other Packers" <TomP at burgoyne.com>
> Sent: Thursday, 27 December, 2001 14:29
> Subject: Re: MTShell and pipes
>
> You wrote:
> >     Are temporary files stored in memory or on disk?  How can they be
fast
> > if stored on disk?
>
> It doesn't matter very much. Modern operating systems cache all disk I/O
in
> memory and use virtual memory to page RAM to disk, so the real world
> difference is minimal - i.e. either way a copy of what is being written
> stays in memory short term, and is likely to end up on disk long term.
>
> >     Regarding a webpage you sent an indirect link to, could you explain
> this
> > statement: "Windows supports asynchronous IO on pipes whereby a single
> > thread will not block on an IO call to a pipe."  What is "asynchronous
IO"
> > and what is "blocking"?
>
> A blocking function call returns when the requested operation has
completed.
> It "blocks" until then.  A non-blocking function call queues up the
request
> internally and returns immediately.
>
> "synchronous" and "asynchronous" in this context describe the temporal
> alignment of request to request completion. A synchronous request blocks
as
> long as it takes for the request to be satisfied.  An asynchronous request
> does not block - there must be an alternative mechanism to determine when
> the request has been completed.
>
> The difference is critical to all forms of interprocess communication.
> Message passing is generally asynchronous, while remote procedure calls
> (RPCs) are generally synchronous - together providing two basic frameworks
> for distributed computing.
>
> TCP/IP, by the way, is an elaborate technique to provide synchronous
> communications (think HTTP) on an inherently asynchronous packet network.
>
> - Mark
>
> --
> Mark Butler        ( butlerm at middle.net )
> Software Engineer
> Epic Data Systems
> (801)-451-4583

--
Mark Butler        ( butlerm at middle.net )
Software Engineer
Epic Data Systems
(801)-451-4583