Re: Check if it is a number
Re: Check if it is a number
- Subject: Re: Check if it is a number
- From: Nigel Garvey <email@hidden>
- Date: Wed, 4 Dec 2002 15:23:11 +0000
Paul Skinner wrote on Tue, 3 Dec 2002 10:44:19 -0500:
>
On Tuesday, December 3, 2002, at 08:41 AM, Nigel Garvey wrote:
>
>
> "Arthur J. Knapp" wrote on Mon, 02 Dec 2002 10:50:25 -0500:
>
>
>
>>> Date: Sat, 30 Nov 2002 11:46:01 -0500
>
>>> Subject: Re: Check if it is a number
>
>>> From: Paul Skinner <email@hidden>
>
>>
>
>>> NumeralsOnly("12A4B5")-->false
>
>>
>
>>> on NumeralsOnly(n)
>
>>> try
>
>>> n as number
>
>>> return n does not contain "-" and n does not contain "+" and n
>
>>> does
>
>>> not contain " " and n is not ""
>
>>> on error
>
>>> return false
>
>>> end try
>
>>> end NumeralsOnly
>
> .... So if you have a
>
> whole row of 'nots', as in the above handler, you can get a slight
>
> *overall* speed improvement by changing 'and' to 'or' (or vica versa)
>
> and
>
> gathering the 'nots' into one operation at the end:
>
>
>
> return not (n contains "-" or n contains "+" or n contains " " or n
>
> is "")
>
>
>
> The advantage is greater the more tests that are actually carried out.
>
>
Interesting, OMM (AS 1.9) these two are identically quick over 100000
>
iterations.
Hmmm.... Well, assuming you didn't just pit the two lines against each
other with the returns left in, you either have a blindingly fast machine
or things have indeed changed between AS's 1.6 and 1.9. On my G3 400
PowerBook running AS 1.6, timing them over 100000 iterations demonstrates
my point very spectacularly. When n is "-" (ie. the dash is found by the
first test), the "serial not" averages about 663 ticks and the "bracketed
not" about 652 ticks. An interesting and inexplicable advantage to the
latter, but too close to be significant. But when n is "5" (ie. all the
tests have performed), then "serial" takes about 2564 ticks and
"bracketed" about 2446. That's a difference of nearly 2 seconds.
"Bracketed" definitely has less work to do here than "serial" on my
machine.
>
> 2) Even with an empty string, it's faster to test its length than its
>
> identity, so:
>
>
>
> return not ([blah] or [blah] or [blah] or (count n) is 0)
>
>
Really? I'd think the cost of this would be higher.
>
ie. getting the value and comparing it to null vs gettting the value
>
and getting it's count and comparing that to 0.
It's counterintuitive. But again, with 100000 iterations on my PowerBook,
when n *is* a blank string, 'n is ""' takes 225 ticks and '(count n) is
0' takes 69. When n is a five-character string, 'n is ""' takes 572 ticks
and '(count n) is 0' takes 106.
>
> 3) The above notwithstanding, if testing for a decimal point isn't
>
> important, here's another fast variation on Paul's handler:
>
>
>
> on NumeralsOnly(n)
>
> try
>
> n as number
>
> return (count n) = (count n's first word)
>
> on error
>
> return false
>
> end try
>
> end NumeralsOnly
>
>
>
> NG
>
>
Much more concise than my 'naught, naught carry the naught'*, but
>
Arthur already found it troublesome.
Apologies for that. I tested "+" many times during the course of the
morning, but obviously not on that particular effort. :-( Try this. It's
slightly slower than the original with "-", but the same or faster with
everything else:
on NumeralsOnly(n)
try
n as number
return result as string is n and result >= 0
on error
return false
end try
end NumeralsOnly
NG
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.