I think Raul was talking about corner cases in code-recognition space, not performance. No matter.
Most users understand 'predictable' to mean 'won't take forever sometimes'. If a job normally takes 10 seconds, most users would be OK with having it finish in 1 second one out of 10 times, but not with finishing in 100 seconds one out of 10 times. One of the problems with tail-recursion optimization in the real world is that it can be a band-aid for an algorithmic flaw. You presumably used some recursive algorithm to divide-and-conquer a problem to get acceptable performance; then you realized that some input will cause the recursion to go very deep; so you reordered the code to replace the deep path with a loop. OK, so you don't crash any more, but the performance of your algorithm may still be terrible on that input. Take quicksort. It is the simplest and most beatiful algorithm, and with tail-recursion optimization it will never break. But you'd better not use it in a web server, because there are Evil People who will send your code an ill-conditioned input that will make your quicksort take O(*:n) time and your sort will never finish. Quicksort is beautiful, but it has a bug. Tail-recursion elimination makes the bug more insidious. The solution is to switch to heapsort when you see the recursion depth getting out of control - and look! then you don't need tail-recursion elimination any more. To answer the question from the other thread, about whether I would cavil at the inclusion of /:~ in J: yes and no. Without /:~, I would code heapsort or shellsort and be content with the result. I am happy that Roger has done the sort in C, because that will be faster; and I am very happy at the high speed of /:~ for most inputs. If I were a company, I would probably insist on understanding the algorithms behind the dyad i. family and /:~, to make sure that they don't have pathological cases that could be exploited by Evil People. Henry Rich Dan Bron wrote: > Raul wrote: >> Recognizing TCO -- this winds up being symbolic manipulation >> of the code, and generally winds up with some obscure corner >> cases which most people tolerate and other people get frustrated >> with. > > Yes, there are those who want performance predictable, even if that means > predictably slow. > > Of course, J doesn't adopt this philosophy, as evidenced by its special code > support [1]. This has its drawbacks; as you noted, special code is > responsible for a number of bugs, and also sometimes results in the dilemma > where one has to choose between the clearest expression of a verb, and one > that takes advantage of special code. > > But personally, I'm glad to have that choice. > > -Dan > > PS: I had a professor once who built a time share system. The system could > allocate more or fewer cycles to a given user. Of course, as more users > signed on, the system would assign fewer cycles to each of them, but there > was some minimum it wouldn't go below (I think this worked by refusing the > next login, not sure). > > Anyway, if you signed in on a day or a time when no one else was using the > system, lucky you! Your job finished in no time at all. My professor > thought this was a wonder feature. But immediately he started getting > complaints about it. People didn't know *when* their job would finish! > They didn't know when they could schedule lunch or go out for beers. > > So the time share system was altered to always assume the worst case and > assign everyone the minimum number of cycles, no matter what. And they > stopped getting complaints. > > [1] Special code supported by J: > http://www.jsoftware.com/help/dictionary/special.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
