This is way too scripted and the childish exuberance is too calculated to not be done by an adult
It's more of an issue with the JVM than it is with scala,
If this were true, then the Java version would be as slow as the Scala version, wouldn't it?
Also, sure you can do some functional/immutable programming in C#, but
that's really not the strength of C# or a good choice for more serious
functional/immutable programming. Even if you prefer pure Microsoft
branded tech, F# is far better for that.
You can also do functional/immutable style designs in Java. Not as
elegantly as you could in Scala/Haskell/Clojure/OCaml/F#, but my team
is doing exactly that.
FYI, here is the Java code that I used:
On Thu, Feb 9, 2012 at 9:49 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
It's more of an issue with the JVM than it is with scala,If this were true, then the Java version would be as slow as the Scala version, wouldn't it?
If, like you say, the issue is with boxing, then it's clearly related to the way Scala does its boxing and it has nothing to do with the JVM.
--Cédric
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Bringing this back to the real world, did someone say imperative? Lets try declarative for a change :)import math._val phi = (1+sqrt(5))/2.0ddef fib(n: Int) = round(pow(phi,n)/sqrt(5))(0 to 10) map (fib)// = Vector(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55)
I would have used BigDecimal for accuracy, but that would need me to use JScience or equivalent or roll my own pow, sqrt, and round functions - a bit overkill for such a simple example!Rest assured that +, /, etc. work just fine for BigDecimals in Scala, and therein lies the real power of the language; the stuff that should be simple remains so, unhindered by boilerplate.
I think in this case the benefit of Scala is if you try and add a few
zeros to the max number you are looking at more than it is
performance. Changing the Scala code to work on BigInt level values
is trivial. Changing the Java is a pain in the neck. (Not
impossible, by any measure, just annoying.)
Also, I'm not entirely sure what you are aiming for in this. The
speed of both of these solutions is quite nice, by any measure. If
you are doing any "non-trivial" application you are most likely
hitting other bottlenecks than number crunching ability.
On Thursday, February 9, 2012 11:47:30 PM UTC+1, KWright wrote:Bringing this back to the real world, did someone say imperative? Lets try declarative for a change :)import math._val phi = (1+sqrt(5))/2.0ddef fib(n: Int) = round(pow(phi,n)/sqrt(5))(0 to 10) map (fib)// = Vector(0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55)That also looks like a completely different algorithm.
I would have used BigDecimal for accuracy, but that would need me to use JScience or equivalent or roll my own pow, sqrt, and round functions - a bit overkill for such a simple example!Rest assured that +, /, etc. work just fine for BigDecimals in Scala, and therein lies the real power of the language; the stuff that should be simple remains so, unhindered by boilerplate.Java is horribly stuck in legacy, it should've had a decimal (base 10) type ages ago, but I digress. What I don't understand is, if Scala suffers from runtime penalties approaching an order of magnitude for this simple problem, under which conditions does it start to pay off automagically? Perhaps the culprit here is that Fibonacci is inherently a linear/serial problem, so prime number factorization might be a better example?!
/Casper