New FAQ Version for review

[Dr J R Stockton]

Re: New FAQ Version for review

In comp.lang.javas cript message <ptadnR_4qLPWyf LY4p2dnA@telcov e.net>,
Thu, 30 Nov 2006 16:59:44, Randy Webb <HikksNotAtHome @aol.comwrote:

>Dr J R Stockton said the following on 11/29/2006 6:23 PM:
>

>It is a change (in falsely-dated 9.0) from 8.1.

>
>With regards to the date, I am not changing the date on it every time I
>update it.
>
>The date that was put on it was a tentative date for trying to get it
>updated to the point where it could be moved to replace the current FAQ.
>If/When it gets moved, the date will be corrected. Until then, the date
>there is irrelevant, is it not?

No. If one looks again at NEWFAQ on the Web, one wants to know whether
there are any changes from last time. For those who feel no need to
look more than once a day - non-addicts - the date of editing would
serve nicely, since most people know the current date and most
interested know roughly when they last looked at the Web copy.

Changing the number would also serve.

Technical documents, of any form, should bear the identity of the
responsible person or organisation, and an indication of their age, to
an appropriate degree of accuracy.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demo n.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Dr J R Stockton]

Re: New FAQ Version for review

In comp.lang.javas cript message <ptadnR34qLO6z_ LY4p2dnA@telcov e.net>,
Thu, 30 Nov 2006 16:50:36, Randy Webb <HikksNotAtHome @aol.comwrote:

>Dr J R Stockton said the following on 11/30/2006 6:29 AM:

>In comp.lang.javas cript message
><1164763720.11 3483.90430@j72g 2000cwa.googleg roups.com>, Tue, 28 Nov 2006
>17:28:40, Peter Michaux <petermichaux@g mail.comwrote:
>>

>>In Section 4.22

>Changed to this:
>
>Question: How do I generate a random integer from 1 to N?
>
function Random(x) { return Math.floor(x*Ma th.random()) }
gives a random number in the range from 0 to x-1;
Random(N)+1 for 1 to N

Completely adequate.

I'd insert "use" after the semi-colon, on aesthetic grounds.

Actually, the result is an integer, rather than a general Number, so I'd
put "random integer".

The upper limit is really Ceil(x-1) or Ceil(x)-1.

One should never want to write Random(0) or Random(1) in code; but in an
algorithm calls with those parameters may occur (well, at least the
second case occurs) and the return value is OK.

