Consider also 2!10 . Sometimes it is worthwhile to present several phrases, each of which contributes to the understanding of the problem or the language. See the solutions in http://www.jsoftware.com/jwiki/Puzzles/Sum%20of%20a%20Vector for a related problem.
----- Original Message ----- From: [email protected] Date: Tuesday, October 13, 2009 7:33 Subject: Re: [Jchat] [Jprogramming] Limit limitation To: Chat forum <[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 > acceptablesolution 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 > betweenPython and J and someone in the J camp decides to replace > the code > with 6!:2 '45', then subjectively everyone would know that > somethingunethical 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, > Pythonitesthough - 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
