Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Is this program OOP? Date: Thu, 12 Dec 2024 08:00:01 -0800 Organization: A noiseless patient Spider Lines: 136 Message-ID: <86zfl0hoxq.fsf@linuxsc.com> References: <63cd41709a703e4ac6d76427d53fe06d7ee8b8b1.camel@gmail.com> <86plm0iwtj.fsf@linuxsc.com> <035b9e2186f9dc6467806e27a76d98525c104e54.camel@gmail.com> <86h67chxn8.fsf@linuxsc.com> <03fcd46b8d44390c78ca1719e2311b528570d276.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 12 Dec 2024 17:00:08 +0100 (CET) Injection-Info: dont-email.me; posting-host="4d4e784de64121797bdb6fbf35a5252c"; logging-data="2291145"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18IJJiwkCmTauP+/3PEvI9BRtj1cc9c5qA=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:J4kC+7+nQB203X9wXcDmeFmRFIM= sha1:QE27RpQbJZBYIcY2KZAGXIv1OBo= Xref: csiph.com comp.lang.c++:121199 wij writes: > On Tue, 2024-12-10 at 17:04 +0100, David Brown wrote: > >> On 10/12/2024 10:23, wij wrote: >> >>> On Mon, 2024-12-09 at 22:15 -0800, Tim Rentsch wrote: >>> >>>> wij writes: >>>> >>>>> On Mon, 2024-12-09 at 09:35 -0800, Tim Rentsch wrote: >>>>> >>>>>> wij writes: >>>>>> >>>>>>> Because I said: C++ is the best language to model general >>>>>>> problems. So it is. >>>>>>> >>>>>>> Almost all are logical propositions. Except those few >>>>>>> keywords, such programwon't be recognized as a C++ program, >>>>>>> instead of some kind of declarative language. >>>>>>> >>>>>>> Zebra puzzle is an interesting programing exercise because it >>>>>>> is not too easy and also not too difficult. >>>>>>> >>>>>>> ------------ >>>>>>> /* Copyright is licensed by GNU LGPL, see file COPYING. by >>>>>>> I.J.Wang 2023 >>>>>>> >>>>>>> Example of solving the zebra puzzle by using propositional logic. >>>>>>> Zebra Puzzle https://en.wikipedia.org/wiki/Zebra_Puzzle >>>>>>> >>>>>>> [...] >>>>>>> */ >>>>>>> #include >>>>>>> #include >>>>>>> >>>>>>> using namespace Wy; >>>>>>> using namespace Sc; >>>>>>> >>>>>>> [...] >>>>>> >>>>>> You're asking a question that cannot be answered because much >>>>>> or most of the program is in the two include files, which are >>>>>> not shown. >>>>>> >>>>>> As a general rule, when posting code there should be enough >>>>>> posted so that readers can at least compile it. In cases like >>>>>> the program asked about here, what is posted should be enough >>>>>> to both compile the program and run the generated executable. >>>>> >>>>> I thought nobody will be interested with the implement, and what >>>>> is shown should be enough for the moment. >>>> >>>> The point is that what was posted is not enough to answer the >>>> question of the Subject: line. >>>> >>>>> The Zebra Puzzle program has two version, a_puzzle_21.cpp (has >>>>> shown) takes too long to complete. a_puzzle_2.cpp (736 lines, >>>>> too long to post, I thought) is the realistic one written in way >>>>> I feel just solving the prolem is enough. >>>> >>>> I wrote a program in prolog to solve this puzzle. The entire >>>> program is 60 lines long, including 13 blank lines. It finds the >>>> solution in 0.03 seconds. The program doesn't do anything fancy; >>>> it pretty much just gives the listed conditions in the form of >>>> prolog rules, plus 20 lines to establish the structure of the >>>> information that is being sought. >>> >>> Very dubious, show us what you say is true. >> >> Prolog is a language that is ideally suited to such problems. >> Basically, you give the language a bunch of objects and facts and >> relations about those objects, then you ask it questions about >> them. It's at least 35 years since I tried Prolog one afternoon, >> and that's exactly the kind of task I played with (though a bit >> smaller). > > I know a bit of prolog,lisp (in DOS era). Strongly suspicious what > Tim says. > >> This is not a big problem in any language. It's 5 characteristics >> for each of 5 houses - that's 3125 possibilities. Make a big array >> of booleans, initialised to true. Run through the array and kill >> any combination that is contrary to one of the facts. It might >> have been a worthy benchmark in 1962 but it should not be >> challenging to solve with modern machines. (Of course it can still >> inspire interesting solutions and ways to express code in different >> languages.) > > Not that simple, try it to know (your eye may fool you, just like > with libwy). > > a_puzzle_2.cpp (736 lines) was a random try in normal C++ > programming style. I did not try to optimize it. It took 3m22s. > a_puzzle_21.cpp has 178 lines, about 40 lines of comments, so > 178-40=138 lines. So, I have reason to doubt 60 lines of prolog > can do the job. And most importantly, the number of 0.03 seconds > is too difficult to explain. Prolog is not really a declarative > language, you need to provide 'algorithm' to 'compute' the answer. > So, there is reason why 'prolog' program can run faster. But, > unless there is some built-in mechanism in modernprolog to solve > Zebra-puzzle-like problem, 60 lines of codes is dubious to me and > even so, 0.03 seconds remains highly dubious. I'm wondering what it is you are dubious about. Are you dubious (a) that I know how to use the 'wc' program to see how many lines there are in a file? (b) that I know how to use awk, and pipe the results into wc, to see how many blank lines there are in a file? (c) that I am capable of writing a prolog program that can be accepted and run by the swipl prolog interpreter? (d) that I know how to run a prolog program contained in a file, and look at the output it produces? (e) that I am capable of checking the output against the problem specification, to be sure the purported solution satisifies the conditions of the problem? (f) that I know how to use 'time' in a linux/unix shell, to see how long it took to run a program? (g) that I know how to interpret the output of 'time', and map it onto a time as measured by a regular time-keeping device such as a stopwatch? Or is that you just think I'm a liar? Incidentally I cleaned up the program a bit, and now it is only 50 lines long, including 13 blank lines. It doesn't run any faster than it did before; still taking about 0.03 seconds of user time, and about 0.04 seconds real time (that includes the time taken by a short shell script wrapper to prettify the output).