I give up. You win. 2009/10/13 <[email protected]>
> 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
