exponentiation operator

scala> case class DoubleWithExp(d: Double) { def **(e:
scala> implicit def doubleWithExp(d: Double) = DoubleWithExp(d)
scala> 2.0 ** 3.0
res4: Double = 8.0
scala> case class IntWithExp(i: Int) { def **(j: Int) = Math.pow(i, j) }
defined class IntWithExp
scala> implicit def intWithExp(i: Int) = IntWithExp(i)
intWithExp: (Int)IntWithExp
scala> 2 ** 3
res5: Double = 8.0

2009/1/31 Russ Paielli <russ.paielli@gmail.com>

I was surprised to discover that Scala apparently has no "**" operator for exponentiation (raising to a power). Am I correct about that? If so, is there another operator for exponentiation, or is the "pow" function considered sufficient? Thanks.

Russ P.

--
http://RussP.us

This should still be part of the standard RichInt/Double/etc classes.

--j

On Sat, Jan 31, 2009 at 1:56 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

scala> case class DoubleWithExp(d: Double) { def **(e:
scala> implicit def doubleWithExp(d: Double) = DoubleWithExp(d)
scala> 2.0 ** 3.0
res4: Double = 8.0
scala> case class IntWithExp(i: Int) { def **(j: Int) = Math.pow(i, j) }
defined class IntWithExp
scala> implicit def intWithExp(i: Int) = IntWithExp(i)
intWithExp: (Int)IntWithExp
scala> 2 ** 3
res5: Double = 8.0

2009/1/31 Russ Paielli <russ.paielli@gmail.com>

I was surprised to discover that Scala apparently has no "**" operator for exponentiation (raising to a power). Am I correct about that? If so, is there another operator for exponentiation, or is the "pow" function considered sufficient? Thanks.

Russ P.

--
http://RussP.us

First, let me say that I think I solved the problem with the implicit conversion that I asked about yesterday. I'm not even sure how I solved it, but it works now, so I'm happy. (Part of the problem was that I had the implicit conversion defined in more than one place, but I think there was more to it than that.)

I would like to return to an issue that I brought up a few days ago: exponentiation using the "**" operator. Ricky Clarkson provided a solution (see below), but I think I just discovered a problem with it: the operator does not have the right precedence level. I think it has the same precedence level as "*" and "/", but it should have a higher precedence level. Given my understanding of the precedence rules, I don't think this problem can be solved in Scala, unless perhaps another special character with a higher precedence can be used.

--Russ P.

On Sat, Jan 31, 2009 at 1:56 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

scala> case class DoubleWithExp(d: Double) { def **(e:
scala> implicit def doubleWithExp(d: Double) = DoubleWithExp(d)
scala> 2.0 ** 3.0
res4: Double = 8.0
scala> case class IntWithExp(i: Int) { def **(j: Int) = Math.pow(i, j) }
defined class IntWithExp
scala> implicit def intWithExp(i: Int) = IntWithExp(i)
intWithExp: (Int)IntWithExp
scala> 2 ** 3
res5: Double = 8.0

2009/1/31 Russ Paielli <russ.paielli@gmail.com>

I was surprised to discover that Scala apparently has no "**" operator for exponentiation (raising to a power). Am I correct about that? If so, is there another operator for exponentiation, or is the "pow" function considered sufficient? Thanks.

Russ P.

--
http://RussP.us

--
http://RussP.us

Hi Russ,

Russ Paielli wrote:
> I would like to return to an issue that I brought up a few days ago:
> exponentiation using the "**" operator. Ricky Clarkson provided a
> solution (see below), but I think I just discovered a problem with it:
> the operator does not have the right precedence level. I think it has
> the same precedence level as "*" and "/", but it should have a higher
> precedence level. Given my understanding of the precedence rules, I
> don't think this problem can be solved in Scala, unless perhaps another
> special character with a higher precedence can be used.

Yes, that is a problem, and you're right about the lack of a good
solution. From section 6.12.3 of the Scala Language Specification:

--

The precedence of an infix operator is determined by the operator’s
first character. Characters are listed below in increasing order of
precedence, with characters on the same line having the same precedence.

(all letters)
|
^
&
< >
= !
:
+ *
/ %
(all other special characters)

--

So you need to find a special character which you can type easily. ~ maybe?

Cheers,
Jon

I did a few tests, and it appears that "~~" or "##" will work correctly as the exponentiation operator. Neither one is ideal, but I lean toward "~~". What do you think?

You can always use "pow," but if Scala is going to be considered suitable for numerical computing, I think it should have an exponentiation operator.

--Russ


On Wed, Feb 4, 2009 at 5:12 PM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Hi Russ,

Russ Paielli wrote:
> I would like to return to an issue that I brought up a few days ago:
> exponentiation using the "**" operator. Ricky Clarkson provided a
> solution (see below), but I think I just discovered a problem with it:
> the operator does not have the right precedence level. I think it has
> the same precedence level as "*" and "/", but it should have a higher
> precedence level. Given my understanding of the precedence rules, I
> don't think this problem can be solved in Scala, unless perhaps another
> special character with a higher precedence can be used.

Yes, that is a problem, and you're right about the lack of a good
solution.  From section 6.12.3 of the Scala Language Specification:

--

The precedence of an infix operator is determined by the operator's
first character.  Characters are listed below in increasing order of
precedence, with characters on the same line having the same precedence.

 (all letters)
 |
 ^
 &
 < >
 = !
 :
 + *
 / %
 (all other special characters)

--

So you need to find a special character which you can type easily.  ~ maybe?

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

That looks wrong.  If / was higher than *, the following would give 3.

scala> 3 * 4 / 3
res0: Int = 4

2009/2/5 Jon Pretty <jon.pretty@sygneca.com>

Hi Russ,

Russ Paielli wrote:
> I would like to return to an issue that I brought up a few days ago:
> exponentiation using the "**" operator. Ricky Clarkson provided a
> solution (see below), but I think I just discovered a problem with it:
> the operator does not have the right precedence level. I think it has
> the same precedence level as "*" and "/", but it should have a higher
> precedence level. Given my understanding of the precedence rules, I
> don't think this problem can be solved in Scala, unless perhaps another
> special character with a higher precedence can be used.

Yes, that is a problem, and you're right about the lack of a good
solution.  From section 6.12.3 of the Scala Language Specification:

--

The precedence of an infix operator is determined by the operator's
first character.  Characters are listed below in increasing order of
precedence, with characters on the same line having the same precedence.

 (all letters)
 |
 ^
 &
 < >
 = !
 :
 + *
 / %
 (all other special characters)

--

So you need to find a special character which you can type easily.  ~ maybe?

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

What about "~^" ?

On Thu, Feb 5, 2009 at 7:06 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

I did a few tests, and it appears that "~~" or "##" will work correctly as the exponentiation operator. Neither one is ideal, but I lean toward "~~". What do you think?

You can always use "pow," but if Scala is going to be considered suitable for numerical computing, I think it should have an exponentiation operator.

--Russ


On Wed, Feb 4, 2009 at 5:12 PM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Hi Russ,

Russ Paielli wrote:
> I would like to return to an issue that I brought up a few days ago:
> exponentiation using the "**" operator. Ricky Clarkson provided a
> solution (see below), but I think I just discovered a problem with it:
> the operator does not have the right precedence level. I think it has
> the same precedence level as "*" and "/", but it should have a higher
> precedence level. Given my understanding of the precedence rules, I
> don't think this problem can be solved in Scala, unless perhaps another
> special character with a higher precedence can be used.

Yes, that is a problem, and you're right about the lack of a good
solution.  From section 6.12.3 of the Scala Language Specification:

--

The precedence of an infix operator is determined by the operator's
first character.  Characters are listed below in increasing order of
precedence, with characters on the same line having the same precedence.

 (all letters)
 |
 ^
 &
 < >
 = !
 :
 + *
 / %
 (all other special characters)

--

So you need to find a special character which you can type easily.  ~ maybe?

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

--
Viktor Klang
Senior Systems Analyst

Viktor Klang wrote:
>
> What about "~^" ?
>

Why not simply "#" ? For me "~" has the connotation "not" or "complement".

Daniel

Hi Ricky,

Ricky Clarkson wrote:
> That looks wrong. If / was higher than *, the following would give 3.

That /does/ look wrong. Turns out that cutting and pasting from the PDF
puts the linebreaks in different places and deletes the minus-sign.
There's probably some over-clever logic involved there...

Here's the correct list:

(all letters)
|
^
&
< >
= !
:
+ -
* / %
(all other special characters)

Jon

The low precedence of ^ is surprising.

2009/2/5 Jon Pretty <jon.pretty@sygneca.com>

Hi Ricky,

Ricky Clarkson wrote:
> That looks wrong.  If / was higher than *, the following would give 3.

That /does/ look wrong.  Turns out that cutting and pasting from the PDF
puts the linebreaks in different places and deletes the minus-sign.
There's probably some over-clever logic involved there...

Here's the correct list:

(all letters)
|
^
&
< >
= !
:
+ -
* / %
(all other special characters)

Jon

--
Jon Pretty | Sygneca Ltd.

Ricky Clarkson wrote:
> The low precedence of ^ is surprising.

Really? Given that it's used for XOR, it's alongside two quite similar
operators...

But it would otherwise have made a nice exponentiation operator...

Jon

Hmm, how about " ° "

On Thu, Feb 5, 2009 at 11:08 AM, Landei <Daniel.Gronau@gmx.de> wrote:

Viktor Klang wrote:
>
> What about "~^" ?
>

Why not simply "#" ? For me "~" has the connotation "not" or "complement".

Daniel

--
View this message in context: http://www.nabble.com/exponentiation-operator-tp21767761p21848530.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Viktor Klang
Senior Systems Analyst

On Thu, Feb 5, 2009 at 2:36 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

Hmm, how about " ° "

What the heck is that?

I think we need something that appears on all keyboards.

On Thu, Feb 5, 2009 at 2:08 AM, Landei <Daniel.Gronau@gmx.de> wrote:

Viktor Klang wrote:
>
> What about "~^" ?
>

That seems to work. I'm not sure if I like it better than "~~" or not.

Why not simply "#" ? For me "~" has the connotation "not" or "complement".

Unfortunately, that doesn't seem to work.

--
http://RussP.us

On Thu, Feb 5, 2009 at 1:09 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Thu, Feb 5, 2009 at 2:36 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

Hmm, how about " ° "

What the heck is that?

I think we need something that appears on all keyboards.

You mean Russian and Chinese keyboards aswell?
Furthermore I think it's the "degree"-symbol

--
Viktor Klang
Senior Systems Analyst

I think, realistically, this isn't going to be added to the standard
library. Wherever it goes[1], it ought to be explicitly imported.

Also, was there anything wrong with just '~'? E.g.,

def cubic(x : Double) = x~3 + 2*x~2 + 3*x + 1

Jon

[1] Scalax would be a suitable place.

On Thu, Feb 05, 2009 at 03:05:33PM +0000, Jon Pretty wrote:
> I think, realistically, this isn't going to be added to the standard
> library. Wherever it goes[1], it ought to be explicitly imported.
>
> Also, was there anything wrong with just '~'? E.g.,
>
> def cubic(x : Double) = x~3 + 2*x~2 + 3*x + 1
>
> Jon

I think this is a bad place to be inventing syntax just to work around scala's precedence inflexibility, because people already have
long expectations about how one expresses exponentiation. Also, ~ means sequential composition in the combinator libraries, and
it's already a unary operator on integer types (bitwise not.)

scala> ~5
res2: Int = -6

If this is really important for numerical computing I hope someone will write a SIP proposing a mechanism for controlling operator
precedence.

You always know when a discussion is about syntax.  Everybody has an opinion.

Hi Paul,

Paul Phillips wrote:
> I think this is a bad place to be inventing syntax just to work around scala's precedence inflexibility, because people already have
> long expectations about how one expresses exponentiation.

True, but I think an external project has every right to define such a
thing. It's all about defining syntax that's appropriate for the
domain, and symbolic operators provide a convenient way of saving on
parentheses.

If you're working with polynomial series all day, then you would want
the syntax to be as concise as possible, but if it's just an occasional
power, Math.pow is perfectly acceptable, and clearer. (Though I don't
understand why the 'er' suffix was so difficult to type...)

> Also, ~ means sequential composition in the combinator libraries, and
> it's already a unary operator on integer types (bitwise not.)

Ah! I'd forgotten that.

> If this is really important for numerical computing I hope someone will write a SIP proposing a mechanism for controlling operator
> precedence.

Hmmm. This is a bit of a minefield, but I'm happy to join in a debate
if there is one. ;-)

Cheers,
Jon

Ok, so according to SLS 6.12.3 (which Jon quoted), the precedence of an operator is defined by the operators first character. The first characters which have higher precedence than */% are  #?@\~

Two of these (# and @) are designated as reserved words, so we can't use the single-character version.

The usable single characters are ? \ and ~. As Paul points out, ~ is already used to mean bitwise NOT, which pretty much rules it out.

This leaves ? and \ for single-character exponentiation operators.

Alternatively, any multi-character operator that starts one of #?@\~ and ends with one or more of !#%&*+-/:<=>?@\^|~

Given these constraints, my vote would go for something along the lines of #^ or ~^. The only unfortunate side effect is that forgetting the # or the ~ would result in doing bitwise OR on Ints or Longs, which could be a really unfortunate bug to find. So maybe it'd be safer to find something that, when mispelled, doesn't end in disaster?

--j

On Thu, Feb 5, 2009 at 7:58 AM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Hi Paul,

Paul Phillips wrote:
> I think this is a bad place to be inventing syntax just to work around scala's precedence inflexibility, because people already have
> long expectations about how one expresses exponentiation.

True, but I think an external project has every right to define such a
thing.  It's all about defining syntax that's appropriate for the
domain, and symbolic operators provide a convenient way of saving on
parentheses.

If you're working with polynomial series all day, then you would want
the syntax to be as concise as possible, but if it's just an occasional
power, Math.pow is perfectly acceptable, and clearer.  (Though I don't
understand why the 'er' suffix was so difficult to type...)

> Also, ~ means sequential composition in the combinator libraries, and
> it's already a unary operator on integer types (bitwise not.)

Ah!  I'd forgotten that.

> If this is really important for numerical computing I hope someone will write a SIP proposing a mechanism for controlling operator
> precedence.

Hmmm.  This is a bit of a minefield, but I'm happy to join in a debate
if there is one. ;-)

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

Given that it would be necessary to invent a completely new symbol for a common operation which already has a fairly well accepted representation (being ** in most languages) simply to work around the precedence rules...

Perhaps at this point (barring some mechanism for controlling precedence) the standard library should just stick with pow() and leave any special symbol up to users who deem them necessary/useful?

Just my (4 ~^ 0.5) cents.

- Colin

Colin Bullock wrote:
> Perhaps at this point (barring some mechanism for controlling
> precedence) the standard library should just stick with pow() and leave
> any special symbol up to users who deem them necessary/useful?

You're right. (And James Iry is especially right.) But what do we
normally do with stuff like this? Answer: stick it in a library and let
users import it if and only if they want to use it.

Not wishing to drag this out longer than it deserves (bit late for that,
maybe...), I'm personally still in favour of using ~ for exponentiation,
even if it does have another (quite different) meaning. Is there any
real problem overloading it (especially if it is only applicable within
the scope of the import).

Jon

I tried ~, and it doesn't work. I think the best choices are ~~, ~^, or #^. I agree, however, that none of these belong in the standard library.

Scala is very flexible and adaptable, but (as others have said) it would be nice if an operator's precedence could somehow be specified at the point of creation. I'll leave it to smarter people than me to decide if that is feasible and wise.

--Russ

On Thu, Feb 5, 2009 at 10:55 AM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Colin Bullock wrote:
> Perhaps at this point (barring some mechanism for controlling
> precedence) the standard library should just stick with pow() and leave
> any special symbol up to users who deem them necessary/useful?

You're right.  (And James Iry is especially right.)  But what do we
normally do with stuff like this?  Answer: stick it in a library and let
users import it if and only if they want to use it.

Not wishing to drag this out longer than it deserves (bit late for that,
maybe...), I'm personally still in favour of using ~ for exponentiation,
even if it does have another (quite different) meaning.  Is there any
real problem overloading it (especially if it is only applicable within
the scope of the import).

Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

It would dramatically complicate parsing to do that.

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

I tried ~, and it doesn't work. I think the best choices are ~~, ~^, or #^. I agree, however, that none of these belong in the standard library.

Scala is very flexible and adaptable, but (as others have said) it would be nice if an operator's precedence could somehow be specified at the point of creation. I'll leave it to smarter people than me to decide if that is feasible and wise.

--Russ

On Thu, Feb 5, 2009 at 10:55 AM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Colin Bullock wrote:
> Perhaps at this point (barring some mechanism for controlling
> precedence) the standard library should just stick with pow() and leave
> any special symbol up to users who deem them necessary/useful?

You're right.  (And James Iry is especially right.)  But what do we
normally do with stuff like this?  Answer: stick it in a library and let
users import it if and only if they want to use it.

Not wishing to drag this out longer than it deserves (bit late for that,
maybe...), I'm personally still in favour of using ~ for exponentiation,
even if it does have another (quite different) meaning.  Is there any
real problem overloading it (especially if it is only applicable within
the scope of the import).

Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

(switching to scala-debate)

Russ Paielli wrote:
> Scala is very flexible and adaptable, but (as others have said) it
> would be nice if an operator's precedence could somehow be specified
> at the point of creation. I'll leave it to smarter people than me to
> decide if that is feasible and wise.
This is one of my hobby horses. My half-assed take on the problem is:

1. There's a class of "easy" solutions (including at least one modelled
on Haskell's) that would smell bad and cause all kinds of nonlocal problems;

2. There's a class of poorly thought-out, extremely hairy solutions that
would require major work in the compiler: the parser understands
precedence, information about precedence would only become available
after the typer has run, and the information flow from parser to typer
is one-way. If you could find a way to surmount these difficulties, the
resulting solution might be very nice. :)

The class of solutions that are only moderately difficult while
remaining reasonably sane is, to my knowledge, uninhabited. :)

I suspect that the only way progress will happen in this area is if
people pick a solution, implement it (hopefully as a compiler plugin)
and see who salutes.

-0xe1a

The main problem with not having a standard exponentiation operator is that people just learning the language are confused. Since the ** operator is a de facto standard in many other languages, the lack of such an operator in Scala should be clearly explained in books and other reference material.

Now that I think about it, I realize that something like 99% of the time I raise a value to a power, the power is two. Squaring is by far the most common use of powers. Given that fact, I will just define a function for squaring. I'll call it "sqr," and I'll even suggest that it be added to the standard library. Well, maybe that could be mistaken for sqare root, so maybe it should be "square." I don't know.

A squaring function may actually be preferable to the pow function when the power is two, because it can just multiply rather than taking logs and antilogs. I don't know if pow is "smart" enough to just multiply when the power is two.

--Russ

On Thu, Feb 5, 2009 at 11:25 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

It would dramatically complicate parsing to do that.

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

I tried ~, and it doesn't work. I think the best choices are ~~, ~^, or #^. I agree, however, that none of these belong in the standard library.

Scala is very flexible and adaptable, but (as others have said) it would be nice if an operator's precedence could somehow be specified at the point of creation. I'll leave it to smarter people than me to decide if that is feasible and wise.

--Russ

On Thu, Feb 5, 2009 at 10:55 AM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Colin Bullock wrote:
> Perhaps at this point (barring some mechanism for controlling
> precedence) the standard library should just stick with pow() and leave
> any special symbol up to users who deem them necessary/useful?

You're right.  (And James Iry is especially right.)  But what do we
normally do with stuff like this?  Answer: stick it in a library and let
users import it if and only if they want to use it.

Not wishing to drag this out longer than it deserves (bit late for that,
maybe...), I'm personally still in favour of using ~ for exponentiation,
even if it does have another (quite different) meaning.  Is there any
real problem overloading it (especially if it is only applicable within
the scope of the import).

Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

--
http://RussP.us

Is that fact clearly explained in C, C++, Java, C#, Pascal, JavaScript, Haskell, etc., all of which don't provide it?

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

The main problem with not having a standard exponentiation operator is that people just learning the language are confused. Since the ** operator is a de facto standard in many other languages, the lack of such an operator in Scala should be clearly explained in books and other reference material.

Now that I think about it, I realize that something like 99% of the time I raise a value to a power, the power is two. Squaring is by far the most common use of powers. Given that fact, I will just define a function for squaring. I'll call it "sqr," and I'll even suggest that it be added to the standard library. Well, maybe that could be mistaken for sqare root, so maybe it should be "square." I don't know.

A squaring function may actually be preferable to the pow function when the power is two, because it can just multiply rather than taking logs and antilogs. I don't know if pow is "smart" enough to just multiply when the power is two.

--Russ

On Thu, Feb 5, 2009 at 11:25 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

It would dramatically complicate parsing to do that.

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

I tried ~, and it doesn't work. I think the best choices are ~~, ~^, or #^. I agree, however, that none of these belong in the standard library.

Scala is very flexible and adaptable, but (as others have said) it would be nice if an operator's precedence could somehow be specified at the point of creation. I'll leave it to smarter people than me to decide if that is feasible and wise.

--Russ

On Thu, Feb 5, 2009 at 10:55 AM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Colin Bullock wrote:
> Perhaps at this point (barring some mechanism for controlling
> precedence) the standard library should just stick with pow() and leave
> any special symbol up to users who deem them necessary/useful?

You're right.  (And James Iry is especially right.)  But what do we
normally do with stuff like this?  Answer: stick it in a library and let
users import it if and only if they want to use it.

Not wishing to drag this out longer than it deserves (bit late for that,
maybe...), I'm personally still in favour of using ~ for exponentiation,
even if it does have another (quite different) meaning.  Is there any
real problem overloading it (especially if it is only applicable within
the scope of the import).

Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

--
http://RussP.us

Hmmm.... You're right. Python and Fortran have the ** operator, and for some reason I thought that C, C++, and Java had it too. My mistake. I guess this whole thread was just a tempest in a teapot after all.

On another matter, I suggest that Scala should have keywords "and" and "or" as aliases for "&&" and "||" (with the same precedence levels, of course).


On Thu, Feb 5, 2009 at 12:22 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Is that fact clearly explained in C, C++, Java, C#, Pascal, JavaScript, Haskell, etc., all of which don't provide it?

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

The main problem with not having a standard exponentiation operator is that people just learning the language are confused. Since the ** operator is a de facto standard in many other languages, the lack of such an operator in Scala should be clearly explained in books and other reference material.

Now that I think about it, I realize that something like 99% of the time I raise a value to a power, the power is two. Squaring is by far the most common use of powers. Given that fact, I will just define a function for squaring. I'll call it "sqr," and I'll even suggest that it be added to the standard library. Well, maybe that could be mistaken for sqare root, so maybe it should be "square." I don't know.

A squaring function may actually be preferable to the pow function when the power is two, because it can just multiply rather than taking logs and antilogs. I don't know if pow is "smart" enough to just multiply when the power is two.

--Russ

On Thu, Feb 5, 2009 at 11:25 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

It would dramatically complicate parsing to do that.

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

I tried ~, and it doesn't work. I think the best choices are ~~, ~^, or #^. I agree, however, that none of these belong in the standard library.

Scala is very flexible and adaptable, but (as others have said) it would be nice if an operator's precedence could somehow be specified at the point of creation. I'll leave it to smarter people than me to decide if that is feasible and wise.

--Russ

On Thu, Feb 5, 2009 at 10:55 AM, Jon Pretty <jon.pretty@sygneca.com> wrote:

Colin Bullock wrote:
> Perhaps at this point (barring some mechanism for controlling
> precedence) the standard library should just stick with pow() and leave
> any special symbol up to users who deem them necessary/useful?

You're right.  (And James Iry is especially right.)  But what do we
normally do with stuff like this?  Answer: stick it in a library and let
users import it if and only if they want to use it.

Not wishing to drag this out longer than it deserves (bit late for that,
maybe...), I'm personally still in favour of using ~ for exponentiation,
even if it does have another (quite different) meaning.  Is there any
real problem overloading it (especially if it is only applicable within
the scope of the import).

Jon

--
Jon Pretty | Sygneca Ltd.

--
http://RussP.us

--
http://RussP.us

--
http://RussP.us

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ Paielli wrote:
> On another matter, I suggest that Scala should have keywords "and"
> and "or" as aliases for "&&" and "||" (with the same precedence
> levels, of course).
Eek! Why keywords when you can just write them yourself?

FWIW I prefer /\ and \/ as per scalaz.BooleanW

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJi2xdmnpgrYe6r60RAnMrAJ9HKihppps7VJ7Nj9Lxdf2yTqm2bQCdEIsU
HaexjDL5QFQwnnUdQ13RmmA=
=V+z1
-----END PGP SIGNATURE-----

Russ Paielli wrote:
> On another matter, I suggest that Scala should have keywords "and"
> and "or" as aliases for "&&" and "||" (with the same precedence
> levels, of course). <http://RussP.us>
Eek! Why keywords when you can just write them yourself?

Correct me if I am wrong, but if you write them yourself, I don't think you will get the correct operator precedence.  If you know how to do this correctly, please provide the code. I would like to use it. Thanks.

FWIW I prefer /\ and \/ as per scalaz.BooleanW

No thanks. Too cryptic and not ASCII characters.

Let's address "Too cryptic".  There's a school, or should I say denial, of thought, that says "everything must be made of words and be easy to understand without learning".  The reason I say 'denial' is that the same people are generally happy with +, -, etc. - they don't want to replace them with plus, minus, etc.

Parser combinators are an excellent example - a~b is much easier to read and write than a.followedBy(b), though the latter is certainly easier to understand without having to learn anything.

Also, /\ and \/ are not each an ASCII character, true, but they are made up of / and \.

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

Russ Paielli wrote:
> On another matter, I suggest that Scala should have keywords "and"
> and "or" as aliases for "&&" and "||" (with the same precedence
> levels, of course). <http://RussP.us>
Eek! Why keywords when you can just write them yourself?

Correct me if I am wrong, but if you write them yourself, I don't think you will get the correct operator precedence.  If you know how to do this correctly, please provide the code. I would like to use it. Thanks.

FWIW I prefer /\ and \/ as per scalaz.BooleanW

No thanks. Too cryptic and not ASCII characters.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ Paielli wrote:
>
> Russ Paielli wrote:
>> On another matter, I suggest that Scala should have keywords
>> "and" and "or" as aliases for "&&" and "||" (with the same
>> precedence levels, of course).
> Eek! Why keywords when you can just write them yourself?
>
>
> Correct me if I am wrong, but if you write them yourself, I don't
> think you will get the correct operator precedence. If you know
> how to do this correctly, please provide the code. I would like to
> use it. Thanks.

What do you think might be the correct precedence?
>
>
> FWIW I prefer /\ and \/ as per scalaz.BooleanW
>
>
> No thanks. Too cryptic and not ASCII characters.
>
>
Bothof these symbols are ASCII and are used widely - and therefore,
are only cryptic if you are unfamiliar with introductory logic - in
ASCII-only contexts to denote the actual non-ASCII symbols of ? and ?

http://en.wikipedia.org/wiki/Logical_conjunction
http://en.wikipedia.org/wiki/Logical_disjunction

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJi3F0mnpgrYe6r60RAjZAAJ9J3xAyoOGp6dUcTZugc2HUPkDrsgCgtCxp
4OmLe5qS3IcAw2GR39PnwEY=
=1gwT
-----END PGP SIGNATURE-----

On Thu, Feb 5, 2009 at 3:02 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Let's address "Too cryptic".  There's a school, or should I say denial, of thought, that says "everything must be made of words and be easy to understand without learning".  The reason I say 'denial' is that the same people are generally happy with +, -, etc. - they don't want to replace them with plus, minus, etc.

We learn + and - in elementary school, but we don't learn "&&" and "||".

Parser combinators are an excellent example - a~b is much easier to read and write than a.followedBy(b), though the latter is certainly easier to understand without having to learn anything.

But that doesn't apply here. I'm just suggesting that "and" and "or" be aliases for "&&" and "||".  As far as I am concerned, this is one thing that Python definitely gets right. They are very self-explanatory. In English, we say "if A is true and B is true", or "if A is true or B is true." What could be more natural? They are hardly even more characters than "&&" and "||".
 

Also, /\ and \/ are not each an ASCII character, true, but they are made up of / and \.

I didn't realize that. I though they were some unicode thing or something.

Call me dense, but their meaning is not as immediately clear to me as "and" and "or".

2009/2/5 Russ Paielli <russ.paielli@gmail.com>

Russ Paielli wrote:
> On another matter, I suggest that Scala should have keywords "and"
> and "or" as aliases for "&&" and "||" (with the same precedence
> levels, of course). <http://RussP.us>
Eek! Why keywords when you can just write them yourself?

Correct me if I am wrong, but if you write them yourself, I don't think you will get the correct operator precedence.  If you know how to do this correctly, please provide the code. I would like to use it. Thanks.

FWIW I prefer /\ and \/ as per scalaz.BooleanW

No thanks. Too cryptic and not ASCII characters.

--
http://RussP.us

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ Paielli wrote:
>
>
> Also, /\ and \/ are not each an ASCII character, true, but they
> are made up of / and \.
>
>
> I didn't realize that. I though they were some unicode thing or
> something.
>
> Call me dense, but their meaning is not as immediately clear to me
> as "and" and "or".
>
>
You are not dense, merely exhibiting your biases. Programming is
exactly the construction of a logical theorem after all (see C-H
Correspondence). Call it my biases if you like, but those symbols are
recognisable by any person I know that has opened a book on
first-order logic.

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJi3UfmnpgrYe6r60RAicgAKCtNXreNj1uAnKs91TmlFZJ4HE2mACeMEgf
RS+jipFv6D0SyLJTil/L5vc=
=Vo1Q
-----END PGP SIGNATURE-----

> Call me dense, but their meaning is not as immediately clear to me
> as "and" and "or".
>
> <http://RussP.us>
You are not dense, merely exhibiting your biases. Programming is
exactly the construction of a logical theorem after all (see C-H
Correspondence). Call it my biases if you like, but those symbols are
recognisable by any person I know that has opened a book on
first-order logic.

If I've even opened such a book, it was long ago, and I suspect that would be true for many programmers. Maybe that's unfortunate, but I'm afraid it's true.

Here's the problem I have. I know (or at least I think I know) that those symbols mean "union" and "intersection." Where I have to think a bit is in deciding which one means "and" and which means "or." On the one hand, "union" could mean "both together," which sounds like "and," but I guess it means "both true together," which means "or". You get the idea.

O/H Russ Paielli έγραψε:
>
> > Call me dense, but their meaning is not as immediately clear to me
> > as "and" and "or".
> >
> >
> You are not dense, merely exhibiting your biases. Programming is
> exactly the construction of a logical theorem after all (see C-H
> Correspondence). Call it my biases if you like, but those symbols are
> recognisable by any person I know that has opened a book on
> first-order logic.
>
>
> If I've even opened such a book, it was long ago, and I suspect that
> would be true for many programmers. Maybe that's unfortunate, but I'm
> afraid it's true.
>
> Here's the problem I have. I know (or at least I think I know) that
> those symbols mean "union" and "intersection." Where I have to think a
> bit is in deciding which one means "and" and which means "or." On the
> one hand, "union" could mean "both together," which sounds like "and,"
> but I guess it means "both true together," which means "or". You get
> the idea.
You opened the wrong book:
http://letmegooglethatforyou.com/?q=first+order+logic+symbols

Hi Russ,

Russ Paielli wrote:
> But that doesn't apply here. I'm just suggesting that "and" and "or" be
> aliases for "&&" and "||". As far as I am concerned, this is one thing
> that Python definitely gets right. They are very self-explanatory. In
> English, we say "if A is true and B is true", or "if A is true or B is
> true." What could be more natural? They are hardly even more characters
> than "&&" and "||".

I have to disagree with that for four reasons:

1. 'Or' in English means something different to ||. It has a different
truth table.

2. && and || are sufficiently-well understood for there to be no need to
replace them. When learning Scala, the meaning of || and && is the
least of your worries.

3. Creating aliases introduces redundancy, and the suggestion to the
reader that a difference between the symbolic and verbal versions exists
when it doesn't.

4. Scala has reasonably simple precedence rules, and to support 'and'
and 'or' we would either have to compromise in giving them the same
precedence or by complicating Scala's rules.

> Call me dense, but their meaning is not as immediately clear to me as
> "and" and "or".

No, it's not immediately clear, but it is easy to look it up. I think
it's reasonable to expect a programmer to look up stuff he doesn't know.

I think you're finding a problem which doesn't exist...

Tony's suggestion of \/ and /\ has the benefit that the symbols
correspond to common mathematical notation, but fall down in being
slightly harder to type, being more susceptible to dyslexographic error
and not having the verbal suggestiveness of the '&&'.

Cheers,
Jon

> We learn + and - in elementary school, but we don't learn
> "&&" and "||".

Well, I didn't learn + in elementary school's language
lessons ...

I did in elementary school's math lessons.

And I learned && and || in elementary school of Java programming,
in the "logical operators" lesson.

> Parser combinators are an excellent example - a~b is
> much easier to read and write than a.followedBy(b), though
> the latter is certainly easier to understand without having
> to learn anything.

This seems to be the way how some people think:
Not in terms of 'expression' -> a statement about a fact
but in terms of commands -> a statement about how things are done.

> They are very self-explanatory. In English, we say "if
> A is true and B is true", or "if A is true or B is true."
> What could be more natural? They are hardly even more
> characters than "&&" and "||".

Would be too easy to confuse the strong formal meaning with
the meaning in spoken language, which is weaker.
"Self explanatory" is generally nothing in a formalised scientific
environment.

This is clearly visible with the word 'implies':
It is not self explanatory why
2 is odd implies Paris is in America
If pigs fly, then Paris is in France
both are true.

Well, I'm not a mathematical geek at all, but I indeed learned
that once you are used to the exact meaning of a special symbol
it is easier to grok a symbolic expression for me as if I had to
interpret a spoken text.

This is why in chemistry water is H2O and
not "Two hydrogene atoms connected with one oxygene atom",
and I'm happy with it.

This is, why I didn't like COBOL with its MOVE a TO b ,
meaning assignment: b = a .

It is always easier to get a memory model from reading
with one or two glances:

if ( a > b) { x = a + 42 }

than:

IF a greaterThan b THEN x is a plus 42

So far my 2ct.

BTW: It's a deja vu of the discussion about (0 /: list) (_ + _) , isn't
it?
Always wanted to make a video clip about that ...

KR
Det

ADD 1 TO DETERING GIVING DETERING

2009/2/6 Detering Dirk <Dirk.Detering@bitmarck.de>

> We learn + and - in elementary school, but we don't learn
> "&&" and "||".

Well, I didn't learn + in elementary school's language
lessons ...

I did in elementary school's math lessons.

And I learned &&  and || in elementary school of Java programming,
in the "logical operators" lesson.


>       Parser combinators are an excellent example - a~b is
> much easier to read and write than a.followedBy(b), though
> the latter is certainly easier to understand without having
> to learn anything.

This seems to be the way how some people think:
Not in terms of 'expression' -> a statement about a fact
but in terms of commands -> a statement about how things are done.

> They are very self-explanatory. In English, we say "if
> A is true and B is true", or "if A is true or B is true."
> What could be more natural? They are hardly even more
> characters than "&&" and "||".

Would be too easy to confuse the strong formal meaning with
the meaning in spoken language, which is weaker.
"Self explanatory" is generally nothing in a formalised scientific
environment.

This is clearly visible with the word 'implies':
It is not self explanatory why
  2 is odd implies Paris is in America
  If pigs fly, then Paris is in France
both are true.


Well, I'm not a mathematical geek at all, but I indeed learned
that once you are used to the exact meaning of a special symbol
it is easier to grok a symbolic expression for me as if I had to
interpret a spoken text.

This is why in chemistry water is H2O and
not "Two hydrogene atoms connected with one oxygene atom",
and I'm happy with it.

This is, why I didn't like COBOL with its MOVE a TO b ,
meaning assignment:  b = a  .

It is always easier to get a memory model from reading
with one or two glances:

if ( a > b) {  x = a + 42 }

than:

IF a greaterThan b THEN x is a plus 42


So far my 2ct.

BTW: It's a deja vu of the discussion about  (0 /: list) (_ + _) , isn't
it?
Always wanted to make a video clip about that ...


KR
Det

On Fri, Feb 6, 2009 at 11:50 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

ADD 1 TO DETERING GIVING DETERING

            ^-------------- Type mismatch

 

2009/2/6 Detering Dirk <Dirk.Detering@bitmarck.de>

> We learn + and - in elementary school, but we don't learn
> "&&" and "||".

Well, I didn't learn + in elementary school's language
lessons ...

I did in elementary school's math lessons.

And I learned &&  and || in elementary school of Java programming,
in the "logical operators" lesson.


>       Parser combinators are an excellent example - a~b is
> much easier to read and write than a.followedBy(b), though
> the latter is certainly easier to understand without having
> to learn anything.

This seems to be the way how some people think:
Not in terms of 'expression' -> a statement about a fact
but in terms of commands -> a statement about how things are done.

> They are very self-explanatory. In English, we say "if
> A is true and B is true", or "if A is true or B is true."
> What could be more natural? They are hardly even more
> characters than "&&" and "||".

Would be too easy to confuse the strong formal meaning with
the meaning in spoken language, which is weaker.
"Self explanatory" is generally nothing in a formalised scientific
environment.

This is clearly visible with the word 'implies':
It is not self explanatory why
  2 is odd implies Paris is in America
  If pigs fly, then Paris is in France
both are true.


Well, I'm not a mathematical geek at all, but I indeed learned
that once you are used to the exact meaning of a special symbol
it is easier to grok a symbolic expression for me as if I had to
interpret a spoken text.

This is why in chemistry water is H2O and
not "Two hydrogene atoms connected with one oxygene atom",
and I'm happy with it.

This is, why I didn't like COBOL with its MOVE a TO b ,
meaning assignment:  b = a  .

It is always easier to get a memory model from reading
with one or two glances:

if ( a > b) {  x = a + 42 }

than:

IF a greaterThan b THEN x is a plus 42


So far my 2ct.

BTW: It's a deja vu of the discussion about  (0 /: list) (_ + _) , isn't
it?
Always wanted to make a video clip about that ...


KR
Det

--
Viktor Klang
Senior Systems Analyst

On Thu, Feb 5, 2009 at 5:25 PM, Jon Pretty <jon.pretty@sygneca.com> wrote:

I have to disagree with that for four reasons:

1. 'Or' in English means something different to ||.  It has a different
truth table.

Virtually everyone calls || the "or" operator. Martin Odersky call it "logical-or" in his Scala book. And he calls && the "logical-and" operator. How people can argue that "||" is a better name than "or" for logical-or escapes me. Ditto for &&.

I am not claiming that "natural language" is always preferable to mathematical notation. But in this case, it just seems so obviously clearer to me.

This is a minor syntax issue, of course, so I will drop it. Scala syntax is much better than Java syntax in other ways, so I guess I can live with "&&" and "||".

4. Scala has reasonably simple precedence rules, and to support 'and'
and 'or' we would either have to compromise in giving them the same
precedence or by complicating Scala's rules.

The precedence rules would have to be maintained, or it wouldn't be worth doing.

Russ Paielli wrote:
> 4. Scala has reasonably simple precedence rules, and to support 'and'
> and 'or' we would either have to compromise in giving them the same
> precedence or by complicating Scala's rules.
>
>
> The precedence rules would have to be maintained, or it wouldn't be
> worth doing.
>

That's nonsense. I note that Perl has different precedence rules for "and" and "&&", which is used
to great effect in that language.

http://www.perl.com/doc/manual/html/pod/perlop.html#SYNOPSIS
http://www.perl.com/doc/manual/html/pod/perlop.html#C_style_Logical_And
http://www.perl.com/doc/manual/html/pod/perlop.html#Logical_And

~~ Robert Fischer.
Grails Trainining http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

Hi Robert,

Robert Fischer wrote:
> That's nonsense. I note that Perl has different precedence rules for
> "and" and "&&", which is used to great effect in that language.

But Perl is a very different language, with a different philosophy.
What's great for Perl isn't necessarily great for Scala...

Cheers,
Jon

I agree with that. I just chafed at the assertion it was "nonsense" that "==" and "and" might have
different precedence rules.

~~ Robert.

Jon Pretty wrote:
> Hi Robert,
>
> Robert Fischer wrote:
>> That's nonsense. I note that Perl has different precedence rules for
>> "and" and "&&", which is used to great effect in that language.
>
> But Perl is a very different language, with a different philosophy.
> What's great for Perl isn't necessarily great for Scala...
>
> Cheers,
> Jon
>

It's already hard enough to know the precedence of an operator without having alphanumeric operators possibly have different precedence to each other.  Remember that your operators can be implemented by others, for different things to what you expect.

9 == 4 and 5

2009/2/6 Russ Paielli <russ.paielli@gmail.com>

On Thu, Feb 5, 2009 at 5:25 PM, Jon Pretty <jon.pretty@sygneca.com> wrote:

I have to disagree with that for four reasons:

1. 'Or' in English means something different to ||.  It has a different
truth table.

Virtually everyone calls || the "or" operator. Martin Odersky call it "logical-or" in his Scala book. And he calls && the "logical-and" operator. How people can argue that "||" is a better name than "or" for logical-or escapes me. Ditto for &&.

I am not claiming that "natural language" is always preferable to mathematical notation. But in this case, it just seems so obviously clearer to me.

This is a minor syntax issue, of course, so I will drop it. Scala syntax is much better than Java syntax in other ways, so I guess I can live with "&&" and "||".

4. Scala has reasonably simple precedence rules, and to support 'and'
and 'or' we would either have to compromise in giving them the same
precedence or by complicating Scala's rules.

The precedence rules would have to be maintained, or it wouldn't be worth doing.

Hi Russ,

Russ Paielli wrote:
> Virtually everyone calls || the "or" operator. Martin Odersky call it
> "logical-or" in his Scala book. And he calls && the "logical-and"
> operator. How people can argue that "||" is a better name than "or" for
> logical-or escapes me. Ditto for &&.

Well, maybe I'm being pedantic. SQL, for example, prefers AND and OR.
And I don't know about other implementations, but Postgres uses || to
mean string concatenation. So there are alternative ways of looking at
this.

Scala also has operators | and & which have their own meaning for Ints
and a subtly different meaning when used with Booleans, but they provide
a useful parallel to || and && which isn't necessary in SQL.

> I am not claiming that "natural language" is always preferable to
> mathematical notation. But in this case, it just seems so obviously
> clearer to me.

Fair enough. This is obviously a subjective point... ;-)

> This is a minor syntax issue, of course, so I will drop it. Scala syntax
> is much better than Java syntax in other ways, so I guess I can live
> with "&&" and "||".

Yeah. Likewise, if Martin had chosen 'and' and 'or' to begin with, I'd
not care hugely, though would happily have had this hypothetical
discussion about changing them... ;-)

Just one more really really small point before I put this to bed:

Symbolic operators have a special feature in that you can use a
shorthand to update a variable, e.g.:

def containsTrue(cs : List[Boolean]) = {
var x = false
for(c <- cs) x ||= c
x
}

Cheers,
Jon

I did not use the word "nonsense," nor did I say anything about the relative precedence of "==" and "and."

All I meant is that, if "and" is used as an alias for "&&" it should have exactly the same precedence level. Ditto for "||" and "or." Think of it as a pre-processor just substituting "and" for "&&".

If Perl has different precedence levels for "&&" and "and", then they are not aliases, and that is a fundamentally different idea than what I am suggesting.

On Fri, Feb 6, 2009 at 8:36 AM, Robert Fischer <robert.fischer@smokejumperit.com> wrote:

I agree with that.  I just chafed at the assertion it was "nonsense" that "==" and "and" might have different precedence rules.

~~ Robert.

Jon Pretty wrote:

Hi Robert,

Robert Fischer wrote:

That's nonsense.  I note that Perl has different precedence rules for
"and" and "&&", which is used to great effect in that language.

But Perl is a very different language, with a different philosophy.
What's great for Perl isn't necessarily great for Scala...

Cheers,
Jon

Hi Russ,

>> 1. 'Or' in English means something different to ||. It
>> has a different truth table.
>
> Virtually everyone calls || the "or" operator.

Even if it is called the "or-operator" (slightly differs to your
quoting), it does not contradict the statement above about
the word "or" and the operator's logic.

> Martin Odersky call it "logical-or" in his Scala book. And he
> calls && the "logical-and" operator.

Well, but you must admit, that no one says:
"Tomorrow I will go to cinema logical or to McDonald's"

So the name for the operator seems indeed to be somewhat
different to the word "or", even if the latter is part of
the name. Trying to avoid confusion is exactly the reason
why Martin Odersky calls it the "logical-or" and not simply
"or". No?

> How people can argue that "||" is a
> better name than "or" for logical-or escapes me. Ditto for &&.

Are we mixing things here?: We are not talking about names, but
about symbols in expressions!

That is not nitpicking: It is not without reason that some
specifications or academic stuff have to define the clear meaning
of a word in the text's context right at the beginning of the
document when the word has also a common but not strict meaning in
spoken language.

(And: To indeed be a nitpicker now ;-) : Why should the words
even be english language, if things easily can be internationalised
and strictly formalised by using a clear symbol language ...
But no: I do not want to replace for/if/else/while/print or whatever
keywords/names we have, but for inline operators it makes sense).

