[seqfan] Re: A090709 Decimal primes whose decimal representation in base 6 is also prime. -- rebasing

[Marc LeBrun]

Well, as Neil knows, I'll agree to respectfully disagree, and just add a
small bit to think about:


Proposal: if the entries are to be interpreted in different bases then this
vital metadata really should be provided in a field (like base:2, defaultly
understood to be 10) much like how the OEIS supports an offset: field.

The current "base" keyword isn't much more than a vague warning.  A full
base: field would  make the data more computer-friendly for things like
transforms, as well as more user-friendly.


Philosophy: [in case anyone else cares]

Without recourse to metadata (given either informally or mathematically) it
is NOT apparent at that the listed data values for the sequence A007088

  1, 10, 11, 100, 101, 110, 111, 1000, 1001, 1010, 1011, 1100, 1101, 1110...

"are clearly not decimal numbers".  They look like perfectly good decimal
numbers to me!

In fact the syntactic rules listed are intentionally designed to support
decimal numbers.  More precisely, decimal numerals of a certain conventional
flavor.  They are purposely crafted to rule out hex, fractions, Roman and
strings like 00.  So why not just embrace the natural simple uniform
semantic interpretation of the house syntax?

Worse, carefully read, the description of A007088 is ambiguous and/or
formally inconsistent.  The very first comment says "Or, numbers that are
sums of distinct powers of 10."  So is the value listed for a(2) to be
interpreted as two or as ten?  In binary the first prime value is a(1), but
interpreted as sums of distinct powers of 10 it is a(2).  Which is it?

Are these "numbers" really integers (the "I" in OEIS) or "strings that look
decimal"?

Given all this, what should superseeker and its ilk make of A007088?

Adopting a firm foundational semantics is a key to future-proofing the OEIS.

OK, 'nuff said.  --MLB


>="Neil Sloane" <njasloane at gmail.com>

> I don't quite agree with everything Marc LeBrun said.
> 
> Look at http://oeis.org/A007088, the binary numbers.
> These are written in base 2. They are clearly
> not decimal numbers.
> 
> What is true is that numbers in the DATA lines in
> the OEIS are written using the digits 0 through 9
> (and, apart from 0 itself, may not begin with 0).
> But it is misleading to call such numbers "decimal numbers".
> 
> Of course there are other rules too: no "decimal" point,
> no internal commas or spaces or periods, minus signs are allowed but not
> plus signs, etc.
> 
> Neil
> 
> 
> On Sun, Jan 5, 2014 at 1:10 PM, Marc LeBrun <mlb at well.com> wrote:
> 
>>> ="Veikko Pohjola" <veikko at nordem.fi>
>>> Should there be some unification of the terminology?
>> 
>> Yes, and here's a possible starting point:
>> 
>> Once upon a time we discussed canonizing the idea of "rebasing" which
>> covers
>> many of these situations.
>> 
>> The definition of "rebasing n from a to b" is roughly "expand n in powers
>> of
>> a, then replace a with b".
>> 
>> Thus A090709 might be described succinctly as "primes that when rebased
>> from
>> 10 to 6 are prime".
>> 
>> A major benefit of adopting and using this concept is that it clarifies
>> that
>> ALL sequences in the OEIS are ALWAYS sequences of INTEGER values that are
>> ALWAY written in DECIMAL.
>> 
>> In particular it establishes that the values are never in any other base,
>> nor are they digit strings or other flavors of non-numerical objects.
>> 
>> After all, it's the "On-line Encyclopedia of INTEGER Sequences".  And it's
>> customary for integers to be "written in decimal" (that redundancy,
>> repeated
>> in 400+ entries, flags that *some* clarification might be in order!<;-).
>> 
>> Rebasing has many other pleasant ramifications in addition to eliminating
>> lots of awkward, inconsistent, imprecise and ambiguous circumlocutions.
>> 
>> For instance in defining a transform it relieves concerns about what base
>> to
>> use to interpret the input values.
>> 
>> Admittedly it takes a little getting used to the idea that, for example,
>> the
>> concise definition of A007088 is "numbers rebased from 2 to 10", but I
>> think
>> the advantages in increased precision are well worth it.
>> 
>> A side-benefit is that rebasing is an operation with widespread interesting
>> and useful applications.  For example rebasing from 10 to 1 sums the
>> digits,
>> and rebasing from 10 to -10 reverses them (mod a left-shift).
>> 
>> More generally it encourages a standardized viewpoint for expanding
>> integers
>> into polynomials and evaluating polynomials back into integers at a base.
>> 
>> For example rebasing A014580 from 2 to 10 gives A058943.  Rebasing to X
>> gives the actual polynomials, which never appear directly in the OEIS, but
>> are perfectly reasonable in definitions or computations with numerical I/O.
>> 
>> And so on...
>> 
>> Anyway, back in the day I was writing, say 10[n]6, to mean "rebase n from
>> 10
>> to 6" from a psychedelic analogy with notations like GF2[n](X).  Franklin
>> T.
>> Adams-Watters proposed n_10->6 which is more suggestive.  Ultimately the
>> notation discussion trailed off inconclusively; there are now entries with
>> a
>> diversity of notations, conventions and terminology.
>> 
>> Yes, this should all be unified.
>> 
>> --MLB
>> 
>> 
>> 
>> _______________________________________________
>> 
>> Seqfan Mailing list - http://list.seqfan.eu/
>> 
> 
>