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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#10982

On Feb 1, 11:02 am, John G Harris <j...@nospam.demon.co.uk> wrote:

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

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}."

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


> >Based on what do you come to this conclusion?
>
> It's my impression based on reading books, articles, and papers.

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.

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

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.


> The definition of procedure and function varies from language to
> language.

Which I've said more than once already.

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

I hope this is going somewhere...

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

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

> 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?

Because it does not have Referential transparency

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

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

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

#11139

On Wed, 1 Feb 2012 at 10:07:23, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Feb 1, 11:02 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
>> 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.
>
>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.


>> >Based on what do you come to this conclusion?
>>
>> It's my impression based on reading books, articles, and papers.
>
>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.
>
>> >> 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).
>
>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.


>> The definition of procedure and function varies from language to
>> language.
>
>Which I've said more than once already.

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


>> 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).
>
>I hope this is going somewhere...
>
>> 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.
>
>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.


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


>> 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.
>
>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
-- 
John Harris

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

#11213

On Feb 2, 9:10 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Wed, 1 Feb 2012 at 10:07:23, in comp.lang.javascript, Michael Haufe
>
> (TNO) wrote:

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

Something like that. If that was not what you were saying, very well
then.

> Do you think I'm a fanatical exponent of currying and was describing a
> cascade of curried functions?

You say that like its a bad thing

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

I'm sure Wikipedia is close enough. It is not only convenient for
theorem provers, and it does make it much easier without question.

> 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're mostly right. I don't believe the "snob" remark is accurate,
nor the "suitable for use by gentlemen." bit. Of course it seems to me
that at this point you seem more content in attacking my character
than anything else. I won't lose sleep over it though.

> 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 you've used JavaScript for such things have you? I didn't know
you had such a intuition into what I feel or think.

> 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?

I think the best answer to your question is another question.

Since everything you do is dictated by the laws of physics, are you
not mathematical? If you write down on a piece of paper "7 + 3 = 1",
is that not mathematical?

Hopefully from this you can recognize that there is a difference in
our usages of the word "mathematical"

To quote Meertens[1989] : "Program construction is a mathematical
activity. By 'mathematical activity' is not
meant: the actual practice of professional mathematicians, but:
establishing properties
of formal objects with perfect certainty..."

But you should probably ignore that quote, since he's a snob by your
definition, and much more of one than I currently am.

I've grown quite tired of this exchange, as it seems to have devolved
into little more than name-calling and has already drifted quite far
from the original topic.

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

#11453

On Thu, 2 Feb 2012 at 11:16:50, in comp.lang.javascript, Michael Haufe
(TNO) wrote:

  <snip>
>Of course it seems to me
>that at this point you seem more content in attacking my character
>than anything else.
  <snip>

I'm merely adopting, temporarily, your style of argument.


Have you now understood the dangers of defining functions on all sets ?

  John
-- 
John Harris

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

#10991

Michael Haufe (TNO) wrote:

> On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>> 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.

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
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

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

#10993

On Feb 1, 2:45 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Michael Haufe (TNO) wrote:
> > On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> >> 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.
>
> 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.

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

#10994

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>> >> 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.
>>
>> 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.

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
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#10999

On Feb 1, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

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

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

#11168

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> 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...).

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.
    <http://www.youtube.com/watch?v=Kq4FpMe6cRs>
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

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

#11171

Thomas 'PointedEars' Lahn wrote:

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

-- 
PointedEars

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

#11189

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

  <snip>
>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
-- 
John Harris

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

#11199

In comp.lang.javascript message <yxqybXCQnQLPFw6m@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris
<john@nospam.demon.co.uk> posted:


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

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

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

#11208

On Sun, 5 Feb 2012 at 16:47:36, in comp.lang.javascript, Dr J R Stockton 
wrote:
>In comp.lang.javascript message <yxqybXCQnQLPFw6m@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris
><john@nospam.demon.co.uk> posted:
>
>
>>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?
   <snip>

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

   John
-- 
John Harris

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

#11391

On Feb 4, 4:34 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> 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.

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

#10615

On Thu, 26 Jan 2012 18:29:06 +0100, 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.
> 
> If you want to compare the elements you will need to define and
> implement your own comparison function I think

It might be easier to compare two vars universally, assuming the JSON 
object is available, by:

function are_identical(var1, var2) {
return JSON.stringify(var1) === JSON.stringify(var2);
}

I think this would work for anything that can be stringified by the 
JSON.stringify() method.

