command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Peter T. Breuer on 3 Dec 2005 09:00 In comp.os.linux.misc blmblm(a)myrealbox.com wrote: > In article <hff863-cbo.ln1(a)news.it.uc3m.es>, > Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >>In comp.os.linux.misc blmblm(a)myrealbox.com wrote: >>> A GUI that limits the total size of the search-criteria expression >>> would impose restrictions not imposed by the CLI. I *think*, however, >>> that Peter is saying he can build a GUI that doesn't impose such >>> restrictions, i.e., something that allows you to create expressions >>> of arbitrary size and complexity, expressed as .... some sort of >>> tree structure maybe? >> >>No, the grammar is just foo* (some finite number of repetitions of foo), >>where foo is >> >> [a] [b] ... [z] >> >>where a-z are the individual kinds of options provided by find, e.g. >>"-type". (I mean "optionally a" by "[a]"). >> >>The semantics is the OR of the a-z, and the AND of the foo. > Here's an example of something that doesn't seem to me to be > expressible that way: They all are - boolean normal form. > find somedir ( -name "foo*" -a -mtime -1 ) -o ( -name "bar*" -a -mtime -2 ) > Or is there something I'm not getting about what you're saying .... Boolean normal form. You have written (A & B) | (C & D). That is the negation of (~A | ~B) & (~C | ~D), which expands to ~A & ~C | ~A & ~D | ~B & ~C | ~B & ~D which is the negation of (A | B) & (A | D) & (B | C) & (B | D) (as claimed! See textbooks for the backup hail mary). Peter
From: Peter T. Breuer on 3 Dec 2005 09:09 In comp.os.linux.misc Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >> find somedir ( -name "foo*" -a -mtime -1 ) -o ( -name "bar*" -a -mtime -2 ) >> Or is there something I'm not getting about what you're saying .... > Boolean normal form. You have written (A & B) | (C & D). That is the > negation of (~A | ~B) & (~C | ~D), which expands to > ~A & ~C | ~A & ~D | ~B & ~C | ~B & ~D > which is the negation of > (A | B) & (A | D) & (B | C) & (B | D) XX (A | C) & (A | D) & (B | C) & (B | D) A cannae tupe. Peter
From: blmblm on 3 Dec 2005 11:34 In article <51l863-6p8.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc blmblm(a)myrealbox.com wrote: >> In article <hff863-cbo.ln1(a)news.it.uc3m.es>, >> Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >>>In comp.os.linux.misc blmblm(a)myrealbox.com wrote: >>>> A GUI that limits the total size of the search-criteria expression >>>> would impose restrictions not imposed by the CLI. I *think*, however, >>>> that Peter is saying he can build a GUI that doesn't impose such >>>> restrictions, i.e., something that allows you to create expressions >>>> of arbitrary size and complexity, expressed as .... some sort of >>>> tree structure maybe? >>> >>>No, the grammar is just foo* (some finite number of repetitions of foo), >>>where foo is >>> >>> [a] [b] ... [z] >>> >>>where a-z are the individual kinds of options provided by find, e.g. >>>"-type". (I mean "optionally a" by "[a]"). >>> >>>The semantics is the OR of the a-z, and the AND of the foo. > >> Here's an example of something that doesn't seem to me to be >> expressible that way: Well, first of all, I chose a really bad example. First, I misread your definition, thinking you were describing a conjunction of terms, each a disjunction, when it appears that what you meant is exactly the other way around. If I had written something of the form (a or b) and (c or d) that might have captured my intent slightly better -- something that didn't obviously fit your description. > >They all are - boolean normal form. > > >> find somedir ( -name "foo*" -a -mtime -1 ) -o ( -name "bar*" -a -mtime -2 ) > >> Or is there something I'm not getting about what you're saying .... > >Boolean normal form. You have written (A & B) | (C & D). That is the >negation of (~A | ~B) & (~C | ~D), which expands to > > ~A & ~C | ~A & ~D | ~B & ~C | ~B & ~D > >which is the negation of > > (A | B) & (A | D) & (B | C) & (B | D) > >(as claimed! See textbooks for the backup hail mary). > Oh, I get it now. (Sorry, I must not have been reading the earlier posts carefully.) All expressions can be converted into a canonical form .... Well, let me try a different example. Suppose the command I would give, using the CLI for find, is this: find somedir -mtime -2 -a ( -name "foo*" -o -name "bar*" ) Now, that can be converted to the canonical form, and in this case it's not even very difficult, but in general .... If I understand you right, you're proposing a GUI that allows you to build expressions in the canonical form. Right? And you're claiming that this would give you access to the full power of find? I would agree with that. But for complex search criteria, I question whether this will be more effective than the CLI, because it seems to me that to use the GUI you're talking about, you must be able to express your search criteria in the canonical form, and while that is certainly mathematically possible, I'm not sure it's something most people will be willing and able to do, even ones who are willing and able to think in terms of Boolean expressions. Very possibly there's still something I'm not getting! -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Peter T. Breuer on 3 Dec 2005 13:30 In comp.os.linux.misc blmblm(a)myrealbox.com wrote: > If I understand you right, you're proposing a GUI that allows you > to build expressions in the canonical form. Right? Well, in a form that _covers_ the normal forms, yes. > But for complex search criteria, I question whether this will be > more effective than the CLI, It's just the same - indeed it may help you factor your search into a sequence of simpler filters. The interface can calculate the most effective equivalent form. > mathematically possible, I'm not sure it's something most people > will be willing and able to do, even ones who are willing and > able to think in terms of Boolean expressions. It's a "normal" way of organising ones thinking. The idea is that you carve out in a first search roughly what you want, and pass it into a second search that excludes some more things you didn't want, etc. This is also an efficient way of going about things in general, since the preselection cuts down on the number of later tests. > Very possibly there's still something I'm not getting! I believe equivalence of boolean expressions is an np-complete problem. Am I right? Anyone recall? Peter
From: Tobias Brox on 4 Dec 2005 00:17
[Lee Sau Dan] > Tobias> A rational number can also be written recursively, still > Tobias> any rational number can be expressed in a normalized form, > Tobias> using only two integers. > Does that make the decimal expansion of 1/3 finite? > Infinite is infinite. Eh, no? 0.3333.... is clearly an infinite decimal expansion, and 3/10+3/100+3/1000+... is clearly an infinite sum. Both can be written precisely and elegantly using the highly finite fraction 1/3. > Tobias> Further on, it is possible to cover the very most of the > Tobias> common use cases with a simple user interface. > Translation: the simple user interface truncates the power of the tool. > Tobias> I'm quite sure that it should be trivial to make a GUI to > Tobias> find, and using such an interface will be easier than to > Tobias> read the find manual. > Then, why haven't you done it? Because I have other things to devote my time to? I know how to use find, and when I'm in doubt, I don't have problems navigating the find manual. For a person that have never used find, an interactive tool would be easier than the manual. If, as I have suggested, the program also actually will show the find command line to the user, and allow the user to modify it, the power of the tool wouldn't be truncated. -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E |