form validation

Hi,

I have a form with a input field. A user has to give a number greater than
0.
I have build a validation that alerts the user when he gives a double, or a
number less than 0.

But I have follow problem : a users gives the number 000045.

How can I check that?

Alain

re: form validation

U¿ytkownik "alain dhaene" <a.dhaene@instruct.be> napisa³ w wiadomo¶ci
news:40a889ad$0$8394$a0ced6e1@news.skynet.be...[color=blue]
> Hi,
>
> I have a form with a input field. A user has to give a number greater[/color]
than[color=blue]
> 0.
> I have build a validation that alerts the user when he gives a double, or[/color]
a[color=blue]
> number less than 0.
>
> But I have follow problem : a users gives the number 000045.
>
> How can I check that?[/color]

(x&(-1>>>1))==x

(if x is a string, of course :)))

try: '0','5','00045' etc. - true
try: '-1','nonsense','1.5' etc. - false

but... x='' ...is true ( '' is like 0 ;)

v.
PS.:
-1 dec = 111(...)111 bin
-1>>>1 = 011(...)111 bin
first bit is a sign bit...

re: form validation

parseint
GR

alain dhaene a écrit:[color=blue]
> Hi,
>
> I have a form with a input field. A user has to give a number greater than
> 0.
> I have build a validation that alerts the user when he gives a double, or a
> number less than 0.
>
> But I have follow problem : a users gives the number 000045.
>
> How can I check that?
>
> Alain
>
>[/color]

re: form validation

JRS: In article <40a889ad$0$8394$a0ced6e1@news.skynet.be>, seen in
news:comp.lang.javascript, alain dhaene <a.dhaene@instruct.be> posted at
Mon, 17 May 2004 11:45:26 :[color=blue]
>
>I have a form with a input field. A user has to give a number greater than
>0.
>I have build a validation that alerts the user when he gives a double, or a
>number less than 0.
>
>But I have follow problem : a users gives the number 000045.
>
>How can I check that?[/color]

Validation should be done with RegExp, in general.

Your meaning is not clear, but ISTM that you want a number which is a
string of decimal digits not starting with 0; so test for that. Your
case matches the second example at <URL:http://www.merlyn.demon.co.uk/js
-valid.htm#Val> :-

/^[1-9]\d*$/ All-digit, non-zero

You can use \d{a,b} with chosen a,b to limit the length of the string.

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

re: form validation

alain dhaene wrote:[color=blue]
> I have a form with a input field. A user has to give a number greater
> than 0. I have build a validation that alerts the user when he gives a
> double, or a number less than 0.
>
> But I have follow problem : a users gives the number 000045.
>
> How can I check that?[/color]

Let "input" be the unchanged value of the "input" element.

if (input && !isNaN(input = parseInt(input, 10)) && (input >= 0))
{
// valid input; `result' is the parsed value
}
else
{
alert("Invalid input. Must be 0 or a positive integer.");
}


PointedEars

re: form validation

Thomas 'PointedEars' Lahn wrote:[color=blue]
> alain dhaene wrote:[color=green]
>> I have a form with a input field. A user has to give a number
>> greater than 0. I have build a validation that alerts the user when
>> he gives a double, or a number less than 0.
>>
>> But I have follow problem : a users gives the number 000045.
>>
>> How can I check that?[/color]
>
> Let "input" be the unchanged value of the "input" element.
>
> if (input && !isNaN(input = parseInt(input, 10)) && (input >= 0))
> {
> // valid input; `result' is the parsed value
> }
> else
> {
> alert("Invalid input. Must be 0 or a positive integer.");
> }[/color]

That would pass "34.56" as valid input, but it is not a zero or a
positive integer.

It looks to me like a regular expression validation would be best suited
to this case, though the specification is not currently clear enough to
propose anything specific.

Richard.

re: form validation

