Comparing arraies

Discussion in 'Javascript' started by Archos, Jan 26, 2012.

  1. 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$>
     
    Thomas 'PointedEars' Lahn, Jan 30, 2012
    #21
    1. Advertisements

  2. On Jan 30, 9:27 am, John G Harris <> 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.
     
    Michael Haufe (TNO), Jan 30, 2012
    #22
    1. Advertisements

  3. 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 <> 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
     
    John G Harris, Jan 31, 2012
    #23
  4. On Jan 31, 5:06 am, John G Harris <> 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.
     
    Michael Haufe (TNO), Jan 31, 2012
    #24
  5. 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
     
    John G Harris, Jan 31, 2012
    #25
  6. 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 <> 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
     
    John G Harris, Jan 31, 2012
    #26
  7. In comp.lang.javascript message <>,
    Mon, 30 Jan 2012 19:03:23, Thomas 'PointedEars' Lahn
    <> 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.
     
    Dr J R Stockton, Jan 31, 2012
    #27
  8. On Jan 31, 10:08 am, John G Harris <> 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 <> 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.
     
    Michael Haufe (TNO), Feb 1, 2012
    #28
  9. 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 <> 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
     
    John G Harris, Feb 1, 2012
    #29
  10. Michael Haufe (TNO) wrote:

    > On Jan 31, 10:08 am, John G Harris <> 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
     
    Thomas 'PointedEars' Lahn, Feb 1, 2012
    #30
  11. On Feb 1, 2:45 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > Michael Haufe (TNO) wrote:
    > > On Jan 31, 10:08 am, John G Harris <> 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.
     
    Michael Haufe (TNO), Feb 1, 2012
    #31
  12. Michael Haufe (TNO) wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Michael Haufe (TNO) wrote:
    >> > On Jan 31, 10:08 am, John G Harris <> 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).
     
    Thomas 'PointedEars' Lahn, Feb 1, 2012
    #32
  13. On Feb 1, 4:44 pm, 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...).

    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.)
     
    Michael Haufe (TNO), Feb 2, 2012
    #33
  14. 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 <> 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
     
    John G Harris, Feb 2, 2012
    #34
  15. 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$> (2004)
     
    Thomas 'PointedEars' Lahn, Feb 2, 2012
    #35
  16. 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
     
    Thomas 'PointedEars' Lahn, Feb 3, 2012
    #36
  17. 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
     
    John G Harris, Feb 4, 2012
    #37
  18. On Feb 4, 4:34 am, John G Harris <> 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.
     
    Michael Haufe (TNO), Feb 5, 2012
    #38
  19. In comp.lang.javascript message <830F0FF37FB96852AD0
    8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris
    <> 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)
     
    Dr J R Stockton, Feb 5, 2012
    #39
  20. On Sun, 5 Feb 2012 at 16:47:36, in comp.lang.javascript, Dr J R Stockton
    wrote:
    >In comp.lang.javascript message <830F0FF37FB96852AD0
    >8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris
    ><> 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
     
    John G Harris, Feb 6, 2012
    #40
    1. Advertisements

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
  1. M.D. van de Burgwal
    Replies:
    3
    Views:
    1,429
    Paul Uiterlinden
    Oct 7, 2004
  2. srinukasam

    comparing the contents of memory

    srinukasam, Jun 22, 2005, in forum: VHDL
    Replies:
    5
    Views:
    850
    Ralf Hildebrandt
    Jun 23, 2005
  3. srinukasam

    comparing the array in parallel

    srinukasam, Jun 28, 2005, in forum: VHDL
    Replies:
    3
    Views:
    646
  4. srinukasam
    Replies:
    3
    Views:
    654
    Andy Peters
    Jun 30, 2005
  5. Jorgen Gustafsson
    Replies:
    4
    Views:
    867
    Jorgen Gustafsson
    Dec 12, 2003
  6. vertigo

    simple string comparing

    vertigo, Apr 20, 2004, in forum: Perl
    Replies:
    2
    Views:
    533
    Jim Gibson
    Apr 21, 2004
  7. Comparing compilers

    , Dec 5, 2005, in forum: VHDL
    Replies:
    4
    Views:
    968
    Mike Treseler
    Dec 6, 2005
  8. Paul

    comparing dates

    Paul, Jul 28, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    501
Loading...