<html>
<head>
</head>
<body>
David,<br>
<br>
I also would like a wild card lookup capability.<br>
<br>
Bob Wilson<br>
<br>
David Wilson wrote:<br>
<blockquote type="cite" cite="mid:000701c23996$9213bd40$75e99318@z0e8q1">
<pre wrap="">----- Original Message -----<br>From: <a class="moz-txt-link-rfc2396E" href="mailto:jeremy.gardiner@btinternet.com"><jeremy.gardiner@btinternet.com></a><br>To: <a class="moz-txt-link-rfc2396E" href="mailto:seqfan@ext.jussieu.fr"><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>
</body>
</html>