• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Check if it is a number
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Check if it is a number


  • Subject: Re: Check if it is a number
  • From: has <email@hidden>
  • Date: Fri, 6 Dec 2002 13:15:17 +0000

Paul Skinner wrote:

I thought that the code I posted on Sat Nov 30, 2002 was nice because
you could read it and easily understand it's logic.

Indeed. But that doesn't mean it wasn't full of holes.


I can't imagine that speed is a great consideration to the OP since it
was to verify user input.

I'd agree speed isn't a big issue in a user-input validation routine. Correctness, however, is essential.


But AppleScripters being gluttons for
punishment that they are, this is as fast as I can get it.

There's an old programmer saying I've run across a lot in my travels: make it work, make it right, make it fast.

If speed is your _only_ concern, the fastest script is always:

on run
-- nothing here!
end run

This runs amazingly quick. Sure it doesn't do anything useful, but neither does a validation script that doesn't catch invalid values or reports correct input as invalid. A slow script that works is always preferable to a fast one that doesn't. If you can come up with something both correct _and_ fast, then brilliant. But speed at the cost of reliability is like a 1980s Skoda, with the back wheels falling off whenever you hit the motorway.


P.S. I couldn't get your testing code to work, it always executed the
first if-then statement even when it evaluated to false. Weird. Still
trying to figure it out.


The testing code worked perfectly then... the point of tests is to break things that are breakable; your handler broke, ergo it's broken. All you have to do now is de-break it. :)

Here, I tidied it up the test code to make it easier to understand:

======================================================================

property validVals : {"512", "1", "001", "0.0001", "324.21"...}
property invalidVals : {"", {}, true, 1, "+", "1-", "1.1.1", "one"...}

ignoring hyphens, punctuation, white space, case, diacriticals and
[NO-BREAK]expansion
repeat with valRef in validVals
if (not NumeralsOnly(valRef's contents)) then error "Failed on:
[NO-BREAK]" & valRef's contents
end repeat
repeat with valRef in invalidVals
if NumeralsOnly(valRef's contents) then error "Failed on: " &
[NO-BREAK]valRef's contents
end repeat
end ignoring

return "All tests passed."

======================================================================

Remember to add more test values - the faulty cases I listed in my first mail should be included, along with any others you can think of.


Heck, the "Failed on 256" result caught me off-guard as well. My own tests even surprise me sometimes, picking up problems I'd never have thought of.

After double-checking the test code to make sure it wasn't at fault (always a wise precaution), I worked through your handler's code till I figured out the problem: the 'n contains "-"' test is suceptible to the effects of an external 'ignoring hyphens' block [1].

To avoid the possibility of your handler giving bad results, these comparisons should be wrapped in a 'considering hyphens' block.

on NumeralsOnly(n)
try
n as number
considering hyphens
return (get not ((count of n) = 0 or n contains "-" or n contains "+"))
end considering
on error
return false
end try
end NumeralsOnly

Now run your tests again, and see how far you get. Repeat the test/debug cycle until all tests pass. [2]


has

[1] Considering/ignoring blocks are even more evil than text item delimiters, which is saying something. See how many problems you can diagnose.


[2] After making a couple of fixes I've got it passing the following tests, working on the assumption that only positive integers or reals are allowed [2a]:

property validVals : {"1", "512", "001", "0.01", "0.0001", "324.21", "1000000000", "0.000000000001"}
property invalidVals : {"", " ", {}, {1}, true, 1, "+", "1-", "1.1.1", "one", "-1", "1.0E+5", "1.0E-5"}

Which isn't to say I haven't overlooked some really gnarly values to throw at the thing, but at least it's looking a bit more promising.


[2a] 'NumeralsOnly' is much too vague; the handler name should be changed to something like 'isPositiveNumber'.
--
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
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.
  • Follow-Ups:
    • Re: Check if it is a number
      • From: Paul Skinner <email@hidden>
  • Prev by Date: Re: Run an AppleScript from within an AppleScript
  • Next by Date: Re: Any editor that does vertical cutting-pasting?
  • Previous by thread: Re: Check if it is a number
  • Next by thread: Re: Check if it is a number
  • Index(es):
    • Date
    • Thread