This leads to the situation like:
-1 ** 0.5 #=> -1
Only parenthesis remedies it:
(-1) ** 0.5 #=> 6.123031769111886e-17+1.0i
which is less favorable then expected 1.i, but basically acceptable. Before I go to Ruby bugs to complain, I would like to know whether there is perhaps some reason for this to be so?
Many languages define their operator precedence tables by modeling after mathematics' order of operations. In math, exponentiation does have higher precedence than multiplication, and unary negation is a multiplication, after all.
From matz in a reply to "the sign of a number is omitted when squaring it":
People with mathematical background demands precedence for ** being
higher than that of unary minus. That's the reason.
Yes, ** has a higher precedence in Ruby.
Unlike some languages, - is not lex'ed as part of the number literal and is thus just (and universally) the unary - (aka -#). That is, both -x and -1 parse the unary -# as an operator applied to the result of the expression.
Related
Apart from making a nice symmetry with unary minus, why is unary plus operator defined on Numeric class? Is there some practical value in it, except for causing confusion allowing writing things like ++i (which, unlike most non-Rubyists would think, doesn't increment i).
I can think of scenario where defining unary plus on a custom class could be useful (say if you're creating some sexy DSL), so being able to define it is ok, but why is it already defined on Ruby numbers?
Perhaps it's just a matter of consistency, both with other programming languages, and to mirror the unary minus.
Found support for this in The Ruby Programming Language (written by Yukihiro Matsumoto, who designed Ruby):
The unary plus is allowed, but it has no effect on numeric operands—it simply returns the value of its operand. It is provided for symmetry with unary minus, and can, of course, be redefined.
As mentioned in the docs, if a string is frozen the unary plus operator will return a mutable string.
One possible reason I see is to explicitly state that a number is positive(even though it by default is positive).
ruby-1.9.2-p136 :051 > +3
=> 3
ruby-1.9.2-p136 :052 > 3
=> 3
I was goofing around in a pry REPL and found some very interesting behavior: the tilde method.
It appears Ruby syntax has a built-in literal unary operator, ~, just sitting around.
This means ~Object.new sends the message ~ to an instance of Object:
class Object
def ~
puts 'what are you doing, ruby?'
end
end
~Object.new #=> what are you doing, ruby?
This seems really cool, but mysterious. Is Matz essentially trying to give us our own customizable unary operator?
The only reference I can find to this in the rubydocs is in the operator precedence notes, where it's ranked as the number one highest precedence operator, alongside ! and unary + This makes sense for unary operators. (For interesting errata about the next two levels of precedence, ** then unary -, check out this question.) Aside from that, no mention of this utility.
The two notable references to this operator I can find by searching, amidst the ~=,!~, and~>` questions, are this and this. They both note its usefulness, oddity, and obscurity without going into its history.
After I was about to write off ~ as a cool way to provide custom unary operator behavior for your objects, I found a place where its actually used in ruby--fixnum (integers).
~2 returns -3. ~-1 returns 1. So it negates an integer and subtracts one... for some reason?
Can anyone enlighten me as purpose of the tilde operator's unique and unexpected behavior in ruby at large?
Using pry to inspect the method:
show-method 1.~
From: numeric.c (C Method):
Owner: Fixnum
Visibility: public
Number of lines: 5
static VALUE
fix_rev(VALUE num)
{
return ~num | FIXNUM_FLAG;
}
While this is impenetrable to me, it prompted me to look for a C unary ~ operator. One exists: it's the bitwise NOT operator, which flips the bits of a binary integer (~1010 => 0101). For some reason this translates to one less than the negation of a decimal integer in Ruby.
More importantly, since ruby is an object oriented language, the proper way to encode the behavior of ~0b1010 is to define a method (let's call it ~) that performs bitwise negation on a binary integer object. To realize this, the ruby parser (this is all conjecture here) has to interpret ~obj for any object as obj.~, so you get a unary operator for all objects.
This is just a hunch, anyone with a more authoritative or elucidating answer, please enlighten me!
--EDIT--
As #7stud points out, the Regexp class makes use of it as well, essentially matching the regex against $_, the last string received by gets in the current scope.
As #Daiku points out, the bitwise negation of Fixnums is also documented.
I think my parser explanation solves the bigger question of why ruby allows ~ as global unary operator that calls Object#~.
For fixnum, it's the one's complement, which in binary, flips all the ones and zeros to the opposite value. Here's the doc: http://www.ruby-doc.org/core-2.0/Fixnum.html#method-i-7E. To understand why it gives the values it does in your examples, you need to understand how negative numbers are represented in binary. Why ruby provides this, I don't know. Two's complement is generally the one used in modern computers. It has the advantage that the same rules for basic mathematical operations work for both positive and negative numbers.
The ~ is the binary one's complement operator in Ruby. One's complement is just flipping the bits of a number, to the effect that the number is now arithmetically negative.
For example, 2 in 32-bit (the size of a Fixnum) binary is 0000 0000 0000 0010, thus ~2 would be equal to 1111 1111 1111 1101 in one's complement.
However, as you have noticed and this article discusses in further detail, Ruby's version of one's complement seems to be implemented differently, in that it not only makes the integer negative but also subtracts 1 from it. I have no idea why this is, but it does seem to be the case.
It's mentioned in several places in pickaxe 1.8, e.g. the String class. However, in ruby 1.8.7 it doesn't work on the String class as advertised. It does work for the Regexp class:
print "Enter something: "
input = gets
pattern = 'hello'
puts ~ /#{pattern}/
--output:--
Enter something: 01hello
2
It is supposed to work similarly for the String class.
~ (Bignum)
~ (Complex)
~ (Fixnum)
~ (Regexp)
~ (IPAddr)
~ (Integer)
Each of these are documented in the documentation.
This list is from the documentation for Ruby 2.6
The behavior of this method "at large" is basically anything you want it to be, as you described yourself with your definition of a method called ~ on Object class. The behaviors on the core classes that have it defined by the implementations maintainers, seems to be pretty well documented, so that it should not have unexpected behavior for those objects.
I know how each of them can be converted to one another but never really understood what their applications are. The usual infix operation is quite readable, but where does it fail which led to inception of prefix and postfix notation
Infix notation is easy to read for humans, whereas pre-/postfix notation is easier to parse for a machine. The big advantage in pre-/postfix notation is that there never arise any questions like operator precedence.
For example, consider the infix expression 1 # 2 $ 3. Now, we don't know what those operators mean, so there are two possible corresponding postfix expressions: 1 2 # 3 $ and 1 2 3 $ #. Without knowing the rules governing the use of these operators, the infix expression is essentially worthless.
Or, to put it in more general terms: it is possible to restore the original (parse) tree from a pre-/postfix expression without any additional knowledge, but the same isn't true for infix expressions.
Postfix notation, also known as RPN, is very easy to process left-to-right. An operand is pushed onto a stack; an operator pops its operand(s) from the stack and pushes the result. Little or no parsing is necessary. It's used by Forth and by some calculators (HP calculators are noted for using RPN).
Prefix notation is nearly as easy to process; it's used in Lisp.
At least for the case of the prefix notation: The advantage of using a prefix operator is that syntactically, it reads as if the operator is a function call
Another aspect of prefix/postfix vs. infix is that the arity of the operator (how many arguments it is applied to) no longer has to be limited to exactly 2. It can be more, or sometimes less (0 or 1 when defaults are implied naturally, like zero for addition/subtraction, one for multiplication/division).
Apart from making a nice symmetry with unary minus, why is unary plus operator defined on Numeric class? Is there some practical value in it, except for causing confusion allowing writing things like ++i (which, unlike most non-Rubyists would think, doesn't increment i).
I can think of scenario where defining unary plus on a custom class could be useful (say if you're creating some sexy DSL), so being able to define it is ok, but why is it already defined on Ruby numbers?
Perhaps it's just a matter of consistency, both with other programming languages, and to mirror the unary minus.
Found support for this in The Ruby Programming Language (written by Yukihiro Matsumoto, who designed Ruby):
The unary plus is allowed, but it has no effect on numeric operands—it simply returns the value of its operand. It is provided for symmetry with unary minus, and can, of course, be redefined.
As mentioned in the docs, if a string is frozen the unary plus operator will return a mutable string.
One possible reason I see is to explicitly state that a number is positive(even though it by default is positive).
ruby-1.9.2-p136 :051 > +3
=> 3
ruby-1.9.2-p136 :052 > 3
=> 3
What is the operator precedence order in Visual Basic 6.0 (VB6)?
In particular, for the logical operators.
Arithmetic Operation Precedence Order
^
- (unary negation)
*, /
\
Mod
+, - (binary addition/subtraction)
&
Comparison Operation Precedence Order
=
<>
<
>
<=
>=
Like, Is
Logical Operation Precedence Order
Not
And
Or
Xor
Eqv
Imp
Source: Sams Teach Yourself Visual Basic 6 in 24 Hours — Appendix A: Operator Precedence
It depends on whether or not you're in the debugger. Really. Well, sort of.
Parentheses come first, of course. Then arithmateic (+,-,*,/, etc). Then comparisons (>, <, =, etc). Then the logical operators. The trick is the order of execution within a given precedence level is not defined. Given the following expression:
If A < B And B < C Then
you are guaranteed the < inequality operators will both be evaluated before the logical And comparison. But you are not guaranteed which inequality comparison will be executed first.
IIRC, the debugger executes left to right, but the compiled application executes right to left. I could have them backwards (it's been a long time), but the important thing is they're different. The actual precedence doesn't change, but the order of execution might.
Use parentheses
EDIT: That's my advice for new code! But Oscar is reading someone else's code, so must figure it out somehow. I suggest the VBA manual topic Operator Precedence. VBA is 99% equivalent to VB6 - and expression evaluation is 100% equivalent. I have pasted the logical operator information here.
Logical operators are evaluated in the following order of precedence:
Not
And
Or
Xor
Eqv
Imp
The topic also explains precedence for comparison and arithmetic operators.
I would suggest once you have figured out the precendence, you put in parentheses unless there is some good reason not to edit the code.