[seqfan] Re: SeqFan Digest, Vol 42, Issue 7
Antti Karttunen
antti.karttunen at gmail.com
Tue Mar 20 19:42:50 CET 2012
On Sun, Mar 18, 2012 at 9:23 PM, <seqfan-request at list.seqfan.eu> wrote:
> Message: 9
> Date: Sat, 17 Mar 2012 13:26:56 -0700
> From: Marc LeBrun <mlb at well.com>
> To: Sequence Fanatics Discussion list <seqfan at list.seqfan.eu>
> Subject: [seqfan] Re: Linked Open Data (LOD) and the OEIS
> Message-ID: <CB8A41A0.AAE0%mlb at well.com>
> Content-Type: text/plain; charset="US-ASCII"
>
>>="Antti Karttunen" <antti.karttunen at gmail.com>
>> Just a couple of questions:
>
> Interesting questions. I'll try to make some cogent comments, but with the
> disclaimer that "I'm not a professional ontologist, I just play one on TV":
>
>> Axxxxxx --is_a_composition_of--> Ayyyyyy, Azzzzzz
>> (this latter meaning something like Axxxxxx(n) = Ayyyyyy(Azzzzzz(n)) )?
>
> A key design discipline that makes a lot of this semantic stuff "work" is to
> represent ALL the "knowledge" uniformly using nothing but triples of URIs.
>
> These simple assertions can get tied together in various ways to form more
> complex relationships, either statically or dynamically:
>
> One simple way is to have multiple triples asserting things "about" Axxxxxx
> coordinate together by convention. For example if Ax = Ay(Az)
> Axxxxxx --isMappingFrom--> Azzzzzz
> Axxxxxx --isMappingVia--> Ayyyyyy
>
> However this is too simple if we also can have Ax = Au(Av). One solution
> could be to introduce new entities, whose URI's are used as "subjects" in
> some triples and "relations" in others:
> Au(.) --isMappingVia--> Auuuuuu
> Axxxxxx --Au(.)--> Avvvvvv
Wouldn't it be better if we make a relation out of the "inner"
sequence (the indexing sequence), as:
Av(.) --isIndexingWith--> Av
Auuuuuu --Av(.)--> Axxxxxx
to signify Ax = Au(Av).
Then we might even have "anonymous" or postulated sequences
(Cf. Skolem functions???), so for example:
A005117(.) --isIndexingWith--> A005117
Aunknown --A005117(.)--> A003649
(This inspired by David Wilson's ideas from 26 Jul 1999, attached below.)
For the convolution, which is commutative, I guess we get some
redundancy, e.g.:
convolved_with_A000045 --isConvolutionWith--> A000045
convolved_with_A000108 --isConvolutionWith--> A000108
A000045 --convolved_with_A000108--> A090826
A000108 --convolved_with_A000045--> A090826
Yours,
Antti
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <wilson at ctron.com>
Sender: wilson at cabletron.com
Message-Id: <379C93C8.D4B200B2 at ctron.com>
Date: Mon, 26 Jul 1999 12:58:48 -0400
From: "David W. Wilson" <wilson at cabletron.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: Antti Karttunen <karttu at walrus.megabaud.fi>
Cc: seqfan at ext.jussieu.fr
Subject: Re: "tabf", new keyword
References: <199907242147.RAA27666 at fry.research.att.com>
<379B0B15.5EA6 at walrus.megabaud.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 310
Precedence: list
IMHO, the "tabl", "tabf", "tabh", ad infinitum approach to dealing with
tables is moving in a bad direction, and will not do service to the
database in the long run. I propose the following solution to the
table problem that deals with the real weakness, which is the indexing
scheme.
My proposal is to modify the current %O entry to specify of one or more
index sequences. For instance, the %O line of A000040 (the prime
numbers) would become:
%O A000040 A000027
This says that A000040 is indexed on A000027 (the nonnegative integers).
Thus we have
n = A000027 1 2 3 4 5 6 7 ...
a(n) = A000040 2 3 5 7 11 13 17 ...
This is much prettier and more general that the current scheme, which
allows only consecutive indices. For instance, we can now express that
A003649 is indexed on the squarefrees by stating:
%O A003649 A005117
For tables, we give a %O line with two index sequences. For instance:
%O A007318 A003056 A002262
gives
x = A003056 0 1 1 2 2 2 3 ...
y = A002262 0 0 1 0 1 2 0 ...
a(x,y) = A007318 1 1 1 1 2 1 1 ...
This approach allows us to build free-form tables of any dimension. It
transforms the integer sequence database to an integer function database,
which is really what we want if we are including tables.
Using this approach, it is easy to tell whether we are dealing with a
sequence or with a higher-dimensional table.
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <njas at research.att.com>
Date: Mon, 26 Jul 1999 23:12:46 -0400 (EDT)
From: "N. J. A. Sloane" <njas at research.att.com>
Message-Id: <199907270312.XAA06417 at fry.research.att.com>
To: seqfan at ext.jussieu.fr
Subject: Re: "tabf", new keyword
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 312
Precedence: list
i think david wilson's proposal is brilliant, and would indeed
many of the indexing problems.
if only he had suggested this 10 years ago
rather than changing all 50,000 %O lines, a more feasible
way to follow his suggestion would be to mention this
in Comment (%C) lines: Indexed by A012345 (say).
To specify that the indices run from (say) 7 to infinity,
one could say
Indexed by A001477 (n>=7)
or for arrays, n indexed by A000027, 1<=k<=n.
In most cases it won't convey any more
information than is there now, in fact.
But for sequences connected with finite geometries,
where the index often runs through the prime powers,
it will be useful.
Neil Sloane
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <wilson at ctron.com>
Sender: wilson at cabletron.com
Message-Id: <379DDCB9.10F85DE8 at ctron.com>
Date: Tue, 27 Jul 1999 12:22:18 -0400
From: "David W. Wilson" <wilson at cabletron.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: "N. J. A. Sloane" <njas at research.att.com>
Cc: seqfan at ext.jussieu.fr
Subject: EIS indexing proposal
References: <199907270312.XAA06417 at fry.research.att.com>
Content-Type: multipart/alternative;
boundary="------------57C9B35640C91F8C6A434550"
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 313
Precedence: list
--------------57C9B35640C91F8C6A434550
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
OK, since I get a rave review, here's my full-blown proposal for
generalized indexing of Sloane sequences:
Redefine the %O line to support a simple index sequence description
language:
<oline> := "%O" <anum> <int> ";" <mdidx> // %O line
<mdidx> := <idx> ( "X" <idx> )* // Multi-dimensional index
<idx> := <idx> ( "," <idx> )* // Concatenated index
<idx> := <int> to <xint> by <int> // Integer-spaced interval index
<idx> := <int> to <xint> // Unit-spaced interval index
<idx> := <int> // Integer index
<idx> := <anum> // Sloane sequence index
<xint> := <int> | "inf" | "-inf" | "?" // Extended integer
<int> := integer constant // Integer
<anum> := Sloane A-number // Sloane sequence A-number
Thus we have:
%O A000040 1; 1 to inf // 1, 2, 3, 4, ...
%O A000367 6; 0 to inf by 2 // 0, 2, 4, 6, ...
%O A001918 2; A000040 // 2, 3, 5, 7, 11, ...
%O A002181 2; A002202 // 1, 2, 4, 6, 8, ...
%O A007318 5; A003056 X A002262 // (0,0), (1,0), (1,1), ...
In the new %O line, the first number is the same as the second number
of the current %O line, that is, the raw index of the first nontrivial
element (or 0 if no such element exists). The expression after the
semicolon describes the index sequence. The free-form indexing allows
us to deal with multi-dimensional integer functions, nonstandard
indexing, unknown elements, etc.
The simplest index sequences (finite sets or ranges, natural numbers,
even numbers, etc) can be described in a straightforward fasion (e.g,
"1 to inf" as opposed to "A000027"). Describing the index sequence on
the %O line allows programs to easily obtain the index sequence (harder
if index information is buried in a comment on a %C line).
In most cases, the existing %O format can be automatically converted to
the new %O format without changing the meaning at all. For instance,
with an infinite sequence it suffices to change "%O A002859 x,y" to
"%O A002859 y; x to inf", and the fix for finite full sequences is
equally trivial. Only non-full finite sequences need be considered
case-by-case.
After conversion, we have a means to specify indexing for tabular and
nonstandard sequences. This doesn't have to be done at one shot for
50,000 sequences, but can be improved over time like other information
in the database.
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <wilson at ctron.com>
Sender: wilson at cabletron.com
Message-Id: <379DF7FD.95492F31 at ctron.com>
Date: Tue, 27 Jul 1999 14:18:37 -0400
From: "David W. Wilson" <wilson at cabletron.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: "Eric W. Weisstein" <eww at wolfram.com>, Neil Sloane
<njas at research.att.com>, Sequence Fans <seqfan at ext.jussieu.fr>
Cc: "David W. Wilson" <wilson at cabletron.com>
Subject: Re: Tabular sequences
References: <Pine.LNX.4.10.9907271114470.14271-100000 at dalembert.wolfram.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 314
Precedence: list
Eric W. Weisstein wrote:
> Hi, David.
>
> I sent this to NJAS and to seqfan this morning but it bounced back from
> seqfan for the moment, so I'll send it to you directly until I can get my
> e-mail address updated for submissions. I haven't looked at your proposal
> in enough detail to see how it differs yet, but looks as if we're thinking
> along similar lines...
>
> Cheers,
> -E
I think that we were basically thinking along the same lines, and I think
both our ideas have merit. I think mine is better with respect to describing
the index sequence, while yours addresses issues of table formatting that
mine does not.
In my proposal, the %O line syntax is altered to accomodate a description of
the index sequence. This does not require a new label, like %i.
In my proposal, the index sequence is specified in a language that expresses
the index sequence in terms of simple explicit sequences, Sloane sequences,
and simple combinations thereof. For instance, any of the following are valid
ways to describe an index sequence:
"1, 2, 3, 5" for (1, 2, 3, 5)
"1 to inf" for (1, 2, 3, 4, ...)
"0 to inf by 2" for (0, 2, 4, 6, ...)
"0 to -inf by 2" for (0, -2, -4, -6, ...)
"1 to ?" for (1, 2, 3, 4, ..., unknown value)
"1, 2, 3 to inf by 2" for (1, 2, 3, 5, 7, ...)
"A000027" for (1, 2, 3, 4, 5, ...) (but "1 to inf" is clearer)
1, A000040 for (1, 2, 3, 5, 7, ...) (1 + primes)
"A003056 X A002262" for ((0, 0), (1, 0), (1, 1), (2, 0), (2, 1),
(2, 2), (3, 0), ...)
Ability to use expressions like "5, 7 to inf" would avoid devoting A-numbers
to arcane index sequences.
It would be easy enough to augment the language with macros for common
index sequences like "N", "Z+", "Z" (for 0, 1, -1, 2, -2, ...),
"primes", "primePowers",
"squarefrees", diagonalTable(0 to inf, 0 to inf) (for ((0, 0), (1, 0),
(1, 1), (2, 0), (2, 1),
(2, 2), (3, 0), ...)) etc.
With regard to formatting 2-d tables, one might provide a matrix from Cartesian
orientation to the preferred orientation. The default matrix would be
"1 0 0 1",
indicating x increases to the right (1, 0), and y increases upward (0,
1). The common
book-style table x increments right and y down if "1 0 0 -1".
Supposing the choice
numbers are indexed according to the choice function, "-1 -1 2 0" or
"-1 -.5 1 0"
gives a Pascal triangle orientation.
Once table orientation is established, cells can be filled with values
and the resulting
table centered on the page, so centering is not really an issue.
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <eww at wolfram.com>
X-Authentication-Warning: dalembert.wolfram.com: eww owned process doing -bs
Date: Tue, 27 Jul 1999 13:38:18 -0500 (CDT)
From: "Eric W. Weisstein" <eww at wolfram.com>
To: Sequence Fans Mailing List <seqfan at ext.jussieu.fr>
Subject: Table formatting proposal
Message-Id: <Pine.LNX.4.10.9907271336380.14271-100000 at dalembert.wolfram.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 315
Precedence: list
Here's the original message to which David Wilson responded. Sorry for
any confusion the reply-before-actual-message caused...
-E
On Mon, 26 Jul 1999, N. J. A. Sloane wrote:
> i think david wilson's proposal is brilliant, and would indeed
> many of the indexing problems.
Although Neil's opinion is the one that really matters on such issues :),
I also think David has a great idea here.
> if only he had suggested this 10 years ago
>
> rather than changing all 50,000 %O lines, a more feasible way to
> follow his suggestion would be to mention this in Comment (%C) lines:
> Indexed by A012345 (say).
IMHO, I think the comment line should stay comments-only (and not include
actual content information like index sequences).
However, here's a fairly detailed, but I think very general and precise,
proposal for dealing with the general problem of tabular sequences. How
about adding a new optional tag (say %f for "formatting") which could
specify, for a tabl/tabf sequence, the sequence numbers indexing the
sequence at hand, the offsets, a reference sequence giving the number of
elements in each row, and the preferred alignment of rows = C, L, or R?
I think this would fairly precisely specify the format of a tabular
sequence (somebody correct me if there are ambiguities which have escaped
me).
Take, for example, Pascal's triangle read by rows
ID Number: A007318 (Formerly M0082)
Sequence: 1,1,1,1,2,1,1,3,3,1,1,4,6,4,1,1,5,10,10,5,1,1,6,15,20,15,6,
1,1,7,21,35,35,21,7,1,1,8,28,56,70,56,28,8,1,1,9,36,84,126,
126,84,36,9,1,1,10,45,120,210,252,210,120,45,10,1,1,11,55,
165,330,462,462,330,165,55,11,1
Name: Pascal triangle read by rows.
1 (0,0)
1 1 (1,0) (1,1)
1 2 1 (2,0) (2,1) (2,2)
1 3 3 1 (3,0) (3,1) (3,2) (3,3)
This would have an %i entry something like
%i A003056,A002262 (0,0) A000027 C
where the indexing sequences are
ID Number: A003056
Sequence: 0,1,1,2,2,2,3,3,3,3,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,7,7,
7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,9,9,9,9,9,9,9,9,9,9,10,10,10,
10,10,10,10,10,10,10,10,11,11,11,11,11,11,11,11,11,11,11,11,
12,12,12
Name: n appears n+1 times.
ID Number: A002262
Sequence: 0,0,1,0,1,2,0,1,2,3,0,1,2,3,4,0,1,2,3,4,5,0,1,2,3,4,5,6,0,1,
2,3,4,5,6,7,0,1,2,3,4,5,6,7,8,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,
5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,11,0,1,2,3,4,5,6,7,8,9,
10,11,12,0,1,2,3,4,5
Name: Integers 0 to n followed by integers 0 to n+1 etc.
The offsets from start of the indexing sequences are (0,0).
The number of lines on successive rows for formatting are
ID Number: A000027 (Formerly M0472 and N0173)
Sequence: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,
24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,
44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,
64,65,66,67,68,69,70,71,72,73,74,75,76,77
Name: The natural numbers.
And the rows themselves are to be centered (C).
Although I haven't thought it all the way through, the %f line could be
generated semi-automatically in the Maple and Mathematica scripts for
automatic sequence formatting. Some of the looking up and specification
of the reference sequences could be automated. For example, instead of
feeding the parser flat lists, nested lists could be used. (I currently
generate nested lists for tabl entries anyway but flatten them out, thus
losing the row length information.) This would give you a list of row
lengths right away. Furthermore, giving lists like { {{{0,0},1}},
{{{1,0},1},{{1,1},1}}, ... } to a special command could automatically pull
out the indexing sequences and create a set of sequence lookup lines to be
e-mailed to sequences, with the resulting sequence numbers then being
inserted in the script FormatSequence[] (or whatever the Maple equivalent
is) command to specify the %i line.
In practice, you could also make assumptions that the index sequences were
"simple" and so have some database of %A numbers corresponding to common
indexing sequences and row lengths built in to the parsing scripts.
If you didn't like the %i line, you could just ignore it.
Does this sound like too much trouble or perhaps potentially useful? I
personally think it would add value to the precise specification of
tabular sequences, although I'll back off if someone points out any
reasons why it won't work...
Cheers,
-Eric
--------------------------------------------------------------------
* Eric W. Weisstein *
* Encyclopedist phone: 217-398-0700 x599 *
* Wolfram Research, Inc. FAX: 217-398-0747 *
* 100 Trade Center Drive e-mail: eww at wolfram.com *
* Champaign, IL 61820-7237 WWW: www.treasure-troves.com/eric.html *
--------------------------------------------------------------------
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <njas at research.att.com>
Date: Tue, 27 Jul 1999 20:16:33 -0400 (EDT)
From: "N. J. A. Sloane" <njas at research.att.com>
Message-Id: <199907280016.UAA24844 at fry.research.att.com>
To: seqfan at ext.jussieu.fr
Subject: %O lines, %K lines
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 316
Precedence: list
i had better put it on record that though some of those
suggstions may be good things for the future,
i will be too busy for the next few months to
make any further major changes to the database.
i do have other things to do!
NJAS
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <conway at math.Princeton.EDU>
Date: Wed, 28 Jul 1999 11:35:32 -0400 (EDT)
From: John Conway <conway at math.Princeton.EDU>
To: "Eric W. Weisstein" <eww at wolfram.com>
Cc: Sequence Fans Mailing List <seqfan at ext.jussieu.fr>
Subject: Re: Table formatting proposal
In-Reply-To: <Pine.LNX.4.10.9907271336380.14271-100000 at dalembert.wolfram.com>
Message-Id: <Pine.SUN.3.91.990728112926.24807B-100000 at math.princeton.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 317
Precedence: list
I put a much simpler proposal to Neil quite some time ago,
and still think it's better - namely that one just separate
"rows" of a table by semicolons. So Pascal's triangle
would be
1;1,1;1,2,1;1,3,3,1;1,4,6,4,1;...
I still think this is a good idea, because it's easy to read,
and because it allows for "weird" formats that not infrequently
happen - for instance the nonzero numbers of types of polyhedra
with given numbers of vertices and faces are
;;;;;1;;1;1,1;2;2,2;...,
with the rows corresponding to edges.
John Conway
On Tue, 27 Jul 1999, Eric W. Weisstein wrote:
> Here's the original message to which David Wilson responded. Sorry for
> any confusion the reply-before-actual-message caused...
>
> -E
>
> On Mon, 26 Jul 1999, N. J. A. Sloane wrote:
>
> > i think david wilson's proposal is brilliant, and would indeed
> > many of the indexing problems.
>
> Although Neil's opinion is the one that really matters on such issues :),
> I also think David has a great idea here.
>
> > if only he had suggested this 10 years ago
> >
> > rather than changing all 50,000 %O lines, a more feasible way to
> > follow his suggestion would be to mention this in Comment (%C) lines:
> > Indexed by A012345 (say).
>
> IMHO, I think the comment line should stay comments-only (and not include
> actual content information like index sequences).
>
> However, here's a fairly detailed, but I think very general and precise,
> proposal for dealing with the general problem of tabular sequences. How
> about adding a new optional tag (say %f for "formatting") which could
> specify, for a tabl/tabf sequence, the sequence numbers indexing the
> sequence at hand, the offsets, a reference sequence giving the number of
> elements in each row, and the preferred alignment of rows = C, L, or R?
> I think this would fairly precisely specify the format of a tabular
> sequence (somebody correct me if there are ambiguities which have escaped
> me).
>
> Take, for example, Pascal's triangle read by rows
>
> ID Number: A007318 (Formerly M0082)
> Sequence: 1,1,1,1,2,1,1,3,3,1,1,4,6,4,1,1,5,10,10,5,1,1,6,15,20,15,6,
> 1,1,7,21,35,35,21,7,1,1,8,28,56,70,56,28,8,1,1,9,36,84,126,
> 126,84,36,9,1,1,10,45,120,210,252,210,120,45,10,1,1,11,55,
> 165,330,462,462,330,165,55,11,1
> Name: Pascal triangle read by rows.
>
> 1 (0,0)
> 1 1 (1,0) (1,1)
> 1 2 1 (2,0) (2,1) (2,2)
> 1 3 3 1 (3,0) (3,1) (3,2) (3,3)
>
> This would have an %i entry something like
> %i A003056,A002262 (0,0) A000027 C
>
> where the indexing sequences are
>
> ID Number: A003056
> Sequence: 0,1,1,2,2,2,3,3,3,3,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6,6,6,6,7,7,
> 7,7,7,7,7,7,8,8,8,8,8,8,8,8,8,9,9,9,9,9,9,9,9,9,9,10,10,10,
> 10,10,10,10,10,10,10,10,11,11,11,11,11,11,11,11,11,11,11,11,
> 12,12,12
> Name: n appears n+1 times.
>
> ID Number: A002262
> Sequence: 0,0,1,0,1,2,0,1,2,3,0,1,2,3,4,0,1,2,3,4,5,0,1,2,3,4,5,6,0,1,
> 2,3,4,5,6,7,0,1,2,3,4,5,6,7,8,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,
> 5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,11,0,1,2,3,4,5,6,7,8,9,
> 10,11,12,0,1,2,3,4,5
> Name: Integers 0 to n followed by integers 0 to n+1 etc.
>
> The offsets from start of the indexing sequences are (0,0).
>
> The number of lines on successive rows for formatting are
>
> ID Number: A000027 (Formerly M0472 and N0173)
> Sequence: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,
> 24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,
> 44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,
> 64,65,66,67,68,69,70,71,72,73,74,75,76,77
> Name: The natural numbers.
>
> And the rows themselves are to be centered (C).
>
> Although I haven't thought it all the way through, the %f line could be
> generated semi-automatically in the Maple and Mathematica scripts for
> automatic sequence formatting. Some of the looking up and specification
> of the reference sequences could be automated. For example, instead of
> feeding the parser flat lists, nested lists could be used. (I currently
> generate nested lists for tabl entries anyway but flatten them out, thus
> losing the row length information.) This would give you a list of row
> lengths right away. Furthermore, giving lists like { {{{0,0},1}},
> {{{1,0},1},{{1,1},1}}, ... } to a special command could automatically pull
> out the indexing sequences and create a set of sequence lookup lines to be
> e-mailed to sequences, with the resulting sequence numbers then being
> inserted in the script FormatSequence[] (or whatever the Maple equivalent
> is) command to specify the %i line.
>
> In practice, you could also make assumptions that the index sequences were
> "simple" and so have some database of %A numbers corresponding to common
> indexing sequences and row lengths built in to the parsing scripts.
>
> If you didn't like the %i line, you could just ignore it.
>
> Does this sound like too much trouble or perhaps potentially useful? I
> personally think it would add value to the precise specification of
> tabular sequences, although I'll back off if someone points out any
> reasons why it won't work...
>
> Cheers,
> -Eric
>
> --------------------------------------------------------------------
> * Eric W. Weisstein *
> * Encyclopedist phone: 217-398-0700 x599 *
> * Wolfram Research, Inc. FAX: 217-398-0747 *
> * 100 Trade Center Drive e-mail: eww at wolfram.com *
> * Champaign, IL 61820-7237 WWW: www.treasure-troves.com/eric.html *
> --------------------------------------------------------------------
>
>
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <eww at wolfram.com>
X-Authentication-Warning: dalembert.wolfram.com: eww owned process doing -bs
Date: Wed, 28 Jul 1999 10:47:14 -0500 (CDT)
From: "Eric W. Weisstein" <eww at wolfram.com>
To: John Conway <conway at math.Princeton.EDU>
Cc: Sequence Fans Mailing List <seqfan at ext.jussieu.fr>
Subject: Re: Table formatting proposal
In-Reply-To: <Pine.SUN.3.91.990728112926.24807B-100000 at math.princeton.edu>
Message-Id: <Pine.LNX.4.10.9907281042380.14271-100000 at dalembert.wolfram.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 318
Precedence: list
On Wed, 28 Jul 1999, John Conway wrote:
> I put a much simpler proposal to Neil quite some time ago, and still
> think it's better - namely that one just separate "rows" of a table by
> semicolons. So Pascal's triangle would be
>
> 1;1,1;1,2,1;1,3,3,1;1,4,6,4,1;...
>
> I still think this is a good idea, because it's easy to read, and
> because it allows for "weird" formats that not infrequently happen -
> for instance the nonzero numbers of types of polyhedra with given
> numbers of vertices and faces are
>
> ;;;;;1;;1;1,1;2;2,2;...,
>
> with the rows corresponding to edges.
>
> John Conway
Works for me. And then the semicolons are just treated as commas for the
purposes of lookups. This simple approach certainly eliminates the need
for a sequence to specify the "number of entries in each row".
However, I still like the idea of specifying in some way the index
sequences (plug in the numbers from these sequences into such-and-such a
function, say, binomial coefficient, and you get the current sequence)
where appropriate.
Cheers,
-Eric
--------------------------------------------------------------------
* Eric W. Weisstein *
* Encyclopedist phone: 217-398-0700 x599 *
* Wolfram Research, Inc. FAX: 217-398-0747 *
* 100 Trade Center Drive e-mail: eww at wolfram.com *
* Champaign, IL 61820-7237 WWW: www.treasure-troves.com/eric.html *
--------------------------------------------------------------------
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
Return-Path: <njas at research.att.com>
Date: Wed, 28 Jul 1999 22:17:51 -0400 (EDT)
From: "N. J. A. Sloane" <njas at research.att.com>
Message-Id: <199907290217.WAA24197 at fry.research.att.com>
To: seqfan at ext.jussieu.fr
Subject: Re: Table formatting proposal
X-Loop: seqfan at ext.jussieu.fr
X-Sequence: 319
Precedence: list
as i told john conway when he suggested this a while ago,
there one small difficulty (in using semicolons in the
sequences) - i have a fairly large number of programs
for extracting or looking up sequences, and they
are written in many languages (shell, maple, fortran, C, perl,
mathamatica) and exist on several different machines...
it is quite a drastic change to contemplate!
NJAS
------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------
More information about the SeqFan
mailing list