puzzle
in [General Programming]
|
Prev: Algorithm book recommendation?
Next: TaskScheduler.dll
From: CBFalconer on 18 Jun 2005 03:57 Randy Howard wrote: > mwojcik(a)newsguy.com says... > .... snip ... >> >> Indeed. Out of curiousity, Tisdale, how would endianness, or any >> ordering, affect any Boolean operator? > > I think you have ERT and nilgewater confused. Much as they both > exhibit some similar traits, albeit in different newsgroups, I am > fairly well convinced that not even ERT is this badly confused > about programming concepts. > >> Doesn't matter. ERT's claim that someone is being silenced is >> vacant and closed to refutation, because you'd have to prove a >> negative to refute it. > > s/ERT/nilgewater Ah, notoriety, where is thy sting. Are there any insults in all this? Could we get a new group comp.nilsdale formed to concentrate the effect? -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
From: Randy Howard on 18 Jun 2005 16:30 In article <42B3CC0C.BA88E3A4(a)yahoo.com>, cbfalconer(a)yahoo.com says... > spinoza1111(a)yahoo.com wrote: > > Look, I've discussed how the language of "bad" (as opposed to > > order(x)) misleads people. But if you want to persist in this > > biographical mode, then you are ignorant of optimizing compilers > > which perform operations including constant subexpression > > evaluation and doubling of the effect of for loops. > > ... snip much prattling ... > > You failed to specify the compiler that chooses algorithms. Can we > assume that you are familiar with the relative penalties and gains > from choosing bubblesort versus mergesort, and the relationship to > the input data size and condition? I want the name and vendor of > the compiler that will replace one of those algorithms with the > other, and the conditions under which it will so do. Please > explain how it knows whether or not the input data is pre-sorted > (or nearly sorted), which may affect the decision. Please also > explain how constant subexpression evaluation affects the > decisions. I think it's the same compiler that mystically hoists strlen() calls out of the top of for loops. It's never been demonstrated, but he swears that "any decent compiler" will do it. Apparently, there are no decent compilers in nilgewater land. -- Randy Howard (2reply remove FOOBAR) "I don't really care about being right you know, I just care about success." --Steve Jobs
From: spinoza1111 on 20 Jun 2005 00:15 CBFalconer wrote: > spinoza1111(a)yahoo.com wrote: > > Christopher Barber wrote: > > > ... snip ... > >> > >> Uh, no they don't. No optimizing compiler I know of would optimize > >> your bad algorithm, but if you know of one, please speak up. > > > > Look, I've discussed how the language of "bad" (as opposed to > > order(x)) misleads people. But if you want to persist in this > > biographical mode, then you are ignorant of optimizing compilers > > which perform operations including constant subexpression > > evaluation and doubling of the effect of for loops. > > ... snip much prattling ... > > You failed to specify the compiler that chooses algorithms. Can we > assume that you are familiar with the relative penalties and gains > from choosing bubblesort versus mergesort, and the relationship to > the input data size and condition? I want the name and vendor of > the compiler that will replace one of those algorithms with the > other, and the conditions under which it will so do. Please > explain how it knows whether or not the input data is pre-sorted > (or nearly sorted), which may affect the decision. Please also > explain how constant subexpression evaluation affects the > decisions. You misread of course. I said that the optimizer would carry out code motion, not algorithm replacement, and code motion does not change O(x). You then yourself prattle on in the key of mockery about "the name and vendor" of a compiler which I never said exists. It's obvious that your computing imagination has been destroyed by the arrogance of existing products which are telescopes, taken as definitive of the stars. I did hypothesize as to whether an optimizer could do in some advanced way algorithm replacement but this was clearly in the context of an understanding that it cannot be done. Fool. > > I'll even accept a reference to an available compiler that > specializes in bubble vs merge sort decisions. It just has to > choose (accurately) at compile time. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address!
From: spinoza1111 on 20 Jun 2005 02:52 Christopher Barber wrote: > spinoza1111(a)yahoo.com wrote: > > Christopher Barber wrote: > > >>Why bother with optimizing a bad algorithm? The only time you would use > >>such an algorithm is when n is very small so there is no need to perform > >>any other optimizing tricks. When n is large you had better be using > >>an O(n) algorithm. > > > > This is what optimizing compilers do, mate. > > Uh, no they don't. No optimizing compiler I know of would optimize your > bad algorithm, but if you know of one, please speak up. > > > And in software maintenance > > you need to know how to make low-risk code improvements to "bad", > > Commie, terrorist, child molestor algorithms. > > Sure, and you also know when not to. > > > There are no "bad" algorithms just as there are no bad dogs. > > There are bad algorithms (though not in the moral sense) and there > are bad dogs too (and I am a dog owner). > > >>>I agree that an O(log n) algorithm is in some nonmoral sense better > >>>than O(n), which is better than O(n^y)! But in real programming there's > >>>much more to know. > >> > >>Like what? > >> > >>Your algorithm doesn't appear to have any practical use and you have yet > >>to suggest one. > > > What IS of practical use to me is the ability to discourse wittingly > > and in an amusing fashion about the actual properties of real software. > > Then what's the problem? Haven't we been doing that? > > >>>The problem is that you seem more concerned with biography than > >>>anything else. OK, the terminology is unfamiliar. > >> > >>It is not the terminology that is unfamiliar, it is your non-standard use of > >>it. I have never heard anyone speak of an O(n^2) algorithm as being "close > >>to" an O(n) one in performance. I have no idea what you mean by "biography". > > > > Then you are unread, for when n<10e1 the O(n) and O(n^2) algorithms are > > "close" in significant cases. > > > > By "biography" I mean wasting time in code reviews and here with an > > attack on the speaker's or poster's professional biography. > > I have made no mention of your professional biography in this thread and know > nothing about you other than what you have posted about yourself. Perhaps you > are referring to someone else. > > > Basically, human dignity and economic good sense should require that > > no-one on a job of work should be either permitted or required to > > establish his right to be a part of a dialog. The "biographical" > > approach wastes time in attacks on competence and knowledge. > > No one said that you should be excluded from the dialogue. Those that feel > that way have probably already put you in their kill file. But being admitted > to the dialogue does not mean that you can say anything you want without fear > of being contradicted. > > >>>But one reason for the 80% failure rate of enterprise > >>>systems is the unwillingness to speak of code without snap judgements > >>>and one-upmanship in a field that has been RUINED by laissez faire > >>>"competition". > >> > >>I don't think anyone here made a "snap judgement". I also don't see > >>how suggesting improvements to algorithms or program designs is going > >>to lead to failures in enterprise systems. > > > > Not in itself. But failure to review because everybody's pulling their > > pud does cause failures. > > No kidding, but that is what you yourself are doing. > > >>>And even if it makes no sense to speak of the execution time of a > >>>program approaching a limit, becoming "close to O(n)", approaching an > >>>infinitesimal but nonzero value for larger N, note that there's a whole > >>>field of code improvement within compiler optimization in which the > >>>improvements are beneath the radar screen of complexity theory. > >> > >>There is no such thing as an infintesimal integer value. It is also not > > > > No, but there are small integer values. > > Then why did you use the word "infinitesimal"? > > >>interesting to claim that algorithms tend to converge in performance as the > >>sample size goes down because all algorithms are going to perform just about > >>the same for n == 0. By this argument, an O(n^n) algorithm is "close to" > >>O(n)! > > > > You're not interested in trivial, degenerate, null cases because as a > > non-mathematician, as at best a techie, you view those cases as members > > of a bogus moral category. > > > > A REAL mathematician, such as Nash, remains I think until the end of > > his life interested in the fact that when you multiply by 0, you get 0: > > that when you multiply n times 1, you get n. > > Well, I was a math major in college, and even study my old books from time > to time but indeed would not call myself a "mathematician". But I think you > are mistaken that "real" mathematicians are especially interested in the > trivial cases. > > > My own experience is that a program that fails for either zero or one > > input is a bad program insofar as its text fails thereby to be a > > recursive proof of the program's correctness. > > Sure, but we were not talking about correctness but about execution speed. > > >>I don't really know what you are talking about w/ regard to compiler > >>optimization, but based on this discussion I wouldn't want you optimizing our > >>compiler. > > > > Note how you reduce everything to the lower-middle class anxiety of who > > has a job. > > Who said anything about who has a job? I assume that you have one. I just > wouldn't want you working on our compiler (our product is a software platform > and programming language) based on what you have said in this ng. > > > And note that given your responses, I am not interested in > > working with you. > > I am not suprised. I am sure that you would much rather work > with people who never disagree with you. > > >>>But I also like to fight with people who deal with their own > >>>feelings of incompetence by transferring them onto innocent bystanders. > >> > >>I don't know who you are taking about, but it isn't me. > > > > Excuse me, you've been harassing me in this thread since day one. > > I have been contradicting you. I know that for you that counts as > harassment, but I don't think that anyone else thinks so. I know > perfectly well that I have no "feelings of incompetence" in this > particular domain, and your suggesting that this characterizes me > is a rude, personal attack, pure and simple. Evidence of your real intentions is available where you agree with Randy Howard and make a game out of my surname. So spare me these denials. Your feelings were hurt because you didn't think of the major objection to considering any solution based on XOR. This has triggered destructive behavior which is then defended as being in the service of a truth, limited to a laundry list of (flawed) programming languages which have excessive preconditions. The fact that you extended a post by Mr. Howard is exhibit A because he has, as, apparently, a retiree with serious problems in anger management, appointed himself to libeling me and is too foolish to realize how he is adding to legal problems for himself in so doing, as he creates a trail of evidence for my attorney. If you were a true professional, you would never recognize a person this rude in a physical space, and this space is, or should be, no different. But I have demonstrated what I set out to demonstrate. Corporate surveillance and its Benthamite potential works through the self-management of the terminally frightened and through psychological transfer. Corporate surveillance and its Benthamite potential reduces people to childhood in which they claim only to be professional while acting in fact through motives of childhood's fears. Grow up. > > - Christopher
From: Chris Dams on 20 Jun 2005 03:38
On Mon, 2005-06-20 at 00:13 -0700, spinoza1111(a)yahoo.com wrote: > Of course, this remains a stunning irrevelance to the fact that the XOR > algorithm cannot be said to be O(n), because it replaces equality in an > operation that is from the standpoint of big O theory not valid. You > have to assume that "in addition to test for equality, we can regard > numbers as bitwise accessible". Of course not. Even if the bitwise representation is not accessible any language that allows division by two can easily be used to make you own binary representation. The algorithm will still be O(n). |