KR
Det

Can you guys take this to scala-debate? It's best to confine annoying repetitive conversations about mathematical notation vs. natural language to there.

Particularly after the first hundred or so times the damn argument has broken out.

Dimitris Andreou wrote:
> O/H Russ Paielli έγραψε:
>>
>> > Call me dense, but their meaning is not as immediately clear to me
>> > as "and" and "or".
>> >
>> >
>> You are not dense, merely exhibiting your biases. Programming is
>> exactly the construction of a logical theorem after all (see C-H
>> Correspondence). Call it my biases if you like, but those symbols
>> are
>> recognisable by any person I know that has opened a book on
>> first-order logic.
>>
>>
>> If I've even opened such a book, it was long ago, and I suspect that
>> would be true for many programmers. Maybe that's unfortunate, but I'm
>> afraid it's true.
>>
>> Here's the problem I have. I know (or at least I think I know) that
>> those symbols mean "union" and "intersection." Where I have to think
>> a bit is in deciding which one means "and" and which means "or." On
>> the one hand, "union" could mean "both together," which sounds like
>> "and," but I guess it means "both true together," which means "or".
>> You get the idea.
> You opened the wrong book:
> http://letmegooglethatforyou.com/?q=first+order+logic+symbols
>
Oh snap!

Russ, you're thinking of the U and upsidedown-U symbols of set theory.