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
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.
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.
In Erlang, using => to compare two variables results in a syntax error, you have to use >= instead:
1> 10 => 5.
* 1: syntax error before: '>'
2> 10 >= 5.
true
Why is that? The same applies for <= which has to be written as =<. Is this because Erlang always used this syntax, or are the sequences => and >= used somewhere else?
Just to confirm what others have said: we used the same comparison operators as Prolog. I can't be certain why it does it this way but one reason could be that it leaves <= and => to be used as "arrows", which could be useful. In Prolog it is very easy to define new operators so even if they are not defined in the basic language they are still very useful:
:- op(Priority, Type, Operator).
The <= operator in in Erlang is a binary generator which can be used in list/binary comprehensions. It works in a similar way to <- but on binaries instead of lists.
Well, Erlang's syntax is influenced by Prolog's and Prolog uses the same convention so that's probably the reason.
I am not sure why Prolog uses >= and =<; => and <= are not really used. I assume that it's because => and <= are operators typically used for the logical implication so it is indeed awkward to use them for comparison, especially in a logic programming language. It is also prettier imho :b
This is probably just an Erlang convention. The reason I'd guess would be to do with how we pronounce these symbols: "greater than or equal to", "less than or equal to". It's really a rendering of the greater-than-or-equal-to/less-than-or-equal-to symbol in ASCII, so at some point someone decided the token should be <= and >=, and the convention has stuck in most languages, but it's fairly arbitrary. Perhaps they were attempting to create some kind of representation of the asymmetric nature of these operators.
It's also worth noting that lots of languages use => to mean some kind of arrow, such as separating the body of a function from its arguments, or as logical entailment. Not sure about the converse one.
EDIT: It appears that Erlang uses <= in comprehensions, which is why they've avoided using it as a comparison operator, and opted for the (slightly backwards) syntax instead.
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).