Richard Cornford wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote:[color=green]
>> Let "input" be the unchanged value of the "input" element.
>>
>> if (input && !isNaN(input = parseInt(input, 10)) && (input >= 0))
>> {
>> // valid input; `result' is the parsed value
>> }
>> else
>> {
>> alert("Invalid input. Must be 0 or a positive integer.");
>> }[/color]
>
> That would pass "34.56" as valid input, but it is not a zero or a
> positive integer.[/color]

Yes, indeed :-/
[color=blue]
> It looks to me like a regular expression validation would be best suited
> to this case, though the specification is not currently clear enough to
> propose anything specific.[/color]

Not necessarily. If it is not an integer, input % 1 is not equal to 0.
In a conditional expression it would then evaluate to `true' which leads
to

if (input
&& !isNaN(input = parseInt(input, 10))
&& input >= 0
&& !(input % 1))
{
// valid input; `result' is the parsed value
}

But it seems to me that Vax' solution is the most efficient one here,
even more efficient than your RegExp proposal.


PointedEars

re: form validation

Thomas 'PointedEars' Lahn wrote:
<snip>[color=blue]
> But it seems to me that Vax' solution is the most efficient
> one here, even more efficient than your RegExp proposal.[/color]

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

Richard.

re: form validation

Thomas 'Ingrid' Lahn wrote:
[color=blue]
> if (input
> && !isNaN(input = parseInt(input, 10))[/color]

s/parseInt/parseFloat/
[color=blue]
> && input >= 0
> && !(input % 1))[/color]


PointedEars

re: form validation

Vax wrote:
[color=blue]
> U¿ytkownik "Richard Cornford" <Richard@litotes.demon.co.uk> napisa³ w
> wiadomo¶ci news:c8e1eu$t$1$8302bc10@news.demon.co.uk...[/color]

Please do not write attribution novels:
<http://netmeister.org/news/learn2quote1.html#ss1.2>
[color=blue][color=green]
>> Thomas 'PointedEars' Lahn wrote:
>> <snip>[color=darkred]
>> > But it seems to me that Vax' solution is the most efficient
>> > one here, even more efficient than your RegExp proposal.[/color]
>>
>> 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[/color]
>
> We know...[/color]

Sure?
[color=blue]
> _Integer_ is 32 bit long, bigger "integer" == float ;)[/color]

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

re: form validation

[...][color=blue]
> Sure?
>[color=green]
> > _Integer_ is 32 bit long, bigger "integer" == float ;)[/color]
>
> No.[/color]

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.

re: form validation

JRS: In article <40AB9276.5060306@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<PointedEars@nurfuerspam.de> posted at Wed, 19 May 2004 18:59:34 :[color=blue]
>Vax wrote:
>[color=green]
>> U¿ytkownik "Richard Cornford" <Richard@litotes.demon.co.uk> napisa³ w
>> wiadomo¶ci news:c8e1eu$t$1$8302bc10@news.demon.co.uk...[/color]
>
>Please do not write attribution novels:
><http://netmeister.org/news/learn2quote1.html#ss1.2>[/color]

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

[color=blue]
>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).[/color]

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.

re: form validation

Vax wrote:
[color=blue]
> [...][color=green]
>> Sure?
>>[color=darkred]
>> > _Integer_ is 32 bit long, bigger "integer" == float ;)[/color]
>>
>> No.[/color]
>
> Ok, ok, in JS we have integer (IEEE)... and integer (binary),[/color]

No, in JS (and other ECMAScript implementations) *all* numeric
values are double-precision IEEE-754 *floating-point* numbers.
[color=blue]
> and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
> (and strings, boolean, float etc.) to integer (bin).[/color]

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

re: form validation

> No, in JS (and other ECMAScript implementations) *all* numeric[color=blue]
> values are double-precision IEEE-754 *floating-point* numbers.[/color]

If the exponent is "neutral", we have 52-bits, that represents integer.
Of course, "machine format" of the number (all numbers) is still "double".
[color=blue][color=green]
> > and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
> > (and strings, boolean, float etc.) to integer (bin).[/color]
>
> No, binary operators convert their operands to 32 bit signed Integers[/color]

...."semantic" :)

