«

On 1 Sep 2004 13:11:27 -0700, lawrence <> wrote:

[snip]

> Is it best to do this:
>
> var num = myArray.length;
> for (var i = 0; i < num; i++) {
>
> or is this better:
>
> for (var i = 0; i < myArray.length; i++) {

I suppose that in practice, it doesn't make much difference. However, the
former will be marginally faster (so it's what I always use , though I'd
write:

for(var i = 0, n = myArray.length; i < n; ++i) {
// ...
}

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

"lawrence" <> wrote in message
news: om...
> "Stephen Chalmers" <> wrote in message
news:<413535f3$>...
>
> > if(i+1 == stepChange[ind])
> > ind++;
> >
> > howFarLeft-=(ind+1);
>
> If I want to creat multiple speeds, do I create another array like
> stepChange, or does the speed change increase as we walk through this
> array? If I wanted a high speed set of DIVS, should I do a separate
> array?
>
>
>
Your original code specified step sizes individually for each div, which
increased by one at given intervals. The contents of stepChange are used to
indicate the points in the array at which the step size is incremented by 1. The
last element in stepChange is not used, but is there as a simple way of
preventing reading past the end.

If you want to increase the speed further, you could change

howFarLeft-=(ind+1) to howFarLeft-=(ind+1)*2

although having seen the display running, I do not recommend it.

--
Stephen Chalmers

JRS: In article < >,
dated Wed, 1 Sep 2004 12:13:44, seen in news:comp.lang.javascript,
lawrence <> posted :
>
>Also, I notice that changing the time on the setTimeout doesn't seem
>to speed things up. When I change the 100 to a 10, things seem nearly
>the same. How can that be?
>
>> setTimeout("moveDivs()", 100);


The resolution of setTimeout, setInterval, and new Date() is system-
dependent. It should not be confused with the resolution of the Date
Object itself, which is 1 ms.

In Win98, it is about 55 ms; in later systems, often 10 ms. It appears
that the set... routines are implemented so as to make *each* delay
always at least the requested value (setInterval could be probably
implemented so as to get the average interval correct). In addition,
one must consider the overheads in code execution, which add delays.

The following function, in js-dates.htm, estimates the resolution of
new Date() :-


function Resol() { var J = 0, T0 = XT = T = new Date().getTime()
while (J < 10) {
if (T != XT) { XT = T ; J++ }
T = new Date().getTime() }
document.write(
"about<tt> ", (new Date()-T0)/10, " ms<\/tt>") }



I seek reliable information on resolutions in various systems, in
particular, where not 55 or 10 ms.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

lawrence wrote:

> "Stephen Chalmers" <> wrote in message
>
> Also, I'm used to PHP syntax, so this surprise me:
>
>> if(elem) //all expected divs available
>> moveDivs();
>> else
>> alert('Cannot find div called todd'+i+' ' );
>> }
>
> Does it work just as well if I go:
>
> if(elem) {
> moveDivs();
> } else {
> alert('Cannot find div called todd'+i+' ' );
> }
> }

Yes, of course. Why do you not just RTFM and/or try it?

> Also, I notice that changing the time on the setTimeout doesn't seem
> to speed things up. When I change the 100 to a 10, things seem nearly
> the same. How can that be?

The maximum resolution for a timeout or interval is restricted to
the system timer's resolution. However, you most certainly stumble
over the fact that the numbers mean *milliseconds* (1/1000 of a
second), not seconds. Human perception usually is too slow to
note the difference between these spans of time.

>> setTimeout("moveDivs()", 100);
>
> Sorry for all the dumb questions.

There are no dumb questions, just not thoughtfully enough asked ones.
As for you, many of your questions would have been answered by
reading a decent manual. You have done that when learning PHP, have
you not?

> I'm sure 3 months from now I'll look back on this script and wince at
> my own stupidity.

Probably.


PointedEars