Rgds

Denis McMahon

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

#10624

On Thu, 26 Jan 2012 16:24:04 -0800, Gene Wirchenko wrote:

> On 26 Jan 2012 23:08:55 GMT, Denis McMahon <denismfmcmahon@gmail.com>
> wrote:
> 
> [snip]
> 
>>It might be easier to compare two vars universally, assuming the JSON
>>object is available, by:
>>
>>function are_identical(var1, var2) {
>>return JSON.stringify(var1) === JSON.stringify(var2); }
>>
>>I think this would work for anything that can be stringified by the
>>JSON.stringify() method.
> 
>      Why not just toString()?
>           if (var1.toString()===var2.toString())

var x;
x.fred = 9;
x.jim = 23.654;
x.sue[0] = [15,"mouse",[12,14,5,"BASHER"],543.876];
x.sue[1] = "is x.toString() defined?";

Rgds

Denis McMahon

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

#10637

Denis McMahon wrote:

> Gene Wirchenko wrote:
>> Denis McMahon wrote:
>>> […]
>>> function are_identical(var1, var2) {
>>> return JSON.stringify(var1) === JSON.stringify(var2); }
>>>
>>> I think this would work for anything that can be stringified by the
>>> JSON.stringify() method.
>> 
>>      Why not just toString()?
>>           if (var1.toString()===var2.toString())
> 
> var x;
> x.fred = 9;
> x.jim = 23.654;
> x.sue[0] = [15,"mouse",[12,14,5,"BASHER"],543.876];
> x.sue[1] = "is x.toString() defined?";

This code cannot run (as-is; if `x' was assigned a reference to an object 
with a `sue' property before, then it *could* work), and does not constitute 
a proof at all.

A useful example showing why toString() does not suffice for all cases is

  /* "1,2,3,4"                 == "1,2,3,4"                 */
     [1, [2, 3], 4].toString() == [[1, 2], [3, 4]].toString()

If the JSON property is unavailable or wrong implemented, it can be 
emulated, either by using the implementation from <http://json.org/> or 
another object serializer.


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]

#10629

On 26 Jan 2012 23:08:55 GMT, Denis McMahon <denismfmcmahon@gmail.com>
wrote:

[snip]

>It might be easier to compare two vars universally, assuming the JSON 
>object is available, by:
>
>function are_identical(var1, var2) {
>return JSON.stringify(var1) === JSON.stringify(var2);
>}
>
>I think this would work for anything that can be stringified by the 
>JSON.stringify() method.

     Why not just toString()?
          if (var1.toString()===var2.toString())

Sincerely,

Gene Wirchenko

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

#10630

Gene Wirchenko wrote on 27 jan 2012 in comp.lang.javascript:

>      Why not just toString()?
>           if (var1.toString()===var2.toString())

This is why not:

var a =  [1,2,3,'qwerty'];
var b =  ['1,2',3,'qwerty'];

alert(String(a) === String(b)); // wrongly true

alert(a.toString() === b.toString()); // wrongly true

alert(a.join('+%%%+=') === b.join('+%%%+=')); // false
// only if you are certain that '+%%%+=' is not part of the content.
// even then only valid if the array content is only numeric or string

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#10659

In comp.lang.javascript message <4f21dd07$0$28275$862e30e2@ngroups.net>,
Thu, 26 Jan 2012 23:08:55, Denis McMahon <denismfmcmahon@gmail.com>
posted:

>On Thu, 26 Jan 2012 18:29:06 +0100, 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.
>>
>> If you want to compare the elements you will need to define and
>> implement your own comparison function I think
>
>It might be easier to compare two vars universally, assuming the JSON
>object is available, by:
>
>function are_identical(var1, var2) {
>return JSON.stringify(var1) === JSON.stringify(var2);
>}
>
>I think this would work for anything that can be stringified by the
>JSON.stringify() method.

Observe :
        A = new Array(5)
        B = new Array(6)
for which A[<anything>] = B[<anything>] = undefined; yet String(B) is
visibly longer than String(A).

Note : JSON.stringify(A) -> [null,null,null,null,null]
so JSON cannot tell a null from an undefined (in FF 9.0.1).

Consider
        A = [1, [1, 1], 1]
        B = [[1, 1], [1, 1]]
String() gives the same for each, but JSON can tell the difference.

But, in general, enough will be reliably known about the array contents
for String() to be safe.

-- 
 (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk  Turnpike 6.05  WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web