Methods of searching -- re part of: parity of integer sequences

[Rick Shepherd]

Please let me add my name to the people who would appreciate
and actually use some sort of general wildcard searching.

I don't normally like to recommend software but I want to point out
that the following exists and there may be other similar tools available.
Here is an immediate, partial solution for some people.  Back in April,
I found some (Windows) freeware called Hilitext (v1.1) that will highlight
items already displayed *or* about to be displayed in browser (and other
program) window(s).  By default, it will highlight all matches in yellow.
It already supports wildcards (at least of the ? and * kind mentioned below.).
It also supports whole word matching, so, for example, if one wanted to
highlight only all terms,say, that are precisely 23 without matching others
where "23" is embedded within another string of digits, this can be
done easily too.  (This all works fine for me with no glitches using Win 98
SE and Internet Explorer 5 and is supposed to work in many other
environments.).  I found this at www.nonags.com under "Text Utilities"
category near bottom of list.

In addition to the more-or-less standard wildcard capabilities, it could be
useful if search attempts could also specify to match only *up to n*
characters (or terms):  There are cases where you know that the numbers
you are seeking would be near the beginning of a sequence and you
have a fairly good upper bound (but not necessarily lower bound) on how
soon your target should appear.  The lack of this type of search can cause
many false hits, often in the depths of decimal expansions of common
fractions, for example.

One more comment related to searches:  It would be helpful if the (standard)
OEIS search told us how many matches are being displayed!  I've often
found myself counting to see whether I've already got 30 (or just 29) matches
displayed before launching a second, Advanced request asking for 100 (or more).
A simple "There are more matches not displayed" or "All matches are displayed"
would prevent having to do this (and could prevent some unnecessary search
launches too.).

Thanks for prompting this discussion,
Rick (Shepherd)
  ----- Original Message ----- 
  From: Robert G. Wilson v 
  To: David Wilson 
  Cc: jeremy.gardiner at btinternet.com ; Sequence Fanatics 
  Sent: Friday, August 02, 2002 2:20 PM
  Subject: Re: parity of integer sequences


  David,

          I also would like a wild card lookup capability.

  Bob Wilson

  David Wilson wrote:

----- Original Message -----From: mailto:<jeremy.gardiner at btinternet.comTo: mailto:<seqfan at ext.jussieu.frSent: Wednesday, July 31, 2002 5:36 AMSubject: parity of integer sequences
I was thinking about how to categorise integer sequences and I wonder how
useful it would be if the on-line encyclopaedia were to contain a referenceto the parity representation for each sequence?
Many of the entries would be all odd, all even or simply alternating
parity but there are also many more interesting examples such as 1010010001... (A023531), however there is no easy way of data mining these withoutcalculating parity for each sequence.
Of course parity is not the only way to categorise integer sequences but
it is an important property.
Perhaps other people have a view on this?
I agree that parity searches would be useful, however, I disagree withadding additional parity sequence fields to the EIS.The EIS already has two potential sets of sequence fields for each entry,the unsigned sequence (%STU) and the signed sequence (%VWX).  Addinga parity sequence would create additional fields, bloating the databasefurther.The logical extreme, adding a new set of fields to each EIS entry for eachsearch criterion, is clearly silly.I would incline in the other direction, that of decreasing the bulk of theEISdatabase and increasing its search capabilities.  Optimally, each EIS entrywould contain only the signed sequence.  The search criteria would consistof a lookup sequence and a transform function.The lookup sequence would be an extended version of the current lookupsequence. I would recommend adding   ? to match a single unknown element   * to ma
tch zero or more unknown elements   + to match one or more unknown elments   ^ to match the beginning of sequenceThus   13,125 matches sequences containing adjacent elements 13,125   ^13,125 matches sequences starting with 13,125   13,?,125 matches sequences containing 13 followed by 125 with oneintervening element.   13,*,125 matches sequence in which 13 occurs prior to 125.The transform function is a function in the variable "n" applied prior tomatching the lookup.Thus, if the transform function were "n mod 2", and the lookup sequence were0,1,1,0,0,1,1,0,0,1,1,0 we might would match the triangular numbers.  Ileave theexpression syntax undefined, but MMa expressions (for their mathcapabilities) andPerl expressions (for their pattern matching capabilities) spring to mind.This mechanism would provide fairly flexible search capabilities.  We coulduse %STUto store the signed sequence, eli
minate %VWX, and use "abs(n)" function tosearch theunsigned sequences.  I would recommend generating indexes for searches onvariouscommon transform functions such as "n", "abs(n)", "n mod 2", etc.  Searcheson lesscommon transform functions would necessarily be slower, but possible.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.seqfan.eu/pipermail/seqfan/attachments/20020802/0900fb1c/attachment-0001.htm>