Mike, that's very interesting! I (aka Eve) have currently solved 160 out of 404 of the Project Euler problems, using APL then J, and my recent progress has been heavy going, so much so that I have practically given up. My last efforts were on Problem 376 in April of this year, a delightful problem that I failed to solve, disagreeing on the answer given to the mini test problem, which disheartened me. I haven't tackled any of the problems you mention.
But my interest in Python is for engineering software, not for Project Euler. I just used a Project Euler problem as an example. This year I developed an engineering package in J, paid for by a client. It was done with considerable urgency to meet a need. Now it has been done the client wishes it was written in Python because he doesn't believe anyone will be able to understand J and he already has some engineers writing elementary engineering software in Python. Of course, I could only have done what I did using J -- one reason being I'm not adept in any other language -- but it was perfect for this particular job because I learned about the problem I was trying to solve as I developed the J software. J helped me to understand the problem. But my illustration of J v Python was given to demonstrate my client's dilemma. Today a colleague in the client's office who saw the comparison commended me for my programming style, and he was not referring to the J code! Of course he knew he was rubbing me up the wrong way! For me one of the great things about J is being able to develop code by trial and error. I'm not good enough to get more than very small amounts of code right the first time. But with J you can choose to make your functions small and you can test them until you get them right, using a lot of thought and minimal key strokes. When you put the functions together, since each is functioning correctly, errors in the glue are easy to fix. This way I was able to get a pretty sophisticated system to work satisfactorily without visible setbacks: progress was steady to the end. There was no GUI. The system was run in an ijx window using a command language that is pure J. The syntax of J is perfect for this. There was no user interface. So 'apparent readability' is my problem. Having written a masterpiece my paymasters complain that they can't read it. I may begin translating it into Python as a PR exercise. I wonder how many times longer the source code would be. Graham On Thu, 06 Dec 2012 12:46 Mike Day wrote: When I started doing the Euler Project problems some years ago I used a mixture of Dyalog APL and J. John Randall pointed me in the direction of Pari GP which has the advantage (for me) of allowing high precision arithmetical operations, pace Roger Hui. Of course J has extended integers and rationals, but for many recent, Euler Problems you need to work out how to scale up from a Mickey Mouse solution to the often very large numbers involved. I've sometimes spent weeks trying to correct my J working only to find it was correct within normal tolerances though wrong according to the extreme rigour required by the Project Euler Gurus. Answers are either right or wrong - there's no hint that you're on the right lines. Going straight to extended integers in J often results in a crippled laptop struggling to swap memory and hogging 100% of cpu! That's when I roll out the GP engine. Pari GP is very powerful mathematically, but is something of a Curate's Egg for a J/APL enthusiast. You can use one operator to multiply or add two compatible vectors and to multiply a vector by a scalar, but you can't add a scalar to a vector except with a loop! It's interpreted, so no faster than J usually. It's got some useful library functions for Project Euler, such as Euler's phi, support for continued fractions, the Moebius mu function and so on. Worth a look! I've occasionally looked at others' Python solutions to these problems, but don't remember getting much enlightenment. Euler Problems for which I've used Pari GP: 224 - no record of a J approach! 248 - but got solution in J anyway, 268 - Pari method same as J but better precision, 272 - no record of a J approach! 276 - remarks at end of my J script: NB. x:t7 NB. xxxx41895680 NB. wrong again! ("xxxx" - don't want to spoil things for Eulerites!) NB. Pari again... [copy and paste from a Pari GP session] NB. ? p276(floor(1e7)) NB. time = 7mn, 35,491 ms. NB. %17 = xxxx39632912 NB. CORRECT!!!! 279 - used J solution 318 - used J solution 322 - remarks at end of J script: NB. x:predict 1e18 1e12-0 10 NB. xxxx3313994 NB. also WRONG!!!!!!!! ("xxxx" - don't want to spoil things for Eulerites!) NB. Pari-GP showed this should be xxxx3313995 !!!!!!!! CORRECT!!!!!!!! ie the error was one unit in a number of order in the high teens. More recent Pari scripts: 341 362* 368 370* 378 379 383* 384 388 390 397 398* * - still on my unsolved list - perhaps I should look at Python for these! Mike ---------------------------------------------------------------------------- On 06/12/2012 10:41 AM, Graham Parkhouse wrote: > I am profiting from a foray into Python, which, it is claimed, is much more > easily understood than J. Some people boast they can program in Python as > quickly as they can type. > > Problem 1 of Project Euler: > > Find the sum of all the multiples of 3 or 5 below 1000. > > Programming in J, I like to see intermediate results to be sure I am on the > right lines, so I write a simple important useful function > > will_divide_into=: +./ @: (0 = |/) > 3 5 will_divide_into i.10 > 1 0 0 1 0 1 1 0 0 1 > 3 5 (will_divide_into # ]) i.10 > 0 3 5 6 9 > 3 5 ([: +/ will_divide_into # ]) i.10 > 23 > > When I have got here, I am pretty confident to get the answer as > > 3 5 ([: +/ will_divide_into # ]) i.1000 > 233168 > > If you are pretty competent at Python you can type this: > >>>> ans = 0 >>>> for n in range(1000): > if not n % 3 or not n % 5: > ans = ans + n > > >>>> ans > 233168 > Very different in concept! The J code will easily handle any number of > divisors, whereas the Python code I have written wouldn't comfortably. Now, > I prefer the J code because I understand it, and because I understand the > power and the potential of the concepts, but I can see why ordinary people > instinctively vote for Python. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm