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

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

Give alert if form checkbox array is empty

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

Contents

  Give alert if form checkbox array is empty Bunyip <bunyip@koalanet.com.au> - 2016-01-20 13:28 +1000
    Re: Give alert if form checkbox array is empty JJ <jj4public@vfemail.net> - 2016-01-20 12:30 +0700
      Re: Give alert if form checkbox array is empty Bunyip <bunyip@koalanet.com.au> - 2016-01-20 17:55 +1000
        Re: Give alert if form checkbox array is empty JJ <jj4public@vfemail.net> - 2016-01-20 19:29 +0700
          Re: Give alert if form checkbox array is empty "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-20 13:46 +0100
    Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-20 08:23 +0000
      Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-20 15:52 +0100
        Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-20 15:43 +0000
          Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-20 17:15 +0100
            Re: Give alert if form checkbox array is empty Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-01-20 17:53 +0000
              Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-20 20:39 +0100
                Re: Give alert if form checkbox array is empty Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-01-20 22:46 +0000
            Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-21 07:53 +0000
              Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 10:52 +0100
                Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-21 10:26 +0000
                  Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-22 00:07 +0100
    Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-20 10:28 +0100
      Re: Give alert if form checkbox array is empty Bunyip <bunyip@koalanet.com.au> - 2016-01-21 08:05 +1000
        Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 00:59 +0100
          Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-21 03:17 +0100
            Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 08:54 +0100
              Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-21 12:17 +0100
          Re: Give alert if form checkbox array is empty John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-21 14:16 +0000
          Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-21 19:52 -0800
            Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-22 09:48 +0100
              Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-22 10:45 -0800
                Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-23 19:41 +0100
                  Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-24 17:51 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-25 19:46 +0100
                      Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-27 11:09 -0800
          Re: Give alert if form checkbox array is empty Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> - 2016-01-23 22:22 +0000
          Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-27 11:06 -0800
            Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-28 14:46 +0100
              Re: Give alert if form checkbox array is empty Gene Wirchenko <genew@telus.net> - 2016-01-28 10:30 -0800
                Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-28 20:06 +0100
                  Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-28 23:32 -0800
                    Re: Give alert if form checkbox array is empty "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-29 09:05 +0100
                      Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 06:02 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:54 +0100
                  Re: Give alert if form checkbox array is empty John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-29 10:36 +0000
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-09 04:39 +0100
                      Re: Give alert if form checkbox array is empty John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-09 18:07 +0000
                  Re: Give alert if form checkbox array is empty Gene Wirchenko <genew@telus.net> - 2016-01-29 09:32 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:34 +0100
                      Re: Give alert if form checkbox array is empty Aleksandro <aleksandro@gmx.com> - 2016-01-29 16:50 -0300
                      Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-30 03:31 +0100
                        Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-30 04:19 +0100
                          Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-30 05:01 +0100
                Re: Give alert if form checkbox array is empty Aleksandro <aleksandro@gmx.com> - 2016-01-28 16:39 -0300
              Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 06:04 -0800
                Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:54 +0100
                  Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 14:55 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-30 04:55 +0100
                      Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-30 15:48 -0800
                        Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-31 21:02 +0100
                          Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-31 13:08 -0800
                            Re: Give alert if form checkbox array is empty Andrew Poulos <ap_prog@hotmail.com> - 2016-02-01 12:28 +1100
                              Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-01 17:58 -0800
    Re: Give alert if form checkbox array is empty "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-01-20 06:25 -0800
    Re: Give alert if form checkbox array is empty Aleksandro <aleksandro@gmx.com> - 2016-01-20 12:54 -0300

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

#29390

Stefan Weiss wrote:

> On 01/21/2016 00:59, Thomas 'PointedEars' Lahn wrote:
>> You should familiarize yourself with the Array methods introduced with
>> implementations of ECMAScript Edition 5 at the latest, in order to not
>> write explicit loops where they are not necessary.  Examples have been
>> given.
>> 
>> Keep in mind that the built-in implementation of an algorithm is
>> naturally always the most efficient one to use as it is, at best,
>> provided in machine code already.
> 
> Had you tested this, you would have discovered that your version - the
> one with `[].slice.call(...)` - takes 2 to 17 times longer than the
> simple loop, depending on the browser and which checkboxes are checked.

