From: Dmitry A. Kazakov on
On Fri, 12 Aug 2005 13:22:31 -0500, Chris Sonnack wrote:

> Dmitry A. Kazakov writes:
>
>>> Do you think fuzzy logic is implemented without binary?
>>
>> Implemented is a wrong word here. Logic isn't implemented.
>
> Oh. So....er.... those fuzzy logic tools I was using a few years
> ago.... were they grown from, like, seeds or raised from pups? (-:

Ah, you meant to implement in the sense to use, to be based on. OK.

>>> Multi-state logic is built on binary logic. Learn basic information
>>> theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it.
>>
>> No, this is wrong.
>
> (Has anyone informed Shannon?)

Hmm, was Shannon aware of Hilbert's program? I think he was. Anyway in the
times after Goedel, we know that there is no way to "break" everything down
to 1s and 0s. And even if there were one, neither fuzziness nor randomness
can be expressed in a deterministic system without some incomputable
elements. The simplest example is: you cannot write a non-pseudo random
generator.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: topmind on
[snipped 3 pointless insults]

>
> >> Let's recap. You claimed GUI software--note the term: SOFTWARE--was
> >> not hierarchical. I showed you that it was. Then you shifted to talking
> >> about GUI usage.
> >
> > I meant it from the point-of-view of the application developer, and
> > not the builder of the tool ("boxed" software). If that was not
> > clear, I apologize.
>
> Once, again, I understood and have been answering that way all along.
> The code I showed you was a VB **application** I wrote. VB comes out
> of the box.


One *can* write hierarhical code in most event-oriented tools
similar to how one can write procedural code in most OOP languages
if so desired. I don't dispute that. However, just because
an event-driven tool allows code or
flow to be hierarchical does not make
the code itself "event driven". Remember, we are mostly
talking about technique here, not tools.


>
> >> Software--in general--is hierarchically structured. It has high-level
> >> routines, mid-level routines and low-level routines.
> >
> > Not event-driven software (from custom app perspective), at least not
> > on the large scale.
>
> Have you ever actually *written* a GUI application of any size? Are you
> under the impression that "event driven software" is JUST event handlers?

Mostly event handlers. There may be a few large tasks that resemble
batch jobs in their structure, but the majority of the code
is just handlers.

>
> The larger the application, the more it does (besides handle various
> events). The more it does, the more it's going to be hierarchical.

I don't see why this has to be or should be.

>
> > The closest thing would be a start-up form, which simply has an attribute
> > or reference somewhere marking it as the starting point.
>
> And you don't think there's start up **code** that sets things up?
> You don't think some events result in executing large bits of code?

Maybe, maybe not. I don't rely heavily on "startup" events even if
they are possible. Like I said before, which form is the startup
form can be indicated by attributes or by code (such as a "main")
routine. I don't remember which approach VB used, but it does
not matter. VB allowed a mix of code styles, not just event-driven.

>
> Sometimes there's quite a lot of it, in fact. When I launch the
> WebSphere App Developer Studio, it takes a couple *minutes* to launch.

Because Java and WebSphere suck. Compiled languages often make
it harder to load stuff as-needed, forcing one to load everything
into RAM up-front.

> It's doing a LOT of set up stuff--all (I have no doubt) hierarchically
> structured. When I compile all projects in the workspace, it can go
> on for several minutes. Again, I'd bet you a year's salary the code
> behind the compile is hierarchically structured.

It does not matter if the code behind it is girbles on
a treadmill. How to write compilers is not the topic
here. Just because domain A may use trees does not mean
that all other domains should also. That is
sloppy extrapolation.

Compilers are mostly just "batch jobs", and thus
usually will be more hierarhical than the app itself.


>
> What's gotten lost here is your understanding of the context. What
> most of this has been about is the occurrence of trees in nature and
> programming. As *data* *structures*, they are natural and vital.

Prove it.

You have demonstrated that trees tend to be
common for lower-level tools {systems software}, but
there is still the extrapolation problem to other domains.
The fact that you have to keep dipping into the
systems software wine for examples raises domain
suspicions with regard to your evidence.

I don't give a flying slht about how to make
compilers and DB indexers. That is not what I
do for a living.


>
> As *taxonomical* structures, you can run into problems, and that's
> where the idea of duplicate nodes or cross-branches can be an issue
> (albeit, in programming, a solvable one).
>
> (I think you'd do better if you recognized how important and useful
> trees are--particularly as data structures--and didn't try to do the
> equivalent of claiming we never landed on the moon. Intelligent
> people know we did and that trees do occur in many places in nature
> and programming and are terribly useful. That you can only push
> your own agenda at the expense of another is--in my book--an almost
> certain sign of a kook and a fool.)

How about you demonstrate them being universally useful instead
of insulting me. Philosphers who have carefully pondered the
nature of classification systems have come to conclusions
fairly similar to mine. Most developers don't spend a lot
of time pondering such stuff, but instead copy the techniques
they find in "Learn Foo in 7 Days" books with little thought.

Those who actually ponder the nature of structure, hierarchies,
and change for a fair number of years will usually agree with me.
Tree fans tend to hope that argument-from-authority is
good enough.

>
>
> >> Not at all, but it has nothing to do with parse trees.
> >
> > Then please clarify. I see no need to make a distinction
> > between control structures and functions because in some
> > languages that are the SAME thing. The other languages
> > simply "hard-wire" them into the syntax or lang
> > definition.
>
> Agreed with you last time. Once again, it has nothing to do with
> (1) parse trees in general and (2) duplicate nodes in a parse tree,
> which (3) IS A PURE TREE (no branches reconnect).

by duplicating patterns instead of referencing them.

>
> >> It still looks like you don't know what a parse tree is, so no.
> >
> > Whenever you lose and argument, you seem to accuse me of ignorance.
>
> I don't think I'm losing this argument at all! In fact, I'm quite
> sure that, were it being judged purely on its debate points, you'd
> have lost it long ago.


You are delusional. The duplication of the parse tree node
detail is plain as the sky, and you pretend it is not there
or that it deserves some special exemption such that your
wrong view of the universe is kept intact. Dup is dup.
You cannot sweep it under the carpet and ONLY see the
tree by ignoring non-tree links/dups. That is cheating,
or perhaps evidence you change the picture to fit your
world view instead of the other way around. ANY graph
can be turned into a tree if dups/CBL's are allowed.
Thus, treeing something in itself does not prove that trees
are the best tool for managing information.

Subroutine calls bust pure trees. That is the facts jacks.


>
> But regardless of that, I just plain think you ARE ignorant.

The feeling is mutual.

>
> > Prove I am ignorant with details instead of claim it with vague
> > accusations.
>
> The fact that you don't seem to recognize how badly you've lost this
> debate or how often I have apparently overwhelmed you with techical
> details ought to make it pretty plain that I HAVE proved it.

Send me a parse tree from a real program, I will mark up the
dup links, scan it to the web, and the whole world can see what a
graph it really is.

>
>
> > By the way, here is an example from c2.com wiki:
>
> Gee, you can copy and paste. Can you *discuss* what you pasted?
>
> Do you understand why (1) how an "if/else" is implemented is totally
> irrelevant, or (2) why a parse tree is a pure tree?


Any graph *can* be represented as a "proper tree", but not
necessarily a "pure tree". A pure tree has no duplication
of nodes or cross-branch links.

Most syntax trees of real code are or can be proper trees, but they
are usually NOT pure trees.


>
> > This code:
> > [snip]
> > Can be represented as a tree:
> > [snip]
>
> Indeed it can. Do you understand what you pasted?

By the way, I was the orginal author of that c2 content.

>
>
> >> The code I showed you was developed (by me) as an APPLICATION.
> >> As I said last time:
> >
> > Yes, but I asked for an *event driven* example. That is
> > not event-driven, or at least is not the event-driven
> > part of the code.
>
> And, in fact, as a medium-small-sized application, the event-driven
> parts are not the bulk part of the application. I showed that to
> you to counter your claim that GUI software was not hierarchical.

*can be* versus *should be* were addressed above.

>
> It most certainly is. The event handlers may all exist at the same
> level of the hierarchy (although this doesn't have to be true), but
> they--if they contain much code at all--will be their own little
> hierarchies.

I have said many times that on a small scale there are indeed
fairly "clean" hierarchies in most code. It is the bigger picture
that is at issue. Trees are nice, or at least often acceptable, on the
small. I have always agreed with that.

>
> In fact, here's an example of hierarchy in event-handlers: In some
> systems, the main window receives events, which it may process and
> return as fully processed or pass on to a child element of the window.
> That child element may fully process the event OR pass it in turn to
> a child control.
>
> So there ya go--you're even wrong about events not being tree-shaped.

I'm sure there are many ways to jury-rig event-driven tools to have
hierarchical features or flow if one is obsessed enough with trees.

In general, the "flow" in event-driven designs is determined by
actions of the *user*. The user may click in a tree-wise fashion
or may not. The point is that the flow is not hard-wired into
the code. The more that is hard-wired, the less "event-driven"
the design is.

>
>
> --
> |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |

-T-

From: Chris Sonnack on
Dmitry A. Kazakov writes:

>>>> Multi-state logic is built on binary logic. Learn basic
>>>> information theory. It ALL can be broken down to 1s and 0s.
>>>> Every, um, BIT of it.
>>>
>>> No, this is wrong.
>>
>> (Has anyone informed Shannon?)
>
> Hmm, was Shannon aware of Hilbert's program? I think he was.
> Anyway in the times after Goedel, we know that there is no
> way to "break" everything down to 1s and 0s.

Are we possibly talking about two different things here? Yes,
Goedel showed we can't fully analyse any non-trivial system,
but I believe Shannon hasn't been superceded in the sense that
anything that *can* be expressed or computed can be expressed
or computed in binary.

> And even if there were one, neither fuzziness nor randomness
> can be expressed in a deterministic system without some
> incomputable elements.

But they are incomputable by *any* means, right?

> The simplest example is: you cannot write a non-pseudo random
> generator.

Agreed.

--
|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
From: Chris Sonnack on
topmind writes:

>tm> If it has one table, it is still relational.

>CS> (This, as stated, is *absolutely* incorrect, BTW.)

>>> Prove it.
>>
>> Here's a table (first row headers):
>>
>> NAME UID COLOR DATE TYPE
>> Alice - Blue 5-3-1948 BG45
>> Bob - Red 5-3-1948 XL220
>> Carol 3345 Red 12-7-1955 E30F
>> Dave 7709 Green 9-14-2000 -

> Note that "relations" (in a link sense) can be to the
> same table, such as a table that can represent hierarchies:
> [snip]

They *can* be, yes. They can also *not* be. Your initial
statement is incorrect *as* *stated*.

>> I dispute your "relational==table" definition, so I see not
>> one thing that makes this table "relational". It's just a
>> (what I'd call) "flat table".
>
> Well, my definition is correct. The history of
> "relational" is based on that usage.

Then no doubt you can provide a reference beyond your mere
assertion. Even the example you just provided seems to show
that it takes a *relation* to be *relational*.


>>>> http://en.wikipedia.org/wiki/Database_normalization
>>>
>>> I dispute that.
>>
>> Okay..... can you support that disputation in any way??

(Apparently not.)

>> The line from that page, "In the relational model, formal
>> methods exist for quantifying "how normalized" a database is,"
>> seems to suggest to me normalization is a fundamental part of
>> a relational database.
>
> Normalization is simply duplication factoring. The principle
> exists in just about every code or data organizational
> principle. In other words, it cuts across paradigms.

But has a very *specific* meaning in relational databases.


>> But I do NOT see any relation to answering the question I asked.
>> Can you answer it, or were you just throwing words out randomly?
>
> Sorry, but I lost the context of this section of discussion.

No, you didn't. It was IN the post you're replying to. In fact,
you quoted it in YOUR post. Here it is again:

>You> However, there are different ways to interpret "duplication" for
>You> empty cells. Empty cells do not have to take up physical space,
>You> especially in "dynamic relational".

>Me> Empty cells? Where did that come from? Are you talking about
>Me> NULL fields? Row duplication?? What???


>>>> http://en.wikipedia.org/wiki/Relational_model
>>>>
>>>> It starts out, "The fundamental assumption of the relational
>>>> model is that all data are represented as mathematical relations,..."
>>>> ^^^^^^^^^
>>>> Sounds interconnected to me.
>>>
>>> Well, it is misleading. The same link also says:
>>>
>>> "A table is an accepted visual representation of a relation; a
>>> tuple is similar to the concept of row."
>>
>> How, exactly, do you think that refutes the first quote?
>
> Maybe it doesn't. Either way it does not appear to support
> your assertation that "relation" means cross-table references
> in the context of relational.

Don't create straw targets. I never said cross-table. But in the
interest of moving this along, perhaps there is a problem of lack
of precision in words here.

By "interconnected" I mean one record referring to another via a
foreign key link to a primary key in another record--which, yes,
can be in the same table (*typically* not, but that's irrelevant).

Where we may still disagree (?) is that, IMO, a "flat table", that
is a table with no relationships, is NOT relational.

Hence "table" != "relational"


>> If the database moves to a different machine (with a different
>> name, obviously), then no. The ODBC setup must be tweaked for
>> the new hostname.
>
> The ODBC name is not the same thing as
> a "machine name". It is essentially the name of
> a configuration, a "reference" to a database (and usually a
> locally-stored configuration).

Yes. And **IN** that configuration is the machine name.
If that changes, the configuration must change.


>> You want to store files in a database. What happens when
>> those files are very, very, very large?
>
> That is an implimentation detail.

But a very significant one with regard to, um, implementing such
a system in the real world.

> I don't know what the upper limits are on the leading vendor's
> products.

Doesn't matter. What happens when I want to store the DB itself
in your virtual file system? You can't store a full ten-gallon
container inside another ten-gallon container, because there's
no room for the container itself.

>>>> Or consider this: in a FS, I can define a folder as publically
>>>> shared, read-only, and any file I drop in there is available
>>>> to those I've shared the folder to. I can casually share and
>>>> unshare files just by moving them in and out of the folder.
>>
>> [...]
>> Describe how you think an RDBMS would provide such a simple service.
>
> UPDATE folders SET shared=true WHERE [folder criteria]

You've missed the point. This isn't about how to make a folder shared.
It's about the ease of--once having a shared folder--dropping files,
or copies of files, into that folder to share them. Or the ease of
removing them, or deleting the copies, to unshare them.

>>> Just because you are not adept at non-tree searches does not mean
>>> the rest of us are also not.
>>
>> Okay, so describe how you would find Bob's old project files after
>> Fred was done changing the attributes?
>
> How is this any worse than changing tree paths to represent
> the newer changed information?

Because, as I've said several times before, I can browse around the
file system looking for likely folders. (I know this to be true,
because I've done it!)

I note that, in your reply, you didn't answer my question this time,
either. I'll ask it again. Bob's gone, Fred hates him, so he's
altered all Bob's attributes.

How do you find the project file?

--
|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
From: Chris Sonnack on
topmind writes:

> One *can* write hierarhical code in most event-oriented tools
> similar to how one can write procedural code in most OOP languages
> if so desired. I don't dispute that.

You still don't seem to understand. If you have a program that
does just about anything non-trivial, it will have a hierarchy
of high-level routines that call medium-level routines that call
low-level routines.

If you dislike trees so much, think of it as an onion or strata
in the earth. Put extremely, your main() routine may call your
keyboard driver, but never vice-versa (in any sane program :-).

>> Are you under the impression that "event driven software" is JUST
>> event handlers?
>
> Mostly event handlers.

Ah, I think I see the problem. That just isn't so in any serious
GUI program. I'd estimate that, AT BEST, it could get as high as
40% to 50%, but that's a rough guess and seems *high* to me.

>> The larger the application, the more it does (besides handle various
>> events). The more it does, the more it's going to be hierarchical.
>
> I don't see why this has to be or should be.

Simple. As your own teeth-brushing example showed, any non-trivial
task breaks into sub-tasks. Therefore, any algorithm of any complexity
also breaks into sub-algorithms.

PART OF GOOD SOFTWARE DESIGN IS DOING THAT BREAK DOWN.

>> And you don't think there's start up **code** that sets things up?
>> You don't think some events result in executing large bits of code?
>
> Maybe, maybe not. I don't rely heavily on "startup" events even if
> they are possible.

Well, once again, I'd have to opine that your lack of experience is
showing. Let's consider a simple example. A highly event-driven
GUI program that is spec'd as international.

That means it needs to change all its labels before the user sees it.
If you don't do that in start up, when will you?

When will you load the system configurations?
When will you load the user's personal configuations?

If a program needs to reference dropdown lists, and those lists are
very static, isn't it smarter to preload them or preload arrays with
the data for fast access later?

>> Sometimes there's quite a lot of it, in fact. When I launch the
>> WebSphere App Developer Studio, it takes a couple *minutes* to launch.
>
> Because Java and WebSphere suck.

(Now there's an intelligent, adult opinion. Supported by fact, too!)
((Yeah, that was irony.))

> Compiled languages often make it harder to load stuff as-needed,
> forcing one to load everything into RAM up-front.

What do compiled languages have to do with it? WebSphere takes so long
to launch, because it sets up a lot of stuff then rather than later.
Something I appreciate, actually. I can start it up and do something else
for a couple minutes (grab a soda, whatever).

Once booted, it works very slick and fast. (And, FWIW, I think WebSphere
is one of the nicest IDE's I've ever used. I believe something very much
like it is freely available as "Eclipse".)

>> Again, I'd bet you a year's salary the code behind the compile is
>> hierarchically structured.
>
> It does not matter if the code behind it is girbles on a treadmill.
> How to write compilers is not the topic here.

But coding is, and writing compilers is coding. More to the point,
it illustrates a point I'm trying to make clear to you. My clicking
the "Build" button is an *event*. However the code behind that event
is (1) considerable and (2) hierarchical.

Compile events are admittedly on the high end of the scale, but the
point is that events can have a lot of code behind them, and that code
will (almost certainly--if written well) be hierarchically structured.


>> What's gotten lost here is your understanding of the context. What
>> most of this has been about is the occurrence of trees in nature and
>> programming. As *data* *structures*, they are natural and vital.
>
> Prove it.

It's been proven over and over in these threads. If you can't see it,
it's because you refuse to see it.

Consider this, though. You've agreed several times that a tree *view*
of data is useful--at least temporarily. How else would you contain
the data of that view, if not in a tree-shaped data structure?

For that matter, how would you represent a parse tree, HTML tree or
XML tree in code?

> I don't give a flying slht about how to make
> compilers and DB indexers. That is not what I
> do for a living.

Then why are you presuming to tell those of us that DO anything at all?

Fine, consider a business application with a button that causes a database
query, which returns data, which is parsed, written into a GUI grid for
the user and also processed some more and put into a chart, which is popped
up into a new window for the user. Possibly all done in separate threads
to make the GUI as responsive as possible.

I can only say this: If *I* wrote the code for that "event", you can bet
your bottom dollar there'd be stratified layers of routines. In a word:
hierarchical.


>> I don't think I'm losing this argument at all! In fact, I'm quite
>> sure that, were it being judged purely on its debate points, you'd
>> have lost it long ago.
>
> You are delusional.

One of us certainly seems to be. I'm content to let history judge.


> The duplication of the parse tree node detail is plain as the sky,
> and you pretend it is not there or that it deserves some special
> exemption such that your wrong view of the universe is kept intact.
> Dup is dup.

And ignorant is ignorant. You've already admitted you don't know
about compilers, and it's clear you don't understand a parse tree
DESPITE your having copy/pasted one into your last post. I'll try
to make this clear once more:

The parse tree represents the source.

If an "if/else" statement appears in the source more than once, it
**must** appear in the parse tree more than once. It's not possible
to parse the code otherwise.

> Subroutine calls bust pure trees. That is the facts jacks.

This has nothing to do with subroutine calls. THAT'S the facts.
A call node in a parse tree is just another node.

(You DO understand that no subroutine calls are made by the code
while it is being parsed, don't you?)


> Send me a parse tree from a real program, I will mark up the
> dup links, scan it to the web, and the whole world can see what
> a graph it really is.

Pointless. It still hasn't sunk in that a parse tree (1) MUST
contain duplicate nodes if the code uses a syntax element more
than once, and (2) they are still perfect trees nevertheless.

See, it's just your self-serving definition of "pure" tree that
makes you think otherwise, and point blank, YOU ARE WRONG.
NO definition of trees prohibits nodes with similar values.

Consider this trivial tree:

root
42
42

It's still a tree. A "pure" tree. It just happens that its two
leaves contain the same value. Ten seconds later, it might look
like this:

root
42.5
21

And it's still the same tree, but with different values.

Again, you need to distinguish between data trees and taxonomic trees.
Duplication is not any sort of issue in data trees (unless the tree
is *defined* as having no duplicate nodes, such as an index might be).


>> In fact, here's an example of hierarchy in event-handlers: In some
>> systems, the main window receives events, which it may process and
>> return as fully processed or pass on to a child element of the window.
>> That child element may fully process the event OR pass it in turn to
>> a child control.
>>
>> So there ya go--you're even wrong about events not being tree-shaped.
>
> I'm sure there are many ways to jury-rig event-driven tools to have
> hierarchical features or flow if one is obsessed enough with trees.

It's not a jury-rig, silly, it's a very appropriate design. Used by
many GUI environments. It's very sensible, as it allows the programmer
to put the event handling code exactly where it needs to be. (Is it
clear to you that this is how the event-driven environment is DESIGNED
and not some kludge by the programmer?)

> In general, the "flow" in event-driven designs is determined by
> actions of the *user*. The user may click in a tree-wise fashion
> or may not.

What??? What the *heck* is clicking in a "tree-wise fashion"?

Apparently, you don't understand THIS example, either. Look, we're
talking about a single click, by the user, somewhere in the window.
I don't know if you even know this, but in some systems, if you click,
say, a button that is in a frame in a window, the main window gets
the event first (in Windows, the "message pump" gets it even before
then).

*IF* there's a handler there, it *MAY* choose to process the event
and return. *OR* it may pass it on to the underlying control--in
this case the frame.

*IF* there's a handler there, it *MAY* choose to process the event
and return. *OR* it may pass it on to the underlying control--now
we're talking about the button.

*IF* there's a handler there, it *MAY* choose to process the event
and return. (*OR* not.)

> The point is that the flow is not hard-wired into the code.
> The more that is hard-wired, the less "event-driven" the design
> is.

Obviously, but that has nothing to do with this discussion other than
to show you just aren't understanding a lot of what I'm saying.


--
|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
First  |  Prev  |  Next  |  Last
Pages: 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
Next: Use Case Point Estimation