sutton036

The Mathematica programming language has many unusual characteristics, two of which are: Everything is an expression. Pattern-based rewrite rules are obscenely powerful. These kinds of characteristics are the foundation of what makes Mathematica a powerful programming language. For example, the bubble sort algorithm can be implemented in a single line without a loop in Mathematica using a single conditional rewrite rule that exchanges adjacent elements when they are out of order: bubble[xs___, x_, y_, ys___] := bubble[xs, y, x, ys] /; x > y This definition causes a new rewrite rule to be injected into Mathematica's global table of rewrite rules. Mathematica then applies this rule to any subexpression it sees that has the form bubble[..] . The pattern on the left side of the rule searches for a pair of adjacent arguments ( x and y ) to bubble where x>y . If the pattern matches then the expression is rewritten such that x and y are exchanged. This example not only demonstra...

We just finished a week of hell after trying and failing to upgrade from Debian Lenny to Debian Squeeze. None of the Debian Linux kernels working correctly on our stock Dell PowerEdge T605 hardware was the first major headache and KDE 4 was the second. In our 10 years of using Linux its user unfriendliness seems to be as poor as ever. With the latest KDE 4, it seems that KDE itself has also gone from bad to worse. We migrated from Gnome to KDE many years ago because we found Gnome to be buggy and user unfriendly only to discover that KDE was only superficially stable. KDE 4 takes this to a new level and our log files are filled with records of segfaults. KMail was once riddled with serious bugs but these were ironed out in KDE 3 and it became a usably-stable e-mail client a few years ago and served us well. Not so with KMail from KDE 4, which regularly segfaults, losing and/or corrupting data and has consistently failed even to move significant numbers of e-mails around within its own ...

The Reddit user ethicszen has kindly created a subreddit for HLVM-related news and discussion . Please post links to interesting HLVM articles there. Also, don't forget to join our mailing list if you want to hear what is going on or discuss HLVM in any way.

Cofounder of Flying Frog Consultancy Ltd. , Dr Jon Harrop, did his PhD at the University of Cambridge on the "Structural properties of Amorphous Materials" in the department of chemistry. A large part of this work was on the application of time-frequency analysis to the study of the diffraction data of amorphous materials. The complete PhD thesis is now freely available for download as a PDF here . In the process, Dr Harrop developed a new approach to time-frequency analysis that is based upon the continuous wavelet transform (CWT). This method of analysis is applicable to a wide variety of signals that arise in many different areas of study including biology , physics , finance , engineering , and bioinformatics . Chapter 2 introduces the method of time-frequency analysis and discusses various different approaches that have been invented over the years. In particular, the beneficial charactistics of the continuous wavelet transform are described in detail, along with the mat...

Miguel de Icaza of the Mono project made two surprise announcements in a recent blog post : "We are working to improve our support for F# and together with various groups at Microsoft we are working to improve Mono's compatibility with the CLR to run IronPython, IronRuby and F# flawlessly in Mono. Supporting F# will require some upgrades to the way that Mono works to effectively support tail call optimizations." "we continue to work on integrating LLVM [better use LLVM to produce better code, use it in more places where the old JIT was still required and expand its use to be used for AOT code]" We have been pushing for these developments (F# support and an LLVM backend) for over a year now and it is very exciting to hear that the Mono team are taking this seriously. F# is the future of .NET and building upon LLVM offers huge potential not only for improving upon the performance of Mono's code generator but also in improving LLVM itself, which is now the ...

For a bit of fun, we recently ran programs to determine the current sizes of our company's OCaml and F# code bases. This includes the code we use in-house for everything from web analytics to accountancy as well as the code behind our commercial products . We found 345kLOC of OCaml code and 171kLOC of F# code. In comparison, Jane St. Capital now have around a million lines of production OCaml code and Citrix have 130kLOC of production OCaml code .

The latest OCaml Journal article High-performance parallel programming with HLVM (23rd January 2010) described a simple but effective parallelization of the HLVM implementation of the ray tracer. Comparing with similarly naive parallelizations of the fastest serial implementations in C++ and Haskell, we obtained the following results: These results exhibit several interesting characteristics: Even the naive parallelization in C++ is significantly faster than HLVM and Haskell. C++ and HLVM scale well, with performance improving as more cores are used. Despite having serial performance competitive with HLVM, the naively-parallelized Haskell scales poorly. In particular, Haskell failed to obtain a competitive speedup with up to 5 cores and its performance even degraded significantly beyond 5 cores, running 4.4× slower than C++ on 7 cores. The efficiency of the parallelization can be quantified as the speed of the parallel version on multiple cores relative to its speed on a single core:...