Irrelevant argument as that was _not_ what I as referring to.  Besides, you 
are deliberately ignoring compilation here, but considering it elsewhere.
 
> Also, storing `subjectTypes.length` in a variable has almost no benefit:
> it makes the loop a tiny bit faster in Firefox (about 5 nanoseconds per
> iteration on my laptop), and a tiny bit slower in Chrome (about the same
> difference in the other direction). Making assumptions about the
> performance of modern JS engines without testing or intimate knowledge
> of the internal optimizations is pointless.

It has been shown in this newsgroup to be much more efficient in general.  
Your test methodology is flawed.

> Not that speed matters in this case - there are four checkboxes to test,
> what kind of performance do you think we need for that? But you were
> criticizing posted code for its performance and at the same time
> advocating a slower and less readable version, so I thought you'd like
> to know.

Your logic is flawed, too.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#29394

On 01/21/2016 08:54, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> On 01/21/2016 00:59, Thomas 'PointedEars' Lahn wrote:
>>> You should familiarize yourself with the Array methods introduced with
>>> implementations of ECMAScript Edition 5 at the latest, in order to not
>>> write explicit loops where they are not necessary.  Examples have been
>>> given.
>>>
>>> Keep in mind that the built-in implementation of an algorithm is
>>> naturally always the most efficient one to use as it is, at best,
>>> provided in machine code already.
>>
>> Had you tested this, you would have discovered that your version - the
>> one with `[].slice.call(...)` - takes 2 to 17 times longer than the
>> simple loop, depending on the browser and which checkboxes are checked.
> 
> Irrelevant argument as that was _not_ what I as referring to.

Then what were you referring to? "Learn about built-in Array methods,
young padawan. Do not write explicit loops. Look at the example I
posted. Built-in algorithms are always faster. ... *handwave* These are
not the benchmarks you're looking for, move along."

> Besides, you are deliberately ignoring compilation here, but considering
> it elsewhere.

I never even mentioned compilation. Care to elaborate?

>> Also, storing `subjectTypes.length` in a variable has almost no benefit:
>> ...
> It has been shown in this newsgroup to be much more efficient in general.  
> Your test methodology is flawed.

Times change. What was once true about optimization can be obsoleted by
advancements in JS engine development, and in this case it has. Besides,
this is trivial to test. If you found a flaw in my tests (without even
seeing them), kindly point it out so we can discuss it.

>> Not that speed matters in this case - there are four checkboxes to test,
>> what kind of performance do you think we need for that? But you were
>> criticizing posted code for its performance and at the same time
>> advocating a slower and less readable version, so I thought you'd like
>> to know.
> 
> Your logic is flawed, too.

Let's see...
* Speed does not matter here - that one's pretty obvious.
* You talked about improving preformance of the posted code - check.
* You posted a slower version - check.
* You want to hear about this - ah, I think I found the flaw.


Again, performance is not an issue when checking four form elements in a
submit handler. The callback returns long before the user's finger has
lifted from the mouse button or enter key. But if you make speed an
issue anyway, don't be surprised when somebody calls you out on it.


- stefan

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

#29396

On Thu, 21 Jan 2016 00:59:20 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Bunyip wrote:
>^^^^^^
>Please post using your full (real) name.
  <snip>

The McGillycuddy of the Reeks is a "full (real)" name. Prove that
"Bunyip" is not.


>> var STchecked;
>
>Names should not start with a capital letter unless the value of the 
>variable/property is intended to be a reference to a constructor.
  <snip>

But only do this if you are following the Java naming convention. If
you aren't don't worry about using a different convention.

  John

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

#29400

Thomas 'PointedEars' Lahn wrote:
> Keep in mind that the built-in implementation of an algorithm is naturally 
> always the most efficient one to use as it is, at best, provided in machine 
> code already.

Nonsense.  This is a complete non sequitur.

One can write a horrible implementation of an algorithm; the fact that it's
available immediately in machine code does not make it more efficient to use
than one written better.

Many people have written implementations of functions such as `map`, `reduce`,
and `filter` more efficient for many uses than their native counterparts on
`Array.prototype`.

  -- Scott

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

