form validation

Richard Cornford wrote:

Thomas 'PointedEars' Lahn wrote:
Thomas 'Ingrid' Lahn wrote:
if (input
&& !isNaN(input = parseInt(input, 10))

s/parseInt/parseFloat/
snip

Ahh, you are at that again. parseFloat is certainly needed with your
following modulo test over parseInt. I still see some problematic
string; "234Z" will look like an integer.

Well, shouldn't an application be this tolerant about user's typos?

I would suggest a forced
type-conversion to a number as that would produce NaN with the preceding
string, but that only reduces the possibilities to problems arising from
"0x234" and the like.

I do not see a problem in deliberately typed hexadecimal literals.
But I see a problem in your "the like" since literals with leading
zero could be interpreted as octal values, depending on the
implementation. So one could strip the leading zeroes with a
RegExp prior to conversion but then you could drop the whole thing
and simply do input.replace(/^0+/, "").test(/^\d*[1-9](\.0*)?$/)
and the like.


PointedEars

Thomas 'PointedEars' Lahn wrote:
Thomas 'Ingrid' Lahn wrote:
if (input
&& !isNaN(input = parseInt(input, 10))

s/parseInt/parseFloat/
snip

Ahh, you are at that again. parseFloat is certainly needed with your
following modulo test over parseInt. I still see some problematic
string; "234Z" will look like an integer.

Well, shouldn't an application be this tolerant about user's typos?

I would suggest a forced
type-conversion to a number as that would produce NaN with the preceding
string, but that only reduces the possibilities to problems arising from
"0x234" and the like.

I do not see a problem in deliberately typed hexadecimal literals.
But I see a problem in your "the like" since literals with leading
zero could be interpreted as octal values, depending on the
implementation. So one could strip the leading zeroes with a
RegExp prior to conversion but then you could drop the whole thing
and simply do /^\d*[1-9](\.0*)?$/.test(input.replace(/^0+/, ""))
and the like.


PointedEars

U¿ytkownik "Richard Cornford" <Richard (AT) litotes (DOT) demon.co.uk> napisa³ w
wiadomo¶ci news:c8e1eu$t$1$8302bc10 (AT) news (DOT) demon.co.uk...

Thomas 'PointedEars' Lahn wrote:
snip
But it seems to me that Vax' solution is the most efficient
one here, even more efficient than your RegExp proposal.

The use of bitwise AND limits the integer range to only those positive
integers that can be expressed as a signed 32 bit integer. We don't know
whether that is acceptable, but it is entirely possible that it would

We know...
_Integer_ is 32 bit long, bigger "integer" == float

v.

Vax wrote:

U¿ytkownik "Richard Cornford" <Richard (AT) litotes (DOT) demon.co.uk> napisa³ w
wiadomo¶ci news:c8e1eu$t$1$8302bc10 (AT) news (DOT) demon.co.uk...

Please do not write attribution novels:
<http://netmeister.org/news/learn2quote1.html#ss1.2>

Thomas 'PointedEars' Lahn wrote:
snip
But it seems to me that Vax' solution is the most efficient
one here, even more efficient than your RegExp proposal.

The use of bitwise AND limits the integer range to only those positive
integers that can be expressed as a signed 32 bit integer. We don't know
whether that is acceptable, but it is entirely possible that it would

We know...

Sure?

_Integer_ is 32 bit long, bigger "integer" == float

No. You seem to miss the fact that there is no distinction between
integers and floats in ECMAScript and conforming implementations
when it comes to data type. Every value of type Number and every
Number object in those languages represents a double-precision
floating-point number based on the IEEE-754 standard (which can
lead to calculation behavior looking strange to the uninitiated,
see the FAQ).

But bitwise operators (need to) make the distinction (AIUI operation must
be done using the CPU's 32-bit registers [EAX, EBX aso.] after all, even
if the compiled bytecode is executed by the VM at first), so your solution
is indeed restricted to the signed 32 bit Integer subset of numbers (where
"Integer" means the _machine_ data type). Example:

var x = Math.pow(2, 30); // 1073741824
alert((x & (-1 >>> 1)) == x); // true, OK since x is a math. integer

x = Math.pow(2, 31); // 2147483648
alert((x & (-1 >>> 1)) == x); // false, although x is a math. integer;
// it is the same if x is typed as literal

<http://jibbering.com/faq/#FAQ4_7>
<http://www.mozilla.org/js/language/>
<http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/expr.html#1008505>
<http://en.wikipedia.org/wiki/Integer_(computer_science)>


PointedEars

[...]

Sure?

_Integer_ is 32 bit long, bigger "integer" == float

No.

Ok, ok, in JS we have integer (IEEE)... and integer (binary),
and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
(and strings, boolean, float etc.) to integer (bin).

Sorry, but my "english" is to bad, to write posts like "manuals".
I prefer other languages... JS, C, PHP... etc. ;D

v.

JRS: In article <40AB9276.5060306 (AT) PointedEars (DOT) de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<PointedEars (AT) nurfuerspam (DOT) de> posted at Wed, 19 May 2004 18:59:34 :

Vax wrote:

U¿ytkownik "Richard Cornford" <Richard (AT) litotes (DOT) demon.co.uk> napisa³ w
wiadomo¶ci news:c8e1eu$t$1$8302bc10 (AT) news (DOT) demon.co.uk...

Please do not write attribution novels:
http://netmeister.org/news/learn2quote1.html#ss1.2

There is, as you well know, no such requirement in the RFCs; the
document you quote has no relevant authority. Terminate intestinal
retrostalsis.

But bitwise operators (need to) make the distinction (AIUI operation must
be done using the CPU's 32-bit registers [EAX, EBX aso.] after all, even
if the compiled bytecode is executed by the VM at first), so your solution
is indeed restricted to the signed 32 bit Integer subset of numbers (where
"Integer" means the _machine_ data type).

I recall nothing in ECMA-262 which says that the CPU must have 320bit
registers, and nothing which says that, if it does, they must include
ones named EAX, EBX, usw (BTW, don't fabricate abbreviations, especially
in a language which is not your own), and nothing which says that the
machine data type must be 32-bit.

All it says is that the operations in question must give 32-bit results.

Turbo Pascal uses only 16-bit code; however, it has a 32-bit integer
data type.

Future PC CPUs will have a 64-bit machine data type; yet they will of
necessity run older code.

Stick to what you know about.

--
© 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.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.

Vax wrote:

[...]
Sure?

_Integer_ is 32 bit long, bigger "integer" == float

No.

Ok, ok, in JS we have integer (IEEE)... and integer (binary),

No, in JS (and other ECMAScript implementations) *all* numeric
values are double-precision IEEE-754 *floating-point* numbers.

and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
(and strings, boolean, float etc.) to integer (bin).

No, binary operators convert their operands to 32 bit signed Integers prior
to operation (i.e. they treat them as Integers), but the operation returns
IEEE-754 doubles as well. (Those doubles have of course a fractional part
of 0, but they are still _not_ Integers.)


PointedEars

No, in JS (and other ECMAScript implementations) *all* numeric
values are double-precision IEEE-754 *floating-point* numbers.

If the exponent is "neutral", we have 52-bits, that represents integer.
Of course, "machine format" of the number (all numbers) is still "double".

and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
(and strings, boolean, float etc.) to integer (bin).

No, binary operators convert their operands to 32 bit signed Integers

...."semantic"

v.

Please include a *short* attribution line like the following one
so it can be seen at a glance who wrote what of the quoted material.

Vax wrote:

No, in JS (and other ECMAScript implementations) *all* numeric
values are double-precision IEEE-754 *floating-point* numbers.

If the exponent is "neutral", we have 52-bits, that represents integer.

What exactly are you trying to say?

Of course, "machine format" of the number (all numbers) is still "double".

Yes, and you can safely omit the quotation characters.

and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
(and strings, boolean, float etc.) to integer (bin).

No, binary operators convert their operands to 32 bit signed Integers

..."semantic"

What exactly are you trying to say?

From the ECMAScript Specification Edition 3:

9.6 ToUint32: (Unsigned 32 Bit Integer)

The operator ToUint32 converts its argument to one of 2^32 integer values
in the range 0 through (2^32)−1, inclusive. This operator functions as
follows:

1. Call ToNumber on the input argument.
2. If Result(1) is NaN, +0, −0, +∞, or −∞, return +0.
3. Compute sign(Result(1)) * floor(abs(Result(1))).
4. Compute Result(3) modulo 2^32; that is, a finite integer value k of
Number type with positive sign and less than 2^32 in magnitude such
the mathematical difference of Result(3) and k is mathematically an
integer multiple of 2^32.
5. Return Result(4).

NOTE Given the above definition of ToUInt32:

Step 5 is the only difference between ToUint32 and ToInt32.

The ToUint32 operation is idempotent: if applied to a result that it
produced, the second application leaves that value unchanged.

ToUint32(ToInt32(x)) is equal to ToUint32(x) for all values of x. (It
is to preserve this latter property that +∞ and −∞ are mapped to +0.)

ToUint32 maps −0 to +0.

[...]
11.7.3 The Unsigned Right Shift Operator ( >>> )

Performs a zero-filling bitwise right shift operation on the left operand
by the amount specified by the right operand.

The production ShiftExpression : ShiftExpression >>> AdditiveExpression is
evaluated as follows:

1. Evaluate ShiftExpression.
2. Call GetValue(Result(1)).
3. Evaluate AdditiveExpression.
4. Call GetValue(Result(3)).
5. Call ToUint32(Result(2)).
6. Call ToUint32(Result(4)).
7. Mask out all but the least significant 5 bits of Result(6), that
is, compute Result(6) & 0x1F.
8. Perform zero-filling right shift of Result(5) by Result(7) bits.
Vacated bits are filled with zero. The result is an unsigned 32 bit
integer.
9. Return Result(8).

HTH

PointedEars

Thomas 'PointedEars' Lahn <PointedEars (AT) nurfuerspam (DOT) de> writes:

No, binary operators convert their operands to 32 bit signed Integers

..."semantic"

What exactly are you trying to say?

Perhaps that the specification doesn't say that it converts to an
integer machine *format*, just that it converts it to an integer
*number* in a range representable by 32 bits.

/L
--
Lasse Reichstein Nielsen - lrn (AT) hotpop (DOT) com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'