Re: Spread*** allowing to use fuzzy logic

On Fri, 01 Sep 2006 06:27:04 GMT, EarlCox wrote:

It seems to me that there are two approaches to using fuzzy data -- either
in a spread*** or in a database.

First, we can populate the cells (or row/column intersections) with fuzzy
membership values derived from some fuzzy process (expert systems, cluster
analysis, neural networks, etc) and then use the membership functions as the
basis for further analysis. The problem with storing fuzzy numbers or fuzzy
quantifiers in a database is simply that the membership values on any data
that is interesting will change over time. Thus, storing the result of the
fuzzy assertion <age> is Young or <project.duration> is Long will invariably
change as the client grows older or the project is revised (or our notion of
what constitutes a Long project changes). In toy or academic databases this
might not be of concern (as evidenced by the large number of academic papers
on static fuzzy databases), but in any real world database containing
thousands or millions of records and hundreds and hundreds of tables,
storing fuzzy membership values is a complete waste of time and (more
important) epistemologically wrong.

Second, we can use the data to derive fuzzy membership values that are used
in context to drive the analysis. This is the basis of FuzzySQL processors
which use fuzzy statements in the where statement as well as the having
clause of the group statement. This would also be the use of fuzzy
statements in the rules of a fuzzy spread***. Queries, rules, and policies
that _use_ the data to drive the conditional flow of analysis are only
constrained by semantic changes in the fuzzy set representations (that is,
what we mean by a fuzzy term). In any case, spreadsheets and databases
should never store fuzzy membership values as persistent data (we might want
to populate a column (in a spread*** or a database table) with the results
of a fuzzy policy execution, but this should always be considered
provisional or transient data).

I agree. The dichotomy you described is universal. It is about handling
fuzzy data vs. fuzzy handling crisp data.

One should never make fuzzy something that originally isn't. There is no
sense to fuzzify anything before storing it into DB. Exactly like in fuzzy
control, where inputs and outputs are crisp.

Only if the thing is natively fuzzy, it must be stored as such. The
question is if a spread*** program could ever meet such things. It is
difficult to judge. In the data acquisition application field it could
(fuzziness due to measurement errors). But it is very specific, and I doubt
spreadsheets are usable there. This is why I asked OP what he wants to do
with the data.

Use cases first!

------------
P.S. BTW, in fact SQL has some rudimentary fuzzy datatypes. They are
INTERVAL MONTH, INTERVAL YEAR, etc. All intervals are fuzzy numbers.

P.P.S. Another case where a crisp store could "leak" is storing evaluated
values. When some fuzzy algebraic operations are applied to crisp data, the
result might be fuzzy.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.