Converting from 0 and 1 to -1 and 1
in [General Programming]
|
From: bart.c on 12 May 2010 08:24 "Lie Ryan" <lie.1296(a)gmail.com> wrote in message news:4bea5a56$1(a)dnews.tpgi.com.au... > On 05/10/10 18:12, Jussi Piitulainen wrote: >>>> > > Anything vaguely usable with three operands would do. Median of >>>> > > three numbers. Majority vote of three booleans. >>> > >>> > Many of these are just special cases of N-operand operators. The >>> > challenge is an operator syntax that allows an arbitrary number of >>> > operands (and which doesn't look like a single operand which happens >>> > to be a list, although that is another way of doing it). >> Yes, I have trouble thinking up any naturally ternary operations. As >> soon as the notation has brackets and a comma in it, it is natural to >> extend the number of operands arbitrarily. We do zero, one, two, many. > > Think again: function call is an N-ary operator I think C calls "()" an operator, but that's C. > all the unary, binary, ternary operator can be thought a syntax sugar > for calling functions (some gotcha: laziness). Operators and functions tend to be different, although functions might be used to implement operators. Certainly in the languages I'm involved with, operators are completely different to functions: Operators have a fixed number of 1 or 2 operands, and always return a value; there is a fixed number of operator names/symbols, while function names are unlimited, and can be exist in namespaces; the operator name/symbol is not itself considered an operand (as in C's () operator), and it's not possible to have a pointer to an operator; and operator operands fully support overloading, as in most languages. And there are the obvious syntax differences: operator operands don't need parentheses, tend to use infix notation and so on. There are a few areas of overlap: I consider maths functions to be operators, not functions (so I can write sin x instead of sin(x)), while for 2-operand operators, I would prefer function notation: 'min(a,b)' looks more natural than 'a min b', and lends itself to N-operands more easily, while still being an operator (defining a function to do the same job is trickier, especially when the operands can be mixed numeric types). > btw, is there any language that have zero-ary operator? otherise we > should go one, two, many not zero, one, two, many... I use some zero-ary operators, but mainly to simplify some implementation details. From the language point of view, it's best to keep quiet about them. -- Bartc
From: Ben Bacarisse on 12 May 2010 09:28 Lie Ryan <lie.1296(a)gmail.com> writes: > On 05/10/10 18:12, Jussi Piitulainen wrote: >>>> > > Anything vaguely usable with three operands would do. Median of >>>> > > three numbers. Majority vote of three booleans. >>> > >>> > Many of these are just special cases of N-operand operators. The >>> > challenge is an operator syntax that allows an arbitrary number of >>> > operands (and which doesn't look like a single operand which happens >>> > to be a list, although that is another way of doing it). >> Yes, I have trouble thinking up any naturally ternary operations. As >> soon as the notation has brackets and a comma in it, it is natural to >> extend the number of operands arbitrarily. We do zero, one, two, many. > > Think again: function call is an N-ary operator Not always. Some languages consider it to be binary (Haskell, for example) and that works out quite neatly. <snip> -- Ben.
From: Lie Ryan on 12 May 2010 14:14 On 05/12/10 23:28, Ben Bacarisse wrote: > Lie Ryan <lie.1296(a)gmail.com> writes: > >> On 05/10/10 18:12, Jussi Piitulainen wrote: >>>>>>> Anything vaguely usable with three operands would do. Median of >>>>>>> three numbers. Majority vote of three booleans. >>>>> >>>>> Many of these are just special cases of N-operand operators. The >>>>> challenge is an operator syntax that allows an arbitrary number of >>>>> operands (and which doesn't look like a single operand which happens >>>>> to be a list, although that is another way of doing it). >>> Yes, I have trouble thinking up any naturally ternary operations. As >>> soon as the notation has brackets and a comma in it, it is natural to >>> extend the number of operands arbitrarily. We do zero, one, two, many. >> >> Think again: function call is an N-ary operator > > Not always. Some languages consider it to be binary (Haskell, for > example) and that works out quite neatly. in Haskell, function call is binary, which is a kind of N-ary. So the statement still hold.
From: Lie Ryan on 12 May 2010 14:26 On 05/12/10 18:23, Jussi Piitulainen wrote: > Lie Ryan writes: >> On 05/10/10 18:12, Jussi Piitulainen wrote: >>>>>>> Anything vaguely usable with three operands would do. Median >>>>>>> of three numbers. Majority vote of three booleans. >>>>> >>>>> Many of these are just special cases of N-operand operators. >>>>> The challenge is an operator syntax that allows an arbitrary >>>>> number of operands (and which doesn't look like a single >>>>> operand which happens to be a list, although that is another >>>>> way of doing it). >>> Yes, I have trouble thinking up any naturally ternary operations. >>> As soon as the notation has brackets and a comma in it, it is >>> natural to extend the number of operands arbitrarily. We do zero, >>> one, two, many. >> >> Think again: function call is an N-ary operator > > Not in the minds of the people who succesfully speak of ?: as "the > ternary operator". Not in my mind either, but that doesn't matter. > >> all the unary, binary, ternary operator can be thought a syntax >> sugar for calling functions (some gotcha: laziness). > > That is a good way to think about many of them. Others do not evaluate > all their operands, so cannot be thought of as functions in a language > where function calls do that. actually you can, you can conceptually consider the short-circuiting OR operator: a() || b() as a function call to: OR_OPERATOR(lambda: a(), lambda: b()) (note: the lambda: x is anonymous function, it makes the function call lazy) > Assignment operators are another special > kind. not really, in a language that supports pointer, assignment can be thought of like: memory_copy(&a, &b) in languages that doesn't support pointer, then it can be thought as: locals = the local variables assignment(locals, 'variablename', value) obviously most languages do not do things as mentioned here, but the point is, conceptually: "function <=> operator"
From: Lie Ryan on 12 May 2010 14:43
On 05/12/10 22:24, bart.c wrote: > > "Lie Ryan" <lie.1296(a)gmail.com> wrote in message > news:4bea5a56$1(a)dnews.tpgi.com.au... >> On 05/10/10 18:12, Jussi Piitulainen wrote: >>>>> > > Anything vaguely usable with three operands would do. Median of >>>>> > > three numbers. Majority vote of three booleans. >>>> > >>>> > Many of these are just special cases of N-operand operators. The >>>> > challenge is an operator syntax that allows an arbitrary number of >>>> > operands (and which doesn't look like a single operand which happens >>>> > to be a list, although that is another way of doing it). >>> Yes, I have trouble thinking up any naturally ternary operations. As >>> soon as the notation has brackets and a comma in it, it is natural to >>> extend the number of operands arbitrarily. We do zero, one, two, many. >> >> Think again: function call is an N-ary operator > > I think C calls "()" an operator, but that's C. Whether C or <insert some language> considers function call an operator or not, it doesn't matter. We're not talking about a real language which always have syntactical limitations artificially imposed by the language design or practicality of implementation or taste. >> all the unary, binary, ternary operator can be thought a syntax sugar >> for calling functions (some gotcha: laziness). > > Operators and functions tend to be different, although functions might be > used to implement operators. Conceptually, there is no difference between function and operator. Their difference is just syntactical. > Certainly in the languages I'm involved with, operators are completely > different to functions: > > Operators have a fixed number of 1 or 2 operands, and always return a > value; > there is a fixed number of operator names/symbols, while function names are > unlimited, and can be exist in namespaces; the operator name/symbol is not > itself considered an operand (as in C's () operator), and it's not possible > to have a pointer to an operator; and operator operands fully support > overloading, as in most languages. those are just syntactical limitations, they're irrelevant. > And there are the obvious syntax differences: operator operands don't need > parentheses, tend to use infix notation and so on. also syntactical, irrelevant given a language with no syntactical limitations, operator is the same as function call and function call is the same as operator. function call is an N-ary operator, binary operator is a function call with two arguments, there is no way to distinguish one from the other. things like ability to pass around function or operator as argument is just syntactical limitations, who says you can't design a language that allows you to write: reduce(+, [3, 4, 2]) |