Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #10604 > unrolled thread

Comparing arraies

Back to article view | Back to comp.lang.javascript

Contents

  Comparing arraies Archos <raul.san@sent.com> - 2012-01-26 07:23 -0800
    Re: Comparing arraies Martin Honnen <mahotrash@yahoo.de> - 2012-01-26 18:29 +0100
      Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-26 19:50 +0100
        Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-26 19:54 +0100
          Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-27 16:49 +0000
            Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-27 18:41 +0100
              Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-28 11:28 +0000
                Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-28 21:17 +0100
                  Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-29 14:55 +0000
                    Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-29 17:13 +0100
                      Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-30 15:27 +0000
                        Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-30 19:03 +0100
                          Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-31 15:07 +0000
                          Re: Comparing arraies Dr J R Stockton <reply1205@merlyn.demon.co.uk> - 2012-01-31 18:51 +0000
                        Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-30 12:01 -0800
                          Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-31 11:06 +0000
                            Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-31 06:08 -0800
                              Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-01-31 16:08 +0000
                                Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-31 18:32 -0800
                                  Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-02-01 17:02 +0000
                                    Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-02-01 10:07 -0800
                                      Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-02-02 15:10 +0000
                                        Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-02-02 11:16 -0800
                                          Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-02-07 15:14 +0000
                                  Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-01 21:45 +0100
                                    Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-02-01 13:07 -0800
                                      Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-01 23:44 +0100
                                        Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-02-01 18:22 -0800
                                          Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-02 23:09 +0100
                                            Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-03 01:47 +0100
                                          Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-02-04 10:34 +0000
                                            Re: Comparing arraies Dr J R Stockton <reply1205@merlyn.demon.co.uk> - 2012-02-05 16:47 +0000
                                              Re: Comparing arraies John G Harris <john@nospam.demon.co.uk> - 2012-02-06 15:21 +0000
                                            Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-02-04 23:37 -0800
      Re: Comparing arraies Denis McMahon <denismfmcmahon@gmail.com> - 2012-01-26 23:08 +0000
        Re: Comparing arraies Denis McMahon <denismfmcmahon@gmail.com> - 2012-01-27 01:42 +0000
          Re: Comparing arraies Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-27 11:41 +0100
        Re: Comparing arraies Gene Wirchenko <genew@ocis.net> - 2012-01-26 16:24 -0800
          Re: Comparing arraies "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-01-27 08:50 +0000
        Re: Comparing arraies Dr J R Stockton <reply1204@merlyn.demon.co.uk> - 2012-01-27 21:07 +0000
          Re: Comparing arraies "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-01-28 13:45 +0000
    Re: Comparing arraies "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-26 16:21 -0800
      Re: Comparing arraies Martin Honnen <mahotrash@yahoo.de> - 2012-01-27 16:00 +0100

Page 1 of 3  [1] 2 3  Next page →

#10604 — Comparing arraies

How to know if 2 arraies are equal? I was expecting that it could be
checked so:

>>> var array1 = [1,2,3,4], array2 = [1,2,3,4];
>>> if (array1 === array2) { console.log("array1 and array2 are equal"); }

Since the comparing of strings or integers works:

var a = "2", b = "2";
if (a === b) { console.log("a == b"); }

[toc] | [next] | [standalone]

#10606

Archos wrote:
> How to know if 2 arraies are equal? I was expecting that it could be
> checked so:
>
>>>> var array1 = [1,2,3,4], array2 = [1,2,3,4];
>>>> if (array1 === array2) { console.log("array1 and array2 are equal"); }
>
> Since the comparing of strings or integers works:
>
> var a = "2", b = "2";
> if (a === b) { console.log("a == b"); }

No, for objects (and arrays are objects) the identity is checked, no 
comparison of properties or elements is done.
So with e.g.

var a1, a2;

a1 = a2 = [1, 2, 3, 4];

a1 == a2

you get true as the two variables hold references to the same array object.


If you want to compare the elements you will need to define and 
implement your own comparison function I think
-- 

	Martin Honnen --- MVP Data Platform Development
	http://msmvps.com/blogs/martin_honnen/

[toc] | [prev] | [next] | [standalone]

#10607

Martin Honnen wrote:

> Archos wrote:
>> How to know if 2 arraies are equal? I was expecting that it could be
>> checked so:
>>>>> var array1 = [1,2,3,4], array2 = [1,2,3,4];
>>>>> if (array1 === array2) { console.log("array1 and array2 are equal"); }
>>
>> Since the comparing of strings or integers works:
>>
>> var a = "2", b = "2";
>> if (a === b) { console.log("a == b"); }
> 
> No, for objects (and arrays are objects) the identity is checked, no
> comparison of properties or elements is done.
> So with e.g.
> 
> var a1, a2;
> 
> a1 = a2 = [1, 2, 3, 4];
> 
> a1 == a2
> 
> you get true as the two variables hold references to the same array
> object.

Correct.  That example might be confusing, though.

> If you want to compare the elements you will need to define and
> implement your own comparison function I think

Not necessarily.  One way without a custom comparison function that works 
for *simple* cases like this is to compare the string representations of the 
Array instances, which are (without overwriting the toString() method) the 
comma-separated string representations of the corresponding array's 
elements:

  /*  "1,2,3,4" == "1,2,3,4"  */
  a1.toString() == a2.toString()

or

  String(a1) == String(a2)

or

  ("" + a1) == ("" + a2)

That is, those two arrays are considered equal if the string representations 
of their elements are the same and occur in the same order (if we assume 
that both instances use the same toString() method).

The caveat is that the string representations of elements can be the same, 
although the elements are different.  Consider this:

  var o = {foo: 'bar'};
  var o2 = {bar: 'baz'};

  /* "[object Object]" == "[object Object]" */
     [o].toString()    == [o2].toString()

Instead of the `==' operator, the `===' operator may be used as well, but it 
is neither supposed to add efficiency nor would it add expressive power 
(both arguments are of the same type), while it certainly reduces the 
backwards-compatibility of the entire code.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#10608

Thomas 'PointedEars' Lahn wrote:

> Instead of the `==' operator, the `===' operator may be used as well, but
> it is neither supposed to add efficiency nor would it add expressive power
> (both arguments are of the same type), while it certainly reduces the
> backwards-compatibility of the entire code.

_Operands_, not arguments.  We are not talking about a function, but about 
an operator.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#10647

On Thu, 26 Jan 2012 at 19:54:19, in comp.lang.javascript, Thomas 
'PointedEars' Lahn wrote:
>Thomas 'PointedEars' Lahn wrote:
>
>> Instead of the `==' operator, the `===' operator may be used as well, but
>> it is neither supposed to add efficiency nor would it add expressive power
>> (both arguments are of the same type), while it certainly reduces the
>> backwards-compatibility of the entire code.
>
>_Operands_, not arguments.  We are not talking about a function, but about
>an operator.

Operators are also functions. How else would + be defined?

   John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10653

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Instead of the `==' operator, the `===' operator may be used as well,
>>> but it is neither supposed to add efficiency nor would it add expressive
>>> power (both arguments are of the same type), while it certainly reduces
>>> the backwards-compatibility of the entire code.
>>
>>_Operands_, not arguments.  We are not talking about a function, but about
>>an operator.
> 
> Operators are also functions. How else would + be defined?

You are confusing functions with algorithms.  The subject of discussion here 
is the syntax of the programming language, not the implementation of the 
syntax.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#10664

On Fri, 27 Jan 2012 at 18:41:05, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Instead of the `==' operator, the `===' operator may be used as well,
>>>> but it is neither supposed to add efficiency nor would it add expressive
>>>> power (both arguments are of the same type), while it certainly reduces
>>>> the backwards-compatibility of the entire code.
>>>
>>>_Operands_, not arguments.  We are not talking about a function, but about
>>>an operator.
>>
>> Operators are also functions. How else would + be defined?
>
>You are confusing functions with algorithms.  The subject of discussion here
>is the syntax of the programming language, not the implementation of the
>syntax.

1. The syntax specification calls new a keyword and + a punctuator Their
operands/arguments are called expressions. So we aren't discussing the
syntax.

2. In a language where you write add(2,3) what would you call 2 and 3 :
operands or arguments?

All that's special about operators is that they are often invoked using
a non-general format, and they tend to be built into the language.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10677

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Instead of the `==' operator, the `===' operator may be used as well,
>>>>> but it is neither supposed to add efficiency nor would it add
>>>>> expressive power (both arguments are of the same type), while it
>>>>> certainly reduces the backwards-compatibility of the entire code.
>>>> _Operands_, not arguments.  We are not talking about a function, but
>>>> about an operator.
>>> Operators are also functions. How else would + be defined?
>> You are confusing functions with algorithms.  The subject of discussion
>> here is the syntax of the programming language, not the implementation of
>> the syntax.
> 
> 1. The syntax specification calls new a keyword and + a punctuator