#29401

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Keep in mind that the built-in implementation of an algorithm is
>> naturally always the most efficient one to use as it is, at best,
>> provided in machine code already.
> 
> Nonsense.  This is a complete non sequitur.

It is not.  Machine code is compiled already; script code is not.  So the 
time to interpret script code or to compile script code to machine code has 
to be taken into account.

> One can write a horrible implementation of an algorithm; the fact that
> it's available immediately in machine code does not make it more efficient
> to use than one written better.

One must start from the assumption that the developers of script engines 
know what they are doing, without assuming any optimizations on their part.
 
> Many people have written implementations of functions such as `map`,
> `reduce`, and `filter` more efficient for many uses than their native
> counterparts on `Array.prototype`.

Now *that* is a non sequitur.  And you want to cite evidence.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#29412

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:

>>> Keep in mind that the built-in implementation of an algorithm is
>>> naturally always the most efficient one to use as it is, at best,
>>> provided in machine code already.
>> 
>> Nonsense.  This is a complete non sequitur.
> 
> It is not.  Machine code is compiled already; script code is not.  So the 
> time to interpret script code or to compile script code to machine code has 
> to be taken into account.

So, taking into account the time to compile a script, how much more 
efficient is the native `Array.prototype.map` method than the one 
supplied by lodash [1]? 

Does this question sound like claptrap to anyone else? It certainly does 
to me. Because the answer will certainly depend on the API differences 
between the pure function supplied by lodash and that of the native 
method, on the number of times the function is called, on the 
optimizations performed by the engine on its native implementation, and 
on the optimizations that the lodash version might be able to take 
advantage of on a given engine. 

But Thomas, you want to point to the fact that it's precompiled as 
enough to outweigh all of these factors. That is pure nonsense. 

 
>> One can write a horrible implementation of an algorithm; the fact that
>> it's available immediately in machine code does not make it more efficient
>> to use than one written better.
> 
> One must start from the assumption that the developers of script engines 
> know what they are doing, without assuming any optimizations on their part.

Why must one start from that assumption?

The writers of script engines are developers like any other, subject to 
the same foibles as anyone else, and subject to constraints from a 
specification that may not be relevant to ones own interests. 


>> Many people have written implementations of functions such as `map`,
>> `reduce`, and `filter` more efficient for many uses than their native
>> counterparts on `Array.prototype`.
> 
> Now *that* is a non sequitur.  And you want to cite evidence.

Do you believe that applies to people who post such ill-supported 
propositions as this: 

| One must start from the assumption that the developers of script 
| engines know what they are doing, without assuming any optimizations
| on their part.

or this:

| Keep in mind that the built-in implementation of an algorithm is
| naturally always the most efficient one to use as it is, at best,
| provided in machine code already.

?

But a very quick search of the Web found many benchmarks, including this 
fairly recent one: 

    <https://jsperf.com/native-vs-array-js-vs-underscore/182>

which demonstrates very different performance characteristics across 
many engines, but finds none in which the native `map` is the fastest. 

  [1]: <https://lodash.com/docs#map>


  -- Scott

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

#29418

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Keep in mind that the built-in implementation of an algorithm is
>>>> naturally always the most efficient one to use as it is, at best,
>>>> provided in machine code already.
>>> Nonsense.  This is a complete non sequitur.
>> It is not.  Machine code is compiled already; script code is not.  So the
>> time to interpret script code or to compile script code to machine code
>> has to be taken into account.
> 
> So, taking into account the time to compile a script, how much more
> efficient is the native `Array.prototype.map` method than the one
> supplied by lodash [1]?

Apples and oranges.  lodash’s _map() can be faster because it is not a 
conforming implementation of Array.prototype.map().
 
> [tl;dr]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#29434

Thomas 'PointedEars' Lahn wrote:
>> [tl;dr]

I believe you mistyped that.  Did you not mean "[tr;dl]"?

For it did seem that my argument was Too Reasonable, and you Didn't 
Listen.

The amusing thing is that I agree with your advice entirely.  The OP 
_should_ learn to use the newer Array.prototype methods.  They would 
improve the posted code sample significantly.  But your suggestion 
that this had to do with efficiency was bogus.  Rarely will a 
well-written block that uses `Array. prototype.some` be more efficient 
than its (appropriately-written) counterpart written with a 
`for`-loop.  But except in the most performance-critical sections of 
code, I would recommend the former, since clean, readable code is more 
maintainable, and such performance differences rarely impose a 
substantial penalty.

  -- Scott

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

