Re: Google AI challenge: planet war. Lisp won.

Wasn't that the "challenge" where they wouldn't even accept solutions written in many other languages (including both OCaml and F#)? Cheers, Jon. "Xah Lee" wrote in message news:44a8f48f-e291-463e-a042-d0cbc31a2...@z17g2000prz.googlegroups.com... discovered this rather late. Google has a AI

Re: Scheme as a virtual machine?

"Ertugrul Söylemez" wrote in message news:20101014052650.510e8...@tritium.streitmacht.eu... That's nonsense. Actually namekuseijin is right. You really need to persevere and familiarize yourself with some of the other languages out there. Haskell is many things but simple is not one of them.

Re: Math Notations, Computer Languages, and the “Form” in Formalism

fortunatus wrote: > to that end you might be interested in Fortress at Sun: > > http://projectfortress.sun.com/Projects/Community > http://research.sun.com/projects/plrg/fortress.pdf > http://research.sun.com/spotlight/2007/2007-01-10_fortress.html Fortress is dead, right? -- Dr Jon D Harrop, F

Re: Social problems of Python doc [was Re: Python docs disappointing]

Xah Lee wrote: > On Aug 12, 12:15 pm, Raymond Hettinger wrote: >> * The reason for implementing the key= parameter had nothing to do >> with limitations of Python's compiler. Instead, it was inspired by >> the >> decorate-sort-undecorate pattern. > > The decorate-sort-undecorate pattern is a com

Re: Xah's Edu Corner: The importance of syntax & notations.

w_a_x_man wrote: > On Aug 16, 11:05 am, Petey Keller wrote: >> Compiler go through *great* pains > > Compiler work real hard. > Compiler have heap big trouble. ROTFL. :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u -- http://mail.python.org/mailman/listin

Re: If Scheme is so good why MIT drops it?

ACL wrote: > Lisp project: > I don't need as many people... Is there any actual evidence of that? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u -- http://mail.python.org/mailman/listinfo/python-list

Re: If Scheme is so good why MIT drops it?

Raffael Cavallaro wrote: > Yes, you are missing the joke. The point is that if python is 60x > slower than C, even if there were not a GIL, it would require running > the python program on a 60 core machine just reach parity with C. The > existence of the GIL means that in reality you'd probably ne

Re: multi-core software

Matthias Blume wrote: > "Jeff M." writes: >> But, assuming that your program works and does what it's supposed to, >> I agree with Jon that performance needs to be right near the top of >> the list of concerns. Why? Performance isn't about looking good as a >> programmer, or having fun making a fu

Re: multi-core software

Arved Sandstrom wrote: > Jon Harrop wrote: >> Arved Sandstrom wrote: >>> Jon Harrop wrote: >>>> No. Concurrent programming is about interleaving computations in order >>>> to reduce latency. Nothing to do with parallelism. >>> >>> Jon

Re: multi-core software

toby wrote: > On Jun 7, 2:41 pm, Jon Harrop wrote: >> Arved Sandstrom wrote: >> > Jon Harrop wrote: >> >> I see no problem with mutable shared state. >> >> > In which case, Jon, you're in a small minority. >> >> No. Most programmers st

Re: multi-core software

Scott David Daniels wrote: > Lew wrote: >> Scott David Daniels wrote: >>> the nub of the problem is not on the benchmarks. There is something >>> to be said for the good old daays when you looked up the instruction >>> timings that you used in a little document for your machine, and could >>> know

Re: multi-core software

Paul Rubin wrote: > "Jeff M." writes: >> > > Even the lightest weight >> > > user space ("green") threads need a few hundred instructions, >> > > minimum, to amortize the cost of context switching >> There's always a context switch. It's just whether or not you are >> switching in/out a virtua

Re: multi-core software

Arved Sandstrom wrote: > Jon Harrop wrote: >> Arved Sandstrom wrote: >>> Lew wrote: >>>> Interesting distinction. Would it be fair to compare concurrent >>>> programming to the bricks used to build the parallel program's edifice? >>> Wa

Re: multi-core software

Ken T. wrote: > On Sun, 07 Jun 2009 11:16:46 -0400, Lew wrote: >> So the good old days are a matter of degree and self-deception - it was >> easier to fool ourselves then that we could at least guess timings >> proportionately if not absolutely, but things definitely get more >> unpredictable over

Re: multi-core software

Lew wrote: > Jon Harrop wrote: >> I agree entirely but my statements were about parallelism and not >> concurrency. Parallel and concurrent programming have wildly different >> characteristics and solutions. I don't believe shared mutable state is >> over

Re: multi-core software

Arved Sandstrom wrote: > Lew wrote: >> Interesting distinction. Would it be fair to compare concurrent >> programming to the bricks used to build the parallel program's edifice? > > Way too much of a fine distinction. While they are in fact different, > the point of concurrent programming is to s

Re: multi-core software

Lew wrote: > As Dr. Jon pointed out upthread, one can write decent code with mutable > shared > state. It is also true that mutable state presents a lot of problems - > potential problems, ones that can be solved, but not ones that can be > solved > thoughtlessly. On the flip side, one can write

Re: multi-core software

Jeff M. wrote: > On Jun 7, 3:19 pm, Arved Sandstrom wrote: >> Jon Harrop wrote: >> > Arved Sandstrom wrote: >> >> Jon Harrop wrote: >> >>> I see no problem with mutable shared state. >> >> In which case, Jon, you're in a small minor

Re: multi-core software

Joshua Cranmer wrote: > Jon Harrop wrote: >> No. Most programmers still care about performance and performance means >> mutable state. > > [ Citation needed ]. > > Most programmers I've met could care less about performance. Then they have no need for parallelism

Re: multi-core software

Arved Sandstrom wrote: > Jon Harrop wrote: >> Arved Sandstrom wrote: >>> Jon Harrop wrote: >>>> I see no problem with mutable shared state. >>> >>> In which case, Jon, you're in a small minority. >> >> No. Most programmers st

Re: multi-core software

Arved Sandstrom wrote: > Jon Harrop wrote: >> I see no problem with mutable shared state. > > In which case, Jon, you're in a small minority. No. Most programmers still care about performance and performance means mutable state. -- Dr Jon D Harrop, Flying Frog C

Re: multi-core software

George Neuner wrote: > On Fri, 05 Jun 2009 16:26:37 -0700, Roedy Green > wrote: >>On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku >> wrote, quoted or indirectly quoted someone who >>said : >>>Even for problems where it appears trivial, there can be hidden >>>issues, like false cache coherency

Re: multi-core software

Roedy Green wrote: > On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku > wrote, quoted or indirectly quoted someone who > said : >>Even for problems where it appears trivial, there can be hidden >>issues, like false cache coherency communication where no actual >>sharing is taking place. Or loc

Re: Function Application is not Currying

I had hoped someone else would correct you but they haven't. So... Xah Lee wrote: > Here are some examples of a function that returns a function as > result, but is not currying. > > Mathematica example: > > f[n_]:=Function[n^#]; > f[7][2] > (* returns 49 *) > > Emacs lisp example: > > (defma

Re: OCaml, Language syntax, and Proof Systems

Xah Lee wrote: > ok, i've been reading these Ocaml tutorials in the past few days: > > intro to ocaml, from official site > http://caml.inria.fr/pub/docs/manual-ocaml/manual003.html > > “Objective CAML Tutorial”, most cited tutorial on the web > http://www.ocaml-tutorial.org/ > > The best one, i

Re: Mathematica 7 compares to other languages

Xah Lee wrote: >> >On Dec 10, 2:47 pm, John W Kennedy wrote: >> >> C: >> >> >> #include >> >> #include >> >> >> void normal(int dim, float* x, float* a) { >> >> float sum = 0.0f; >> >> int i; >> >> float divisor; >> >> for (i = 0; i < dim; ++i) sum += x[i] * x[i]; >> >> divis

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > On Dec 10, 2:47 pm, John W Kennedy wrote: >> Xah Lee wrote: >> > In lisp, python, perl, etc, you'll have 10 or so lines. In C or Java, >> > you'll have 50 or hundreds lines. >> >> C: >> >> #include >> #include >> >> void normal(int dim, float* x, float* a) { >> float sum = 0.0f;

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > Kaz Kylheku wrote: >> Really? ``50 or hundreds'' of lines in C? >> >> #include /* for sqrt */ >> >> void normalize(double *out, double *in) >> { >> double denom = sqrt(in[0] * in[0] + in[1] * in[1] + in[2] * >> in[2]); >> >> out[0] = in[0]/denom; >>

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > On Dec 10, 12:37 pm, [EMAIL PROTECTED] wrote: >> Ruby: >> >> def norm a >> s = Math.sqrt(a.map{|x|x*x}.inject{|x,y|x+y}) >> a.map{|x| x/s} >> end > > I don't know ruby, but i tried to run it and it does not work. > > #ruby > def norm a > s = Math.sqrt(a.map{|x|x*x}.inject{|

Re: Mathematica 7 compares to other languages

Stef Mientki wrote: > Who said Mathematica was a high level language ? Xah is using what he calls "highlevelness" as an excuse for poor performance. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u -- http://mail.python.org/mailman/listinfo/python-list

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > On Dec 8, 5:25 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: >> Lest anyone doubt that problem size is important for comparing program >> run times, consider ... > > just in case there's any doubt: > > Simply change these lines in Jon's program: > > Main[9, 512, 4] to Main[9, 512,

Re: Mathematica 7 compares to other languages

[EMAIL PROTECTED] wrote: > For the interested, with MMA 6, on a Pentium 4 3.8Ghz: > > The code that Jon posted: > > Timing[Export["image-jon.pgm", [EMAIL PROTECTED]@Main[2, 100, 4]]] > {80.565, "image-jon.pgm"} That is not the code I posted: you are using Xah's parameters that generate a differe

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > A moron, wrote: > > You failed the challenge that you were given. > > you didn't give me a challenge. Thomas gave you the challenge: "What I want in return is you to execute and time Dr. Harrop's original code, posting the results to this thread... By Dr. Harrop's original cod

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > Also, in this discussion, thanks to Thomas M Hermann's $20 offered to > me for my challenge to you, that i have taken the time to show working > code that demonstrate many problems in your code. You failed the challenge that you were given. Specifically, your code is not measurabl

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > For those interested in this Mathematica problem, i've now cleaned up > the essay with additional comments here: > > • A Mathematica Optimization Problem > http://xahlee.org/UnixResource_dir/writ/Mathematica_optimization.html In that article you say: > Further, if Intersect is

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > The result and speed up of my code can be verified by anyone who has > Mathematica. You changed the scene that is being rendered => your speedup is bogus! Trace the scene I originally gave and you will see that your program is no faster than mine was. -- Dr Jon D Harrop, Flying

Re: Mathematica 7 compares to other languages

[EMAIL PROTECTED] wrote: > Well, its past 'tonight' and 6 hours to go till past 'tomorrow'. > Where the hell is it Zah Zah? Note that this program takes several days to compute in Mathematica (even though it takes under four seconds in other languages) so don't expect to see a genuinely optimized

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > I didn't realize until after a hour, that if Jon simply give numerical > arguments to Main and Create, the result timing by a factor of 0.3 of > original. What a incredible sloppiness! and he intended this to show > Mathematica speed with this code? > > The Main[] function calls Cr

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > On Dec 2, 5:13 pm, Jon Harrop <[EMAIL PROTECTED]> wrote: >> The Mathematica code is 700,000x slower so a 50% improvement will be >> uninteresting. Can you make my Mathematica code five orders of magnitude >> faster or not? > > Pay me $10 thru pa

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > On Dec 1, 4:06 pm, Jon Harrop <[EMAIL PROTECTED]> wrote: >> Mathematica is a whopping 700,000 times slower! > > LOL Jon. r u trying to get me to do otimization for you free? > > how about pay me $5 thru paypal? I'm pretty sure i can speed it up. &

Re: Mathematica 7 compares to other languages

Xah Lee wrote: > And on this page, there are sections where Mathematica is compared to > programing langs, such as C, C++, Java, and research langs Lisp, > ML, ..., and scripting langs Python, Perl, Ruby... Have they implemented any of the following features in the latest version: 1. Redistributa

Re: what's so difficult about namespace?

On Nov 26, 7:29 am, Xah Lee <[EMAIL PROTECTED]> wrote: > ... It's mostly a problem of culture. If you look, for example, at chinese names, the name space is not that much important: "Xee Laa" only takes this space: " " ^^^ Instead, if you take a typical english name, say, "Abraham Lin

Re: The Importance of Terminology's Quality

On 5 Giu, 12:37, Jon Harrop <[EMAIL PROTECTED]> wrote: > [...] P.S. Please don't look at my profile (at google groups), thanks! Jon Harrop -- http://mail.python.org/mailman/listinfo/python-list

Re: The Importance of Terminology's Quality

Robert Maas, http://tinyurl.com/uh3t wrote: >> From: [EMAIL PROTECTED] (David Combs) >> Lisp is *so* early a language (1960?), preceeded mainly only by >> Fortran (1957?)?, and for sure the far-and-away the first as a >> platform for *so many* concepts of computer-science, eg lexical vs >> dynamic

Re: generate all possible math expr of one term

[EMAIL PROTECTED] wrote: > Here's a example of Expressiveness of a Language. > > The following is Mathematica code that generates all possible > equations of one term involving trig function. (tweak the funList and > nesting level to define what ?all possible? means. if nesting level is > 2, it ta

Re: The Importance of Terminology's Quality

Terry Reedy wrote: > "Jon Harrop" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | Perhaps the best example I can think of to substantiate your original > point > | is simple comparison because Mathematica allows: > | > | a < b < c >

Re: The Importance of Terminology's Quality

[EMAIL PROTECTED] wrote: > I'd like to introduce a blog post by Stephen Wolfram, on the design > process of Mathematica. In particular, he touches on the importance of > naming of functions. > > ? Ten Thousand Hours of Design Reviews (2008 Jan 10) by Stephen > Wolfram > http://blog.wolfram.com/20

Re: pop langs website ranking

[EMAIL PROTECTED] wrote: > Alexa's data is more reliable than quantcast. Alexa claim to have accurate data on lots of sites but I just tried to correlate their data with the exact data on our web server and the discrepancies are huge. For example, combining our number of absolute visitors with the

Paid subscription Python magazines

Are there any Python magazines that you can pay to subscribe to? (either paper or on-line). -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?u -- http://mail.python.org/mailman/listinfo/python-list

First class lexical closures

Just debating somewhere else whether or not Python might be considered a functional programming language. Lua, Ruby and Perl all seem to provide first class lexical closures. What is the current state of affairs in Python? Last time I looked they were just removing (?!) closures... -- Dr Jon D

Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations

Markus E Leypold wrote: > The answer to your question is very simple: Xah Lee is a troll. In this context, I believe he is marketing/advertising himself as a consultant and some kind of vampiric man-whore according to this page: http://xahlee.org/PageTwo_dir/Personal_dir/xah.html "... I'm tech

Iron Python

Anybody tried it? -- Dr Jon D Harrop, Flying Frog Consultancy The F#.NET Journal http://www.ffconsultancy.com/products/fsharp_journal/?usenet -- http://mail.python.org/mailman/listinfo/python-list

Re: Why stay with lisp when there are python and perl?

Nameless wrote: > Why should I keep on learning lisp when there are python and perl? Lisp compilers are much more advanced, for one thing. Xah Lee wrote: > (if there is some demand, i will add a concrept, little programing > example, that shows, how lisp's symbols and macros concepts, set it > ap

Re: Requirements For A Visualization Software System For 2010

Xah Lee wrote: > In this essay, i give a list of requirements that i think is necessary > for a software system for creating scientific visualization for the > next decade (2007-2017). You may be interested in the F# programming language from Microsoft Research. This is a high-performance function

Re: What are OOP's Jargons and Complexities

Xah Lee wrote: > As part of this new syntax and purity, where everything in a program > is of Classes and Objects and Methods, many complex issues and concept > have arisen in OOP from both the OOP language machinery as well as a > engineering practice. I think the fact that many design patterns f

Re: ocaml to python

Gigs_ wrote: > Is there any way to convert ocaml code to python? but not manually Translating between dissimilar high-level languages is very difficult, so difficult that it is hard to do such a task justice by hand, let alone automating the procedure. If you must do it then write a compiler that

Re: Writing more efficient code

[EMAIL PROTECTED] wrote: > Jon Harrop: >> I think most people could pick up the core ideas in a day and start >> writing working programs. > > Probably I am not that intelligent, I probably need some months :-) But > that language has many good sides, and one day I'll

Re: Writing more efficient code

Beliavsky wrote: > If in the newsgroup comp.lang.x somone asks how to do y, and you > suggest using language z, without answering their question, which was > how to do it in x, you will likely just annoy people and perhaps make > it even less likely that they will try z. Pattern matching isn't a l

Re: Writing more efficient code

[EMAIL PROTECTED] wrote: > Jon Harrop: >> OCaml's pattern matcher is very sophisticated and very fast. You'll >> probably shrink your code by several fold whilst also having it run a few >> orders of magnitude faster and having it statically checked, so it will >

Re: Writing more efficient code

gonzlobo wrote: > I picked up Python a few weeks ago, and have been able to parse large > files and process data pretty easily, but I believe my code isn't too > efficient. I'm hoping dictionaries will help out, but I'm not sure the > best way to implement them. > > I've been using a bunch of nest

Re: Xah's Edu Corner: Introduction to 3D Graphics Programing

Xah Lee wrote: > Introduction to 3D Graphics Programing > http://xahlee.org/3d/index.html You will probably find it more rewarding to use a more modern graphics system, such as OpenGL or DirectX, with a suitable programming language rather than Mathematica's. I would recommend any of OCaml, F#, Ha

Re: merits of Lisp vs Python

Rob Thorpe wrote: > Once you can do the above then you can phrase programs entirely in > terms of composition of functions, which is what functional programming > is about. There are many aspects to functional programming. Some languages (like Lisp and Python) are very impure and hardly encourage

Re: merits of Lisp vs Python

Kaz Kylheku wrote: > The removal for the need for manual object lifetime computation does > not cause a whole class of useful programs to be rejected. Sometimes you must be able to guarantee that a resource has been disposed before you can continue. That is why we have finalisers in OCaml and disp

Re: merits of Lisp vs Python

Raffael Cavallaro wrote: > haskell and ocaml are more popular than any lisp library that tries to > imitate Haskell and ocaml. Implementing pattern matching does not mean imitating Haskell or OCaml. > This only speaks to the relative > unpopularity of imitating these features of haskell and oca

Re: merits of Lisp vs Python

Raffael Cavallaro wrote: > On 2006-12-17 07:54:28 -0500, Jon Harrop <[EMAIL PROTECTED]> said: >> What if eager impurity isn't the "very nature" of the problem but, >> rather, is the very nature of Tilton's chosen solution? > > That's the who

Re: merits of Lisp vs Python

Raffael Cavallaro wrote: > On 2006-12-16 13:58:37 -0500, Jon Harrop <[EMAIL PROTECTED]> said: >> Why do you think that uniform syntax is necessary to provide new >> paradigms when it is equivalent to infix syntax? > > Because it doesn't require one to write a parse

Re: merits of Lisp vs Python

Raffael Cavallaro wrote: > Of course it does - Thats why we try ocaml and haskell etc. It's just > that we don't see the useful features of these languages as being > sufficiently useful to compensate for their lack of the ability to > easily do syntactic abstractions over a uniform syntax. That a

Re: About alternatives to Matlab

sturlamolden wrote: > Jon Harrop wrote: >> Yes. The time taken is dominated by memory accesses. The amount of >> arithmetic is almost irrelevant. > > That is extremely interesting. It would explain why I see almost the > same performance in NumPy and Fortran 95 on this kin

Re: About alternatives to Matlab

Filip Wasilewski wrote: > Jon Harrop wrote: >> Yes. The time taken is dominated by memory accesses. The amount of >> arithmetic is almost irrelevant. > > I can say from my experience, that this depends much on the input size > and the CPU cache size. For arrays of about n^

Re: About alternatives to Matlab

Filip Wasilewski wrote: > Jon Harrop wrote: >> Filip Wasilewski wrote: >> > Jon, both Python and Matlab implementations discussed here use the >> > lifting scheme, while yours is a classic convolution based approach. >> >> I've done both in OCaml. The r

Re: About alternatives to Matlab

Paul Rubin wrote: > Interesting, where do I get it, and is there source? I've never been > interested in Mono but maybe this is a reason. How does the compiled > code compare to OCaml or MLton code? GC intensive code is 2-4x slower than OCaml or 4-8x slower than MLton. Floating point intensive c

Re: About alternatives to Matlab

Marc 'BlackJack' Rintsch wrote: > So you don't count line endings when counting bytes. ;-) You'd probably replace "\n" -> " " so it wouldn't affect the byte count. Anyway, I think I was using non-whitespace bytes, so neither "\n" nor " " is counted. -- Dr Jon D Harrop, Flying Frog Consultancy O

Re: About alternatives to Matlab

[EMAIL PROTECTED] wrote: > A concrete example of interest to me: can I get an OCaml-to-native > compiler for an IBM BlueGene? The processor is in the PowerPC family, > but it has some modifications, and the binary format is different > from standard Linux as well. No idea. OCaml has quite a good P

Re: About alternatives to Matlab

Filip Wasilewski wrote: > Jon, both Python and Matlab implementations discussed here use the > lifting scheme, while yours is a classic convolution based approach. I've done both in OCaml. The results are basically the same. > These are two *different* algorithms for computing wavelet transforms.

Re: merits of Lisp vs Python

Bill Atkins wrote: > Despite its dynamism, Lisp is quite compilable. For example, I can > redefine classes, functions, macros, etc. at runtime and compiled code > referring to the old code will still work. You are conflating > dynamism with interpretedness, and that's incorrect. There is clearly

Re: merits of Lisp vs Python

André Thieme wrote: >> Contrast the much more common >> >> a[i] = b[n] >> >> with >> >> (setf (aref a i) (aref b n)) >> >> and the attractions of Python may make more sense. > > Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python > one has to write less since "[]" are 2 cha

Re: merits of Lisp vs Python

André Thieme wrote: > I think you could do that with functional programming. > You can protect the evaluation by encapsulating the args in a function > object? > > def f_Args(x): >return x > > def g_Args(x): >return x > > and then > a = cond(test, f, g, f_Args(x), g_Args(x)) > > if you

Re: merits of Lisp vs Python

André Thieme wrote: > Well, macros are one (big) thing that Lisp has and which many other > languages don't have. Their are other things too, and some of them are > in Python as well, which is a very nice scripting language. I think s-exprs and EVAL are the main things that Lisp has and that other

Re: About alternatives to Matlab

Konrad Hinsen wrote: > Well, then it should also run on my Mac... Do you have any experience > with performance of numerical code under Mono, or, for that matter, > under .NET? I suspect that the JIT compilers were not written with > number crunching in mind, but perhaps I am wrong. Actually, F# s

Re: merits of Lisp vs Python

Paul Rubin wrote: > Are there any Lisp devotees who have done serious development in ML? There is a disproportionately small overlap between the Lisp/Scheme and ML/Haskell communities. They are probably of comparable size at the moment. I believe the difference is largely geographical. -- Dr Jon

Re: merits of Lisp vs Python

jayessay wrote: > Fair enough. But really, I don't see any of these things as > particularly "modern" (whatever that means) or groundbreaking. > Certainly not at this point. Performance and type theory are modern in the context of FPLs. Both have been retrofitted to Lisp with varying results. >

Re: merits of Lisp vs Python

Pascal Costanza wrote: > Paul Rubin wrote: >> Yes; I'd rather go by what the standard says than rely on >> implementation-dependent hacks. > > You shouldn't limit yourself to what some standard says. You shouldn't ignore previous work and standards can embody decades of programming language resea

Re: merits of Lisp vs Python

Michael Livshin wrote: > Paul Rubin writes: >> Nobody seems to concerned that Haskell lacks macros. What's up with >> that? > > Haskell is lazy, so it doesn't need macros Outside Lisp, macros are for syntax. Evaluation semantics (e.g. lazy evaluation) then have nothing

Re: merits of Lisp vs Python

Stephen Eilert wrote: > So, let's suppose I now want to learn LISP (I did try, on several > occasions). What I would like to do would be to replace Python and code > GUI applications. Yes, those boring business-like applications that > have to access databases and consume those new-fangled web-serv

Re: About alternatives to Matlab

Paul Rubin wrote: > Well, work is already under way (already mentioned) to implement > Python in Python, including a reasonable compiler (Psyco). > > The big deficiency of MLton from a concurrency perspective is > inability to use multiprocessors. Of course CPython has the same > deficiency. Sam

Re: About alternatives to Matlab

Carl Banks wrote: > Jon Harrop wrote: >> What about translating the current Python interpreter into a language >> with a GC, like MLton-compiled SML? That would probably make it much >> faster, more reliable and easier to develop. > > I doubt it would work too

Re: About alternatives to Matlab

[EMAIL PROTECTED] wrote: > On 10.12.2006, at 11:23, Jon Harrop wrote: >> F# addresses this by adding operator overloading. However, you have >> to add more type annotations... > > That sounds interesting, but I'd have to see this in practice to form > an opinion. As

Re: merits of Lisp vs Python

Mark Tarver wrote: > How do you compare Python to Lisp? What specific advantages do you > think that one has over the other? > > Note I'm not a Python person and I have no axes to grind here. This is > just a question for my general education. >From my point of view as neither a Lisp nor Python

Re: merits of Lisp vs Python

Steven D'Aprano wrote: > Anything any language can do is possible in any other language Not true. Concurrency, for example. > Lisp developers so often gloss over that: "Oh, > feature X is *easy*, I could write it in a couple of macros. Two or three. > Maybe thirty. Or forty, max. And they would

Re: About alternatives to Matlab

Filip Wasilewski wrote: > Besides of that this code is irrelevant to the original one and your > further conclusions may not be perfectly correct. Please learn first > about the topic of your benchmark and different variants of wavelet > transform, namely difference between lifting scheme and dwt,

Re: About alternatives to Matlab

sturlamolden wrote: > Little is as efficient as well-written ISO C99 (not to be confused with > C++ or ANSI C). OCaml and F# are almost as fast as C++ in this case. I suspect most other modern languages are. > So I assume you make sure that the cache is > prefetched and exploited optimally for yo

Re: About alternatives to Matlab

sturlamolden wrote: > I don't agree that slicing is not the best way to approach this > problem. Indeed, the C++ approach can be written very succinctly using slicing: for i=0 to n/2-1 do tmp[i] = dot a[2*i:] h; tmp[i + n/2] = dot a[2*i + 1:] g; where a[i:] denotes the array starting at inde

Re: About alternatives to Matlab

Carl Banks wrote: >> Optimized Python is 14% slower than badly written OCaml. > > I'd call that roughly the same speed. Did you use any sort of > benchmark suite that miminized testing error, or did you just run it > surrounded by calls to the system timer like I did? System timer, best of three

Re: About alternatives to Matlab

Carl Banks wrote: >> 0.56s C++ (direct arrays) >> 0.61s F# (direct arrays) >> 0.62s OCaml (direct arrays) >> 1.38s OCaml (slices) >> 2.38s Python (slices) >> 10s Mathematica 5.1 > [snip] >> 1.57s Python (in-place) > > So, > optimized Python is roughly the same speed as naive Ocaml > optimized Ocam

Re: About alternatives to Matlab

Carl Banks wrote: >> fill a (map3 (fun b c d -> b + c + d) b c d) >> >> which will be much faster because it doesn't generate an intermediate >> array. > > Ah, but, this wasn't about temporaries when you spoke of "eagerly > allocating arrays", was it? I had thought that all of the array operati

Re: About alternatives to Matlab

Carl Banks wrote: > No, they're never redefined (even in the recursive version). Slices of > them are reassigned. That's a big difference. I see. > (Actually, it does create a temporary array to store the intermediate > result, but that array does not get bound to odd.) Sure. >> In particular

Re: About alternatives to Matlab

I don't know Python but this benchmark caught my eye. >>def D4_Transform(x, s1=None, d1=None, d2=None): >> """ >> D4 Wavelet transform in NumPy >> (C) Sturla Molden >> """ >> C1 = 1.7320508075688772 >> C2 = 0.4330127018922193 >> C3 = -0.066987298107780702 >> C4 = 0.517638090205041