No, the _lexical grammar_ of ECMAScript (Ed. 5.1) says that `new' is a 
keyword (section 7.6.1.1), and that `+' is a punctuator (section 7.7).

The _syntactic grammar_ calls `new' and `+' operators, as in "11.2.2 The 
`new' Operator" and "11.6.1 The Addition operator (+)".

"Productions of the lexical and RegExp grammars are distinguished by having 
two colons “::” as separating punctuation. […]" (section 5.1.2, last 
paragraph).

> Their operands/arguments are called expressions.

Correct for "operands", in the syntactic grammar.  Operators do not have 
arguments; functions (and by extension to OOP, methods) have them.

> So we aren't discussing the syntax.

Yes, we are.  `+' is an operator in the syntax of ECMAScript; it has 
operands.

> 2. In a language where you write add(2,3) what would you call 2 and 3 :
> operands or arguments?

I get it now: you are trolling again.

> All that's special about operators is that they are often invoked using
> a non-general format, and they tend to be built into the language.

Wrong.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#10735

On Sat, 28 Jan 2012 at 21:17:21, in comp.lang.javascript, Thomas 
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Instead of the `==' operator, the `===' operator may be used as well,
>>>>>> but it is neither supposed to add efficiency nor would it add
>>>>>> expressive power (both arguments are of the same type), while it
>>>>>> certainly reduces the backwards-compatibility of the entire code.
>>>>> _Operands_, not arguments.  We are not talking about a function, but
>>>>> about an operator.
>>>> Operators are also functions. How else would + be defined?
>>> You are confusing functions with algorithms.  The subject of discussion
>>> here is the syntax of the programming language, not the implementation of
>>> the syntax.
>>
>> 1. The syntax specification calls new a keyword and + a punctuator
>
>No, the _lexical grammar_ of ECMAScript (Ed. 5.1) says that `new' is a
>keyword (section 7.6.1.1), and that `+' is a punctuator (section 7.7).

So the terms 'keyword' and 'punctuator' are now available for use in 
higher layers of the language's syntax specification.

E.g When saying that identifiers exclude keywords.


>The _syntactic grammar_ calls `new' and `+' operators, as in "11.2.2 The
>`new' Operator" and "11.6.1 The Addition operator (+)".

I'm sure you're going to find it quite difficult to prove that a section 
title is normative. If you look closely you'll find that the text of 
such sections doesn't say which symbols comprise the 'operator'.
E.g As in

"11.1.6 The Grouping Operator
  The production PrimaryExpression : ( Expression ) is evaluated as follows:"
...

The word 'operator' is used informally in the standard.


>"Productions of the lexical and RegExp grammars are distinguished by having
>two colons “::” as separating punctuation. […]" (section 5.1.2, last
>paragraph).
>
>> Their operands/arguments are called expressions.
>
>Correct for "operands", in the syntactic grammar.  Operators do not have
>arguments; functions (and by extension to OOP, methods) have them.

OOP, indeed.

In C++, the user-defined member function (aka method)

   Thing operator+ (Thing t, int) { ... }

will cause

   Thing a, b;
   b = a + 1;

to compile and execute correctly.

FTR, this is not off-topic : it is entirely possible that one day one of 
the javascript languages will allow operator overloading, maybe even 
ECMAScript itself.


>> So we aren't discussing the syntax.
>
>Yes, we are.  `+' is an operator in the syntax of ECMAScript; it has
>operands.

>> 2. In a language where you write add(2,3) what would you call 2 and 3 :
>> operands or arguments?
>
>I get it now: you are trolling again.

See above.


>> All that's special about operators is that they are often invoked using
>> a non-general format, and they tend to be built into the language.
>
>Wrong.

Tell us what feature an operator has that is not listed there.

Or are you claiming all those university text books that define + as a 
function are somehow wrong.


