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?

 

[Dr John Stockton]

JRS: In article <[email protected]>,
seen in Dan Brussee <dbrussee@NOTbetterwaycom
puting.com> posted at Tue, 8 Jul 2003 00:08:55 :-

The reason it does not work with + is that the plus is both the addition
and concatenation operator.

// It is also the unary + operator.

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(thispage, 10) + 1);

or nextpage = +thispage + 1

Just be sure that thispage will never overflow as an integer

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.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Richard Cornford

Though integers that exceed the largest
integer representable will end up as floats with exponents.

<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 999999999999999934469 , which converts to 999999999999999900000 .

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 =
9007199254740993 .

</pedant>

 

[Richard Cornford]

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.

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.

I noted the time taken, and then changed the assignment to x into
+"4.4E+4";
Number("4.4E+4")
parseFloat("4.4E+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.

That is, only optimize the inner loop. Or, as a saying goes:
"10% of the code takes 90% of the execution time".

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.

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.

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]

JRS: In article <[email protected]>, seen in

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.

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.

 

[Lasse Reichstein Nielsen]

Typo for 2^53 ?

Yes.

/L