RE: Confused by Clojure floating-point differences (compared to other languages)
IIRC, Java provides unusual trigonometric functions which, I’m guessing,
Clojure is using. I think the Java ones are actually more accurate (and slower)
so you may well find the answer obtained on the JVM is more precise than the
others.
Cheers,
Jon.
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of
Glen Fraser
Sent: 05 February 2014 13:17
To: clojure@googlegroups.com
Subject: Confused by Clojure floating-point differences (compared to other
languages)
(sorry if you received an earlier mail from me that was half-formed, I hit send
by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result 0.0541718..., but in Clojure I
get 0.24788989 I realize this is a contrived case, but -- doing an
identical sequence of 64-bit floating-point operations on the same machine
should give the same answer. Note that if you only run the function for about
~110 iterations, you get the same answer in Clojure (or very close), but then
it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the type it tells me java.lang.Double, which seems right). Maybe
Clojure's answer is better, but I do find it strange that it's different.
Can someone explain this to me?
Here are some results:
Clojure: ~23 seconds
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: 0.24788989279493556 (???)
C++ (g++ -O2): ~4 seconds
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: 0.0541718
Lua: ~39 seconds
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: 0.054171801051906
Python: ~72 seconds
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: 0.05417180105190572
SClang: ~26 seconds
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: 0.054171801051906 (same as C++, Lua, Python; different from Clojure)
Thanks,
Glen.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Do you guys have any concrete examples? Sent from my iPhone On 23 Dec 2013, at 10:13, Korny Sietsma ko...@sietsma.com wrote: This ties in nicely to my summary of how I feel about static typing: Static typing is a premature optimisation. Like most optimisations, it has genuine value, but if you apply it globally and too early, you end up causing more pain than you gain. sometime type discussions lead to lead to early and convenient detection of bugs - I'd agree with this; but in my experience, most of the bugs caught by type systems are relatively simple and straightforward, and not the sort of bugs that make it into production. I've almost never seen a _serious_ bug caused by dynamic typing - and I've seen plenty of serious bugs that type systems would not have caught. Static types also help with rapid IDE/compiler feedback of errors - but you often pay for this with slow compilation, especially when you need global type inferencing; and with complex (and often buggy) IDEs/compilers. I had huge pain getting the Scala IDEs to work reliably, last time I worked in Scala (admittedly this was a few years ago) - and they are still having lots of pain with performance, even though Scala doesn't have global type inference. Statically typed code generally performs better - but if there's one major rule I've learned in 25 years in IT, it's that code performance is not your real problem, 99% of the time. Your real problem is more likely to be IO, or poor algorithm design, or inefficient scalability, or slow speed of development, or difficulty diagnosing bugs, or unreadable unmaintainable code. I had people telling me that C++ was too slow, I should stick to C. Then, that Java was too slow, I should stick to C++. Then, that Ruby/JavaScript was too slow, I should stick to Java. None of these people were right. These days, I'd generally optimise first for expressive code so it's fast to develop and maintain; then for powerful flexible languages that can do anything I need them to do, and last for raw performance. I'm quite attracted by optional static typing, because it means I can rapidly code in a flexible dynamic language, and if I get to the point where I really need types, I can add them. But I suspect that most of the time, I'll never get to that point - or I'll use something like Prismatic Schema to define constraints at my external interfaces only, which is where I generally find I need them. - Korny On 23 December 2013 12:24, Richard Cole richard.j.c...@gmail.com wrote: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a language, it's a building material. If you want to know what are the current problems in static typing you going to have to start learning what people are doing in that field, e.g. is their foreign function interface from Haskel to Java? Why not? Can a well typed program still exhibit bugs? If the type checking is so powerful why do bugs persist? You might also look at what Gilhad Brakka was attempting to do with newspeak and his notions of types being anti-modular. You are not going to find a proof that that line of enquirely is fruitless, you'll instead find what people can do today in that field and where they're pushing the bounds. regards, Richard. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at
Re: Pattern Matching
On Thursday 04 February 2010 23:53:19 Base wrote: Hi John - Thanks for a very intersting response. Do you have any real experience in F#? Yes. I consulted for Microsoft on F# twice, wrote both the first and the most recent books on F#, wrote and published the world's first and second commercial applications written in F# and am an editor and author for the F#.NET Journal. I am really interested in hearing your opinion/thoughts on it relative to other functional languages (you appear to be quite well versed). The main thing that sets F# apart from the other functional languages is that it is officially backed by a huge corporation: Microsoft. They have put a lot of time and money into F# (almost 10 years in the making and ~10 people on the F# team now) and it really shows. F# is comparatively polished with a nice IDE compared to other functional languages, although it still lacks support for some features that C# has like GUI designer integration and WSDL. F# is really bred for interactive technical computing. They took the core of the OCaml language, which was known for being pragmatic and predictably efficient, and made it a lot faster and added the good features from other languages like Python and Haskell as well as new features like parallelism. F# has first-class interop with the whole of .NET and, in particular, because it is statically typed can easily be used to write components for C# users to consume. It looks very interesting, but I am frankly having a hard enough time with Clojure to spend my time on trying to add more to my plate. In the language zoo, F# and Clojure are very different (think C# vs Jython). However, Clojure is similar in an unusual methodological way from the point of view of functional programming: it is designed from the ground up to be pragmatic. Most functional languages (e.g. OCaml, Haskell, Scala) are designed by researchers for the purposes of generating papers and grant funding. Consequently, they usually either have no support or poor support for mundane but essential features like interoperability and they do not absorb good features from elsewhere (because it would not constitute research). In contrast, Clojure and F# are designed and implemented by real world programmers for real world programmers and are not afraid to borrow good features from other languages. From a business point of view, this pragmatism means a healthier and wealthier market of users who depend upon the language. That is reflected in the funding (the Industrial Haskell Group failed to garner a single new subscriber since its inception, the CAML Consortium garnered a dozen or so users over several years but could not even fund a single developer whereas Rich Hickey just had to ask his community to get complete funding and Steve Ballmer is throwing resources at Microsoft). Having tried both the academic and the pragmatic languages, I must say that I really prefer not only the pragmatic tools but also the kinds of people who gravitate around them. I much prefer reading about real users and their experiences trying to apply technology to solve important problems, rather than reading endless articles about scalably parallelized Fibonacci functions and rigged language comparisons. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Pattern Matching
On Thursday 04 February 2010 14:08:44 Sean Devlin wrote: Do we have a concise way of doing this? Is it actually useful? http://www.artima.com/weblogs/viewpost.jsp?thread=281160 Are you talking about the pattern matching or the for loop? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Pattern Matching
On Thursday 04 February 2010 16:32:36 Sean Devlin wrote: Pattern matching Ok. Pattern matching is a core construct from the ML family of languages and, consequently, is now ubiquitous in F#, OCaml, Standard ML and Haskell as well as Scala. In the MLs, pattern matching is the only way to destructure data. For example, you can extract the two elements of a pair and bind their values to the variable names a and b as follows (OCaml/F# code): let a, b = a_pair Pattern matching is a powerful technique that has been generalized in many ways, so you can also destructure a pair of pairs by nesting patterns: let (x0, y0), (x1, y1) = two_vectors Pattern matching is also used for dispatch in those languages (although the object oriented ones including OCaml and F# also provide method dispatch). Moreover, patterns can match on more than just objects, e.g. numbers: let rec factorial = function | 0 | 1 - 1 | n - n * factorial(n-1) Note the or-pattern 0|1 to match either 0 or 1. A more advanced example including nesting, or-patterns, guarded patterns (with when) and named subpatterns is to merge two sorted lists (OCaml/F# code): let rec merge = function | [], xs | xs, [] - xs | x::xs', (y::_ as ys) when x = y - x::merge(xs', ys) | xs, y::ys' - y::merge(xs, ys') I've written about it here: http://www.ffconsultancy.com/ocaml/benefits/pattern_matching.html You may also be interested in this symbolic simplifier challenge: http://www.lambdassociates.org/studies/study10.htm Note that the Common Lisp solutions are 50-160% longer and 1.7-7.5x slower than the OCaml. Pattern matching is uncommon is Lisps because its core benefits (static checking and performance) rely upon static type information. However, some dynamic languages (e.g. Mathematica) do provide and make heavy use of pattern matching. On the other hand, dynamic languages can do lots of funky things with pattern matching that static languages do not, most notably allowing patterns to be generated at run-time (even MetaOCaml does not allow this). A major disadvantage of pattern matching can be that it requires libraries to expose their internals in order for a user to be able to pattern match over them. This problem was solved using view patterns which are bundled with F# (as active patterns) and Scala (as extractors). I have found pattern matching to be extremely valuable not only because it permits very clear and concise solutions to many problems but also because the static checking it provides allows me to leverage a static type system to prove aspects of correctness that remove major classes of bugs from real applications. HTH. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Matt Raible: Why is Clojure better than Scala or Groovy?
On Saturday 16 January 2010 18:10:15 Shantanu Kumar wrote: The best benefit of Clojure is, I think, the power-to-weight ratio. That's a really good description for a low barrier to entry. :-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in java
On Saturday 28 November 2009 20:58:54 eyeris wrote: It's also important to get features into Java if you want real substantial JVM performance tuning for them. Not if they're anything like Microsoft: F#'s closures are much faster than .NET's closures... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures in java
On Saturday 28 November 2009 17:25:58 Daniel Simms wrote: Also, I wanted to chime in with something like we already have closures: use Clojure! or Jython, or... So how about TCO? Amen, brother. PS: And value types. ;-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure vs scala
On Wednesday 26 August 2009 08:35:49 Konrad Hinsen wrote: On 26 Aug 2009, at 07:06, Vagif Verdi wrote: I fail to see how macros can be contrasted to static typeng. They are orthogonal. That is true in principle, but integrating Lisp-style macros and compulsory static typing (as opposed to optional type hints) into the same language does require some careful thought. I haven't seen such a combination yet... I'm not sure what you regard as Lisp-style macros but you may be interested in OCaml's untyped Camlp4 macros and Template Haskell's typed macros. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure vs scala
On Wednesday 26 August 2009 04:37:58 Alan Busby wrote: On Wed, Aug 26, 2009 at 5:43 AM, npowell nathan.pow...@gmail.com wrote: I mean, I didn't think the article was terribly in depth, but a real, evenhanded comparison would be enlightening. Reducing it further, I'd be interested just to hear more about the contrast of static typing versus macros. Which is more beneficial for different situations and why? Both are used in OCaml but static typing is, of course, far more common there because it is a core feature of the language. They really solve completely different problems. Static typing is used to improve performance, catch errors, provide a form of machine-verified documentation and convey information to the programmer in the IDE or REPL. Macros are used to extend the syntax of the language either for adding missing general features or for creating DSL. Additionally, OCaml's macro system is often used for general lexing and parsing or arbitrary syntaxes. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure vs scala
On Tuesday 25 August 2009 21:43:56 npowell wrote: On Aug 25, 4:36 pm, Christian Vest Hansen karmazi...@gmail.com wrote: I think he misrepresents both Scala and Clojure. ... Not a super helpful assessment. I'd like to hear more. What do you disagree with and why? I think most of the article was vacuous, consisting mainly of verbatim quotes of contentless propaganda. Some of the statements are absurd, such as Clojure and Scala have big momentum. Java has big momentum. Clojure and Scala are struggling to reach the first rung on the ladder. For example, Scala has around 0.02% share of the job market here in the UK (!): http://www.itjobswatch.co.uk/jobs/uk/scala.do I don't want to rain on anyone's parade but that is not big momentum by any stretch of the imagination. What does Very clever immutable datastructures mean? How are Clojure's any more clever than the next implementation? What about [Scala has a] very powerful type system? Sounds like C++ has a Turing complete type system to me. Powerful != good when it comes to type systems. I have explained why I dislike Scala's type system (particularly its very poor type inference) before: http://groups.google.com/group/jvm-languages/msg/b7edd5f9e6ed0361 The biggest promise of Scala nevertheless is power and terseness. Compared to OCaml, Scala is verbose because it requires all of those unnecessary type definitions and annotations. Finally, the article failed to mention what is perhaps the single biggest concern about Scala: it is an academic language. Consequently, Scala will always be developed toward what is novel and not what is useful. At least for me, that is seriously off-putting. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Java STM
On Monday 13 July 2009 01:55:07 Mark Volkmann wrote: Is there another STM implementation that enforces its use like this? I assume Haskell tells you at compile time. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: loneclojurian at ICFP programming contest
On Tuesday 07 July 2009 02:08:57 Bradbev wrote: On Jul 6, 4:30 pm, fft1976 fft1...@gmail.com wrote: On Jul 5, 11:42 pm, Bradbev brad.beveri...@gmail.com wrote: more to modern x86 chips. After you have the best algorithm for the job, you very quickly find that going fast is entirely bound by memory speed (actually latency) - cache misses are the enemy. IME (outside JVM), this depends strongly on the kind of problem you are solving as well as your implementation (you need to know how to cache-optimize). One can easily think of problems that would fit entirely in cache, but take an enormous amount of time. What sort of problems did you have in mind? Anything that I can think of quickly spills the cache. There are many examples in scientific computing where many small problems are attacked instead of one large problem. For example, practical use of FFTs fall into this category with most users performing many transforms with no more than 1,024 elements rather than fewer longer transforms. Time frequency analysis usually takes n samples and produces an nxn grid over time and frequency representing the signal where each frequency is computed from a separate FFT. So you can get away with naive distribution of FFTs across cores with no regard for cache coherence and still get very good performance. This is somewhat reflected in the SciMark2 benchmark, which has small and large variants. Most people are interested in the in-cache small variant because it is more practically relevant. Cache coherence is still relevant in some of the subtasks even in the small case but it is a much smaller effect. I am in the process of reimplementing stock numerical algorithms (Cholesky, LU, QR, Eigenvalues) for our F# for Numerics product, written entirely in F# and parallelized using the TPL. Surprisingly, some of my F# code is 3x faster than the equivalent MATLAB for small (e.g. 100x100 matrices) problems even though MATLAB is calling directly into vendor-tuned code. For larger problems (e.g. 1000x1000 matrices), MATLAB is usually 10x faster because it is using code that was carefully optimized for cache issues. I would actually say that intercore cache effects are more important than conventional cache coherence today because you get massive performance degradation if you cock it up and it is not at all obvious when that might occur because it depends upon things like where the allocator places your data. For example, if you have cores mutating global counters then you must make sure they are spaced out enough in memory that none share cache lines. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: loneclojurian at ICFP programming contest
On Sunday 05 July 2009 23:19:31 fft1976 wrote: On Jul 5, 10:53 am, igorrumiha igorrum...@gmail.com wrote: I think it's safe to say that once again it's proved that Clojure easily matches the Java level of performance. I think one shouldn't generalize from one [unverified] example. Personally, I'll wait for Jon Harrop or someone to port the relevant Shootout benchmarks or his Ray tracing benchmark to Clojure and see what time they get and what the code looks like. That's a fantastic idea! Let's try porting my ray tracer to Clojure. Incidentally, Java's performance was extremely variable on the ray tracer benchmark. All of the other submissions I received were substantially slower than the one currently on the site. I forget why but I remember thinking it was an innocuous-looking tweak at the time... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: loneclojurian at ICFP programming contest
On Thursday 02 July 2009 07:58:11 you wrote: I wonder if Jon Harrop is still planning to write Clojure for Scientists or Scala for Scientists or both? I am certainly interested in writing both books. I reviewed Scala back in 2007 and decided that it was not ready to be advocated. Perhaps things have progressed significantly since then but my impression is that Clojure is developing in a more productive direction and much more rapidly. I am also more interested in Clojure because it strives to be a genuine functional language rather than an OOP language with some odds and sods bolted on (Scala feels like a minor departure from Java to me, and I am not a Java fan. In fact, more like C# 3 than any real functional language) and because Clojure is designed with industrial use in mind rather than as an academic exercise. However, I have yet to give Clojure the thorough study that it deserves simply because I am tied up getting our F# products ready for its big release in 2010. If anyone here is interested in a Clojure book aimed at technical users (scientists and engineers), please let me know. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Monday 22 June 2009 12:01:19 Konrad Hinsen wrote: Java threads, according to the documentation: clojure.core/future ([ body]) Macro Takes a body of expressions and yields a future object that will invoke the body in another thread, and will cache the result and return it on all subsequent calls to deref/@. If the computation has not yet finished, calls to deref/@ will block. The macro future is used in the implementation of pmap. If that is spawning a new thread every time a future is created then it is really for concurrent programming rather than parallel programming. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Monday 22 June 2009 22:33:24 Stephen C. Gilardi wrote: On Jun 22, 2009, at 5:53 PM, Jon Harrop wrote: If that is spawning a new thread every time a future is created then it is really for concurrent programming rather than parallel programming. The thread is from a cached thread pool provided by the Executors class: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executors.html#n ewCachedThreadPool%28%29 Ok, that will be reliable then but performance is quite a bit worse than it could be. Essentially the same as pre-TPL .NET, e.g. using asynchronous workflows in F# today. The migration occurs officially on the MS side with the release of .NET 4 next year. Is there a similar plan on the JVM side? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sunday 21 June 2009 02:44:02 Kyle Schaffrick wrote: On Sat, 20 Jun 2009 11:29:44 +0100 Jon Harrop j...@ffconsultancy.com wrote: The Task Parallel Library. It uses concurrent wait-free work-stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! Interesting. It strikes me that it's called task parallel library, while it sounds a lot like Intel Threading Building Blocks, which is a sort of STL-style quasi-functional template library for *data*-parallel algorithms; the stuff people like to write with Fortran, OpenMP and friends. I had not looked at Intel's offering because it does not (AFAIK) support accurate garbage collection. Also, it is worth noting that there is no difference between data and task parallelism in a genuine functional language. It uses a work-stealing thread-pool scheduler as well, atop which stuff like parallel maps and reductions are implemented as templates. You can create your own work items and stick them in the scheduler by hand, but the useful bits are actually the prefab algorithms, IMO. Right. If you hand-roll your C++ very carefully then you can get decent performance but I was disappointed with the performance of the template libraries and quality of g++ back in 2004 and have never used C++ since. I've heard good things about D but, IMHO, it fails to cash in on lots of language features. Most notably FP. The tunable/pluggable slicing strategies, built on the standard iterator concepts, are particularly interesting way to give you full control of work unit granularity, without having to know too much about the innards of the algorithms themselves. Yes. The nice thing about using a functional language is that you can easily pass two functions, one to solve the problem and the other describing the complexity of the first as a function of its inputs. If necessary, you can augment your data structures with extra information to make it efficient to compute complexities. Then you can use the new complexity function to intelligently parallelize your algorithms into tasks such that the (roughly-constant) overhead of spawning tasks is guaranteed to be small compared to the work done by the task and, hence, you can greatly increase the probability of getting a speedup compared to ordinary chunking. Moreover, there is great benefit in sharing the same load balancing system. For example, if you write a parallel .NET program where tasks invoke the Intel MKL then the MKL uses independent parallelization and that renders your performance unpredictable at best and awful at worst. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sunday 21 June 2009 08:55:54 Anand Patil wrote: Sounds similar to ForkJoin, which Rich pointed out to me a while ago: http://www.ibm.com/developerworks/java/library/j-jtp11137.html Yes. I believe the main difference is that the TPL does not block because there is no join operation. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Saturday 20 June 2009 08:34:39 Konrad Hinsen wrote: On 19.06.2009, at 10:35, Jon Harrop wrote: If you really do mean scientific applications in general (e.g. Mathematica, MATLAB) then I would say that they are definitely almost all running on multicore desktops and not distributed clusters. What I really meant is scientific applications typically written by scientists, and in my experience that is mostly number-crunching stuff, if only because that's all most scientists would care to write. Mathematica and MATLAB are written and maintained by professional programmers. Ok. I think scientists write a lot of other software as well and, in particular, the vast majority of their code is disposable software written in languages like Mathematica. That software runs on individual desktops. Shared-memory parallelism is certainly a major problem in scientific computing today so I, for one, would love to see parallelized Clojure solutions to interesting problems (even toys). What sort of basic infrastructure would you use in Clojure, e.g. equivalent to Microsoft's TPL? What't TPL? The Task Parallel Library. It uses concurrent wait-free work-stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! I assume the JVM has everything required to implement wait-free algorithms? What are parallel map reduce etc. implemented upon in Clojure? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Scala vs Clojure
Can anyone who has tried both of these languages to a decent degree compare them in practical terms? In other words, I am not interested in the technical aspects of the languages themselves (e.g. dynamic vs static typing) but things like IDE support, tools (lexers and parsers), standard libraries, books and their quality, existing commercial applications and the commercial viability of shipping products targeted at their programmers (e.g. libraries)? I've never done anything significant on the JVM so I'm interested in picking one of these two languages and shipping a product for it. I've done a lot of commercial work with F# over the past 2 years but all Microsoft-related sales have died this year so I'm looking to diversify... Many thanks, -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Thursday 12 March 2009 06:38:48 Korny Sietsma wrote: But maybe you use unit tests some other way? How do you use unit tests to track down bugs? I mean: I had unit tests for each function but they were not identifying the bug so I kept augmenting them with more tests in the hope that I would identify the bug. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Wednesday 11 March 2009 04:44:17 e wrote: ...Afterall he could have chosen a dynamically typed language for his business if he had wanted to... FWIW, my company ships products written in many different languages including dynamic languages and I have been programming in dynamic languages for over 25 years. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Wednesday 11 March 2009 15:05:39 Konrad Hinsen wrote: On Mar 11, 2009, at 3:31, Jon Harrop wrote: Most of the reasons given in this thread were red herrings and many of static typing's real issues were not even touched upon: ... I'd add two more: - Metaprogramming is a lot more complicated with static typing. Look at MetaOCaml or TemplateHaskell and compare to any Lisp to appreciate the difference. Of course, Lisp's syntactic simplicity is also an important factor, but type-correctness adds another level of complexity to metaprogramming. I agree that static type checking metaprograms when the compiler is compiled does not work well (e.g. in MetaOCaml and Template Haskell) but static type checking what the run-time compiler generates works very well (e.g. JIT compilation in LLVM). - Type-related boilerplate code can make a program harder to read in some situations. For an example, look at Haskell's monad transformer implementations and compare to Clojure's. In the Haskell code, wrapping the real data into an algebraic data type that exists only for type checking, and the associated unwrapping, seriously obfuscates the rather simple structure of the monad transformers. Yes, that is the best example yet IMHO. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Wednesday 11 March 2009 15:30:01 Cosmin Stejerean wrote: Actually it happens a lot in real code and in many non-trivial programs in static typed languages you end up with a proliferation of types that are simply there to make the compiler happy. To me it happens very often where I know what I want: to pass an object of type B into a function f that expects type A, because I know that B is sufficiently A-like to allow function f to work. Another red herring: you are describing a disadvantage of nominal over structural typing. Not dynamic vs static typing. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Wednesday 11 March 2009 18:18:59 Raoul Duke wrote: Another red herring: you are describing a disadvantage of nominal over structural typing. Not dynamic vs static typing. there are probably several different arguments being conflated in such discussions. for example, theory vs. practice: there is the theory of what in fact are the options for typing, and then there is the practice of what programming languages currently exist, and what of all those options do they implement. so if there is not a popular statically typed language which does duck typing, and most people are only aware of statically typed languages that don't, then that practice can easily lead one to be confused into saying the theory of statically typed languages don't work because they don't support duck typing. or statements made can be mistakenly inferred to be talking about the theory when they are really talking about the practice. Exactly, yes. in other words, what statically typed language do proponents of such languages hold up as the one which would most likely be the least despicable in the eyes of dyed-in-the-wool dynamic language folks? The least despicable would probably be F# because you can resort to dynamic typing so easily: just box everything and use run-time type tests. That is not possible in OCaml and Haskell but they have more advanced static type system features (e.g. structurally-typed objects and polymorphic variants in OCaml) that are used to solve the same problems. The obvious bad examples are Java and C++ and I don't think it is a coincidence that most of these red herring examples seem to be drawn from problems specific to those two languages. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Wednesday 11 March 2009 18:35:46 Cosmin Stejerean wrote: On Wed, Mar 11, 2009 at 1:03 PM, Jon Harrop j...@ffconsultancy.com wrote: Another red herring: you are describing a disadvantage of nominal over structural typing. Not dynamic vs static typing. You are correct, my apologies. I was trying to show an example of situations where what I know and what the compiler wants is different, but as you pointed out my example is only valid in the case of a nominal type system. No problem. The most commonly cited examples in academia are the fix point combinator and polymorphically recursive functions, neither of which type directly in the Hindley-Milner type system that today's statically-typed FPLs are almost all based upon. However, not only do both OCaml and Haskell handle those examples fine but the examples themselves are of little practical relevance. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Wednesday 11 March 2009 20:27:15 chris wrote: Lets take this discussion forward and think of how we could incrementally add the important benefits of strongly typed and inferred systems like ML, Haskell, and F# to Clojure while keeping the very beautiful and clean syntax and minimal mental overhead of using a LISP derivative. Check out Mark Tarver's Qi language: http://www.lambdassociates.org It provides an optional and extensible static type system built upon Common Lisp. The main problem is that statically typed languages are often chosen for performance reasons and, of course, if you built a static language on top of a dynamic language then you lose that benefit. However, that is not true of all static languages and Haskell in particular is seeing significant uptake right now despite its performance issues. So perhaps it would be most productive to have Haskell or a Haskell-like DSL within Clojure if you're interested in this kind of thing (I have no idea how useful that would actually be!). -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Thursday 12 March 2009 00:01:43 James Reeves wrote: On Mar 11, 2:31 am, Jon Harrop j...@ffconsultancy.com wrote: 2. The whole thing does not need to be complete or even functional for you to start unit testing. Apples and oranges: unit tests are not the same between dynamic and static code bases because dynamic code bases rely upon a huge number of additional unit tests to serve as a poor man's substitute for static type checking. This doesn't have to be the case. There is nothing inherently magical about a types that makes them more concise to define than a unit test. Type inference: you don't write anything and the compiler infers your implicit constraints. For example, you know that your container: [1; 2; 3] always contains 0 elements so you rewrite it as: 1, [2; 3] Same amount of code but the compiler will now prove that the container can never be empty. With unit testing, you must create tests for every function that handles the container and try to find cases where it erroneously produces an empty result. If you wished, you could create something like QuickCheck to automatically generate a test based on a type definition: (data + Integer - Integer) (data count [a] - Integer) (data str a - String) The only benefit of a static type system is that it gives you absolute guarantees that a unit test cannot. I believe brevity is a major benefit. Clarity is another: hover the mouse over a definition in F# and you get a tool tip with the inferred type as well as any relevant documentation. In Haskell, I can be certain that a function will not return an incorrect type. In Clojure, I can merely say that it is extremely unlikely the function will return the wrong type. The question is whether the guarantees a good type systems offers poses a significant advantage. I've done a fair amount of programming in Haskell, but I don't believe the type system offers any real advantage over unit tests. Guarantees sound good on paper, but the guarantees even a language like Haskell offers are very basic, unless you're willing to go to a great deal of trouble. IME, the trouble can be well worth it. I once wasted two weeks trying to track down bugs in a thousand lines of code using unit tests and never managed it. When I finally caved in and tried to leverage the static type system instead, I fixed all of the known bugs in 24 hours. I simply rearranged my data structures, exactly as I did in the above example, and the OCaml compiler would point at lines of code responsible for run-time errors and would tell me that they had now been proven redundant and could be removed safely. That was an enlightening 24 hours. You can be certain that a function will only return integers, for example, but can you be certain a function will only return even numbers? Halve it. :-) Obviously this test was extremely small, and bares little resemblance to real programs, which are exponentially more complex. But it does seem to tie into my experience, which is that unit tests are surprisingly good at ensuring a program is correct, enough that they seem comparable to the security of static types. I haven't noticed any significant different in bug rates between Haskell and Clojure, so static typing doesn't appear to have made a whole lot of difference. That will depend very strongly on your application. If you are using the applications I described before where static typing offers little advantage (essentially because the problem is inherently dynamic) then you would not expect to see a difference. On the other hand, I do seem to get less bugs than with Ruby, so perhaps immutability is a more significant factor than static typing when it comes to creating robust applications. Interesting. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Thursday 12 March 2009 00:28:06 Raoul Duke wrote: i mean, one of the major benefits, i think, of immutability is that you are in so many ways actually reducing the cognitive load that you are under when running mental simulations of your program -- which is a crucial part of being a programmer. Yes, I can well believe that for many applications. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Tuesday 10 March 2009 21:33:38 Mark Engelberg wrote: A static type system also documents these properties, but you're restricted to certain concepts that the computer can understand and prove things about. You'll start to realize that there are concepts that are difficult or impossible to easily capture with a static type system (e.g., this function takes positive even integers, and returns a number from 0 to 9). While your point is valid your example is not. Specifically, you can easily imagine a function signature: uint seq - digit -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Static type guy trying to convert
On Tuesday 10 March 2009 13:26:32 Vincent Foley wrote: Here's my feeling on it (note that I am talking about languages from the C family, not Haskell or ML). Then the feelings you are describing are specifically about C and are not related to static typing in general. 1. Like Jason Wolfe said, the interactive REPL means that you can manually test a function as soon as you're done writing it, so it's easy to get feedback and know if something breaks. Even C# has a REPL now. 2. The whole thing does not need to be complete or even functional for you to start unit testing. Apples and oranges: unit tests are not the same between dynamic and static code bases because dynamic code bases rely upon a huge number of additional unit tests to serve as a poor man's substitute for static type checking. 3. The type systems of Java, C and C++ do not protect you against errors like NullPointerExceptions. (I am pretty sure C# has nullable types now, and of course Haskell has Maybe t.) Actually Haskell's Maybe monad is a counter example because its sole purpose is to protect you from the equivalent of null pointer exceptions by forcing you to be explicit about them. 4. Not having the static type system means that if it's ever needed, it will be possible for you to do what you know is right instead of what the compiler wants. You are assuming that what you know is right and what the compiler wants are different. IME, that is virtually unheard of in real code. Most of the reasons given in this thread were red herrings and many of static typing's real issues were not even touched upon: . Implementing modern static type systems correctly is really hard. Consequently, the vast majority of new languages are dynamically typed because that is much easier to implement. . Interface code between dissimilar parts of a program is often incapable of conveying static type information so static type checking is useless here. This includes everything from remote procedure calls through to database transactions and down to the foreign function interface. Haskell's Darcs project was almost killed by an FFI-related bug. . Static typing is hard to appreciate and hard to learn. People with no experience of developing complex software correctly cannot appreciate the benefit of proving any kind of correctness because everything they have done is obvious. Concepts like parametric polymorphism are just mathematics so a math background helps. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Strapped to the JVM?
On Saturday 07 February 2009 00:19:44 mikel wrote: Can you imagine a Clojure implementation on a different underlying runtime? Which ones might possibly be suitable? Can you imagine a Clojure on top of, say the CLR? Or on top of a Common Lisp? Or on GHC or perhaps the LLVM? IMHO the world would benefit enormously from a well implemented open source common language run-time (not necessarily compatible with Microsoft's). However, that is a very tall order and nobody has come close to delivering on it yet. The main sticking point is the creation of a concurrent garbage collector, particularly now that LLVM is on the scene. Mono has a variety of serious problems in this context so the JVM is currently the best thing on offer. If the JVM really does get genuine tail call elimination then it will be by far the best option. Moreover, the effort required to build such a common language run-time would dwarf the effort required to port Clojure to it. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure speed
On Monday 02 February 2009 19:12:48 David Nolen wrote: Please do the list a favor and read the very long threads about performance. I would be interested to see a Clojure port of my ray tracer benchmark: http://www.ffconsultancy.com/languages/ray_tracer/ -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Santiago Clojurians?
On Tuesday 03 February 2009 00:39:45 blackdog wrote: Hi If there's anyone in Santiago, Chile, who speaks Clojure and some English (my Spanish is not very good) would be good to meet up. Perhaps a Venn diagram would help. ;-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure is not a serious language
Apologies if you've seen this before but I just thought it was absolutely hillarious: http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/ -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure for Games/Simluation/Art (Optimization in Clojure)
On Wednesday 28 January 2009 15:09:26 Konrad Hinsen wrote: It is possibe to generalize the Fast Multipole Method somewhat, but it remains a technique for a limited (though important) class of interactions. I disagree. The most obvious generalization of FMM (and the one presented in my books OCaml for Scientists and F# for Scientists) is the hierarchical spatial decomposition of general contributions rather than just poles. That category of methods is huge, encompasses many of the most important algorithms ever invented and is applicable to most physical simulations, most notably heterogeneously distributed ones. Moreover, the inherent ability of these methods to attain a required accuracy efficiently also makes them ideally suited for games programming where physical accuracy is traded for soft real-time performance. It is rather unlikely that it will be of any use for simulating a flock of birds. People are using FMM for flocking: http://www.itk.ilstu.edu/faculty/portegys/research/ptree-PDPTA03.pdf http://litis.univ-lehavre.fr/~tranouez/publications/Cossom2007-LITIS-DutotTranouez.pdf -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure for Games/Simluation/Art (Optimization in Clojure)
On Wednesday 28 January 2009 18:09:30 bOR_ wrote: Errata: Hanno works in Groningen. As I work in Utrecht, I sort of automatically appended 'Utrecht' after 'Theoretical Biology'. Ontopic: There is a thing called Hilbert curves that you could use. http://en.wikipedia.org/wiki/Hilbert_curve You could define a 1d array, and translate the bird 2d position into a position in that array, using the hilbert curve. Now, if you want to have a subset of nearby birds, you can just take a subarray of that array around the bird of interest, and base your bird behaviour on the birds in that subarray. Not sure what the best data structure is to implement this in, or what way to do it in clojure, but it gives you an idea. That is an academically fascinating idea that I once persued when I was an academic (in the context of dynamical matrix preconditioning). :-) Unfortunately, it does not work out well in practice despite the existence of some great Hilbert curve libraries: http://www.tiac.net/~sw/2008/10/Hilbert/moore/index.html The reason is that cache locality much prefers striping over suitably-sized tiles rather than fancy curves. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Mysterious performance anomalies
On Tuesday 20 January 2009 21:41:29 Rich Hickey wrote: This issue (TCO) is resolved - it's a limitation of the JVM that Clojure accepts. If that is a significant problem for anyone they should either not use Clojure or work on adding TCO to the JVM via the MLVM effort: http://openjdk.java.net/projects/mlvm/ Too late: http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000331.html -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Mysterious performance anomalies
On Tuesday 20 January 2009 08:01:19 ivant wrote: IIRC, the only major complain Rich has about JVM is the lack of tail-call optimization. That's a pretty major problem. :-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
