In Ruby, why are the following lines true?
0 && 1 == 1
1 && 0 == 0
Why are they different and aren't both 0?
Boolean AND operator && returns its second operand if first is not false. 0 and 1 are true in boolean expressions in Ruby. Only nil and false are false in boolean expressions.
nil && 15 # => nil
15 && 17 # => 17
15 && nil # => nil
0 and 1 don't represent truth values in Ruby. In ruby anything that is not nil or false is true. If you add to this that:
The and and && operators evaluate their first operand. If false, the expression returns false; otherwise, the expression returns the value of the second operand.
You get that you evaluate true && true and then the result of the second operand is returned. If you wrote 3 && 4, you would have gotten 4!
In addition to excellent answers here:
You probably confuse logical and bitwise ANDs.
$ irb
1.9.3-p125 :001 > 1 & 0
=> 0
1.9.3-p125 :002 > 0 & 1
=> 0
Related
My question was triggered by this discussion on SO, which did not lead to an answer that would really explain the issue. I am "rewriting" it here in a slightly different way, because I want to make it more clear what the real problem is and therefore hope to get an answer here.
Consider the following two Ruby expressions:
1 * a - 3
1 && a = 3
From the Ruby precedence table, we know that of the operators mentioned here, * has the highest precedence, followed by -, then by && and finally by =.
The expressions don't have parenthesis, but - as we can verify in irb, providing a suitable value for a in the first case - they are evaluated as if the bracketing were written as (1*a) - 3, respectively 1 && (a=3).
The first one is easy to understand, since * binds stronger than -.
The second one can't be explained in this way. && binds stronger than =, so if precedence only would matter, the interpretation should be (1 && a) = 3.
Associativity (= is right-associative and - is left-associative) can't explain the effect either, because associativity is only important if we have several operators of the same kind (such as x-y-z or x=y=z).
There must be some special rule in the assignment operator, which I did not find in the docs I checked in particular the docs for assignment and syntax.
Could someone point out, where this special behaviour of the assignment operator is documented? Or did I miss / misunderstand something here?
From the doc: https://ruby-doc.org/docs/ruby-doc-bundle/Manual/man-1.4/syntax.html#assign
Assignment expression are used to assign objects to the variables or such. Assignments sometimes work as declarations for local variables or class constants. The left hand side of the assignment expressions can be either:
variables
variables `=' expression
On the right there is an expression, so the result of the expression is assigned to the variable.
So, you should look for expressions (*) before following the precedence.
1 && a = 3 are basically two "chained" expressions:
3 and 1 && 3
Maybe it is more readable as:
1 && a = 3 + 4 where the expressions are 3 + 4 and 1 && 7, see:
1 && a = 3 + 4 #=> 7
1 && 7 #=> 7
res = 1 && a = 3 + 4
res #=> 7
(*) The precedence table also helps to find the expression (Find the precedence table in the linked doc at the Operator expressions paragraph):
What's above the = in the table "forms" an expression to be assigned by =, what's below does not.
For example:
1 + 3 and 2 + 4 #=> 4
a = 1 + 3 and b = 2 + 4 #=> 4
(a = 1 + 3) and (b = 2 + 4) #=> 4
a = (1 + 3 and b = 2 + 4) #=> 6
You can also check these examples respect to the precedence table:
1 && 3 #=> 3
1 && a = 3 #=> 3
a #=> 3
3 and 1 #=> 3
3 and b = 1 #=> 3
b #=> 1
2 ** c = 2 + 1 #=> 8
c #=> 3
d = 2 ** 3
d #=> 8
e = 3
e **= 2
e #=> 9
I think the understanding of 1 && (a = 3) is, understandably, mislead.
a = false
b = 1
b && a = 3
b
=> 1
a
=> 3
Why is a being assigned to in the && expression when a is false? Should the && expression not return when encountering a false value? Spoiler, it does return!
Taking a step back, we think of the purpose of the && operator to control the flow of logic. Our disposition to the statement
1 && a = 3
is to assume the entire statement is returned if a is nil or false. Well no, the interpreter is evaluating like so:
(1 && a) = 3
The interpreter does not raise a if it is nil or false nor does it return the left side if a is nil or false
a = nil
1 && a
=> nil # a was returned
The interpreter returns the variable, this is why the original statement can be read:
a = 3
due to 1 && a returning a which is a variable that can be assigned to by the = operand on the second half of the statement.
TLDR
In your origin example: 1 is neither nil nor false so the variable a is returned in (1 && a) which is subsequently assigned in a = 3
Probably because the other interpretation does not work:
irb(main):003:0> (1 && a) = 3
Traceback (most recent call last):
3: from /home/w/.rbenv/versions/2.7/bin/irb:23:in `<main>'
2: from /home/w/.rbenv/versions/2.7/bin/irb:23:in `load'
1: from /home/w/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/irb-1.2.3/exe/irb:11:in `<top (required)>'
SyntaxError ((irb):3: syntax error, unexpected '=', expecting `end')
(1 && a) = 3
^
So, perhaps Ruby parenthesizes 1 && a = 3 in the only way that is legally interpretable by the language.
I want someone to enter number "1", "2", or "3", and if the number is correct, want to say "ok". If not, I want to say "enter 1 or 2 or 3".
This is my code:
puts "enter 1 or 2 or 3"
num = gets.to_i
if num == 1 or 2 or 3
puts "ok"
else
puts "enter 1 or 2 or 3"
end
When I enter an incorrect answer such as "e" or "p", it still says "ok".
Why is it the case?
Let's first examine why you are obtaining incorrect results.
If a equals false or nil (is falsy, meaning logically false), a or b returns the value of b. If a equals any other value (is truthy, meaning logically true), a or b returns a.
Suppose we have an expression a op1 b op2 c, where op1 and op2 are operators (e.g., a == b or c). This could be evaluated (a op1 b) op2 c or a op1 (b op2 c), where parentheses have the highest precedence.
The precedence of Ruby's operators (most implemented as methods) is given here. Note that == has higher precedence than or. Moreover, for any given operator op, a op b op c is evaluated (a op b) op c.
The expression num == 1 or 2 or 3 is therefore evaluated
((num == 1) or 2) or 3
Now consider the value of this expression, depending on the value of num.
num = 1
((num == 1) or 2) or 3 => (true or 2) or 3 => true or 3 => true
num != 1
((num == 1) or 2) or 3 => (false or 2) or 3 => 2 or 3 => 2
Here are some ways to obtain your desired result.
(num == 1) or (num == 2) or (num == 3)
(num == 1) || (num == 2) || (num == 3)
[1, 2, 3].include?(num)
[1, 2, 3] & [num] == [num]
([num] - [1, 2, 3]).empty?
Because of the precedence rules for operators, the parentheses are not needed in the first two expressions, but it can be argued they clarify the code, at least for some readers. (I would include them.)
Regarding the choice between using or or ||, see this SO queston, particularly the second answer. In practice, or is rarely used.
See Array#include?, Array#& and Array#-.
To round out the possibilities, one could conceivably use a case statement.
case num
when 1, 2, 3 then true
else false
end
If, as here, the acceptable values of num form a range, one could write either of the following.
num.between?(1, 3)
(1..3).cover?(num)
(num >= 1) && (num <= 3)
See Comparable#between and Range#cover?. Again, the parentheses in the latter are optional.
In your code, num == 1 or 2 or 3 evaluates to true always, as 2 is considered logically true, and using an or`` operator with logically true value returns atrue` result always.
The correct way to compare is like this
puts "enter 1 or 2 or 3"
num = gets.to_i
if num == 1 or num == 2 or num == 3
puts "ok"
else
puts "enter 1 or 2 or 3"
end
Here, you are comparing the value of variable with right literal.
How can this be achieved in Ruby? Can it be done without repeating the variable?
Javascript:
b = a || 7
This assigns a if a is not 0 and 7 otherwise
One specific case is converting date.wday to 7 if it returns 0 (Sunday).
Just out of curiosity:
class Object
def javascript_or?(other)
(is_a?(FalseClass) || nil? || '' == self || 0 == self) ? nil : self
end
end
and:
a = b.javascript_or?(7)
There are only two falsy values in Ruby: nil and false. So, if you really want this approach
a = b == 0 ? 7 : b
is a plausible solution, because 0 can't be evaluated as false.
However, a better option for your need is cwday, and not wday. Then you don't need to make this comparison anymore, because it returns 1 for Monday, 2 for Tuesday, and finally 7 for Sunday, as you need.
date = Date.new(2016,19,6) # => Jun 19 2016, Sunday
date.cwday # => 7
For the particular case of 0 and 7:
a = (b + 6) % 7 + 1
:)
You can use ternary operator:
date.wday == 0 ? 7 : date.wday
What you're describing here is less of a logical problem and more of a mapping one:
WEEKDAY_MAP = Hash.new { |h,k| h[k] = k < 7 ? k : nil }.merge(0 => 7)
This one re-writes 1..6 to be the same, but 0 becomes 7. All other values are nil.
Then you can use this to re-write your day indicies:
b = WEEKDAY_MAP[a]
If at some point you want to tinker with the logic some more, that's also possible.
does anyone know the meaning of && and || when applied to integers in Ruby?
Here are some examples in IRB when && and || are applied to integers:
>> 1 && 2
=> 2
>> 2 && 1
=> 1
>> 15 && 20
=> 20
>> 20 && 15
=> 15
>> 0 && -1
=> -1
>> -1 && -2
=> -2
>> 1 || 2
=> 1
>> 2 || 1
=> 2
The boolean operators &&, ||, and and or are among the few that are not syntactic sugar for method calls, and thus, there are no different implementations in different classes.
In other words: they behave exactly the same for all objects, i.e. they behave the same for Integers as they do for Strings, Hashes, Floats, Symbols, and any other object.
a && b
evaluates to a if a is falsey (and will not evaluate b at all in this case), otherwise it evaluates to b (and only then will b be evaluated)
a || b
evaluates to a if a is truthy (and will not evaluate b at all in this case), otherwise it evaluates to b (and only then will b be evaluated)
nil and false are falsey, everything else is truthy, including 0, 0.0, '', [], and {}.
When playing with IRB I came across this:
a = -1
b = 1
(a and b) > 0
returns true, however
(false and true) == true
returns false.
Why does the first statement return true? In the 'pickaxe' I read "Both and and && evaluate to true only if both operands are true. They evaluate the second operand only if the first is true[...]"
This implies -- to me -- that the first statement should return false
Why should it be false? Both operands a and b are not false, and even not nil..
IIRC, in Ruby, every value different than false/nil is considered true. Even zero. Hence 0 and 0 is true. -1 and 1 surely too!
EDIT: aah, I just grasped what you meant. You mean that the first expression -1 and 1 should return -1? No, that's what OR does!
-1 and 1 => 1
-1 or 1 => -1
AND evaluates ALL operand for 'true' result, and reduces checks only if one item is 'false'.
OR evaluates ALL operand for 'false' result, and reduces checks only if one item is 'true'
Both -1 and 1 are "truthy" values from ruby's point of view. That's why
-1 and 1 # => 1
false and true => false
that the first statement should return false
I don't see where you got this from. Aren't you confusing it with OR operator?
a = -1
b = 1
a and b # => 1
(a and b) > 0 # => true
a && b # => 1
(a && b) > 0 # => true
a || b # => -1
(a || b) > 0 # => false
in ruby, the only time an object is false is if it is false or nil.
>> !!nil # false
>> !!false # false
>> !!-1 # true
in your syntax, it is impossible to get what you want to say when you try
>> (1 and -1) > 0
since and should be used to return true or false but what I found interesting is the value returned
>> (1 and -1) # -1
>> (-1 and 1) # 1
so having (b and a) > 0 would return false which is interesting
(1 and -1) will return -1 since the and operator needs to satisfy all conditions. there's something wrong with me today.