Random does not give good results for x < 0 (example : Random(-2)
matches -Random(2)-1 EXCEPT that it gives zero once per 2^K times where
K is probably 32, 53, or 64. So in a full description I'd include
(x>=0).

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demo n.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.

[John G Harris]

Re: New FAQ Version for review

In article <ptadnR34qLO6z_ LY4p2dnA@telcov e.net>, Randy Webb
<HikksNotAtHome @aol.comwrites

<snip>

>Changed to this:
>
>Question: How do I generate a random integer from 1 to N?
>
function Random(x) { return Math.floor(x*Ma th.random()) }
gives a random number in the range from 0 to x-1;
Random(N)+1 for 1 to N

<snip>

Would you be willing to add 'inclusive', as in

gives a random number in the range from 0 to x-1 inclusive;

Then there is no doubt about the meaning.

Also, 'random number' should be 'random integer' to match the question.

John
--
John Harris

[Randy Webb]

Re: New FAQ Version for review

Dr J R Stockton said the following on 12/1/2006 5:41 AM:

In comp.lang.javas cript message <ptadnR_4qLPWyf LY4p2dnA@telcov e.net>,
Thu, 30 Nov 2006 16:59:44, Randy Webb <HikksNotAtHome @aol.comwrote:

>Dr J R Stockton said the following on 11/29/2006 6:23 PM:
>>

>>It is a change (in falsely-dated 9.0) from 8.1.

>>
>With regards to the date, I am not changing the date on it every time
>I update it.
>>
>The date that was put on it was a tentative date for trying to get it
>updated to the point where it could be moved to replace the current FAQ.
>If/When it gets moved, the date will be corrected. Until then, the
>date there is irrelevant, is it not?

>
>
No. If one looks again at NEWFAQ on the Web, one wants to know whether
there are any changes from last time. For those who feel no need to
look more than once a day - non-addicts - the date of editing would
serve nicely, since most people know the current date and most
interested know roughly when they last looked at the Web copy.

OK, I will start changing it when I modify and upload it.

Changing the number would also serve.

Would it be better then to re-number it to 8.2 or so and when it becomes
a final draft to go live with then change it to 9.0?

Technical documents, of any form, should bear the identity of the
responsible person or organisation, and an indication of their age, to
an appropriate degree of accuracy.

Valid Point.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Re: New FAQ Version for review

Dr J R Stockton said the following on 12/1/2006 6:12 AM:

In comp.lang.javas cript message <ptadnR34qLO6z_ LY4p2dnA@telcov e.net>,
Thu, 30 Nov 2006 16:50:36, Randy Webb <HikksNotAtHome @aol.comwrote:

>Dr J R Stockton said the following on 11/30/2006 6:29 AM:

>>In comp.lang.javas cript message
>><1164763720.1 13483.90430@j72 g2000cwa.google groups.com>, Tue, 28 Nov 2006
>>17:28:40, Peter Michaux <petermichaux@g mail.comwrote:
>>>
>>>In Section 4.22

>

>Changed to this:
>>
>Question: How do I generate a random integer from 1 to N?
>>
> function Random(x) { return Math.floor(x*Ma th.random()) }
> gives a random number in the range from 0 to x-1;
> Random(N)+1 for 1 to N

>
Completely adequate.
>
I'd insert "use" after the semi-colon, on aesthetic grounds.

Added.

Actually, the result is an integer, rather than a general Number, so I'd
put "random integer".

Changed

The upper limit is really Ceil(x-1) or Ceil(x)-1.
>
One should never want to write Random(0) or Random(1) in code; but in an
algorithm calls with those parameters may occur (well, at least the
second case occurs) and the return value is OK.

Not sure I would agree with the return value being OK since this code:

<script type="text/javascript">
function Random(x) { return Math.floor(x*Ma th.random()) }

for (i=0;i<1000;i++ ) document.write( Random(1))
</script>

Prints out 1,000 zeros.

Yes, that is "OK" in that there are no errors but the return value is
pretty useless.

Random does not give good results for x < 0 (example : Random(-2)
matches -Random(2)-1 EXCEPT that it gives zero once per 2^K times where
K is probably 32, 53, or 64. So in a full description I'd include
(x>=0).

Since x=1 gives such useless results I added "where N>2".

Modified proposed entry:

How do I generate a random integer from 1 to N?

function Random(x) { return Math.floor(x*Ma th.random()) }
gives a random integer in the range from 0 to x-1 ; use
Random(N)+1 for 1 to N where N>2.

Do you have a page/anchor, or know of one, that deals with random
numbers where X<2 that I could add a link reference to the entry?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Re: New FAQ Version for review

John G Harris said the following on 12/1/2006 3:49 PM:

In article <ptadnR34qLO6z_ LY4p2dnA@telcov e.net>, Randy Webb
<HikksNotAtHome @aol.comwrites
>
<snip>

>Changed to this:
>>
>Question: How do I generate a random integer from 1 to N?
>>
> function Random(x) { return Math.floor(x*Ma th.random()) }
> gives a random number in the range from 0 to x-1;
> Random(N)+1 for 1 to N

<snip>
>
Would you be willing to add 'inclusive', as in
>
gives a random number in the range from 0 to x-1 inclusive;

Done.

Then there is no doubt about the meaning.
>
Also, 'random number' should be 'random integer' to match the question.

Done, JRS pointed it out also.

See my reply to John Stockton for a proposed modified entry there. The
proposed entry doesn't have inclusive in it but it is added in my local
copy to be uploaded.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Re: New FAQ Version for review

Randy Webb said the following on 12/1/2006 4:36 PM:
<snip>

Modified proposed entry:
>
How do I generate a random integer from 1 to N?
>
function Random(x) { return Math.floor(x*Ma th.random()) }
gives a random integer in the range from 0 to x-1 ; use
Random(N)+1 for 1 to N where N>2.

Modified to say from "0 to x-1 inclusive".

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Re: New FAQ Version for review

VK said the following on 12/1/2006 11:42 AM:

Randy Webb wrote:

>I think that 3.2 is getting sufficiently lengthy enough that it might
>benefit from being moved to a page of it's own.
>>
>Thoughts and comments are welcome.

>
<http://www.jibbering.c om/faq/#FAQ3_2>
>
I see no immediate need to move links onto a separate page, but I would
suggest to group links by logical sections and place them in some
"usability order".

Yes, I tried making it an OL list and the file that creates the HTML
balked on it. When I have time I have to go through the process.wsf file
and find where it is balking and try to correct it. Making it an OL
would, as JRS suggested, make it easier to reference the links.

As for re-ordering them, absolutely. It would make it easier to keep the
separated and put like links together. As for what order, I will work on
that this weekend and try to get a new update posted.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr J R Stockton]

Re: New FAQ Version for review

In comp.lang.javas cript message <_MKdnZ5b_ZyvEf LY4p2dnA@telcov e.net>,
Thu, 30 Nov 2006 20:58:16, Randy Webb <HikksNotAtHome @aol.comwrote:

>Dr J R Stockton said the following on 11/30/2006 3:29 PM:

>In comp.lang.javas cript message <7amdnQXDOcLF7v PY4p2dnA@telcov e.net>,
>>Thu, 30 Nov 2006 01:00:41, Randy Webb <HikksNotAtHome @aol.comwrote:

>>Dr J R Stockton said the following on 11/29/2006 6:51 PM:

>>

>>>However, the code cited above lacks one advantage of DynWrite : it
>>>>
>>>wherever used, longer.
>>> function DineRite(ID, HTML) {
>>> document.getEle mentById(ID).in nerHTML = HTML }
>>> is the way to go, so that in the code one sees the job each time
>>>>and not
>>>the mechanism.
>>>
>>That one is shorter but it suffers a flaw that my code dosen't.

> Then explain it. Don't attempt to demonstrate superiority by
>>obscurity.

>
>
>Practice what you preach.
>
>The only difference between your code and mine is that yours is wrapped
>in a function

That is the important difference. Don't confuse "way to go" with "final
solution.

It is IMPORTANT, for efficient work, that detailed code is not repeated
where it could be better put into a loop or a function. And if the
details are hidden away in a function the calling code is less
cluttered.

However long or short the meat of the section is, provided that it
exceeds about a third of a line and is used repeatedly, putting it into
a function is better. We see frequently in what is posted in the group
that the naive do not think of that.

>and lacks any feature detection at all. Your claim was that my code
>"was longer", and it is, for the reason of feature detection.

No. Your document.getEle mentById(ID).in nerHTML = HTML; is longer
than my DineRite(ID, HTML). Feature detection makes it even longer
every time that it is written - so write it once.

>function DineRite(ID, HTML){
>if (document &&
document.getEle mentById &&
document.getEle mentById(ID) &&
document.getEle mentById(ID).in nerHTML)
{
document.getEle mentById(ID).in nerHTML = HTML;
}
>}
>
>If the browser doesn't support getElementById, if the element doesn't
>exist, or the browser doesn't support innerHTML then your version
>throws an error. That is the flaw that your code suffers from that the
>code I posted doesn't suffer from.

And yours suffers the flaw that if a naive site writer copies it (and
the FAQ is aimed at naive users), then someone reading without
getElementById will have something not working without any indication.
Remember that in general the reader does not know exactly what to
expect.

With my short version the reader will at least know that the page is
incompatible with his browser.

function DineRite(ID, HTML) {
if (document &&
document.getEle mentById &&
document.getEle mentById(ID) &&
document.getEle mentById(ID).in nerHTML)
{
document.getEle mentById(ID).in nerHTML = HTML; else alert("OOps")
}
}

will show the writer how to give a warning.

In FAQ code, it is much better to put alerts where they might be wanted
(the FAQ reader can easily take them out) than to leave them out (the
FAQ reader may not see where they might be advisable).



If getElementById is not available, ISTM likely to be better to detect
it at the start of the page, and plan subsequent operation accordingly,
avoiding the circumstances leading to the DineRite call.



Feature detection is easy if it is a question of whether a method
exists, easy enough if it is a question of whether a method works
correctly AND one knows how it fails, and not at all easy (until one
knows how) for such as whether RegExp look-ahead works. I hope that the
relevant Notes section goes far enough.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demo n.co.uk/- FAQish topics, acronyms, & links.
For news:borland.*, use their server newsgroups.borl and.com ; but first read
Guidelines <URL:http://www.borland.com/newsgroups/guide.htmlff. with care.

[VK]

Re: New FAQ Version for review


Dr J R Stockton wrote:

No. Your document.getEle mentById(ID).in nerHTML = HTML; is longer
than my DineRite(ID, HTML). Feature detection makes it even longer
every time that it is written - so write it once.

May ask what browsers these "innerHTML support checks" are targeted to?
By the intensity of the discussion side readers may decide that this is
some crucial problem of the modern web-development :-): while this
problem is not practically relevant for several years already. If there
is a known web browser without innerHTML support produced over the last
say three years I'd like to know it.

