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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