v.

re: form validation

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:[color=blue][color=green]
>> No, in JS (and other ECMAScript implementations) *all* numeric
>> values are double-precision IEEE-754 *floating-point* numbers.[/color]
>
> If the exponent is "neutral", we have 52-bits, that represents integer.[/color]

What exactly are you trying to say?
[color=blue]
> Of course, "machine format" of the number (all numbers) is still "double".[/color]

Yes, and you can safely omit the quotation characters.
[color=blue][color=green][color=darkred]
>> > and operators: "^,~,|,&,>>,>>>....." converts integer (IEEE)
>> > (and strings, boolean, float etc.) to integer (bin).[/color]
>>
>> No, binary operators convert their operands to 32 bit signed Integers[/color]
>
> ..."semantic" :)[/color]

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

re: form validation

Thomas 'PointedEars' Lahn <PointedEars@nurfuerspam.de> writes:
[color=blue][color=green][color=darkred]
>>> No, binary operators convert their operands to 32 bit signed Integers[/color]
>>
>> ..."semantic" :)[/color]
>
> What exactly are you trying to say?[/color]

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@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: form validation

JRS: In article <40ABE748.405@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<PointedEars@nurfuerspam.de> posted at Thu, 20 May 2004 01:01:28 :
[color=blue]
>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.)[/color]


I hope you don't mean that.

IEEE Doubles are binary floats.

In IEEE Doubles, all & only those numbers which are powers of two have a
zero fractional part.

You should have written that :-
(Those doubles, when expressed in common decimal, have of course
a fractional part of 0, but they are still _not_ Integers.)



Programmers need to be continuously aware of the actual type that they
are working with, and of its implications.



For example, in another language, I have recently become of a library
routine that is supposed to do Banker's Rounding.

Aside: We should think, for the FAQ, about Banker's Rounding,
in which a.bc5 rounds to x.yz *with z even*.

For rounding to two places, it calculates 1.0/10^2 (by iteration),
divides the number by that, rounds to integer, multiplies by that.

But 10^-2, nominally 0.01, cannot be rendered exactly as a Double.

It has been observed that the supplied function incorrectly rounds
literal 1.875 to 1.87 (contrary to what the Help file says); and that
changing the algorithm to use multiplication by (exact) 100, rounding,
division fixes the error.

The routine in FAQ 4.6 uses the proper arithmetic.

Note : it was written on the presumption that, since M & N are numbers
of places, generally supplied as literals, they would be positive. The
case of M<=0 is equivalent to that of M=0, and may give a deprecated
format; N=0 gives a deprecated but tolerable format, and N<0 gives a
wrong value.


<FAQENTRY> in 4.6, after "successfully", insert ", for M>0, N>0" - or
such other adjustment as appeals.

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

re: form validation

Lasse Reichstein Nielsen wrote:
[color=blue]
> Thomas 'PointedEars' Lahn <PointedEars@nurfuerspam.de> writes:[color=green][color=darkred]
>>>> No, binary operators convert their operands to 32 bit signed Integers
>>> ..."semantic" :)[/color]
>>
>> What exactly are you trying to say?[/color]
>
> 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.[/color]

And how you suggest the binary AND should be computed
if the operands are not in a machine format?


PointedEars

re: form validation

Thomas 'PointedEars' Lahn <PointedEars@nurfuerspam.de> writes:
[color=blue]
> And how you suggest the binary AND should be computed
> if the operands are not in a machine format?[/color]

Ofcourse they are. It just don't have to be an *integer* format.
(It can be, and probably is, but the standard doesn't say that
it has to).

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

re: form validation

Lasse Reichstein Nielsen wrote:
[color=blue]
> Thomas 'PointedEars' Lahn <PointedEars@nurfuerspam.de> writes:[color=green]
>> And how you suggest the binary AND should be computed
>> if the operands are not in a machine format?[/color]
>
> Ofcourse they are. It just don't have to be an *integer* format.[/color]

Name a CPU that does not use integer registers for binary operations.


PointedEars