If at the beginning you'd said that "operand is the more usual name" 
then there would have been no argument.

   John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10736

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> John G Harris wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> Instead of the `==' operator, the `===' operator may be used as
>>>>>>> well, but it is neither supposed to add efficiency nor would it add
>>>>>>> expressive power (both arguments are of the same type), while it
>>>>>>> certainly reduces the backwards-compatibility of the entire code.
>>>>>> _Operands_, not arguments.  We are not talking about a function, but
>>>>>> about an operator.
>>>>> Operators are also functions. How else would + be defined?
>>>> You are confusing functions with algorithms.  The subject of discussion
>>>> here is the syntax of the programming language, not the implementation
>>>> of the syntax.
>>>
>>> 1. The syntax specification calls new a keyword and + a punctuator
>>
>> No, the _lexical grammar_ of ECMAScript (Ed. 5.1) says that `new' is a
>> keyword (section 7.6.1.1), and that `+' is a punctuator (section 7.7).
> 
> So the terms 'keyword' and 'punctuator' are now available for use in
> higher layers of the language's syntax specification.

Not "now".  Those terms are far from new in the history of the ECMAScript 
Language Specification.  If only you would get yourself informed before you 
posted …

> E.g When saying that identifiers exclude keywords.

That is self-evident.  A programming language where identifiers could form a 
non-empty intersecting set with keywords would not be overly useful.  Only 
recently (Ed. 5) ECMAScript has started allowing reserved words in the dot 
property accessor notation, because in this evaluation context we *know* 
that a keyword's meaning is not intended.  It complicates parsing, though, 
as there is an additional /IdentifierName/  production now.

>>The _syntactic grammar_ calls `new' and `+' operators, as in "11.2.2 The
>>`new' Operator" and "11.6.1 The Addition operator (+)".
> 
> I'm sure you're going to find it quite difficult to prove that a section
> title is normative.

I do not have to prove that, for it is common knowledge that the section of 
a technical specification is normative unless marked differently.

> If you look closely you'll find that the text of
> such sections doesn't say which symbols comprise the 'operator'.
> E.g As in
> 
> "11.1.6 The Grouping Operator
>   The production PrimaryExpression : ( Expression ) is evaluated as
>   follows:"
> ...
> 
> The word 'operator' is used informally in the standard.

No, it is not.  In this case, it is apparent that the /Expression/ is the 
(single) operand to the Grouping Operator.

>>> Their operands/arguments are called expressions.
>>
>> Correct for "operands", in the syntactic grammar.  Operators do not have
>> arguments; functions (and by extension to OOP, methods) have them.
> 
> OOP, indeed.
> 
> In C++, the user-defined member function (aka method)

I am aware of operator overloading (e. g. in C++), but we are not discussing 
those languages or possible implementations of ECMAScript written in those 
languages.  We are discussing the syntax of ECMAScript (implementations).  
And again, in the syntax of ECMAScript, `+' is an operator; it has operands, 
not arguments.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#10790

On Sun, 29 Jan 2012 at 17:13:01, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:

  <snip a lot of Lahn silliness>
>I am aware of operator overloading (e. g. in C++), but we are not discussing
>those languages or possible implementations of ECMAScript written in those
>languages.  We are discussing the syntax of ECMAScript (implementations).
>And again, in the syntax of ECMAScript, `+' is an operator; it has operands,
>not arguments.

Attention! Thomas has forbidden the Mozilla team to contemplate adding
operator overloading in *any* future version of JavaScript ... because
it destroys his case.

Wikipedia and an online dictionary agree with me : operators are just
functions it's convenient to distinguish from other functions.

<http://foldoc.org/operator>
<http://en.wikipedia.org/wiki/Operator_(programming)>

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10794

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
> 
>   <snip a lot of Lahn silliness>

*plonk*

>> I am aware of operator overloading (e. g. in C++), but we are not
>> discussing those languages or possible implementations of ECMAScript
>> written in those
>> languages.  We are discussing the syntax of ECMAScript (implementations).
>> And again, in the syntax of ECMAScript, `+' is an operator; it has
>> operands, not arguments.
> 
> Attention! Thomas has forbidden the Mozilla team to contemplate adding
> operator overloading in *any* future version of JavaScript ... because
> it destroys his case.

No, I have not.
 
> Wikipedia and an online dictionary agree with me : operators are just
> functions it's convenient to distinguish from other functions.
> 
> <http://foldoc.org/operator>

And now look up "function" there, stupid.

> <http://en.wikipedia.org/wiki/Operator_(programming)>

That is a reference (a doubtful one at that), but not a proof for your 
statement.  In fact, it happens to confirm what I have said (although 
citations are lacking).

Troll away.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#10888

