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

[franktaw at netscape.net]

My understanding is that every number in the entries of the OEIS is a 
decimal number. There may be other ways to view it, but insofar as it 
is in the OEIS it is decimal. For this reason, using extra digits such 
as are commonly used for hex (A-F) is not permitted in the database.

And please note that the base keyword is used for many more things than 
just the case where the final numbers are reinterpreted from some other 
base into base 10.

Franklin T. Adams-Watters

-----Original Message-----
From: Marc LeBrun <mlb at well.com>
To: Sequence Fanatics Discussion list <seqfan at list.seqfan.eu>
Sent: Sun, Jan 5, 2014 2:37 pm
Subject: [seqfan] Re: A090709 Decimal primes whose decimal 
representation in base 6 is also prime. -- rebasing


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/
>>
>
>



_______________________________________________

Seqfan Mailing list - http://list.seqfan.eu/