If the aim is to cover NN3/IE3 as well (so excluding if(property in
object) boolean check) it could be:

<body onload="
for (var p in document.body) {
if (p == 'innerHTML') {
alert('has innerHTML');
}
}
">

But again: for what *current* purpose? And if getElementById and
innerHTML can be missing, why a bunch of other things are presumed as
"given no matter what"? Like Array constructor, Image, src attribute
support for script tag etc?

[Randy Webb]

Re: New FAQ Version for review

Dr J R Stockton said the following on 12/1/2006 4:32 PM:

<snip>

Feature detection is easy if it is a question of whether a method
exists, easy enough if it is a question of whether a method works
correctly AND one knows how it fails, and not at all easy (until one
knows how) for such as whether RegExp look-ahead works.

Feature detection is "easy enough"? OK, I want to know if createTextNode
works correctly in the browser. I know, quite well, how it fails in one
very widely used browser (IE). Yet, there is no feature detection test
to find out if it works correctly or not even though I know exactly how
it's going to fail (fatal error to the script). See the thread from the
last two days entitled "createText Node and IE7" that was started by me
and you can see the issue. So no, feature detection is not always "easy
enough".

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

Re: New FAQ Version for review


Randy Webb wrote:

Feature detection is "easy enough"? OK, I want to know if createTextNode
works correctly in the browser. I know, quite well, how it fails in one
very widely used browser (IE). Yet, there is no feature detection test
to find out if it works correctly or not even though I know exactly how
it's going to fail (fatal error to the script).

