Re: [scala-functional] Re: lazy val memoization

[Steven Parkes]

And, FWIW, one thing we just noticed is that the lazy implementation for
this case takes the lock on the object that contains this val even though
the scope of this particular value is note the object scope, at least in
2.11.something.

In our case, we had a lot of lock contention that we weren't
expecting/aware of.

Our conclusion was that lazy locals are of _very_ limited and mostly to be
avoided.

On Tue, Apr 10, 2018 at 8:41 AM, Adam Mackler  wrote:

> The value cached is defined inside the definition of the method func(),
> so everytime you invoke func() it defines a new local Int named cached.
> Change your code to this:
>
> def func(i: => Int): Unit = {
>   lazy val cached = {
> println("Calculating")
> i * i
>   }
>   println(cached)
>   println(cached)
>   println(cached)
> }
>
>
> and you will see that it prints "Calculating" only once each time you
> invoke func(), even though func() is now accessing cached three times.
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-functional" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-functional+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[scala-functional] Re: lazy val memoization

[Adam Mackler]

The value cached is defined inside the definition of the method func(), so 
everytime you invoke func() it defines a new local Int named cached.  
Change your code to this:

def func(i: => Int): Unit = {
  lazy val cached = {
println("Calculating")
i * i
  }
  println(cached)
  println(cached)
  println(cached)
}


and you will see that it prints "Calculating" only once each time you 
invoke func(), even though func() is now accessing cached three times.

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[scala-functional] Re: lazy val memoization

[des . magner]

Ah OK. So I am guessing I misunderstood section 5.2.1. The "cons" function 
is only ever called once in this scenario?

On Tuesday, 10 April 2018 17:19:24 UTC+2, des.m...@gmail.com wrote:
>
> Hi
>
> Based on my understanding of the explanation of lazy val memoization in 
> section 5.2.1, I would have thought that if I define the following function:
>
> def func(i: => Int): Unit = {
> lazy val cached = {
> println("Calculating")
> i * i
> }
> cached
> }
>
> And then made the following calls:
>
> func(3)
> func(3)
>
> that my lazy evaluation should only happen once? - as the function is 
> getting called with the same parameter the second time. But this is not the 
> case when I test. Could someone explain what I am missing here?
>
> Thanks
> Des
>

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [scala-functional] lazy val memoization

[Brian Maso]

The lazy val is declared as a member of the function, so each time the
function is called there is a new lazy val being memoized.

Brian Maso

On Tue, Apr 10, 2018 at 8:19 AM,  wrote:

> Hi
>
> Based on my understanding of the explanation of lazy val memoization in
> section 5.2.1, I would have thought that if I define the following function:
>
> def func(i: => Int): Unit = {
> lazy val cached = {
> println("Calculating")
> i * i
> }
> cached
> }
>
> And then made the following calls:
>
> func(3)
> func(3)
>
> that my lazy evaluation should only happen once? - as the function is
> getting called with the same parameter the second time. But this is not the
> case when I test. Could someone explain what I am missing here?
>
> Thanks
> Des
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-functional" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-functional+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
br...@blumenfeld-maso.com

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[scala-functional] lazy val memoization

[des . magner]

Hi

Based on my understanding of the explanation of lazy val memoization in 
section 5.2.1, I would have thought that if I define the following function:

def func(i: => Int): Unit = {
lazy val cached = {
println("Calculating")
i * i
}
cached
}

And then made the following calls:

func(3)
func(3)

that my lazy evaluation should only happen once? - as the function is 
getting called with the same parameter the second time. But this is not the 
case when I test. Could someone explain what I am missing here?

Thanks
Des

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [scala-functional] EXERCISE 6.2: generating a random Double from a random Int

[Ben Hutchison]

On Tue, Apr 10, 2018 at 8:24 AM, Adam Mackler  wrote:
>
> Maybe I'm missing something, but it seems to me that since a Double is
> represented using 64 bits and an Int 32, that using the amount of
> randomness in an Int to generate a random Double will mean that the results
> will be unevenly distributed, perhaps with possible values of the Double
> never returned.
>


I agree with your analysis. Generating Doubles from a single Int is no a
good real world strategy.  I guess it was just posed as an exercise.

-Ben

> --
> You received this message because you are subscribed to the Google Groups
> "scala-functional" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-functional+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[scala-functional] EXERCISE 6.2: generating a random Double from a random Int

[Adam Mackler]

Exercise 6.2 on page 83:

*Write a function to generate a Double between 0 and 1 , not including 1.*


The given hint and answer indicate generating a non-negative Int and then 
dividing it by the one more than the maximum possible Int value.

Maybe I'm missing something, but it seems to me that since a Double is 
represented using 64 bits and an Int 32, that using the amount of 
randomness in an Int to generate a random Double will mean that the results 
will be unevenly distributed, perhaps with possible values of the Double 
never returned.  Here's what I came up with:

  def double(rng: RNG): (Double, RNG) = {
val (int1, rng2) = rng.nextInt
val (int2, rng3) = rng2.nextInt
val long = (int1.toLong << 32) | int2// this is a random 
Long
val nnLong = if (long < 0) -(long + 1) else long // non-negative random 
Long
val rLong = -(nnLong.toDouble / Long.MinValue)   // random double
(rLong, rng3)
  }


I generate two random integers, convert one to a Long and bit-shift it 32 
bits to the left and then OR it with the other Int.  This should give me a 
random Long.  Then I make it non-negative, divide it by the minimum Long 
value, and negate that.  Intuitively this seems to me that it would give a 
more even distribution since there are extra bits of randomness from the 
second Int.  Is my thinking correct?  Is this worse or better than the 
answer given in the book?

-- 
You received this message because you are subscribed to the Google Groups 
"scala-functional" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to scala-functional+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.