editiable variables to arguments

[DaveGreens]

I'm using javascript to grab the page url and cut it up so that
variables can be passed- eg images.html?img =23 returns an argument
args[arg] what I can use to display an image from an array.

The problem only comes when I want to perform an action on the
variable.

I can say:

thispage = args[arg]
//This returns the value of the current page.

previouspage = (thispage -1)
//This works ok- it's the page number minus one.

nextpage = (thispage +1)
//This doesn't work. It returns the pagenumber with a 1 appended on
the end. ie if the page was 23 I would get 231.

I've tried -- and ++ aswell, but I can't get the result I want.
How do I do this?

[Richard Cornford]

Re: editiable variables to arguments

"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:4r1x4aq2.f sf@hotpop.com.. .
<snip>[color=blue][color=green]
> > A string.
> > A number (64 bit IEEE double precision floating point).
> > A boolean.
> > A reference (to an object or a function. References to
> > objects include references to the - null - object
> > and functions are really function objects.)
> > Or undefined.[/color]
>
>It makes sense to group functions and objeccts, or objects and
>null, but not both at the same time. To a programmer, the
>"typeof" operator tells the type of a value. It groups objects
>and the null value, but distinguishes functions and objects.
>Internally, functions are objects, but the null value is its own type.[/color]

A reasonable point. typeof may insist that null is an object which
implies that there is a null object and the variable would hold a
reference to it, but the last thing that null will ever do is behave as
if it was an object and null is separately categorised in the spec.

<snip>[color=blue]
>I noted the time taken, and then changed the assignment to x into
> +"4.4E+4";
> Number("4.4E+4" )
> parseFloat("4.4 E+4")
>and compared the times. The results were (approximatly averaged):
> Base unary + Number parseFloat
>IE6 1100 1600 2730 2830
>Moz 1180 2100 7300 6700
>Op7 2150 2800 4520 5320
>(on a 1GHz Athlon CPU)
>
>The unary + is indeed much faster, although neither takes
>significant time. If you only do a few conversions, the
>efficiency is not worth caring about, but if you get into
>the tens of thousands or more, then the diffrerence is
>measurable.[/color]
[color=blue]
>That is, only optimize the inner loop. Or, as a saying goes:
>"10% of the code takes 90% of the execution time".[/color]

Maybe its my obsession with absolute performance but I am inclined to
think that when one approach is objectively optimum then there needs to
be a positive reason for not using it in any context no matter how small
the individual gains. Unary + though is also very short so its use will
reduce the download slightly (even if parenthesised for code clarity).

Incidentally, when I was speed testing the various methods I noticed
that there is quite a variation in performance with different input.
Obviously the length of the string has an influence but also the nature
of the number. If the number is easily represented as an IEEE double
precision float (2 for example) the conversion is faster than when the
result needs some approximation in its representation. But as I recall
the most noticeable differences were when type converting string that
would result in NaN.
[color=blue][color=green]
>>Though integers that exceed the largest
>>integer representable will end up as floats with exponents.[/color]
>
>As they would with Number, parseFloat or parseInt or when written as
>literals. Since Javascript has only one number type, and it
>corresponds to IEEE 754 double-precission (64 bit) floating point
>numbers, it can only represent all integers up to 2^54 exactly.
>The ones below that limit are also floats with exponents, only the
>exponent is zero. The ones above need to have exponents larger than
>zero, and therefore can't range over all the numbers.[/color]

I was considering not even mentioning the limit on integers, I figured
that if the site has 2^54 pages the visitor will die of old age before
they get to 2^54+1 ;-)

Richard.

[Dr John Stockton]

Re: editiable variables to arguments

JRS: In article <MPG.1973d595ca a039fc989790@ne ws-server.nc.rr.co m>,
seen in news:comp.lang. javascript, Dan Brussee <dbrussee@NOTbe tterwaycom
puting.com> posted at Tue, 8 Jul 2003 00:08:55 :-[color=blue]
>
>The reason it does not work with + is that the plus is both the addition
>and concatenation operator.[/color]

// It is also the unary + operator.
[color=blue]
> Since all variables in javascript are the
>same, if you happen to know you are going to add 2 numeric variables,
>you should "parse" them. If integers, use parseInt(var, 10) where 10 is
>the radix (or base) of the number. In your case, I would use:
>
>nextpage = (parseInt(thisp age, 10) + 1);[/color]

or nextpage = +thispage + 1
[color=blue]
>Just be sure that thispage will never overflow as an integer[/color]

Javascript numbers are floats. All positive integer values up to and
including 2^53 = +9,007,199,254, 740,992 can be stored exactly, so 1 can
be added to all but the last; adding 1 to the last has no effect. There
will be no overflow.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Dr John Stockton]

Re: editiable variables to arguments

JRS: In article <bed877$p7j$1$8 300dec7@news.de mon.co.uk>, seen in
news:comp.lang. javascript, Richard Cornford
<Richard@litote s.demon.co.uk> posted at Tue, 8 Jul 2003 02:53:41 :-
[color=blue]
> Though integers that exceed the largest
>integer representable will end up as floats with exponents.[/color]

<pedant> I think you want to think that out again.

Integers become sparse above 2^53 ~ 9.007e15 ; but 2^69, if converted to
string, is of form /\d+/.

The largest /\d+/ in code which gives a Number which converts to /\d+/
is 999999999999999 934469 , which converts to 999999999999999 900000 .

The largest integer representable must be (2^53-1)*2^lots, and is about
1.7e308 .

The smallest positive integer not representable in 2^53+1 =
900719925474099 3 .

</pedant>

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Dr John Stockton]

Re: editiable variables to arguments

JRS: In article <4r1x4aq2.fsf@h otpop.com>, seen in
news:comp.lang. javascript, Lasse Reichstein Nielsen <lrn@hotpop.com >
posted at Tue, 8 Jul 2003 11:41:09 :-
[color=blue]
> Since Javascript has only one number type, and it
>corresponds to IEEE 754 double-precission (64 bit) floating point
>numbers, it can only represent all integers up to 2^54 exactly.
>The ones below that limit are also floats with exponents, only the
>exponent is zero.[/color]

Typo for 2^53 ?

In IEEE 754 double-precision, we have (see <URL:http://www.merlyn.demon.
co.uk/pas-type.htm#FF>) Sign (1), Exponent (11), Mantissa (52); but that
is the fractional part of the mantissa, and there is an implicit binary
'1.' preceding it. Not, AFAICS, that the structure is exposed in
javascript.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 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.zip> Timo Salmi's Turbo Pascal FAQ.

[Lasse Reichstein Nielsen]

Re: editiable variables to arguments

Dr John Stockton <spam@merlyn.de mon.co.uk> writes:
[color=blue]
> Typo for 2^53 ?[/color]

Yes. :(

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'