evaluating expressions left to right

[John Merlino]

class Proc
def apply(enum)
enum.map &self
end
alias | apply

def reduce(enum)
enum.inject &self
end
alias <= reduce

def compose(f)
if self.respond_to?(:arity) && self.arity == 1
lambda {|*args| self[f[*args]] }
else
lambda {|*args| self[*f[*args]] }
end
end
alias * compose

end

sum = lambda {|x,y| x+y } # A function to add two numbers
mean = (sum<=a)/a.size # Or sum.reduce(a) or a.inject(&sum)
deviation = lambda {|x| x-mean } # Function to compute difference from
mean
square = lambda {|x| x*x } # Function to square a number
standardDeviation = Math.sqrt((sum<=square*deviation|a)/(a.size-1))

Ok so now I have another example from this book which does not contain
parentheses around deviation|a. So then why is this part:

(sum<=square*deviation|a)

not evaluated from left to right.

Apparently, it evaluates this part:

deviation|a

first

and this part second:

square*deviation|a

and then finally:

sum<=

So it looks like it is evaluating from right to left. Even though it
should be evaluating from left to right...

[7stud --]

In this method call:

meth1(meth2(meth3))

...which value has has to be computed first so that meth1 can return?

--
Posted via http://www.ruby-forum.com/.

[Jordon Bedwell]

meth3 -> (meth2) -> (meth1)

The logic is that meth3 has to return so that meth2 can accept,
process and return so that meth1 can accept, process and return.
Don't read nested methods like you read a book, with nested methods
the last to be nested is the first to be executed.

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-ta...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Colin Law]

If you think about it there is only one possible answer to that
question. How could it evaluate meth2(meth3) without evaluating meth3
first, in order to pass the result to meth2? Similarly how could it
call meth1 before it evaluated the parameter to pass to it?

Colin

[John Merlino]

ok, it didn't look like nested methods. But I made to believe that
this:

sum<=square*deviation|a

is exactly the same as this:

sum<=(square*(deviation|(a)))

So if this is true, then still a question remains.

Here's the original context again:


module Functional

def compose(f)
if self.respond_to?(:arity) && self.arity == 1
lambda { |*args| self[f[*args]] }
else
lambda {|*args| self[*f[*args]] }
end
end
alias * compose


def apply(enum)
enum.map &self
end
alias | apply

def reduce(enum)
enum.inject &self
end
alias <= reduce

end

class Proc
include Functional
end

#client code
a = [1,2,3]

sum = lambda { |x,y| x+y }

mean = (sum<=a)/a.size

deviation = lambda { |x| x-mean }

square = lambda { |x| x*x }

standardDeviation = Math.sqrt((sum<=square*deviation|a)/(a.size-1))

On the last line, this executes first:

deviation|a

this returns a new array of how far each of elements are from the
mean.

Then this array gets passed to * which is invoked on square (a lambda
object):

square*returned_array

That calls compose where f parameter is the returned array from above.
So then this line is returned by compose since the array object doesnt
respond to arity:

lambda {|*args| self[*f[*args]] }

So it appears the return value of compose is the lambda object. That
presents a problem because <= expects an enum argument.

sum<=this_should_be_an_enum

[Matt Jones]

On Tuesday, 25 December 2012 20:13:16 UTC-5, John Merlino wrote:

ok, it didn't look like nested methods. But I made to believe that
this:

sum<=square*deviation|a

is exactly the same as this:

sum<=(square*(deviation|(a)))

So if this is true, then still a question remains.

 That's not how it parses, thanks to operator precedence - the same reason that 2+5*10+3 parses as 2.+((5.*(10)).+(3)) and not 2.+(5.*(10.+(3))).

 You can use a tool like Ripper (http://www.rubyinside.com/using-ripper-to-see-how-ruby-is-parsing-your-code-5270.html) to see exactly how something is being parsed. Trying your expression yields:

[:program,

 [[:binary,

   [:vcall, [:@ident, "sum", [1, 0]]],

   :<=,

   [:binary,

    [:binary,

     [:vcall, [:@ident, "square", [1, 5]]],

     :*,

     [:vcall, [:@ident, "deviation", [1, 12]]]],

    :|,

    [:vcall, [:@ident, "a", [1, 22]]]]]]]

Or, distilled back to a fully-parenthized code version:

sum <= ((square*deviation) | a)

With the method calls written out explicitly:

sum.<=((square.*(deviation)).|(a))

Essentially, this creates a function that calculates the squared deviation from the mean (square*deviation), applies it to the list a, and then sums the resulting values.

This sort of confusion is why most people recommend avoiding operator overloading in most cases - there are a bunch of precedence rules built into the language, and you're essentially stuck with them.

--Matt Jones

[John Merlino]

That was my hunch. Thanks for clarifying.