<html>
<head>
</head>
<body>
I also like python.<br>
<br>
When doing pure math I have been using J for prototyping algorithms.<br>
<br>
J is basically APL without the special symbols .<br>
<br>
<br>
Good paper with many links for APL and J:<br>
<br>
<a class="moz-txt-link-freetext" href="ftp://watserv1.uwaterloo.ca/languages/apl/software-library/index.html">ftp://watserv1.uwaterloo.ca/languages/apl/software-library/index.html</a><br>
<br>
<a class="moz-txt-link-freetext" href="http://www.jsoftware.com/">http://www.jsoftware.com/</a><br>
<br>
<br>
<br>
These are expecially good for heavy linear algerbra,<br>
<br>
Have fun,<br>
Mike<br>
<br>
Alex Martelli wrote:<br>
<blockquote type="cite" cite="mid:YZli9.114624$ub2.2439313@news1.tin.it">
<pre wrap="">Michal Kaukic wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Hi,<br> <br> we like Python - I use it (with Numeric and SciPy modules)<br>for teaching of Numerical analysis and my colleague is doing<br>some research in discrete optimization in Python. And he often<br>surprises me with non-conformal use of language :-)<br><br> We are mathematicians, not programmers. I suppose, he believes<br>that Python "thinks" like Mathematician. Yesterday, he was struggling<br></pre>
</blockquote>
<pre wrap=""><!----><br>I think the concept of "MODIFYING an object" is pretty far from<br>most areas of maths I've dabbled in (I'm an engineer, not a<br>mathematician, but do find maths fascinating). It seems to me<br>that the only real way to get a language that WILL "think like<br>a mathematician" is to take your pick among languages that have<br>no concept of "modifying an object" - which nowadays basically<br>means, Functional Programming languages. Personally I find<br>Haskell the most elegant one -- clean syntax (uses whitespace<br>much like Python), clean semantics (lazy evaluation the default<br>everywhere). Last I checked, the best Haskell compilers were<br>able to produce very decent code for many problems -- performance<br>will in most cases be better than Python's. If you want even<br>MORE performance, I suspect some less-puritanical but still FP<br>language (such as O'Caml) can probably deliver it.<br><br>If for some reason you don't want to get into FP
, then I think<br>you can forget everything about "thinking like a mathematician".<br>If data modification IS allowed, then your chosen language needs <br>to choose either of two possibilities:<br><br>-- COPY-semantics: an assignment such as<br> x = y<br> inherently copies y, so that any future change to y has no<br> more effect on x<br><br>-- REFERENCE-semantics: an assignment such as<br> x = y<br> makes x a synonym of y, so that both refer to the same<br> object: any future change to that object affects any<br> synonym for the object equally<br><br>Many languages choose a MIX of these two kinds of behavior,<br>but that's the worst of both worlds, as it complicates things<br>a lot. Generally, OLD languages (such as Fortran) relied on<br>copy semantics (references or synonyms were not considered,<br>and when they could happen, as in argument-passing, they were<br>prohibited by the language rules, although those rules were<br>rarely enforced). Modern
languages by and large have moved<br>to reference semantics, which is generally much cleaner even<br>though in some cases performance can suffer (optimization is<br>the main reason some languages complicate things by mixing<br>reference and copy semantics). "Generally" is important: LISP,<br>one of the oldest languages around (second-oldest after<br>Fortran, among those still widely used today), relied on<br>reference semantics from the start. The resulting elegance<br>has much to do with Lisp's acceptance in the mathematical<br>community, IMHO.<br><br>Python uses reference semantics. When you want a copy, you<br>ask for a copy -- it's as simple as this. If you don't ask<br>for a copy, you don't get a copy... you get a reference to<br>the original. There is no complication: it's _always_ this<br>way. (OK, OK, at the margin there are doubtful cases: in<br>particular, a SLICE is a copy-request for all built-in types,<br>but a reference, sharing data with the original arra
y, when<br>you use the Numeric package... Numeric had to move _away_<br>from copy and onto reference in this case to avoid accidental<br>copies of huge array slices... take this as the exception<br>that proves the rule, OK?-).<br><br>Python does have some data types that are immutable, which<br>helps move it a little bit closer to FP -- numbers, strings<br>and tuples are immutable. (Even Java has strings as<br>immutables -- SOME of FP's niceties do start to move into<br>the mainstream, albeit slowly:-). But the main style is still<br>very much NOT FP, rather relying on modifiable data.<br><br></pre>
<blockquote type="cite">
<pre wrap="">with the code shown below (somewhat simplified):<br> <br><br>L_L=[[1,2,3], [2,3,4], [3,4,5]]<br><br>def do_process(LL):<br> n=len(LL[0])<br> rec = [0]*n<br> Res=[]<br> <br> for row in LL:<br> rec[0] = row[0]<br> # further code - modifying rec<br> # lots of conditional processing and such...<br> # ...<br> Res += [rec]<br> <br> return Res<br><br>---------------------------------------------<br><br>After calling do_process(L_L), the "expected" result should be<br><br> [[1, 0, 0], [2, 0, 0], [3, 0, 0]]<br><br>but the true result is<br><br> [[3, 0, 0], [3, 0, 0], [3, 0, 0]].<br><br><br> Yes, this is fully in accordance with how the Python language should<br>behave:<br> Res += [rec] inserts references to list object rec,<br> which are further modified... (he should use copy(rec) instead).<br></pre>
</blockquote>
<pre wrap=""><!----><br>Right in all respects, yes.<br><br> <br></pre>
<blockquote type="cite">
<pre wrap=""> But there is nothing to make this behaviour clearly VISIBLE in code.<br></pre>
</blockquote>
<pre wrap=""><!----><br>*EVERY* assignment in Python uses reference semantics. Every occurrence<br>of an assignment, therefore, makes reference behavior "clearly VISIBLE".<br><br>Presumably fish don't find water "clearly VISIBLE", being used to that,<br>much as it is for us and air. When something "is *EVERYWHERE*", how<br>can it be "clearly VISIBLE" at the same time?-)<br><br><br></pre>
<blockquote type="cite">
<pre wrap="">If I work with pointers in C/C++ I know and see they are pointers.<br></pre>
</blockquote>
<pre wrap=""><!----><br>That's because C uses copy semantics, and uses pointer to emulate<br>reference semantics when needed. That's just the reverse of Python,<br>which uses reference semantics, and explicit calls to copy to<br>emulate copy semantics when needed.<br><br>C++ lets you define "references" which IMPLY reference semantics<br>rather than copy semantics -- and you don't SEE what they are at<br>the point of use (only at the point of definition). Flaming about<br>that here, one way or another, won't be very useful:-). But there<br>are LOTS of precedents: Pascal (!!!) lets you declare arguments<br>to a procedure as either reference or copy -- then you don't see<br>the difference at the point of use; Visual Basic emulated that, too<br>(the default has changed in recent releases of VB, but that's<br>-another- flame:-); languages with sophisticated macro systems,<br>such as Dylan or relatively-recent LISPs, let you do all that and<br>worse.<br><br>But C and
Python are SIMPLE languages: one semantics is pervasive<br>(reference for Python, copy for C), you take explicit measures<br>when you want the OTHER semantics, and those measures are visible<br>at the point of use (well, _mostly_ -- C does complicate things<br>a bit by having arrays "decay to" pointers, Python has the<br>"slice aren't copies in Numeric" issue -- but that's definitely<br>at the margin).<br><br></pre>
<blockquote type="cite">
<pre wrap="">You can say - we also know that rec is list object and so be careful<br>with it. Yes, but consider the complex code where the similar constructs<br>are very easy to overlook. And debugging of such code can be frustrating.<br></pre>
</blockquote>
<pre wrap=""><!----><br>The issue has nothing to do with rec being a list object, really.<br>You may see the issue as having to do with the fact that rec is<br>(any kind of) *MUTABLE* -- indeed, a language without mutable data<br>DOES shield you from these issues. If you tried to mutate non-<br>mutable data, as rec[0] = .... does, you'd get an exception at<br>runtime (if every kind data was immutable, of course, the language<br>wouldn't even have any CONSTRUCTS to express mutation).<br><br><br></pre>
<blockquote type="cite">
<pre wrap=""> My colleague was in state of despair and made thoughtful remarks<br>about FORTRAN and Python similarity. He believes that Python is corrupting<br>his (computer) memory...<br></pre>
</blockquote>
<pre wrap=""><!----><br>Fortran (up to F77 -- I lost touch with it afterwards) had reference <br>semantics in all parameter passing to subprograms (with aliasing forbidden <br>in rather complex ways -- very few compilers ever enforced that, letting<br>the hard-to-debug cases for the programmers:-)), copy semantics for all <br>assignments. I can't see any parallel between that and Python's<br>behavior, not even in the "anti-parallel" sense of Python // C.<br><br><br></pre>
<blockquote type="cite">
<pre wrap=""> So what is the point? I wrote this message in hope that there are<br>more people with similar experience. My question is - how to explain<br>to novice non-programmer users (maybe mathematically "infected")<br>the quirks of Python sequence objects? Which methodology to use<br></pre>
</blockquote>
<pre wrap=""><!----><br>First of all, somebody with reasonable math bent will prefer a<br>more general explanation -- so, forget sequence objects, because<br>that's just one specific cases. ALL object-mutation works the<br>same way, whether it be of a sequence or non-sequence.<br><br></pre>
<blockquote type="cite">
<pre wrap="">in programs so we can clearly see we work with "pointers"?<br></pre>
</blockquote>
<pre wrap=""><!----><br>You're in water. Water is *everywhere*. When you think there<br>is nothing there, there's water. Just get used to it. Trying<br>to muddy up the water in an attempt to make it more visibile<br>would be counter-productive.<br><br></pre>
<blockquote type="cite">
<pre wrap="">Or maybe someone can propose the changes to the Language to overcome<br>this (psychological) barrier? I feel this as a serious obstacle<br>in using Python (my students experienced it too).<br></pre>
</blockquote>
<pre wrap=""><!----><br>It appears, though you never state it, that the behavior you<br>would consider "natural" would have to do with copy semantics.<br>I find that weird, absolutely weird -- I've seen it happen to<br>old died-in-the-wool programmers without solid mathematical<br>bases, because for 20 or 30 years of their lives they had only<br>seen copy semantics and could no longer conceive of any other,<br>but that's exactly the reverse from the "mathematical bent"<br>you keep mentioning.<br><br>Accepting your mention of "mathematical bent" as relevant, I<br>repeat my suggestion that you look into functional programming.<br>FP is seriously cool, IF all the programmers involved have a<br>solid mathematical outlook on life, the universe and everything.<br><br>If for whatever reason you want to keep using languages based<br>on the idea of data modification, you won't find a simpler or<br>more regular one than Python. And it would be absurd to pick<br>ol
d-enough languages that use copy semantics because some<br>previous experience (NOT with maths itself, surely?!) makes<br>you feel that's natural and divergences from it should be<br>made "very VISIBLE" -- besides Python, you'd be cutting yourself<br>off from Java, Eiffel, C# ... reference semantics IS the wave<br>of the last decade-plus, and probably of the next one too<br>(unless FP comes into its own, but I've sort of stopped holding<br>my breath for THAT -- there just isn't enough of an audience<br>with a pervasive-enough mathematical turn of mind:-).<br><br>Just remembed that EVERYTHING works by reference, and what<br>could possibly be the problem...?<br><br><br>Alex<br><br></pre>
</blockquote>
<br>
</body>
</html>