Comparing arraies

[Thomas 'PointedEars' Lahn]

<snip a lot of Lahn silliness>
*plonk*


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

 

[Michael Haufe (TNO)]

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.

 

[John G Harris]

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

 

[Michael Haufe (TNO)]

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.

 

[John G Harris]

*plonk*

***Plonkity plonk***

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

No, I have not.

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

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?

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 G Harris]

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).

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

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,
Mon, 30 Jan 2012 19:03:23, Thomas 'PointedEars' Lahn

*plonk*

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

 

[Michael Haufe (TNO)]

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.

I think this is more often something computer scientists do.

Based on what do you come to this conclusion?

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.

 

[John G Harris]

On Jan 31, 10:08 am, John G Harris <[email protected]> wrote:

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).

Based on what do you come to this conclusion?

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

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).

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.

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?

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

 

[Thomas 'PointedEars' Lahn]

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.

I have to disagree here. That the outcome of a programmatic function, given
the same arguments in the same order, is not necessarily the same always,
and there may be side-effects, is what distinguishes it from a programmatic
operator.

With such a programmatic operator, by definition the outcome must be the
same given the same operand(s) in the same order (or the operator becomes
ambiguous and useless). It is therefore an non-injective *mathematical*
function of the operands, from the sets that the operands may belong to, to
the set of the result type. But it is _not_ a function in the *syntax* of
any programming language, not even C++, because you *need to* tell the two
kinds apart to make sense of the syntax, i. e. to parse the program.


PointedEars

 

[Michael Haufe (TNO)]

I have to disagree here.  That the outcome of a programmatic function, given
the same arguments in the same order, is not necessarily the same always,
and there may be side-effects, is what distinguishes it from a programmatic
operator.

With such a programmatic operator, by definition the outcome must be the
same given the same operand(s) in the same order (or the operator becomes
ambiguous and useless).  It is therefore an non-injective *mathematical*
function of the operands, from the sets that the operands may belong to, to
the set of the result type.  But it is _not_ a function in the *syntax*of
any programming language, not even C++, because you *need to* tell the two
kinds apart to make sense of the syntax, i. e. to parse the program.

First off, I need to correct an error:

"...nor can all of the operators of the language."

s/can/are

Second, I'm not certain what you're disagreeing with exactly. Perhaps
I was ambiguous on something.

 

[Thomas 'PointedEars' Lahn]

First off, I need to correct an error:

"...nor can all of the operators of the language."

s/can/are

Second, I'm not certain what you're disagreeing with exactly. Perhaps
I was ambiguous on something.

I am disagreeing with you when you say that (all) operators in a programming
language ("programmatic operator(s)") are not true functions in the
mathematical sense (are not "mathematical function(s)"). I think they are,
because of the reasons I named above.


PointedEars

 

[Michael Haufe (TNO)]

I am disagreeing with you when you say that (all) operators in a programming
language ("programmatic operator(s)") are not true functions in the
mathematical sense (are not "mathematical function(s)"). I think they are,
because of the reasons I named above.

Ah, I see. I am specifically referring to JavaScript though and this
is what I am trying to say with that sentence:

let "x" represent a particular operator

let P(x) represent the claim "x is a function"

¬(∀x P(x))

which is equivalent to:

∃x ¬P(x)

I am not trying to say:

(∀x ¬P(x))

I hope that is clearer (and of course I hope Google Groups doesn't
mangle the quantifiers when I hit submit...).

But now the burden of proof is on me to prove that there exists an
operator which is not a function. Luckily for me and my laziness, this
work has already been done:

<https://drj11.wordpress.com/2008/07/11/javascript-using-numbers-as-
table-keys-considered-harmful/>

So I think x + "" would qualify if x is one of the values mentioned
in the link.

(I took a glance at the 5.1 spec and that note is still there.)

 

[John G Harris]

Its more complicated than it has to be because this is different from
what you said earlier:

"But every relation can be re-defined as a function from the inputs to
the set {true, false}."

If you misread what I've written then you are bound to be confused.

I still can't work out how you turned "inputs" into multiple functions.
Do you think I'm a fanatical exponent of currying and was describing a
cascade of curried functions?

No matter how you slice it, this statement is false.

Only when misinterpreting it.

As someone who works with Computer Scientists on a daily basis, this
has not been my experience at all, but if that is your impression so
be it.


