J
Jim Ley
<div id="chicken">false</div>
....
Jim.
<div id="chicken">false</div>
....
Jim.
D
Dr J R Stockton
In comp.lang.javascript message <[email protected]>,
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.
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.
D
Dr J R Stockton
In comp.lang.javascript message <[email protected]>,
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).
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).
V
VK
Randy said:
<http://www.jibbering.com/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". Say Netscape 4 documentation doesn't need to be the
second link from the top, right after "check it first".
<vk> ... </vk> marks my comments.
Javascript FAQ site, please check first:-
<http://javascript.faqts.com>
<vk>Does it really has to be the very first resource
for someone willing to learn JavaScript? That seems
more like a resource for advanced users
doing advanced scripting. IMHO anyway.</vk>
1. Browser producers documentation
Mozilla JavaScript 1.5 reference:-
<http://developer.mozilla.org/en/docs/JavaScript>
Mozilla DOM Reference:-
<http://www.mozilla.org/docs/dom/domref>
<vk>"Online Gecko DOM Reference" is confusing
in context of "Mozilla JavaScript 1.5 reference":
as if these are two different organizations.
"Mozilla" is more recognizable for a novice,
so should be preferred over "Gecko".</vk>
Download:-
<http://www.mozilla.org/docs/dom/domref.zip>
(817Kb, HTML format)
<vk>Size and format should be indicated for all downloads.</vk>
Microsoft JScript 5.6 reference and related resources:-
<http://msdn.microsoft.com/library/en-us/script56/html/1e9b3876-3d38-4fd8-8596-1bbfe2330aa9.asp>
<vk>The title is uniformed with the Mozilla resource above</vk>
<vk>Important!
The current link doesn't work for Internet Explorer: it randomly
reports "Page not found" and stays there or "Page not found" and
then 5 sec delay redirection to the correct location. The first
one
is simply bad, the second is very confusing for a novice.
The link was updated.</vk>
Download:
<http://www.microsoft.com/downloads/details.aspx?familyid=01592C48-207D-4BE1-8A76-1C4099D7BBB9>
(2.8Mb, Microsoft Windows .chm help file)
Microsoft DOM reference:-
<http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp>
<vk>The title is uniformed with the Mozilla resource above</vk>
Opera JavaScript and DOM documentation:-
<http://www.opera.com/docs/specs/#ecmascript>
<http://www.opera.com/docs/specs/js/>
iCab InScript documentation:-
<http://www.muchsoft.com/inscript/>
<vk>Watch the corrected case for UA and script names</vk>
Safari Developer FAQ:-
<http://developer.apple.com/internet/safari/faq.html>
<vk>Added for your considerations</vk>
2. Standards and specifications
The official ECMAScript specification:-
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>
Other versions of the ECMAScript specification:-
<http://www.mozilla.org/js/language/>
DOM Level 1 ECMAScript language binding
<http://www.w3.org/TR/REC-DOM-Level-1/ecma-script-language-binding.html>
DOM Level 2 ECMAScript language binding
<http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>
<vk>Both items above re-named properly, also W3C typo corrected:
the relevant language is called "ECMAScript", not "ECMA script",
it is typed properly only in the 2nd document.</vk>
3. Other ECMAScript implementations
FESI - a free implementation of ECMAScript in Java:-
<http://www.lugrin.ch/fesi/index.html>
Whitebeam Apache Module - Server Side Javascript in Apache;-
<http://www.whitebeam.org>
Digital Mars DMD Script, console and MS Active Script implementation of
ECMAScript, claimed to be faster than other implementations:-
<http://www.digitalmars.com/dscript/>
4. Developer resources:-
Source code and tutorials:-
<http://www.w3schools.com/>
<vk>"DHTML" term is obsolete, moreover say XSLT is not "DHTML"</vk>
Frequently asked questions about source code obfuscation:-
<http://jibbering.com/faq/obfuscate.html>
<vk>It is already covered in FAQ 4.1, so I see no need
to repeat the same but in more words. I could be
safely removed and referenced instead in actual posts.</vk>
Sites discussing Active Server Pages:-
<http://www.15seconds.com/>
<http://www.4guysfromrolla.com/>
<http://www.aspfaq.com/>
<vk>The majority of ASP pages
being programmed in VBScript, not JScript.
This way a generic ASP sites are irrelevant
to ECMAScript. If they contain some JScript
specific sections then link them directly.
Respectively the link should be renamed to
something like "JScript in ASP".</vk>
Sites focused on using Scripting to automate Windows:-
<http://www.windows-script.com/>
<http://cwashington.netreach.net/>
<vk>Again: VBScript or JScript scripting?
Same considerations as for the item above</vk>
Microsoft's Windows Scripting Host (WSH) Newsgroup:-
<microsoft.public.scripting.wsh>
<vk>Again: VBScript or JScript scripting?
Same considerations as for the item above</vk>
Manipulating times, dates and the lastModified date and time in
javascript:-
<http://www.merlyn.demon.co.uk/js-dates.htm>
5. Developer tools
Venkman - Mozilla Visual JS debugger:-
<http://www.mozilla.org/projects/venkman/>
Microsoft Script Debugger Download:
<http://msdn.microsoft.com/downloads/list/webdev.asp>
<vk>This link is not valid and never was. I'm not
sure how did it slip in here. Simply remove it.
It could be replaced by two new items below:</vk>
Microsoft Script Debugger:-
<http://en.wikipedia.org/wiki/Microsoft_Script_Debugger>
Microsoft Visual Studio Express (free version):-
<http://msdn.microsoft.com/vstudio/express/vwd/>
6. Legacy resources
Netscape JavaScript 1.3 reference:-
http://docs.sun.com/source/816-6408-10/contents.htm
<vk>was: "Index of Netscape 4 JavaScript docs online
(These documents are no longer available form Netscape
but are still reproduced by Sun Microsystems, Inc.)"
The title is corrected and shortened.</vk>
Index of Archived Netscape 4 JavaScript docs online and for download:-
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/
<vk>I see no download links in there (?) Otherwise it is exactly what
the
above item is. IMHO only one should stay: and I suggest this one.
As there is not enough confusion between Java and JavaScript: why
add more by referencing JavaScript docs from sun.com?</vk>
Archived documentation for MSIE 3.x:-
http://members.tripod.com/~housten/download/
7. Browser download links
<vk>Suggested section to add</vk>
R
Randy Webb
Jim Ley said the following on 12/1/2006 4:35 AM:
I remember
And that is why I replied to myself and corrected myself.
That wasn't the specific flaw that I had in mind though. If the browser
doesn't support getElementById then trying to use it results in a
visible JS error. If the element doesn't exist then trying to access
document.getElementById('incorrectID').property then it results in a JS
error.
I think what you are referring to is not knowing for sure that setting
the .innerHTML actually changes the .innerHTML of an element and any
code that uses .innerHTML is subject to that flaw :\
I remember
And that is why I replied to myself and corrected myself.That wasn't the specific flaw that I had in mind though. If the browser
doesn't support getElementById then trying to use it results in a
visible JS error. If the element doesn't exist then trying to access
document.getElementById('incorrectID').property then it results in a JS
error.
I think what you are referring to is not knowing for sure that setting
the .innerHTML actually changes the .innerHTML of an element and any
code that uses .innerHTML is subject to that flaw :\
J
John G Harris
<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
R
Randy Webb
Dr J R Stockton said the following on 12/1/2006 5:41 AM:
OK, I will start changing it when I modify and upload it.
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?
Valid Point.
OK, I will start changing it when I modify and upload it.
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?
Valid Point.
D
Dr J R Stockton
In comp.lang.javascript message <[email protected]>,
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.
No. Your document.getElementById(ID).innerHTML = HTML; is longer
than my DineRite(ID, HTML). Feature detection makes it even longer
every time that it is written - so write it once.
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.getElementById &&
document.getElementById(ID) &&
document.getElementById(ID).innerHTML)
{
document.getElementById(ID).innerHTML = 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.
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.
No. Your document.getElementById(ID).innerHTML = HTML; is longer
than my DineRite(ID, HTML). Feature detection makes it even longer
every time that it is written - so write it once.
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.getElementById &&
document.getElementById(ID) &&
document.getElementById(ID).innerHTML)
{
document.getElementById(ID).innerHTML = 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.
R
Randy Webb
Dr J R Stockton said the following on 12/1/2006 6:12 AM:
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*Math.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.
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*Math.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?
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*Math.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.
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*Math.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?
R
Randy Webb
John G Harris said the following on 12/1/2006 3:49 PM:
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.
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.
R
Randy Webb
Randy Webb said the following on 12/1/2006 4:36 PM:
Modified to say from "0 to x-1 inclusive".
Modified to say from "0 to x-1 inclusive".
R
Randy Webb
VK said the following on 12/1/2006 11:42 AM:
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.
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.
V
VK
Dr said:
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 thisproblem 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?
R
Randy Webb
Dr J R Stockton said the following on 12/1/2006 4:32 PM:
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 "createTextNode and IE7" that was started by me
and you can see the issue. So no, feature detection is not always "easy
enough".
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 "createTextNode and IE7" that was started by me
and you can see the issue. So no, feature detection is not always "easy
enough".
V
VK
Randy said:
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
Luckyit 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.com/group/mozilla.dev.tech.svg/browse_frm/thread/92f3c6f392886f26>
R
Randy Webb
VK said the following on 12/1/2006 8:02 PM:
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.getElementById(elemID).innerHTML = elemContent;
}
Unless someone has a viable reason why it would be faulty in a modern
context.
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.getElementById(elemID).innerHTML = elemContent;
}
Unless someone has a viable reason why it would be faulty in a modern
context.
R
Randy Webb
VK said the following on 12/1/2006 8:17 PM:
Don't let John know that, he said it was "easy enough" and I know,
firsthand, better than that.
Or 3) implements it but barely and not in accordance with the specs.
Don't let John know that, he said it was "easy enough" and I know,
firsthand, better than that.
Or 3) implements it but barely and not in accordance with the specs.
M
Michael Winter
Dr J R Stockton wrote:
[snip]
Agreed. Perhaps "Why doesn't parseInt('09') return what I expect?" would
be a better question.
[snip]
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.
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",10)
The Notes article would be a better location for more detail, if desired.
[MLW:]
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.
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.
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:]
Quite. Sorry.
[snip]
Mike
[snip]
Agreed. Perhaps "Why doesn't parseInt('09') return what I expect?" would
be a better question.
[snip]
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.
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",10)
The Notes article would be a better location for more detail, if desired.
[MLW:]
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.
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.
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:]
Quite. Sorry.
[snip]
Mike
D
Dr J R Stockton
In comp.lang.javascript message <[email protected]>,
Since it was said that the First Complete RW Version would be released
as 9.0 on 2006-12-01, I think I have to answer a definite Don't Know.
On second thoughts, no. The numbering sequence must increase
monotonically; consecutive releases of the same number are appropriate
only where the change is truly cosmetic (e.g. more tasteful shades of
similar colours done in the CSS).
But, starting from where I think we may be, I suggest using 10.0 for the
number of the first release for which you are fully responsible, with a
target date of Before 2007 and an actual date of whatever it is.
Since it was said that the First Complete RW Version would be released
as 9.0 on 2006-12-01, I think I have to answer a definite Don't Know.
On second thoughts, no. The numbering sequence must increase
monotonically; consecutive releases of the same number are appropriate
only where the change is truly cosmetic (e.g. more tasteful shades of
similar colours done in the CSS).
But, starting from where I think we may be, I suggest using 10.0 for the
number of the first release for which you are fully responsible, with a
target date of Before 2007 and an actual date of whatever it is.
D
Dr J R Stockton
In comp.lang.javascript message <[email protected]>,
If I were rewriting that, I think I'd omit the reference to Random(0).
One can choose an element from a set of 1 or more elements, but not from
an empty set.
That's right. Each of those zeroes could have been chosen, at
equi-probable random, from a set of digits holding a single zero.
Remember that N factorial is generally considered as the product of all
integers from 1 to N, but 1!=1 then involves no multiplication and 0!=1
involves no integers. A broader definition is that (for N>=0) N! is "1
times all the integers from 1 or 2 to N in turn".
NO. In an algorithm similar to shuffling, where a sequence of N is
used, it may be desirable to include N=1 rather than to add code to
exclude it. There, "similar to" does not include "the same as".
The limits of validity given in a description of an algorithm should
include all cases in which it is correct, without regard to any
judgement of utility; otherwise, a reader may waste time/effort by
assuming that it is not valid outside the stated limits.
There is no need for " where N>2"
Offhand, no. In the cases I've looked at today, the coding has been
able to avoid using Random(1) without extra code.
It's always wise to allow extreme cases as a limit of non-extreme cases.
In Algol, IIRC, arrays are dynamically sized when the block containing
the declaration is executed. Ignoring syntax errors,
procedure X(N) ;
var A : array [1:N] ; J : integer ;
begin for J = 1 step 1 to N do A[J] := 0 ; end;
will work for integer N > 0; but the declaration will fail for N=0,
though the loop would execute perfectly, zero times. A corresponding
Javascript can handle an array of no elements.
If I were rewriting that, I think I'd omit the reference to Random(0).
One can choose an element from a set of 1 or more elements, but not from
an empty set.
That's right. Each of those zeroes could have been chosen, at
equi-probable random, from a set of digits holding a single zero.
Remember that N factorial is generally considered as the product of all
integers from 1 to N, but 1!=1 then involves no multiplication and 0!=1
involves no integers. A broader definition is that (for N>=0) N! is "1
times all the integers from 1 or 2 to N in turn".
NO. In an algorithm similar to shuffling, where a sequence of N is
used, it may be desirable to include N=1 rather than to add code to
exclude it. There, "similar to" does not include "the same as".
The limits of validity given in a description of an algorithm should
include all cases in which it is correct, without regard to any
judgement of utility; otherwise, a reader may waste time/effort by
assuming that it is not valid outside the stated limits.
There is no need for " where N>2"
Offhand, no. In the cases I've looked at today, the coding has been
able to avoid using Random(1) without extra code.
It's always wise to allow extreme cases as a limit of non-extreme cases.
In Algol, IIRC, arrays are dynamically sized when the block containing
the declaration is executed. Ignoring syntax errors,
procedure X(N) ;
var A : array [1:N] ; J : integer ;
begin for J = 1 step 1 to N do A[J] := 0 ; end;
will work for integer N > 0; but the declaration will fail for N=0,
though the loop would execute perfectly, zero times. A corresponding
Javascript can handle an array of no elements.