#29440

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>>> [tl;dr]
> 
> I believe you mistyped that.  Did you not mean "[tr;dl]"?

Yes, I did not.
 
> For it did seem that my argument was Too Reasonable, and you Didn't
> Listen.

You can believe that if you want, but the fact of the matter is that you 
snipped my counter-argument showing that your argument is fallacious as
you are proceeding from a false assumption.

> […] I agree with your advice entirely. […]

Good.

> But your suggestion that this had to do with efficiency was bogus.

No, it was not.

        [weasel word]       [weasel word]             
> Rarely will a well-written block that uses `Array. prototype.some` be more
                                           [weasel word]
> efficient than its (appropriately-written) counterpart written with a 
> `for`-loop.

Proof by statement.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#29459

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:

>> [...] I agree with your advice entirely. [...]
> 
> Good.
> 
>> But your suggestion that this had to do with efficiency was bogus.
> 
> No, it was not.

So will you offer any evidence to your assertion that, "the built-in implementation of an algorithm is naturally always the most efficient 
one to use as it is, at best, provided in machine code already"?

  -- Scott

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

#29423

In comp.lang.javascript message <1851504.v7CTRd67sv@PointedEars.de>,
Thu, 21 Jan 2016 00:59:20, Thomas 'PointedEars' Lahn
<PointedEars@web.de> posted:

>Keep in mind that the built-in implementation of an algorithm is naturally
>always the most efficient one to use as it is, at best, provided in machine
>code already.

Not necessarily.  Microsoft VBScript's implementation of the computation
of ISO 8601 Week Number is near enough built in, as they say to use
DatePart with specified arguments.

But it was not efficient _to_use_, as for (as I recall) one day in each
of three years in every 28 years and one other day in every 400 years it
gives an incorrect answer - and that could waste a considerable amount
of production and sorting-out time.  Evidently that have not understood
the implications of ISO 8601, and the method needed is probably not
within the capabilities of DatePart.

I did find replacement script on the Microsoft Web Site, and it gives
the right results.  But it appears to have been produced by first
writing something that usually gives the right result them treating
specially the cases where it does not.  It could well be slower, on
average, than an intelligently-written script.

But there is/was worse.  A core Date routine in Windows Safari
JavaScript behaved in a manner suggesting that a 3 had crept in instead
of a 4 in the Gregorian part of their Leap Year rule, so that there was
a one day error for one or two thirds of dates.  The errors were in
66/67-year blocks, and did not appear for current dates.  But before
very long the Year 2033/2034 will appear ...

Then there was the famous Pentium FDIV bug.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.

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

#29458

Thomas 'PointedEars' Lahn wrote:
> Keep in mind that the built-in implementation of an algorithm is naturally 
> always the most efficient one to use as it is, at best, provided in machine 
> code already.

Proof by statement.

  -- Scott

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

#29460

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Keep in mind that the built-in implementation of an algorithm is
>> naturally always the most efficient one to use as it is, at best,
>> provided in machine code already.
> 
> Proof by statement.

I have already explained why.  It is not my problem if you are not paying 
attention and can only come up with apples vs. oranges.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#29461

On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Scott Sauyet wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Keep in mind that the built-in implementation of an algorithm is
>>> naturally always the most efficient one to use as it is, at best,
>>> provided in machine code already.
>> 
>> Proof by statement.
>
>I have already explained why.  It is not my problem if you are not paying 
>attention and can only come up with apples vs. oranges.

     Sorry, but your reasoning is invalid.  It is quite possible for
an implementation to be inefficient.

     I would require good reason to not use the built-in
implementation rather than coming up with my own, but if the built-in
implementation were that bad, it might be worth it.

Sincerely,

Gene Wirchenko

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

#29462

Gene Wirchenko wrote:

> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:

Attribution _line_, not attribution novel.  Will you ever learn?

>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Keep in mind that the built-in implementation of an algorithm is
>>>> naturally always the most efficient one to use as it is, at best,
>>>> provided in machine code already.
>>> Proof by statement.
>> I have already explained why.  It is not my problem if you are not paying
>> attention and can only come up with apples vs. oranges.
> 
>      Sorry, but your reasoning is invalid.

