[Jprogramming] J v Python

[Don & Cathy Kelly]

Thanks for the comments; What I had seen from a very brief view was the 
"same old".
You give a couple of examples which require a library, These examples 
are ones that were handled easily  many years ago in the original 
versions of APL
Yes, you can define sin and sum etc in a library file-so can APL but  I 
can make a "math" library tuned to my needs.
In J one can load a "library script' defined by someone else or designed 
for my particular needs- which defines sum, sin,  pi or one can define 
them for themself.

sum=:+/
pi =:o.  (pi n gives n*pi)
sin =:1& o.   ( 1 is tied by & to o.   2& o. is cos etc including _1& o. 
for inverse sin (one way)
range =:i. (range n is integers from 0 to n-1)

These can be put into a "math " library (and probably are as I haven't 
checked) as someone did in producing your math library
I could define a ijs file with a mess of definitions of this form and 
load this script file if I need it
Then:

  sin pi 0.1*range 10
0 0.309017 0.587785 0.809017 0.951057 1 0.951057 0.809017 0.587785 0.309017

or

    1 o. o.0.1*i.10
0 0.309017 0.587785 0.809017 0.951057 1 0.951057 0.809017 0.587785 0.309017

If you want more decimal places -that can be done- default used in the above

sum=:+/
    sum 1,10,5,7,9
32
    +/ 1,10,5,7,9
32
    +/3*i.10
135

sum 3* range 10
135
A bit more terse than Python
Admittedly it can be less readable -particularly for those coming from a 
basis non-array languages such as C , Fortran, etc but it can also be 
expressed in terms that  are readable

suppose I want the mean  of some numbers in a list; This is a case of 
summing and dividing by the number of elements (count)
so I can write
count=:#.

mean=: sum % count    (% is the primitive division operator -read it as 
divided by in this case)
mean 2 4 5 5
4
This is more reasonable at start -problem defined and solved


but then one can put them together to get the final product -eliminating 
2 intermediate steps - sum and count
mean2=:+/ % #
    mean2  2 4 5 5
4

After all this- I will look further into Python and make comparisons - 
out of curiosity- not need. I will also look at numpy

Don



On 08/12/2012 1:55 AM, June Kim (김창준) wrote:
> On Sat, Dec 8, 2012 at 1:35 PM, Don & Cathy Kelly <dhky at shaw.ca> wrote:
>
>> Hey - I am approaching this as an engineer (and ex educator)  rather than
>> as a professional programmer. I have in the past used a variety of
>> languages- first was MAD (1961 at U of Michigan-credit to the Ford
>> Foundation which provided generous support) which was a superior Fortran at
>> the time, then various flavours of Fortran, Basic, Pascal (1 program), C++
>> (got pissed off with it), APL  - loved it, and now playing with J. The
>> latter two put the problem first, the others put programming style (and
>> much of the trivia which the "idiot counting on fingers box" can do faster
>> and better) ahead of the problem. So, using J, you get the problem solves
>> while users of these other languages are still defining variables as
>> floating, integer, and boolean in cases where the language can decide
>> 'close enough'. Of these non J or non APL languages  the old Turbo Basic
>> was the easiest to use to solve a problem- it had the advantage of getting
>> a compiled program vs interpreted (speed gain over the APL equivalent at
>> the time and compiled very quickly with good error checking.However, with
>> the problem I had, it took several pages of code (including subroutines but
>> not line number GOTO's )vs an APL equivalent which took less than 1 page of
>> code (most of which was taken up by some unfortunately necessary loop
>> control and necessary output formatting).
>>
>> In going back to a language such as Python- from my first impression-
>> you'll may be frustrated by some of the clumsiness inherited from the  past
>> non array oriented languages. Look at the power of a simple +/ vs the
>> Python, Fortran, Basic, C  approach? Try out the  1 o. o.0.1*i.10
>> equivalent in Python without writing a loop.
>>
>>
> Maybe, it's not your main point, but in Python:
>
>>>> from math import *
>>>> [sin(0.1*x*pi) for x in range(10)]
> [0.0, 0.3090169943749474, 0.5877852522924731, 0.8090169943749475,
> 0.951056516295
> 1535, 1.0, 0.9510565162951535, 0.8090169943749475, 0.5877852522924732,
> 0.3090169
> 943749475]
>
> BTW, +/ in Python is sum : sum([1,10,5,7,9]) or even sum(i*3 for i in
> range(10))
>
> What is fascinating about Python is it has gradually learned many good
> things from other great language, one of which is the list comprehension
> used above.
>
> In addition to that, what Python and many other general dynamic languages
> extend themselves is often via libraries. Due to their dynamic nature and
> hence its malleability, they don't need to sacrifice the expressibility and
> they can contract the expression to a succinct and natural form. (however,
> not as succinct as J, as I think) For matrix manipulation, have a look at
> numpy.

>
>
>> At the end of this rant- I hope that engineers do not really want  a 'one
>> way to do it' approach- otherwise engineering becomes strictly by the book
>> which allows no room for innovation or improvement.
>>   APL and it's heir J give flexibility. I found this from this forum when I
>> had a problem which involved modifying the  diagonal of a matrix-
>> essentially adding a vector along the diagonal- conceptually it involved an
>> efficient way to get a unit matrix. I asked for help and learned that, in
>> this case,  J is like Heinz - about 47 ways exist- some good, some not so
>> good, but all valid. Dealer's choice.
>>
>> Don Kelly
>>
>> P.S. you are a wee bit younger than  I am- your taxing problem  at age 68
>> is no worse than mine, in learning J, at 81. I do have two advantages in
>> that I do have an APL background going back to the IBM 360 and IBM
>> typewriters/terminals with an APL character ball and in that I am retired
>> and am my own  boss (i.e. my wife gives me a lot of slack)..
>>
>>
>>
>>
>>
>> On 07/12/2012 3:53 PM, Graham Parkhouse wrote:
>>
>>> Thank you for all your responses! My thoughts are:
>>>
>>> 1. Give up engineering and teach J in math classes in schools. This is not
>>> an opportunity open to me, I'm afraid Linda, for several reasons. I think
>>> I
>>> will serve everybody best by focusing on my particular problem and helping
>>> my colleagues to understand the issues.
>>>
>>> 2. Bo, your advice is straight forward, and refusing to translate it is
>>> open
>>> to me. The job's been done, it's been used and it works. But there is a
>>> reluctance on their part to want me to develop it further. They have only
>>> *suggested* I might translate it into Python.
>>>
>>> 3. The cost in my time to rewrite in Python would be immense, educational,
>>> taxing on a 68 year old, and could be very frustrating. I think I may
>>> begin
>>> without being paid just to get a glimpse of the scale of the task and to
>>> weigh up Python v. J. If they really wanted it badly, hiring a good Python
>>> programmer to help me, as Raul suggested, would be well worthwhile, and
>>> good
>>> fun.
>>>
>>> 4. David and Boyko touch on the conundrum, which is J thinking v. orthodox
>>> (e.g. Python) thinking. My engineering colleagues are not interested in
>>> this. They don't see this conundrum. They don't much like programming.
>>> They
>>> like being successful at engineering. Python looks friendly and J doesn't.
>>> Sure, this is a superficial view, but they are not interested in
>>> programming
>>> languages or major differences between them. Indeed, they don't believe
>>> there are major differences between any of them.
>>>
>>> 5. So I have a mind to do more or less what Don Kelly suggests.
>>>
>>>       a. Learn Python
>>>
>>>       b. Make myself available for Python programming. None of them are
>>> professional Python programmers, so I should be able to hold my own.
>>>
>>>       c. Experience the difference between Python and J software from the
>>> vantage point of being an effective programmer of both.
>>>
>>>       d. Give them the benefit of my wisdom. Show them just how easy J is
>>> to
>>> write. My hope would be that one or two young engineers would get the
>>> idea.
>>> But, as you can probably tell, I'm being cautious about how well this will
>>> turn out.
>>>
>>> One final point. Don suggests showing different approaches in J. One of
>>> the
>>> boasts of Python is 'There should be one-- and preferably only one
>>> --obvious
>>> way to do it', and many engineers would like life to be like that, so that
>>> they can quickly get on and do it.
>>>    Regards
>>>
>>> Graham
>>>
>>> ------------------------------**------------------------------**
>>> ----------
>>> For information about J forums see http://www.jsoftware.com/**forums.htm<http://www.jsoftware.com/forums.htm>
>>>
>>>
>> ------------------------------**------------------------------**----------
>> For information about J forums see http://www.jsoftware.com/**forums.htm<http://www.jsoftware.com/forums.htm>
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>