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

Testing for Well Formed Numeric Field

Expand Messages
  • Art Kocsis
    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
    Message 1 of 4 , Jan 2, 2013
    • 0 Attachment
      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->|
      <any text> + 123<any txt>
      <any text> +123<any txt>
      <any text> - 123<any txt>
      <any text>+ 3<any txt>
      <any text>+ 356456 [next line is at EOF]
      <any text>+ 3

      And these would all be ill-formed, invalid fields:

      |<-test->|
      <any text> -+ 123<any txt> [multiple operators]
      <any text> 2+23<any txt> [embedded operator]
      <any text> - 1 23<any txt> [embedded white space]
      <any text>+ aa 3<any txt> [non-digit character]
      <any text> 2 <any txt> [trailing white space] [next line is at EOF]
      <any text>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.
    • 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 2 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 3 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 4 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.