On Mon, 30 Jan 2012 at 19:03:23, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>
>>   <snip a lot of Lahn silliness>
>
>*plonk*

 ***Plonkity plonk***

I could have said Troll! or Newbie! or Idiot! as Thomas would do, but I
said silly; it's more polite.


>>> I am aware of operator overloading (e. g. in C++), but we are not
>>> discussing those languages or possible implementations of ECMAScript
>>> written in those
>>> languages.  We are discussing the syntax of ECMAScript (implementations).
>>> And again, in the syntax of ECMAScript, `+' is an operator; it has
>>> operands, not arguments.
>>
>> Attention! Thomas has forbidden the Mozilla team to contemplate adding
>> operator overloading in *any* future version of JavaScript ... because
>> it destroys his case.
>
>No, I have not.

"We are discussing the syntax of ECMAScript" says otherwise.


>> Wikipedia and an online dictionary agree with me : operators are just
>> functions it's convenient to distinguish from other functions.
>>
>> <http://foldoc.org/operator>
>
>And now look up "function" there, stupid.

I look up 'function' in Foldoc and find it says what it ought to say.
What point are you trying to make?


>> <http://en.wikipedia.org/wiki/Operator_(programming)>
>
>That is a reference (a doubtful one at that), but not a proof for your
>statement.

'Proof'? Who said 'proof'? You must be hoping to get the job of
propaganda minister. What I said was that here are two sources that
agree with me.


>In fact, it happens to confirm what I have said (although
>citations are lacking).

Again you'll have to explain. What I see are almost the same words I
used.


>Troll away.

Silly Thomas.


  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10903

In comp.lang.javascript message <1353630.WGnKmheAe9@PointedEars.de>,
Mon, 30 Jan 2012 19:03:23, Thomas 'PointedEars' Lahn
<PointedEars@web.de> posted:

>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>
>>   <snip a lot of Lahn silliness>
>
>*plonk*

Plonking someone and continuing to reply to their article is unusually
childish, even for you.

-- 
(c) John Stockton, nr London UK.  ???@merlyn.demon.co.uk  Turnpike v6.05  MIME.
 Web  <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
     Check boilerplate spelling -- error is a public sign of incompetence.
    Never fully trust an article from a poster who gives no full real name.

[toc] | [prev] | [next] | [standalone]

#10803

On Jan 30, 9:27 am, John G Harris <j...@nospam.demon.co.uk> wrote:

> Wikipedia and an online dictionary agree with me : operators are just
> functions it's convenient to distinguish from other functions.

An operator is not necessarily a function in the strict mathematical
sense. It COULD be a function. For example:

y^2 + 3x = 6

Is not a function, but a relation. Since this is JavaScript we are
talking about and not a Logic Language, Functional language, nor a
Proof assistant, it is generally understood that a "function" really
means "procedure" with potential side-effects.

[toc] | [prev] | [next] | [standalone]

#10883

On Mon, 30 Jan 2012 at 12:01:28, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Jan 30, 9:27 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
>> Wikipedia and an online dictionary agree with me : operators are just
>> functions it's convenient to distinguish from other functions.
>
>An operator is not necessarily a function in the strict mathematical
>sense. It COULD be a function. For example:
>
>y^2 + 3x = 6
>
>Is not a function, but a relation.

But every relation can be re-defined as a function from the inputs to
the set {true, false}. This is what C, etc, do with the == 'relation' :
it's a function that returns a boolean value.


>Since this is JavaScript we are
>talking about and not a Logic Language, Functional language, nor a
>Proof assistant, it is generally understood that a "function" really
>means "procedure" with potential side-effects.

Surely most descriptions of procedures say that they are functions with
no return value (void functions in C terminology).


  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10887

On Jan 31, 5:06 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
> But every relation can be re-defined as a function from the inputs to
> the set {true, false}. This is what C, etc, do with the == 'relation' :
> it's a function that returns a boolean value.

Not every relation is a predicate, but I think I understand what you
are trying to say.

This is where Mathematicians and Physicists tend to get sloppy. When
it comes to the hand-manipulation of symbols, Math is more an
impressionistic language than a rigorous one. Generally you'll notice
that the common practice is to treat single element sets and the
single element of that set as the same thing, where clearly they are
not and do not share the same operations:

sqrt 9  != sqrt {9}

One cannot take the sqrt of a set. sqrt is not defined in the Algebra
of Sets.

So while we could step back and just say every function is simply:

f : Set -> Set

That lacks an enormous amount of expressiveness.

> Surely most descriptions of procedures say that they are functions with
> no return value (void functions in C terminology).

But they MIGHT return a value. They could also launch the missiles as
a side-effect.  They may not return the same value twice when called
twice. They could also throw exceptions, or a number of other things.
Regardless of whether the word "function" is used as its name or as
part of the description, they clearly are not the same "function" that
has been used mathematically or in PLs with better foundations. In
most PLs the word "function" is more impressionistic than something of
substance.

[toc] | [prev] | [next] | [standalone]

#10889

On Tue, 31 Jan 2012 at 06:08:57, in comp.lang.javascript, Michael Haufe 
(TNO) wrote:
>On Jan 31, 5:06 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>>
>> But every relation can be re-defined as a function from the inputs to
>> the set {true, false}. This is what C, etc, do with the == 'relation' :
>> it's a function that returns a boolean value.
>
>Not every relation is a predicate, but I think I understand what you
>are trying to say.

I'll say it in more detail. The main, or only, part of a relation is 
represented by a set of tuples, each with the same number of elements. 
The elements in a tuple are the arguments or operands, whichever you 
prefer to say. If a tuple is in the set then the relation is true for 
those elements, if not then it's false. There is obviously a function 
from tuples to bool that gives the same answer.


>This is where Mathematicians and Physicists tend to get sloppy. When
>it comes to the hand-manipulation of symbols, Math is more an
>impressionistic language than a rigorous one.

Professional mathematicians are usually rigorous, but they have an 
annoying habit of switching to shorthand notation without saying so. I 
suspect it's because they do it to students and expect them to work it 
out for themselves, and provide the full gruesome working just once, 
yawn, yawn.


>Generally you'll notice
>that the common practice is to treat single element sets and the
>single element of that set as the same thing, where clearly they are
>not and do not share the same operations:
>
>sqrt 9  != sqrt {9}
>
>One cannot take the sqrt of a set. sqrt is not defined in the Algebra
>of Sets.

I think this is more often something computer scientists do.


>So while we could step back and just say every function is simply:
>
>f : Set -> Set
>
>That lacks an enormous amount of expressiveness.

You should also use the partial function symbol, something like |-> . 
Functions defined for all sets are very dangerous. (They can't be 
represented by sets for a start).


>> Surely most descriptions of procedures say that they are functions with
>> no return value (void functions in C terminology).
>
>But they MIGHT return a value. They could also launch the missiles as
>a side-effect.  They may not return the same value twice when called
>twice. They could also throw exceptions, or a number of other things.
>Regardless of whether the word "function" is used as its name or as
>part of the description, they clearly are not the same "function" that
>has been used mathematically or in PLs with better foundations. In
>most PLs the word "function" is more impressionistic than something of
>substance.

To put it crudely, a procedure doesn't have a return statement, so it 
can't 'return' a value.

If you want to describe side effects then you have to say that the 
function is from system state to system state. The input state includes 
places to hold the arguments, and places holding anything else that 
affects the result. The output state includes a place to hold the 
result, if any, and places holding the consequences of side effects, 
including the effects of an exception.

Defining just the arguments and result is only a part of the complete 
description, but an important part of course.

As for launching missiles when your sqrt function goes wrong, the output 
state simply has more empty missile silos.


   John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#10907

On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Tue, 31 Jan 2012 at 06:08:57, in comp.lang.javascript, Michael Haufe
>
> (TNO) wrote:
> >On Jan 31, 5:06 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
> >> But every relation can be re-defined as a function from the inputs to
> >> the set {true, false}. This is what C, etc, do with the == 'relation' :
> >> it's a function that returns a boolean value.
>
> >Not every relation is a predicate, but I think I understand what you
> >are trying to say.
>
> I'll say it in more detail. The main, or only, part of a relation is
> represented by a set of tuples, each with the same number of elements.
> The elements in a tuple are the arguments or operands, whichever you
> prefer to say. If a tuple is in the set then the relation is true for
> those elements, if not then it's false. There is obviously a function
> from tuples to bool that gives the same answer.


A relation can be redefined using multiple functions, and you can
place those functions into a set. You can then define a function from
that set to the set of booleans. This does not make the latter
function the same as the original relation.


> >One cannot take the sqrt of a set. sqrt is not defined in the Algebra
> >of Sets.
>
> I think this is more often something computer scientists do.

Based on what do you come to this conclusion?

> >So while we could step back and just say every function is simply:
>
> >f : Set -> Set
>
> >That lacks an enormous amount of expressiveness.
>
> You should also use the partial function symbol, something like |-> .
> Functions defined for all sets are very dangerous. (They can't be
> represented by sets for a start).

I suggest glancing at Axiomatic Set Theory then.

> To put it crudely, a procedure doesn't have a return statement, so it
> can't 'return' a value.

Since procedures can branch, and can branch back to the caller, it is
possible to "return". There are versions of SQL with "return"
statements in procedures for example.

> If you want to describe side effects then you have to say that the
> function is from system state to system state. The input state includes
> places to hold the arguments, and places holding anything else that
> affects the result. The output state includes a place to hold the
> result, if any, and places holding the consequences of side effects,
> including the effects of an exception.

That is one possible method, but neither the 'function' of JavaScript
or any other language you've mentioned do this. To repeat what has
been said earlier: it does not matter what word is used in the
language, 'function' is not a true function in the mathematical sense,
nor can all of the operators of the language.


> As for launching missiles when your sqrt function goes wrong, the output
> state simply has more empty missile silos.

And since the language doesn't represent this in its syntax or
semantics, such "functions" are still not.

[toc] | [prev] | [next] | [standalone]

#10978

On Tue, 31 Jan 2012 at 18:32:35, in comp.lang.javascript, Michael Haufe 
(TNO) wrote:
>On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:

   <snip>
>A relation can be redefined using multiple functions, and you can
>place those functions into a set. You can then define a function from
>that set to the set of booleans. This does not make the latter
>function the same as the original relation.

I don't know why you think it's so complicated. You have a function 
that, given (2, 3) returns true if 2 < 3, false if not, and the same 
rule for all other pairs of numbers. That's all.

When you do
   var a = 2 < 3;
the language is using the functional version of < (with extra rules for 
NaN and other peculiar values).


>> >One cannot take the sqrt of a set. sqrt is not defined in the Algebra
>> >of Sets.
>>
>> I think this is more often something computer scientists do.
>
>Based on what do you come to this conclusion?

It's my impression based on reading books, articles, and papers.


>> >So while we could step back and just say every function is simply:
>>
>> >f : Set -> Set
>>
>> >That lacks an enormous amount of expressiveness.
>>
>> You should also use the partial function symbol, something like |-> .
>> Functions defined for all sets are very dangerous. (They can't be
>> represented by sets for a start).
>
>I suggest glancing at Axiomatic Set Theory then.

Which do you prefer : ZF or VNB? What I said is true in both.

(Hint: Russel's paradox).


>> To put it crudely, a procedure doesn't have a return statement, so it
>> can't 'return' a value.
>
>Since procedures can branch, and can branch back to the caller, it is
>possible to "return". There are versions of SQL with "return"
>statements in procedures for example.

The definition of procedure and function varies from language to 
language. In Pascal they are keywords. A procedure must not have a 
return value, a function must. In C and relatives it's common to use 
procedure for functions that do not return a value (void functions).

An ECMAScript function cannot be flagged as void, but if it doesn't 
return a value or always returns undefined then we can call it a 
procedure if we wish. But if it causes arguments then we mustn't use the 
word.


>> If you want to describe side effects then you have to say that the
>> function is from system state to system state. The input state includes
>> places to hold the arguments, and places holding anything else that
>> affects the result. The output state includes a place to hold the
>> result, if any, and places holding the consequences of side effects,
>> including the effects of an exception.
>
>That is one possible method, but neither the 'function' of JavaScript
>or any other language you've mentioned do this. To repeat what has
>been said earlier: it does not matter what word is used in the
>language, 'function' is not a true function in the mathematical sense,
>nor can all of the operators of the language.

Have a look at ECMA 262 v5.1, section 15.9.5.27 where it defines a Date 
object's setTime method. The method has side effects. The method's 
definition describes the changes to the system state outside the return 
value.

In what way is this not mathematical?


>> As for launching missiles when your sqrt function goes wrong, the output
>> state simply has more empty missile silos.
>
>And since the language doesn't represent this in its syntax or
>semantics, such "functions" are still not.

It does in C++. It's called 'undefined behaviour'. It's what happens if 
you break a rule that the compiler can't catch. E.g if you break a 
precondition.


   John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web