No, it is not.

>      It is quite possible for an implementation to be inefficient.

Yes; nobody debated that.  But AISB that reasoning presupposes that the 
developers of script engines do not know what they are doing.  Since WLOG 
you do _not_ know what script engine your code will be exposed to, it is not 
logical to write your code based on either assumption, and *that* reasoning 
is "invalid" instead.

In addition, AISB, comparing implementations of different algorithms is 
comparing apples and oranges; it is a fallacious argumentation.  For 
example, you can use lodash’s _map() instead of Array.prototype.map() and 
the former can be more efficient than the latter for the cases that _map() 
supports (at least with regard to execution speed), but you need to be aware 
that the former is both deficient regarding standards compliance (it does 
not perform all the steps of the specification algorithm) and does more than 
the standard implementation does at the same time (it does steps that the 
specification algorithm does not contain), so in general the former *cannot* 
be used as a stand-in for the latter.
 
>      I would require good reason to not use the built-in
> implementation rather than coming up with my own, but if the built-in
> implementation were that bad, it might be worth it.

You cannot not know what you cannot know, and using conditionals in order to 
to tell script engines apart so that you could *perhaps* know that your 
script is executed by a less efficient implementation regarding a certain 
use-case (my research – see sig; and yes, I know that it is not up-to-date 
*yet* – shows that with the exception of JScript you can only *infer* the 
script engine version, and that knowledge will always be out of date at the 
time the code is run) is only going to make your script *less* efficient 
*for execution under all script engines* because you have to run those tests 
precisely when your code is executed.

BTW, it is an oft-neglected fact, which can be seen in this discussion prior 
to this posting, that the term efficiency in computer science is not limited 
to execution speed but also has as memory-usage component.  There is runtime 
efficiency *and* memory efficiency.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.y

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

#29468

Thomas 'PointedEars' Lahn wrote:
> Gene Wirchenko wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:

>>>>> Keep in mind that the built-in implementation of an algorithm is
>>>>> naturally always the most efficient one to use as it is, at best,
>>>>> provided in machine code already.

>>>> Proof by statement.

>>> I have already explained why.  It is not my problem if you are not paying
>>> attention and can only come up with apples vs. oranges.

>> 
>>      Sorry, but your reasoning is invalid.
 
> No, it is not.

Yes, it is.  And quite obviously so, too.

 
>>      It is quite possible for an implementation to be inefficient.
 
> Yes; nobody debated that.  But AISB that reasoning presupposes that the 
> developers of script engines do not know what they are doing.  

Not at all.  Perhaps the author of the code in question is simply a better
developer than the one who wrote that part of the script engine.  Or, and
this is quite likely, the user might need an algorithm related to, but less
complex than that specified by a document such as ECMA-262.  If so, she
can create an implementation that will process more quickly and/or in less 
space than a version required to conform to that spec.

> Since WLOG
        ^^^^

(I've always used that abbreviation for "Without loss of generality".  I use
it in mathematical contexts to suggest that a representative case can in
obvious ways be transformed to cover each other case.  that how you mean it
here?  If so, I can make little sense of it in this context.  Would one 
generalize on "you"?)


> you do _not_ know what script engine your code will be exposed to, it is not 
> logical to write your code based on either assumption, and *that* reasoning 
> is "invalid" instead.

And yet you maintain that it is inherently better to use the native
implementation.  Poor logic.


> In addition, AISB, comparing implementations of different algorithms is 
> comparing apples and oranges; it is a fallacious argumentation.  

You presented your contention in the context of suggesting that Bunyip should
change a `for`-loop to use the Array methods from ES5+.  You already have 
apples and oranges here.  None of the Array methods are exactly equivalent to
Bunyip's `for`-loop.  Does that make your argument equally fallacious?


>                                                                  For 
> example, you can use lodash's _map() instead of Array.prototype.map() and 
> the former can be more efficient than the latter for the cases that _map() 
> supports (at least with regard to execution speed), but you need to be aware 
> that the former is both deficient regarding standards compliance (it does 
> not perform all the steps of the specification algorithm) and does more than 
> the standard implementation does at the same time (it does steps that the 
> specification algorithm does not contain), so in general the former *cannot* 
> be used as a stand-in for the latter.

