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
