Let's say I have a function that returns a array of doubles. I want to test this function and have calculated the correct value by hand. However since it's floating point numbers, I can't do direct comparisons so is there any sweet syntax by ScalaTest that makes me able to compare double arrays with an epsilion/error margin?
Thanks
Well as I feared there is no nice syntax in ScalaTest for this, and I will accept my own answer with a very basic solution.
val Eps = 1e-3 // Our epsilon
val res = testObject.test // Result you want to test.
val expected = Array(...) // Expected returning value.
res.size should be (expected.size)
for (i <- 0 until res.size) res(i) should be (expected(i) +- Eps)
As seen, this works. Then you can make it nicer by perhaps defining an implicit method.
How about:
import Inspectors._
import scala.math._
forExactly(max(a1.size, a2.size), a1.zip(a2)){case (x, y) => x shouldBe (y +- eps)}
Or you can provide custom equality (there is a built-in one as #Suma sugested)
Related
I would expect #::: and ++ to behave identically when both operands are LazyLists. Indeed, with the following code typed into a VS Code / Metals worksheet:
LazyList.from(0) ++ LazyList.from(0)
LazyList.from(0) #::: LazyList.from(0)
both evaluate to LazyList[Int] = LazyList(<not computed>). Makes perfect sense. And if I do this:
def countFrom(initial: LazyList[Int]): LazyList[Int] =
LazyList(initial.head) #::: countFrom(LazyList(initial.head + 1))
val m1 = countFrom(LazyList(0))
VS Code shows that m1 evaluates to: LazyList[Int] = LazyList(<not computed>) which again makes perfect sense to me. No one asked for any elements, so nothing should be computed yet. But if I change the #::: to ++ as per the following:
def countFrom(initial: LazyList[Int]): LazyList[Int] =
LazyList(initial.head) ++ countFrom(LazyList(initial.head + 1))
val m1 = countFrom(LazyList(0))
then VS Code cannot evaluate m1 due to a stack overflow error while evaluating countFrom calling countFrom calling countFrom, etc. (Btw, yes, this is bizarre, contrived code. It's a simplification of code from a project I was working on that was constructing more interesting LazyLists.)
So apparently there IS a difference between ++ and #::: which is not exposed when concatenating LazyLists generated via the built-in from method, but which IS exposed by my (weird) countFrom method. Can anyone explain what's going on here?
[added after Luis Miguel Mejía Suárez's comment]
Thanks to Luis Miguel Mejía Suárez, I think I get it now, so I'm going to try to explain the details after having looked at the LazyList source (feel free to fix me if I get something wrong!). In the expression X #::: Y, Y is this, and X is the argument (which is why the parameter to #::: is named prefix in the scala docs). Since #::: is defined on Deferrer, this causes an implicit conversion of Y (a LazyList) into a Deferrer, which wraps Y into a thunk (nullary function). X #::: Y then becomes X lazyAppendedAll toDeferrer(Y)(). Then, I guess the key is that the second parameter to lazyAppendedAll is pass-by-name, so toDeferrer(Y)() is not actually evaluated until it is needed. Now as for ++, I did not see a definition of ++ in the LazyList source, so I guess it gets inherited and has a much simpler definition where, with X ++ Y, X is this and Y is the argument and Y is passed by value, and is thus evaluated on entry to ++. Since Y is a LazyList, the elements are not calculated, but Y must be evaluated down to the LazyList itself, and that's where the infinite recursion results.
For most languages I wouldn't ask "why did they do X like this?" as it's generally opinion based.
For languages like C++ the usual answer is to quote some bit of some specification and all one can say is that someone probably thought long and hard before making a particular choice (but could have made a different choice).
Scala is different - often the answer is to point out that you can think of X in terms of some simpler structures Y and Z and so the formulation of X as it is makes sense when seen in this context.
So given that I'll ask why Scala allows a definitions that introduces multiple names and evaluates a given expression once for each name?
If you asked a Java programmer to guess what would happen here, they'd probably guess wrong:
var x, y, z = 3
I.e. they'd guess only z got assigned a value.
If you explained val and then told them the following was legal:
val x, y, z = 3
Then they'd probably guess more was afoot as clearly x and y must have values after this line as they cannot be assigned a different value later.
They might assume that x and y took a default values for their type, e.g. 0 for integers, but as there are no explicit types here that'd be a leap.
They might assume that it's handled as:
val z = 3
val x = z
val y = z
It doesn't really matter when the expression to the left of the = produces a primitive value or an immutable object. But the following might give them cause to wonder:
val x, y, z = new StringBuilder
Why would anyone want to introduce three names for the same StringBuilder instance?
And if you showed them the following they might, from the construction, guess that something odder was up before they even ran the code:
var i = 0
def f: Int = {
i += 1
println(i)
i
}
val x, y, z = f
One eventually realizes that the expression that appears to only be associated with z is actually evaluated once for each name, i.e. the above is equivalent to:
val x = f
val y = f
val z = f
So is it even interesting to talk about what programmers who are used to another language might think?
Well most people come to a language like Scala from somewhere else so to a degree constructions that are likely to be confusing should be avoided unless there's a good reason for them.
At first glance this feature doesn't seem to offer much, it avoids you having to repeat yourself, but to add this piece of rather confusing syntactical sugar for such a small gain seems odd.
So is there some circumstance in which it brings real benefit? Or is there no real gain here but e.g. we maintain some kind of logical consistency with some broader pattern established elsewhere?
There is one case where this surprising feature is used: when defining a scala.Enumeration:
object Weekday extends scala.Enumeration {
val Monday, Tuesday, Wednesday, Thursday, Friday = Value
}
which calls Value (a def inherited from Enumeration) 5 times, once for each field of the enumeration. Effectively this allocates a new instance of Enumeration#Value for each field, which is obviously what you need for an enumeration to be useful.
Without this multi-assignment feature, you would have to write:
object Weekday extends scala.Enumeration {
val Monday = Value
val Tuesday = Value
val Wednesday = Value
val Thursday = Value
val Friday = Value
}
I have never seen the multi-assignment feature used anywhere else but in an Enumeration declaration.
Whether or not this is good idea in terms of language design is a subjective question, and SO is not the right place to discuss it.
You have basically answered your own question. The choice is between val x, y, z = someComplexExpression meaning
val z = someComplexExpression
val y = z
val x = z
or
val x = someComplexExpression
val y = someComplexExpression
val z = someComplexExpression
or not being allowed at all. The first is a bad choice for two reasons:
You mention the first: you don't generally need to give multiple names to the same instance.
If you choose the first, you have to duplicate the someComplexExpression every time you need the second, or to extract it to a method. If you choose the second, writing the first when you need it (despite point 1) is trivial:
val z = someComplexExpression
val x, y = z
Not allowing it would be possible. I don't think I've ever actually seen it used [before seeing your comment]. But removing it once it's allowed is a bad idea.
Obviously var x, y, z = ... needs to be consistent with this.
I have written this function in Scala to calculate the fibonacci number given a particular index n:
def fibonacci(n: Long): Long = {
if(n <= 1) n
else
fibonacci(n - 1) + fibonacci(n - 2)
}
However it is not efficient when calculating with large indexes. Therefore I need to implement a function using a tuple and this function should return two consecutive values as the result.
Can somebody give me any hints about this? I have never used Scala before. Thanks!
This question should maybe go to Mathematics.
There is an explicit formula for the Fibonacci sequence. If you need to calculate the Fibonacci number for n without the previous ones, this is much faster. You find it here (Binet's formula): http://en.wikipedia.org/wiki/Fibonacci_number
Here's a simple tail-recursive solution:
def fibonacci(n: Long): Long = {
def fib(i: Long, x: Long, y: Long): Long = {
if (i > 0) fib(i-1, x+y, x)
else x
}
fib(n, 0, 1)
}
The solution you posted takes exponential time since it creates two recursive invocation trees (fibonacci(n - 1) and fibonacci(n - 2)) at each step. By simply tracking the last two numbers, you can recursively compute the answer without any repeated computation.
Can you explain the middle part, why (i-1, x+y, x) etc. Sorry if I am asking too much but I hate to copy and paste code without knowing how it works.
It's pretty simple—but my poor choice of variable names might have made it confusing.
i is simply a counter saying how many steps we have left. If we're calculating the Mth (I'm using M since I already used n in my code) Fibonacci number, then i tells us how many more terms we have left to calculate before we reach the Mth term.
x is the mth term in the Fibonacci sequence, or Fm (where m = M - i).
y is the m-1th term in the Fibonacci sequence, or Fm-1 .
So, on the first call fib(n, 0, 1), we have i=M, x=0, y=1. If you look up the bidirectional Fibonacci sequence, you'll see that F0 = 0 and F-1 = 1, which is why x=0 and y=1 here.
On the next recursive call, fib(i-1, x+y, x), we pass x+y as our next x value. This come straight from the definiton:
Fn = Fn-1 + Fn-2
We pass x as the next y term, since our current Fn-1 is the same as Fn-2 for the next term.
On each step we decrement i since we're one step closer to the final answer.
I am assuming that you don't have saved values from previous computations. If so, it will be faster for you to use the direct formula using the golden ratio instead of the recursive definition. The formula can be found in the Wikipedia page for Fibonnaci number:
floor(pow(phi, n)/root_of_5 + 0.5)
where phi = (1 + sqrt(5)/2).
I have no knowledge of programming in Scala. I am hoping someone on SO will upgrade my pseudo-code to actual Scala code.
Update
Here's another solution again using Streams as below (getting Memoization for free) but a bit more intuitive (aka: without using zip/tail invocation on fibs Stream):
val fibs = Stream.iterate( (0,1) ) { case (a,b)=>(b,a+b) }.map(_._1)
that yields the same output as below for:
fibs take 5 foreach println
Scala supports Memoizations through Streams that is an implementation of lazy lists. This is a perfect fit for Fibonacci implementation which is actually provided as an example in the Scala Api for Streams. Quoting here:
import scala.math.BigInt
object Main extends App {
val fibs: Stream[BigInt] = BigInt(0) #:: BigInt(1) #:: fibs.zip(fibs.tail).map { n => n._1 + n._2 }
fibs take 5 foreach println
}
// prints
//
// 0
// 1
// 1
// 2
// 3
I've got a Vector of Vectors that I'm accessing to apply a boolean function. i.e.
Vector[Vector[T]] where I'm going to execute something along the lines of
f(myVector(i)(j)) where f is of type T => Boolean.
But this does not do bounds checking, and I can't get something really elegant.
I can use applyOrElse:
myVector.applyOrElse(i, (_:Int) => Vector.empty).applyOrElse (j, (_:Int) => defaultT)
where f(defaultT) would return false
But I wish I could just set a default Value instead of a function.
I could use lift to give me an Option, but it doesn't compose well at the second level:
myVector.lift(i) map (_.lift(j) map f getOrElse false) getOrElse false
Which does work, but is still really hard to read.
And then there's standard if/else blocks:
if (myVector.size <= i) false
else {
val myVector2 = levelVector(i)
if (myVector2.size <= j) false
else f(myVector2(j))
}
It just seems like something that should be able to be decomposed easier than what I can achieve. And if I add a 3rd layer, it's gets even uglier.
Are there other options?
Disclaimer: this is adapted from coursera's progfun course
Take the following code from the question:
myVector.lift(i) map (_.lift(j) map f getOrElse false) getOrElse false
This can be rewritten as follows:
myVector.lift(i).flatMap(_.lift(j)).fold(false)(f)
Or, before fold was introduced in Scala 2.10:
myVector.lift(i).flatMap(_.lift(j)).map(f).getOrElse(false)
The key idea is to defer unwrapping (or mapping) the Option for as long as possible. This approach will generalize quite naturally to more than two dimensions.
This is pretty close to equivalent to the for-comprehension in your answer (assuming you meant to include lift in there), but once you have to wrap the comprehension in parentheses I personally tend to find the desugared version clearer.
I've figured something that seems elegant, even if it seems to be a bit overkill:
(for {
myVector2 <- myVector(i)
t <- myVector2(j)
} yield t) map f getOrElse false
Is this sensible? It's certainly readable. Is it slow?
Assuming you vector is named vec and your predicate is named pred, this expression will yield right value: vec.lift(p.row).fold(false)(_.lift(p.col).fold(false)(pred(_))
I would like to not to mind about type of numbers.
All numbers could be treated as Double,
but I would like to know the better scalaish way to use numbers just as numbers.
This is just one example, suppose I have the following:
val n = 5
val l = List(1,2,3,4,5) grouped (n / 2d).ceil.toInt
Is there a way to do just (exactly):
val l = List(1,2,3,4,5) grouped (n / 2).ceil
with no compilation error due to the mismatched type of 'grouped' parameter?
EDIT
The n / 2 in grouped (n / 2).ceil part could be, in another example, the non integer result of a function f:
grouped f.ceil
It still needs type conversion, or in all situations there is a trick or design pattern to avoid it?
val l = List(1,2,3,4,5) grouped((n + 1) / 2)
You could check out the numeric library Spire, I believe it has what you are looking for, namely, the ability to treat numbers as numbers whether they are int/double/float/etc.
There is a way to do it. You can define an implicit conversion like this:
implicit def double2Int(d: Double): Int = d.toInt
Once that's in scope, it will convert any Double automatically to Int. However, doing so is not recommended, as you lose type safety.