And `Array.prototype.some` -- or whatever method you would suggest that
Bunyip use in place of the `for`-loop has different characteristics than that
`for`-loop.  So would you argue that it cannot be used in place of the loop?

In fact, the real reason to switch Bunyip's code from the `for`-loop to 
somethng modern has to do with the change to a more expressive API.
Similar arguments migt well propel one toward something like lodash or,
closer to my own heart as a co-author, Ramda.  This has nothing at all to
do with efficiency.

>>      I would require good reason to not use the built-in
>> implementation rather than coming up with my own, but if the built-in
>> implementation were that bad, it might be worth it.
 
> You cannot not know what you cannot know, and using conditionals in order to 
> to tell script engines apart so that you could *perhaps* know that your 
> script is executed by a less efficient implementation regarding a certain 
> use-case (my research - see sig; and yes, I know that it is not up-to-date 
> *yet* - shows that with the exception of JScript you can only *infer* the 
> script engine version, and that knowledge will always be out of date at the 
> time the code is run) is only going to make your script *less* efficient 
> *for execution under all script engines* because you have to run those tests 
> precisely when your code is executed.

I agree with the broad point that knowledge of inefficiencies in specific
engines or even wide ranges of engines should generally not dictate writing
one's own version, especially for code that will run in browser environments.
And choosing a native versus a custom implementation based on an inference of
the script engine simply hearkens back to the horrible days of 
`if (document.all)`.  But the argument that having to run the tests is a key
efficiency problem is far over-generalized.  That will depend on the speed of
the test and how often the code that uses the technique at issue is run.

Moreover, there is a lot of server-side scripting now in which the user does
know precisely what engine will be running her code, so much of that argument
is moot.




> BTW, it is an oft-neglected fact, which can be seen in this discussion prior 
> to this posting, that the term efficiency in computer science is not limited 
> to execution speed but also has as memory-usage component.  There is runtime 
> efficiency *and* memory efficiency.

Yes there is, and for a long time algorithmic analysis in computer science
investigated the trade-offs between space and time.  But over the years, the
concerns over space have diminished tremendously, to the point where only a
very small part of the discussion about complexity or efficiency ever even 
mention it.  (This decline in the worry about space efficiency started a long
time ago.  A professor was discussing this phenomenon in a class I took 29 years
ago.)  It is also a much less tractable problem for Ecmascript implementations.
There are many tools to help capture and analyze time  efficiency.  Tools for 
doing the same with space efficiency are harder to find and generally harder to 
use.

Do you have an important point to dicuss in bringin this up?


  -- Scott

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

#29469

Some of you wrote in comp.lang.javascript:

>>> Sorry, but your reasoning is invalid.

>> No, it is not.
 
> Yes, it is.  And quite obviously so, too.

Children!

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

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

#29476

Evertjan. wrote:

> Some of you wrote in comp.lang.javascript:
>>>> Sorry, but your reasoning is invalid.
>>> No, it is not.
>> Yes, it is.  And quite obviously so, too.

> Children!

Yes, and on my part, quite intentionally.  I almost left it as
"Yes, it is" to show just how ridiculous that sort of response
can be.  But in the end, I couldn't get myself to do just that.

:-)

  -- Scott

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

#29494

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Gene Wirchenko wrote:
>>>      It is quite possible for an implementation to be inefficient.
>> Yes; nobody debated that.  But AISB that reasoning presupposes that the
>> developers of script engines do not know what they are doing.
> 
> Not at all.  Perhaps the author of the code in question is simply a better
> developer than the one who wrote that part of the script engine. 

It would seem that your hubris knows no end.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#29472

On Thu, 28 Jan 2016 20:06:14 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Gene Wirchenko wrote:
>
>> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>
>Attribution _line_, not attribution novel.  Will you ever learn?
  <snip>

If Gene is following the British advice on News bodies he is doing the
right thing.

<https://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.2.2.1>

If he is following the German advice then he is doing the wrong thing,
but for the right reason. (To make it work).
  <https://www.netmeister.org/news/learn2quote.html>

  John

[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