Loading ...
Sorry, an error occurred while loading the content.

Re: Testing for Well Formed Numeric Field

Expand Messages
  • joy8388608
    ... Hi Art. I m not nearly as good at RegExp at others but I ll give you what I have so far. I m unclear about your data and what you mean by the selection
    Message 1 of 4 , Jan 3, 2013
    • 0 Attachment
      --- In ntb-clips@yahoogroups.com, Art Kocsis wrote:
      >
      > I don't have much hair left to pull so maybe you guys can save
      > my scalp and suggest a way to make this search pattern work in
      > a clip.
      >
      > I am trying to verify a selection to be a well formed numeric
      > field. By that I mean, the selection may have leading white space,
      > possibly a plus or minus sign (possibly followed by horizontal
      > white space), followed by one or more decimal digits with no
      > embedded or trailing white space. The total width of the selection
      > is fixed and known and may range from one to a large number. The
      > selection may be preceded or followed by any text. The preceding
      > code guarantees the selection to contain at least one non-white-
      > space character.
      >
      >
      > For example these would all be well formed, valid fields:
      > |<-test->|
      > + 123
      > +123
      > - 123
      > + 3
      > + 356456 [next line is at EOF]
      > + 3
      >
      > And these would all be ill-formed, invalid fields:
      >
      > |<-test->|
      > -+ 123 [multiple operators]
      > 2+23 [embedded operator]
      > - 1 23 [embedded white space]
      > + aa 3 [non-digit character]
      > 2 [trailing white space] [next line is at EOF]
      > a+ 3
      >
      > The RegEx pattern, "^\s*[\+-]?\s*\d*?\K[\D]+?", seemed to work OK
      > in the Toolbar dialog. Although the toolbar Find does not respect
      > selection boundaries for selections less than 24 characters, the
      > matches found for valid fields were outside the selection field
      > and could be testable by their column number.
      >
      > However, in a clip (target fields are preselected),
      >
      > ^!Find "^\s*[\+-]?\s*\d*?\K[\D]+?" HRS
      >
      > yields entirely different results and consistently matches valid
      > operators and white space within the selection. It seems that the
      > clip command is respecting the selection.
      >
      > Upon further investigation, I found that pressing the F3 key to
      > invoke the search (instead of clicking the Find next button),
      > yields the same results as the clip. Another inconsistency of
      > Notetab.
      >
      > Any suggestions on how to make this pattern work in a clip?
      >
      > Darn - I just realized I forgot all about decimal points. Best
      > leave them for later as this clip was just for integers.


      Hi Art.
      I'm not nearly as good at RegExp at others but I'll give you what I have so far. I'm unclear about your data and what you mean by "the selection may be preceded or followed by any text" since your example started with ^\s[\+-] which means start at beginning of line...

      This may help you start down the right path.
      ^\s*[\+\-]?\s*\d+(?=\s*$)

      Something like ^\s*[\+\-]?\s*\d+(\.?\d+)*(?=\s*$)
      may help with decimals as long as you don't have grouping characters.

      Joy
    • Art Kocsis
      ... Actually, the ^ means start of selection, if any, start of line if not. What I was trying to convey was that at this point in my clip a selection exists,
      Message 2 of 4 , Jan 3, 2013
      • 0 Attachment
        At 01-03-2013 23:03 +0000, Joy wrote:
        >Hi Art.
        >I'm not nearly as good at RegExp at others but I'll give you what I have so far. I'm unclear about your data and what you mean by "the selection may be preceded or followed by any text" since your example started with ^\s[\+-] which means start at beginning of line...

        Actually, the "^" means start of selection, if any, start of line if not.

        What I was trying to convey was that at this point in my clip a selection exists, it contains at least one non-white-space character, is restricted to a single line and that the selection could be anywhere in a line - there could be text preceding and/or text following the selection. The "^" was necessary to ensure that the search pattern started from and included the start of the selection.


        >This may help you start down the right path.
        >^\s*[\+\-]?\s*\d+(?=\s*$)

        Thank you for the suggestion. However, that pattern will only find valid numeric strings followed by white space to the EOL. My selections may be followed by any text, not just white space. And I need to ensure that within the selection, no non-digit character appears following the first digit. That is what the [\D] class was supposed to do. Oops! PAUSE. STOP. RETHINK.

        Well now, between the two of our misconceptions, I think we've got it.

        Writing the above explanation evoked a new line of thought. I had been trying to test if an invalid character existed in the selection ("\s*\d*?\K[\D]", a positive negative) and you were going by my stated goal of verifying a valid field ("\s*\d+", a positive positive). I took my approach as I didn't know of a way to ensure that the search didn't stop short of the entire selection. However, that is exactly what the "$" meta character means: End of selection, if any, EOL if not. I had thought the "$" only meant EOL. Your use of it made me look it up. Learned something new.

        So a working search pattern becomes simply:

        ^!Find "^\s*[\+-]?\s*\d+?$" HRS

        Thanks. You did help.

        Now, I wonder if anyone picked up on the different behaviors of Toolbar "Find Text" between the F3 and mouse invocations.


        Art
      • Don
        Seems to work I think ... ^ *( +|-)? *?([ d .]+)(?! )[^ d r n]*$
        Message 3 of 4 , Jan 4, 2013
        • 0 Attachment
          Seems to work I think ...
          ^ *(\+|-)? *?([\d\.]+)(?! )[^\d\r\n]*$

          On 1/3/2013 6:03 PM, joy8388608 wrote:
          > For example these would all be well formed, valid fields:
          >> |<-test->|
          >> + 123
          >> +123
          >> - 123
          >> + 3
          >> + 356456 [next line is at EOF]
          >> + 3
          >>
          >> And these would all be ill-formed, invalid fields:
          >>
          >> |<-test->|
          >> -+ 123 [multiple operators]
          >> 2+23 [embedded operator]
          >> - 1 23 [embedded white space]
          >> + aa 3 [non-digit character]
          >> 2 [trailing white space] [next line is at EOF]
          >> a+ 3
          >>
        Your message has been successfully submitted and would be delivered to recipients shortly.