<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Please let me add my name to the people who would
appreciate</FONT></DIV>
<DIV><FONT face=Arial size=2>and actually use some sort of general wildcard
searching.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I don't normally like to recommend software but I
want to point out</FONT></DIV>
<DIV><FONT face=Arial size=2>that the following exists and there may be other
similar tools available.</FONT></DIV>
<DIV><FONT face=Arial size=2>Here is an immediate, partial solution for some
people. Back in April,</FONT></DIV>
<DIV><FONT face=Arial size=2>I found some</FONT><FONT face=Arial size=2>
(Windows) freeware called Hilitext (v1.1) that will highlight</FONT></DIV>
<DIV><FONT face=Arial size=2>items already</FONT><FONT face=Arial size=2>
displayed *or* about to be displayed in browser (and other</FONT></DIV>
<DIV><FONT face=Arial size=2>program)</FONT><FONT face=Arial size=2>
window(s). By</FONT><FONT face=Arial size=2> default, it will highlight
all matches in yellow.</FONT></DIV>
<DIV><FONT face=Arial size=2>It already</FONT><FONT face=Arial size=2> supports
wildcards (at least of the ? and * kind mentioned below.).</FONT></DIV>
<DIV><FONT face=Arial size=2>It also supports whole word matching, so, for
example, if one wanted to</FONT></DIV>
<DIV><FONT face=Arial size=2>highlight only all terms,say, that are precisely 23
without matching others</FONT></DIV>
<DIV><FONT face=Arial size=2>where "23" is embedded within another string of
digits, this can be</FONT></DIV>
<DIV><FONT face=Arial size=2>done easily too. (This all works fine for me
with no glitches using Win 98</FONT></DIV>
<DIV><FONT face=Arial size=2>SE and Internet Explorer 5 and is supposed to work
in many other</FONT></DIV>
<DIV><FONT face=Arial size=2>environments.). I found this at <A
href="http://www.nonags.com">www.nonags.com</A> under "Text
Utilities"</FONT></DIV>
<DIV><FONT face=Arial size=2>category near bottom of list.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>In addition to the more-or-less standard wildcard
capabilities, </FONT><FONT face=Arial size=2>it could be</FONT><FONT face=Arial
size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>useful if search attempts could </FONT><FONT
face=Arial size=2>also specify to match only *up to n*</FONT></DIV>
<DIV><FONT face=Arial size=2>characters</FONT><FONT face=Arial size=2> (or
terms):</FONT><FONT face=Arial size=2> There are cases where you know that
the numbers</FONT></DIV>
<DIV><FONT face=Arial size=2>you are</FONT><FONT face=Arial size=2> seeking
</FONT><FONT face=Arial size=2>would be near the beginning of a sequence and
you</FONT></DIV>
<DIV><FONT face=Arial size=2>have a</FONT><FONT face=Arial size=2>
fairly</FONT><FONT face=Arial size=2> good upper bound (but not necessarily
lower bound) on how</FONT></DIV>
<DIV><FONT face=Arial size=2>soon your target should appear. The lack of
this</FONT><FONT face=Arial size=2> type of search can cause</FONT></DIV>
<DIV><FONT face=Arial size=2>many false hits, often in the depths of
</FONT><FONT face=Arial size=2>decimal expansions of common</FONT></DIV>
<DIV><FONT face=Arial size=2>fractions, for example.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>One more comment related to searches: It
would be helpful if the (standard)</FONT></DIV>
<DIV><FONT face=Arial size=2>OEIS search told us how many matches are being
displayed! I've often</FONT></DIV>
<DIV><FONT face=Arial size=2>found myself counting to see whether I've already
got 30 (or just 29) matches</FONT></DIV>
<DIV><FONT face=Arial size=2>displayed before launching a second, Advanced
request asking for 100 (or more).</FONT></DIV>
<DIV><FONT face=Arial size=2>A simple "There are more matches not displayed" or
"All matches are displayed"</FONT></DIV>
<DIV><FONT face=Arial size=2>would prevent having to</FONT><FONT face=Arial
size=2> do this (and could prevent some unnecessary search</FONT></DIV>
<DIV><FONT face=Arial size=2>launches too.).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Thanks for prompting this discussion,</FONT></DIV>
<DIV><FONT face=Arial size=2>Rick (Shepherd)</FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:rgwv@kspaint.com" title=rgwv@kspaint.com>Robert G. Wilson
v</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:davidwwilson@attbi.com" title=davidwwilson@attbi.com>David
Wilson</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A
href="mailto:jeremy.gardiner@btinternet.com"
title=jeremy.gardiner@btinternet.com>jeremy.gardiner@btinternet.com</A> ; <A
href="mailto:seqfan@ext.jussieu.fr" title=seqfan@ext.jussieu.fr>Sequence
Fanatics</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, August 02, 2002 2:20
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: parity of integer
sequences</DIV>
<DIV><BR></DIV>David,<BR><BR> I also
would like a wild card lookup capability.<BR><BR>Bob Wilson<BR><BR>David
Wilson wrote:<BR>
<BLOCKQUOTE cite="mid:000701c23996$9213bd40$75e99318@z0e8q1" type="cite"><PRE wrap="">----- Original Message -----<BR>From: <A class=moz-txt-link-rfc2396E href="mailto:<jeremy.gardiner@btinternet.com">mailto:<jeremy.gardiner@btinternet.com</A><BR>To: <A class=moz-txt-link-rfc2396E href="mailto:<seqfan@ext.jussieu.fr">mailto:<seqfan@ext.jussieu.fr</A><BR>Sent: Wednesday, July 31, 2002 5:36 AM<BR>Subject: parity of integer sequences<BR><BR><BR></PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">I was thinking about how to categorise integer sequences and I wonder how<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->useful it would be if the on-line encyclopaedia were to contain a reference<BR>to the parity representation for each sequence?<BR></PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Many of the entries would be all odd, all even or simply alternating<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->parity but there are also many more interesting examples such as 1010010001<BR>... (A023531), however there is no easy way of data mining these without<BR>calculating parity for each sequence.<BR></PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Of course parity is not the only way to categorise integer sequences but<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->it is an important property.<BR></PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Perhaps other people have a view on this?<BR></PRE></BLOCKQUOTE><PRE wrap=""><!----><BR>I agree that parity searches would be useful, however, I disagree with<BR>adding additional parity sequence fields to the EIS.<BR><BR>The EIS already has two potential sets of sequence fields for each entry,<BR>the unsigned sequence (%STU) and the signed sequence (%VWX). Adding<BR>a parity sequence would create additional fields, bloating the database<BR>further.<BR>The logical extreme, adding a new set of fields to each EIS entry for each<BR>search criterion, is clearly silly.<BR><BR>I would incline in the other direction, that of decreasing the bulk of the<BR>EIS<BR>database and increasing its search capabilities. Optimally, each EIS entry<BR>would contain only the signed sequence. The search criteria would consist<BR>of a lookup sequence and a transform function.<BR><BR>The lookup sequence would be an extended version of the current lookup<BR>sequence. I would recommend adding<BR><BR> ? to match a single unknown element<BR> * to ma
tch zero or more unknown elements<BR> + to match one or more unknown elments<BR> ^ to match the beginning of sequence<BR><BR>Thus<BR><BR> 13,125 matches sequences containing adjacent elements 13,125<BR> ^13,125 matches sequences starting with 13,125<BR> 13,?,125 matches sequences containing 13 followed by 125 with one<BR>intervening element.<BR> 13,*,125 matches sequence in which 13 occurs prior to 125.<BR><BR>The transform function is a function in the variable "n" applied prior to<BR>matching the lookup.<BR>Thus, if the transform function were "n mod 2", and the lookup sequence were<BR>0,1,1,0,0,1,1,0,0,1,1,0 we might would match the triangular numbers. I<BR>leave the<BR>expression syntax undefined, but MMa expressions (for their math<BR>capabilities) and<BR>Perl expressions (for their pattern matching capabilities) spring to mind.<BR><BR>This mechanism would provide fairly flexible search capabilities. We could<BR>use %STU<BR>to store the signed sequence, eli
minate %VWX, and use "abs(n)" function to<BR>search the<BR>unsigned sequences. I would recommend generating indexes for searches on<BR>various<BR>common transform functions such as "n", "abs(n)", "n mod 2", etc. Searches<BR>on less<BR>common transform functions would necessarily be slower, but possible.<BR><BR><BR></PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>