The paradox doesn't exist in either. A trivial search will show this
to anyone truly interested (Axiom 3 in the former, and the use of
classes in the latter). If this fact isn't recognized, I see little
reason to continue.

There must be hundreds of text books that explain that Russell's paradox
hasn't been a paradox since the 1920's, but that the name persists.

The better books then go on to prove the theorem that replaces the
paradox, then prove that no function that is defined for *all* sets can
be represented, aka modelled, by a set or sets.

As I said. Such functions are dangerous and only for use by the very
cautious.

Which I've said more than once already.

But not at the point where you started this sub-thread.

I hope this is going somewhere...


Yes, we've come full circle to recognizing that it is arbitrary once
again.

You didn't make it very clear that you were arguing that the definition
of 'procedure' is arbitrary.

Because it does not have Referential transparency

Referential transparency, if you're using the same definition as in
Wikipedia, is certainly convenient for automatic theorem provers, but
doesn't stop you proving things about Date objects.

Nor does lack of it stop you writing correct code.

Using a broken language's arbitrary definition (or lack thereof) is
not a counterpoint to what a function is formally defined to be.

Ah, I see what it's all about. You are a language snob. You think that a
pure functional language is the only kind that is first class and
suitable for use by gentlemen.

You feel that languages used to control petrol pumps and implement sat
navs are working class and should be sneered at and are only fit for
common people.

Cobblers.

And another thought. How come Turing machines are modelled as a function
from system state to system state? Does that mean they are not
mathematical?


John

 

[Thomas 'PointedEars' Lahn]

Ah, I see. I am specifically referring to JavaScript though and this
is what I am trying to say with that sentence:

let "x" represent a particular operator

let P(x) represent the claim "x is a function"

¬(∀x P(x))

which is equivalent to:

∃x ¬P(x)

I am not trying to say:

(∀x ¬P(x))

I hope that is clearer (and of course I hope Google Groups doesn't
mangle the quantifiers when I hit submit...).

Your statement is clear now, as Google Groups positive-surprisingly kept the
Unicode characters intact.

But now the burden of proof is on me to prove that there exists an
operator which is not a function. Luckily for me and my laziness, this
work has already been done:

<https://drj11.wordpress.com/2008/07/11/javascript-using-numbers-as-
table-keys-considered-harmful/>

So I think x + "" would qualify if x is one of the values mentioned
in the link.

(I took a glance at the 5.1 spec and that note is still there.)

While the argument on number representation in the referred article might be
solid, a disturbing (but unfortunately common) amount of inaccuracies,
misnomers and misconceptions with regard to its environment can be found
there. This includes, but might not be limited to:

| […] in JavaScript all tables (associative arrays) are indexed by strings,
| and nothing else."

There are _no_ (built-in) "associative arrays" or "tables" in JavaScript
(the programming language). There are *objects* (as required by ES 5.1,
section 8.6, and corresponding sections of earlier Editions, of which
JavaScript is stated by the respective vendor [see below] to be an
implementation of). [How ECMAScript objects are to be implemented in a
programming language is _not_ specified.]

