I'm curious how the greater than (>) and less than (<) operators work with types that are not int, float, or double in OCaml.
For instance, I was able to discover that string "a" > "b" but is there some reference that lists the conventions for all non-numerical data types. Furthermore, how do these operators work across types? e.g. Is "a" > true or is "a" < true?
Finally, how would these work across a user-defined data type?
Thanks!
The OCaml <, >, <=, >= operators only work with two values of the same type, so the expression "a" > true is invalid. However, they work for all types (with caveats below). You can find the definitions of these operators in the Stdlib module (formerly known as Pervasives).
The order for these operators is defined only for simple values (integers, characters, strings, byte sequences, and floating). In these cases the documentation says they give "the usual ordering".
The usual ordering for strings and byte sequences is lexicographic order. For strings, case is significant.
For compound values the order is only guaranteed to be consistent with = and to be a consistent ordering.
As far as I can see, order is not defined for simple user-defined types like type abc = A | B | C. I didn't expect this to be the case, but that's what I see in the documentation. In practice, the values of constant constructors like A, B, C, will be ordered in the order of declaration with the first value the smallest.
I also don't see a definition of the order between false and true. Again, this is surprising. In practice, false is less than true.
It is worth noting that comparisons between cyclic values is not guaranteed to terminate. Also, comparison between values that contain functions may raise an exception. These can cause unexpected problems, sometimes serious ones.
$ ocaml
OCaml version 4.02.1
# (+) < (+);;
Exception: Invalid_argument "equal: functional value".
# let rec cycle = 1 :: cycle;;
val cycle : int list = [1; <cycle>]
# cycle < cycle;;
(( Does not terminate ))
Related
I'm fairly new to Visual Basic (my background is mostly C#) so I only recently found out that ++i is not the same thing as i+=1 in VB.NET. However, my VB.NET code still compiles when I pass ++i as a parameter, even though it doesn't increment the variable:
++i 'doesn't compile
i++ 'doesn't compile
Foobar(i++) 'doesn't compile
Foobar(++i) 'compiles, but doesn't increment i
The fact that the last statement above doesn't cause an error leads me to wonder if ++ actually does mean something in VB.NET, just not what I thought it meant at first. If it doesn't, is there some other reason it isn't causing an error?
It is just the unary version of the + operator (see docs) applied twice.
Foobar(++i)
Foobar(+(+i))
Foobar(+(+(i)))
' These are all the same
For numerical values, the unary + (i.e. the + operator without second operand) does nothing:
If expression2 is absent, the + operator is the unary identity operator for the unchanged value of an expression.
However, it is not entirely clear from the docs what it will do to non-numeric values. The docs explain various cases with two operands, which all don't seem to apply here.
There is even one sentence that sounds like it could be applied, but it does not do what it says if used with unary +:
If either Object expression evaluates to Nothing or DBNull, the + operator treats it as a String with a value of "".
So you would expect that +Nothing gives "" as well, but it gives 0 instead. In fact, it appears that the unary + converts non-numerical types to Double, including strings for which + would otherwise mean concatenation (for example +"1.234" gives 1.234, and +"Hello" gives an error that this string cannot be converted to Double - and with Option Strict On, you can't convert any string implicitly anyway). It seems to behave more like a binary + with 0.0 as first operand.
You can also overload the unary + separately from the binary + and give it a different meaning entirely*. (Or do the opposite - make it do nothing even on a non-numeric type, such as what TimeSpan does - it returns the original timespan again when unary + is applied on it, and not a Double.)
*: Which probably is not such a good idea though. When overloading an operator, the meaning of it should always be intuitive.
There is no ++ operator in VB. The + unary operator is just like the - unary operator applied to a number. Numbers are positive by default but, just as you can explicitly make a number negative by prefixing it with a - operator, you can make it explicitly positive by prefixing it with a + operator. You can use as many + operators as you like. Similarly, you can use as many - operators as you like. The difference is that + operators don't change the value where - operators do.
In C-based languages, assignments actually return a value where they don't in VB. In C#, you can do this:
i += 1
and it will get the value of i, add 1 to it, assign the result back to i and then return that result, so you can use that expression where a value is expected. In VB, it does all the same things up to the assignment but it does not return a value, so you cannot use that expression where a value is expected.
In C-based languages, where you place the ++ operator makes a difference. The expression:
++i
increments i and returns the final value, whereas this expression:
i++
increments i and returns the original value. That's why some argue that the C++ language should actually be named ++C.
In Selenium I have written a xpath and both of them retrieves the same result.
//a[#role='tab'][text()=' Assets']
//a[#role='tab' and text()=' Assets']
Does both of them have the same meaning?
In most cases a[b][c] has exactly the same effect as a[b and c]. There are two exceptions to be aware of:
They are not equivalent if either predicate is numeric, or has a dependency on position() or last() (I call these positional predicates). For example a[#x][1] selects the first a element that has an #x attribute, while a[1][#x] selects the first a element provided it has an #x attribute (and selects nothing otherwise). By contrast a[1 and #x] converts the integer 1 to the boolean true(), so it just means a[#x].
There may be differences in behaviour if evaluation of b or c fails with a dynamic error. The precise rules here depend on which version of XPath you are using, and to be honest the rules leave implementations some leeway, but you need to exercise care if you want to be sure that in the event of b being false, c is not evaluated. (This hardly matters in XPath 1.0 because very few expressions throw dynamic errors.)
When you add Square Brackets ([]) to XPath you are adding a condition, so
first row adding 2 conditions
Which produce similar results as adding condition with and
Normally you don't use first row, because it less readable,
Mainly because this syntax represent in other languages a Matrix
// return a random m-by-n matrix with values between 0 and 1
public static double[][] random(int m, int n) {
See tutorial:
5 XPaths with predicates
A predicate is an expression that can be true or false
It is appended within [...] to a given location path and will refine results
More than one predicate can be appended to and within (!) a location path
The first one is a predicate, which means it checks if a[#role='tab'] is true then it proceeds to [text()=' Assets']
The second one is a just using an and operator so it validates both are true.
I've seen := used in several code samples, but never with an accompanying explanation. It's not exactly possible to google its use without knowing the proper name for it.
What does it do?
http://en.wikipedia.org/wiki/Equals_sign#In_computer_programming
In computer programming languages, the equals sign typically denotes either a boolean operator to test equality of values (e.g. as in Pascal or Eiffel), which is consistent with the symbol's usage in mathematics, or an assignment operator (e.g. as in C-like languages). Languages making the former choice often use a colon-equals (:=) or ≔ to denote their assignment operator. Languages making the latter choice often use a double equals sign (==) to denote their boolean equality operator.
Note: I found this by searching for colon equals operator
It's the assignment operator in Pascal and is often used in proofs and pseudo-code. It's the same thing as = in C-dialect languages.
Historically, computer science papers used = for equality comparisons and ← for assignments. Pascal used := to stand in for the hard-to-type left arrow. C went a different direction and instead decided on the = and == operators.
In the statically typed language Go := is initialization and assignment in one step. It is done to allow for interpreted-like creation of variables in a compiled language.
// Creates and assigns
answer := 42
// Creates and assigns
var answer = 42
Another interpretation from outside the world of programming languages comes from Wolfram Mathworld, et al:
If A and B are equal by definition (i.e., A is defined as B), then this is written symbolically as A=B, A:=B, or sometimes A≜B.
■ http://mathworld.wolfram.com/Defined.html
■ https://math.stackexchange.com/questions/182101/appropriate-notation-equiv-versus
Some language uses := to act as the assignment operator.
In a lot of CS books, it's used as the assignment operator, to differentiate from the equality operator =. In a lot of high level languages, though, assignment is = and equality is ==.
This is old (pascal) syntax for the assignment operator. It would be used like so:
a := 45;
It may be in other languages as well, probably in a similar use.
A number of programming languages, most notably Pascal and Ada, use a colon immediately followed by an equals sign (:=) as the assignment operator, to distinguish it from a single equals which is an equality test (C instead used a single equals as assignment, and a double equals as the equality test).
Reference: Colon (punctuation).
In Python:
Named Expressions (NAME := expr) was introduced in Python 3.8. It allows for the assignment of variables within an expression that is currently being evaluated. The colon equals operator := is sometimes called the walrus operator because, well, it looks like a walrus emoticon.
For example:
if any((comment := line).startswith('#') for line in lines):
print(f"First comment: {comment}")
else:
print("There are no comments")
This would be invalid if you swapped the := for =. Note the additional parentheses surrounding the named expression. Another example:
# Compute partial sums in a list comprehension
total = 0
values = [1, 2, 3, 4, 5]
partial_sums = [total := total + v for v in values]
# [1, 3, 6, 10, 15]
print(f"Total: {total}") # Total: 15
Note that the variable total is not local to the comprehension (so too is comment from the first example). The NAME in a named expression cannot be a local variable within an expression, so, for example, [i := 0 for i, j in stuff] would be invalid, because i is local to the list comprehension.
I've taken examples from the PEP 572 document - it's a good read! I for one am looking forward to using Named Expressions, once my company upgrades from Python 3.6. Hope this was helpful!
Sources: Towards Data Science Article and PEP 572.
It's like an arrow without using a less-than symbol <= so like everybody already said "assignment" operator. Bringing clarity to what is being set to where as opposed to the logical operator of equivalence.
In Mathematics it is like equals but A := B means A is defined as B, a triple bar equals can be used to say it's similar and equal by definition but not always the same thing.
Anyway I point to these other references that were probably in the minds of those that invented it, but it's really just that plane equals and less that equals were taken (or potentially easily confused with =<) and something new to define assignment was needed and that made the most sense.
Historical References: I first saw this in SmallTalk the original Object Language, of which SJ of Apple only copied the Windows part of and BG of Microsoft watered down from them further (single threaded). Eventually SJ in NeXT took the second more important lesson from Xerox PARC in, which became Objective C.
Well anyway they just took colon-equals assiment operator from ALGOL 1958 which was later popularized by Pascal
https://en.wikipedia.org/wiki/PARC_(company)
https://en.wikipedia.org/wiki/Assignment_(computer_science)
Assignments typically allow a variable to hold different values at
different times during its life-span and scope. However, some
languages (primarily strictly functional) do not allow that kind of
"destructive" reassignment, as it might imply changes of non-local
state.
The purpose is to enforce referential transparency, i.e. functions
that do not depend on the state of some variable(s), but produce the
same results for a given set of parametric inputs at any point in
time.
https://en.wikipedia.org/wiki/Referential_transparency
For VB.net,
a constructor (for this case, Me = this in Java):
Public ABC(int A, int B, int C){
Me.A = A;
Me.B = B;
Me.C = C;
}
when you create that object:
new ABC(C:=1, A:=2, B:=3)
Then, regardless of the order of the parameters, that ABC object has A=2, B=3, C=1
So, ya, very good practice for others to read your code effectively
Colon-equals was used in Algol and its descendants such as Pascal and Ada because it is as close as ASCII gets to a left-arrow symbol.
The strange convention of using equals for assignment and double-equals for comparison was started with the C language.
In Prolog, there is no distinction between assignment and the equality test.
So, I'm writing a language using flex/bison and I'm having difficulty with implementing identifiers, specifically when it comes to knowing when you're looking at an assignment or a reference,
for example:
1) A = 1+2
2) B + C (where B and C have already been assigned values)
Example one I can work out by returning an ID token from flex to bison, and just following a grammar that recognizes that 1+2 is an integer expression, putting A into the symbol table, and setting its value.
examples two and three are more difficult for me because: after going through my lexer, what's being returned in ex.2 to bison is "ID PLUS ID" -> I have a grammar that recognizes arithmetic expressions for numerical values, like INT PLUS INT (which would produce an INT), or DOUBLE MINUS INT (which would produce a DOUBLE). if I have "ID PLUS ID", how do I know what type the return value is?
Here's the best idea that I've come up with so far: When tokenizing, every time an ID comes up, I search for its value and type in the symbol table and switch out the ID token with its respective information; for example: while tokenizing, I come across B, which has a regex that matches it as being an ID. I look in my symbol table and see that it has a value of 51.2 and is a DOUBLE. So instead of returning ID, with a value of B to bison, I'm returning DOUBLE with a value of 51.2
I have two different solutions that contradict each other. Here's why: if I want to assign a value to an ID, I would say to my compiler A = 5. In this situation, if I'm using my previously described solution, What I'm going to get after everything is tokenized might be, INT ASGN INT, or STRING ASGN INT, etc... So, in this case, I would use the former solution, as opposed to the latter.
My question would be: what kind of logical device do I use to help my compiler know which solution to use?
NOTE: I didn't think it necessary to post source code to describe my conundrum, but I will if anyone could use it effectively as a reference to help me understand their input on this topic.
Thank you.
The usual way is to have a yacc/bison rule like:
expr: ID { $$ = lookupId($1); }
where the the lookupId function looks up a symbol in the symbol table and returns its type and value (or type and storage location if you're writing a compiler rather than a strict interpreter). Then, your other expr rules don't need to care whether their operands come from constants or symbols or other expressions:
expr: expr '+' expr { $$ = DoAddition($1, $3); }
The function DoAddition takes the types and values (or locations) for its two operands and either adds them, producing a result, or produces code to do the addition at run time.
If possible redesign your language so that the situation is unambiguous. This is why even Javascript has var.
Otherwise you're going to need to disambiguate via semantic rules, for example that the first use of an identifier is its declaration. I don't see what the problem is with your case (2): just generate the appropriate code. If B and C haven't been used yet, a value-reading use like this should be illegal, but that involves you in control flow analysis if taken to the Nth degree of accuracy, so you might prefer to assume initial values of zero.
In any case you can see that it's fundamentally a language design problem rather than a coding problem.
For better understanding of functional programming, I am reading the wiki page for lambda calculus here.
The definition says:
If x is a variable and M ∈ Λ, then (λx.M) ∈ Λ
Intuitively I thought variable are / represented by single-letter id's. But since here we deal with strict math definitions, I just want to double confirm this understanding: in general, can expression be classified as variable?
e.g. if x is a variable, is expression (x + x) a variable in lambda calculus? i.e. is it ok to write (λ(x+x).M) as an lambda calculus abstraction?
(Concern is in some context this is true. e.g. Here: An expression such as 4x^3 is a variable)
No, (x + x) is no variable (indeed it's not even a expression in naive lambda calculus).
I think you mix the terms variables and expressions somehow (or want some kind of pattern-matching?).
So let's follow the core-definition of lambda-calculus and expressions:
The definition itself is not that hard (indeed you linked it yourself with the wiki-page).
It's mentioned right from the start:
you have a set of variables V: (v_1, v_2, ...) (of course you can name them as you want - it's only important that you remmber that these are considered different symbols in your calculus)
the symbols λ, ., ( and )
This is it - thats all of the "Tokens" for this grammar/calculus.
Now there are a couple of rules how you can form Expressions from these:
each Variable is a expression
Abstraction: if E is a expression and x is a Variable then (λx.E) is a expression (here x and E are templates or Metavariables - you have to fill them with some real Expression to make this an Expression!)
Application: if A and B are expressions than (A B) is a expression.
So possible expressions are:
v_50
(λv_4.v_5)
((λv_4.v_5) v_50)
....
This is all when it comes to expressions.
You see: if you don't allow (x+x) as a symbol or name for a variable from the start it can never be a variable - indeed no expression is a variable even if there are some expressions consisting only of one said variable - if you called something expression it will never be a variable (again) ;)
PS: of course there are a couple of conventions to keep the parentheses a bit down - but for a start you don't need those.