I subjectively like '(-:*>:) 9' much better. Sent via BlackBerry by AT&T
-----Original Message----- From: Matthew Brand <[email protected]> Date: Tue, 13 Oct 2009 09:30:54 To: Chat forum<[email protected]> Subject: Re: [Jchat] [Jprogramming] Limit limitation As I said, it is subjective. If the point of RC is to produce elegant code which demonstrates the language, then I subjectively think it is obvious that the only acceptable solution you present is +/i.10. I think most people would agree that that is the only solution which is in the spirit of RC and that the others are inelegant attempts to over optimize. So +/i.10 is the one which should be posted, on purely subjective grounds. I.e., the elegant code is posted regardless of execution time. The execution time of the elegant code can then be stated. If a polemic ensues between Python and J and someone in the J camp decides to replace the code with 6!:2 '45', then subjectively everyone would know that something unethical had been done. I am pretty sure that the J camp would not do that kind of thing though. I don't know about those filthy, rotten, Pythonites though - they might require closer monitoring. Like most things that humans do, it will always rely somewhat on the honesty and integrity of the people involved. I have no problems trusting people to not write things like 6!:2 '45', even the Pythonites, and if they do then I can subjectively chose to ignore it or to complain loudly if it upsets me enough. Most programmers can tell whether code is over optimized or not, and if somebody were to write things like 6!:2 '45', then I guess most people would start to ignore them after a while. I am sure that the response 6!:2 '45' would be questioned a lot if it was used as an example of the high speed of execution of J, whereas +/i.10 would not be. Either way, I would like to see a comparison of execution time between different languages of the actual code segments which are posted on RC. 2009/10/13 <[email protected]> > This is my point, which one is the most optimized or least covert. > > 6!:2 '{:>:i.45' > 1.5e_5 > 6!:2 '+/i.10' > 1e_5 > 6!:2 '+/ 0 1 2 3 4 5 6 7 8 9' > 9e_6 > 6!:2 '0+1+2+3+4+5+6+7+8+9' > 1.1e_5 > 6!:2 '1+2+3+4+5+6+7+8+9' > 8e_6 > 6!:2 '45' > 7e_6 > > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Matthew Brand <[email protected]> > Date: Tue, 13 Oct 2009 00:12:37 > To: Chat forum<[email protected]> > Subject: Re: [Jchat] [Jprogramming] Limit limitation > > None-the-less, it would be nice to see a comparison of the algorithms > posted > in Rosetta code run on the same machine using the default installation of > each language with no overt (or covert) optimization. > The purpose of writing the algorithms should still be elegance, not > optimization. It would just be nice to know how fast they execute relative > to each other on some standard machine. > One can judge subjectively whether or not an algorithm has been "over > tuned" > for the particular machine and can also agree that there are faster ways to > write the algorithm - but it would be nice to see how fast the elegant code > executes. > > E.g. how do you sum the first 10 integers? > > Well, if I said in J... > +/ i.10 > 45 > > and in Python*... > a = 0 > for i in range(1,10) : > a = i + a > a > 45 > > *I have no idea if this is reasonable Python code apart from that it does > execute. > > Then most people would agree that these are "reasonable" algorithms, in > that > there is no tinkering there. > > But if I did some trickery, which was clearly only advantageous on a > particular machine or compiler setting then most people would agree that it > is not in the spirit of Rosetta Code and hopefully it would be > altered/ignored. > > I agree that you should measure in terms of time taken to write the > algorithm + number of times you expect to run the algorithm * time to > execute the algorithm. > > But I am just looking for un-rigorous, ball park comparisons of the actual > code that is posted - without anybody trying to make it go faster. I think > it is a definable task and would be a useful comparison. > > > 2009/10/12 <[email protected]> > > > There is site that does this. But I believe Rosetta Code is in a > different > > spirit. Optimizing code for performance is tricky. if you dig deep enough > > its _always_ about knowing the way the cpu works, regardless of what > > language you start with you will always have to keep digging into the > > language the interpreter is written in or how the compiler works or how > the > > virtual machine works. A good J programmer could implement an algorithm > more > > efficiently than a bad assembly programmer. But a good assembly > programmer > > will _always_ be able to implement the same algorithm more effeciently > than > > a J programmer. > > > > But J programmers don't care. It will take us a fraction of the time to > > program it and be able to describe the code in high level human or > symbolic > > language better. And that's where there is room for evangelism in Rosetta > > Code. We can say look how easy this is to express if you are expressing > it > > in the right language. I recall seeing, somewhere on this mailing list, > > Roger express efficiency of an algorithm as a function of the time it > takes > > run _and_ the time it takes to code. > > > > http://shootout.alioth.debian.org/ > > > > I admire the fact that they admit the benchmarks are flawed. For some > > algorithms the leaders can change quite often, and it depends heavily on > the > > cpu. Basically because of what I mentioned above. > > > > Optimizing code is a never ending story. Optimizing while also making it > > easier to understand is the real trick. > > > > Sent via BlackBerry by AT&T > > > > -----Original Message----- > > From: Matthew Brand <[email protected]> > > Date: Mon, 12 Oct 2009 22:36:58 > > To: Chat forum<[email protected]> > > Subject: Re: [Jchat] [Jprogramming] Limit limitation > > > > WRT > > evangelism. Would it be worthwhile to show a comparison of the time to > > execute the given C++ (or > > Python) algorithm on a selected example and the time to execute the given > > algorithm in J? > > > > For example, > > nth_root takes 300 times as long as %: on my computer. I wonder how long > > they > > take compared to the Python program? > > > > It would be good on the Rosetta code site > > if there was a table of execution time comparisons for each language on > the > > same machine. I would like to see J vs Python vs C++ in particular. > > > > I could not work out how to time a program in Python though, and do not > > know > > how accurate the Ts function from load 'system\packages\misc\jforc.ijs' > is. > > I.e., I do not know enough about Python or Ts to fairly publish a time > > comparison, but think it would be useful. > > > > The question is, is J faster than Python when the best J programmers > write > > J > > vs the best Python programmers writing Python? What about C++? > > > > > > > > 2009/10/12 Dan Bron <[email protected]> > > > > > I wrote: > > > > To that end, I've created a page on RC to start that dicussion: > > > > http://rosettacode.org/wiki//HouseStyle . > > > > > > The link should've been http://rosettacode.org/wiki/J/HouseStyle . > > > > > > -Dan > > > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.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 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