Objects are _not_ "indexed by string". Objects *have properties* with
String-type names, where with Array instances some property names with
numeric representation are special (ES 5.1, 15.4). [That particular
misconception might be a direct result of David Flanagan's listing `['…`]'
as "Array/index operator" in his "JavaScript: The Definitive Reference"
(IIRC).]

| […] when you go a[0] = thing, isn’t that indexing the table `a' with the
| number 0? Well, yes and no.

| So with (small) integer keys there are few possible problems.

`a[0]' is _not_ accessing a "table `a' with the number `0'" or by "integer
key". It is accessing a *property* of an *object* by the numeric
representation of its *property name*. Likewise, a["0"] is accessing the
property with the name "0" (for short: "the '0' property") of the object
*referred to* by the `a' property of the next matching object in the scope
chain (and potentially by other properties of other objects).

| Given the importance of arrays in JavaScript, […]

| When converting numbers to strings JavaScript requires that the
| parsimonious printing rule is applied.

| In principle a JavaScript implementation could make a different choice
| each time it performed the conversion.

| It would of course be insanity for an implementation to do that, but it’s
| still a loophole in the specification, and it should be closed.

The terms JavaScript and ECMAScript are used interchangeably there. But
JavaScript (1.1+) is (merely) *an implementation of* ECMAScript, originally
by (Brendan Eich of) the Netscape Communications Corporation, and later the
Mozilla Organization (Mozilla.org).

The article is speaking about "JavaScript implementations". However, there
are, in a manner of speaking, AFAIK only two production-quality JavaScript
implementations: SpiderMonkey (with improvements TraceMonkey and
JägerMonkey), and Rhino [1, 2]. [There is also a test implementation of
what was then called "JavaScript 2.0", itself an implementation of
Netscape's (Waldemar Horwat's) proposal for ECMAScript Edition 4, called
Epimetheus (as in Greek mythology) [2], see also [3].]

All other implementations that this concerns are *ECMAScript*
implementations. This is important because "varying between
implementations" with regard to the ECMAScript Language Specification means,
of course, "varying between *ECMAScript* implementations".

I will look into said argument later, but this needed pointing out right
now.


PointedEars
___________
[1] <https://developer.mozilla.org/en/JavaScript>
[2] <https://developer.mozilla.org/en/JavaScript_Language_Resources>
[3] "Google Tech Talk – Changes to JavaScript, Part 1: EcmaScript 5", with
Mark Miller, Waldemar Horwat, and Mike Samuel.
<

>

 

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:
| […] in JavaScript all tables (associative arrays) are indexed by
| [strings, and nothing else."

There are _no_ (built-in) "associative arrays" or "tables" in JavaScript
(the programming language). There are *objects* (as required by ES 5.1,
section 8.6, and corresponding sections of earlier Editions, of which
JavaScript is stated by the respective vendor [see below] to be an
implementation of). [How ECMAScript objects are to be implemented in a
programming language is _not_ specified.]

Objects are _not_ "indexed by string". Objects *have properties* with
String-type names, where with Array instances some property names with
numeric representation are special (ES 5.1, 15.4). [That particular
misconception might be a direct result of David Flanagan's listing `['…`]'
as "Array/index operator" in his "JavaScript: The Definitive Reference"
(IIRC).]

I meant "JavaScript: The Definitive Guide" as mentioned in the FAQ. The
relevant section of the Sixth(?) Edition of that book has been reviewed
here (by mere chance) by Richard Cornford and criticised accordingly, while
David Flanagan (by rare appearance here) was not convinced in the following
discussion that this listing could be positively harmful. I might be able
to find the Message-ID later if anyone is interested.

 

[John G Harris]

But now the burden of proof is on me to prove that there exists an
operator which is not a function. Luckily for me and my laziness, this
work has already been done:

<https://drj11.wordpress.com/2008/07/11/javascript-using-numbers-as-
table-keys-considered-harmful/>

So I think x + "" would qualify if x is one of the values mentioned
in the link.

That's not a good example. That's just a case of a function being partly
specified by the manufacturer, who might regard it as a commercial
secret.

The example you are looking for is the function that returns the current
time. It returns different values at different times, so lacks any
Referential transparency.

John

 

[Michael Haufe (TNO)]

On Wed, 1 Feb 2012 at 18:22:41, in comp.lang.javascript, Michael Haufe

(TNO) wrote:

[...]
So I think   x + ""  would qualify if x is one of the values mentioned
in the link.

That's not a good example. That's just a case of a function being partly
specified by the manufacturer, who might regard it as a commercial
secret.

You can't be serious...

The example you are looking for is the function that returns the current
time. It returns different values at different times, so lacks any
Referential transparency.

The example I was looking for is a JavaScript "operator" that is not
R.T.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris

The example you are looking for is the function that returns the current
time. It returns different values at different times, so lacks any
Referential transparency.

I know of a constructor which does that; but is it a function? Of
course, it can be put into an undoubted function. If one's code is
quick enough, it can return the same result repeatedly at slightly
different times.

Math.random() will almost always return a different result for every
call, until after 2^n calls, where n is not necessarily as large as
should be hoped for.

function AllDiff() { return +new Date() + String(Math.random()) }

should never repeat itself, unless Math.random is either unexpectedly
good or bad, or the computer is prodigiously fast.

 

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris


I know of a constructor which does that; but is it a function?

<snip>

I was thinking of
(new Date()).getTime()
which is a function call, but of a function with an unusual name.

John