Purely in-script feature detection driven code is not possible in some
or many circumstances. That could be always possible only if all UA
producers either 1) don't implement a feature at all or 2) do implement
it uniformely strictly by publically available specs. Every time the
2nd happens I'm getting all nervious: because it's too good to be true
and usually means some especially big hidden sh** to explode :-) Lucky
it happens on expremely rare basis :-)
Is it bad? It *is*. Can we do something besides carefully studying each
UA of our interests? Not too much.

See also my recent discussion over SVG at
<http://groups.google.c om/group/mozilla.dev.tec h.svg/browse_frm/thread/92f3c6f392886f2 6>

[Randy Webb]

Re: New FAQ Version for review

VK said the following on 12/1/2006 8:02 PM:

Dr J R Stockton wrote:

>No. Your document.getEle mentById(ID).in nerHTML = HTML; is longer
>than my DineRite(ID, HTML). Feature detection makes it even longer
>every time that it is written - so write it once.

>
May ask what browsers these "innerHTML support checks" are targeted to?

Any browser that doesn't support innerHTML <g>

The part of the post he quoted I was referring to the body of the
function of DynWrite and John, in his typically pedantic childish way,
chose to pedant that I hadn't wrapped it in a function call. Most of
that conversation was based on a philosophical issue of feature
detection but JRS totally missed it.

If DynWrite gets changed, it will be, almost verbatim:

function DynWrite(elemID ,elemContent){
document.getEle mentById(elemID ).innerHTML = elemContent;
}

Unless someone has a viable reason why it would be faulty in a modern
context.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Re: New FAQ Version for review

VK said the following on 12/1/2006 8:17 PM:

Randy Webb wrote:

>Feature detection is "easy enough"? OK, I want to know if createTextNode
>works correctly in the browser. I know, quite well, how it fails in one
>very widely used browser (IE). Yet, there is no feature detection test
>to find out if it works correctly or not even though I know exactly how
>it's going to fail (fatal error to the script).

>
Purely in-script feature detection driven code is not possible in some
or many circumstances.

Don't let John know that, he said it was "easy enough" and I know,
firsthand, better than that.

That could be always possible only if all UA producers either 1)
don't implement a feature at all or 2) do implement it uniformely
strictly by publically available specs.

Or 3) implements it but barely and not in accordance with the specs.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Michael Winter]

Re: New FAQ Version for review

Dr J R Stockton wrote:

[snip]

The previous discussion was just about what parseInt *returns*. The
first point of this one is that the existing Subject line of 4.12 is
badly chosen, since a correct answer to it must start by saying that
parseInt('09') does not give an error, but returns 0 or 9.

Agreed. Perhaps "Why doesn't parseInt('09') return what I expect?" would
be a better question.

[snip]

I don't recall anyone asking why it gives 9; that question is valid,
but not frequent.

Most people that encounter the issue have probably only tested in an
environment that chooses octal for leading zeros. To omit the return
value of 9 might suggest that such a value is in error.

Nevertheless, if a FAQ description says what parseInt does, it should
certainly include both what ECMA requires or permits and what browsers
actually do.

An edit of the current entry:

The parseInt function decides what base the number is by
looking at the number. It assumes that any number beginning
with '0x' or '0X' is hexadecimal, but it has a choice with a
leading zero: the number can either be octal or decimal.
Assuming octal, the string '09' will be converted to 0 (octal
digits are 0-7); assuming decimal, '09' will be converted to 9
(the leading zero is ignored).
To force use of a particular radix, add a second parameter:
parseInt("09",1 0)

The Notes article would be a better location for more detail, if desired.

[MLW:]

>The argument began from (what I believe to be) the sensible
>conclusion that the second, base argument should be passed to the
>function. Your counterargument was that such an action prevents
>users from entering hexadecimal numbers of the form 0xHH, which
>would otherwise receive treatment as base-16 numbers.

>
I disagree with your conclusion (as a FAQ recommendation) because it
is not always valid.

Recommendations can be ignored when there is sufficient reason. They are
not requirements and there's no need to abandon judgement; the eval
function is evil, but not always.

As a general rule for the majority of commercial applications, it
holds

Which is why it's a good general recommendation. Someone with special
needs should have the sense to overlook it when they know better,
especially if the rationale for the recommendation is clear.

- with a doubt whether there are any cases where unary plus cannot be
used *and* parseInt needs an explicit base 10.

The radix need not be 10. For example, colour codes (#rrggbb) can begin
with a zero, but should be interpreted as hexadecimal. Using unary plus
would evaluate to NaN.

[snip]

[MLW:]

> parseInt(value, /^\s*0\d/.test(value) ? 8 : 0);

[snip]

That may need developing to allow for signed numbers. /^\s*[-+]?0\d/
might suffice.

Quite. Sorry.

[snip]

Mike