[seqfan] Re: Sum and absolute difference share no digit

[M. F. Hasler]

PS: (with apologies for consecutive postings...)
- The given program yields incorrect terms slightly earlier than the
mentioned "dead end", namely, the value 6380 doesn't appear.
   (But A_vec(N) is a permutation of [1..N] for, e.g., N = 6000 and N =
6225, and I'm confident that one can go further with minimal adjustment of
the program: Slightly more care has to be taken when jumps are > 5 and one
goes too far beyond the next larger multiple of 5.)
- The sum of consecutive terms can never be a pandigital number, because
this would (of course) not only exclude a difference <= 9, but *any*
difference. But does this mean that the sequence can't be extended
infinitely? Could it be possible to make large enough jumps to avoid
pandigital sums, in particular for numbers in the neighborhood of
1234567890...0 / 2 etc.?
Otherwise one could ask: what are the numbers N such that we can have a
permutation of [1..N] with the given property?
- I will propose the sequence as https://oeis.org/draft/A328021  - see
there for more!

Regards,
- Maximilian

On Tue, Oct 1, 2019 at 7:53 PM M. F. Hasler <seqfan at hasler.fr> wrote:

> On Sun, Sep 29, 2019 at 8:24 AM Éric Angelini <eric.angelini at skynet.be>
> wrote:
>
>> I don't know if this sequence exists  but I'm looking for the
>> lexicographically first _derangement_ of N such that the sum and the
>> absolute difference of two successive terms don't share any digit.
>> S = 1,2,3,5,4,6,8,10,7,9,12,11,15,14,13,...
>> In computing S, one has to backtrack quite often as an  integer K
>> ending with 0 or 5 cannot be followed by an integer > K.
>>
>
> Hello Eric & SeqFans,
>
> I agree with your statement : any multiple of 5 must be sandwiched between
> two smaller numbers,
> because if it has a neighbor which is larger, then their sum and their
> difference end in the same digit.
>
> As often, this apparent complication finally made it even simpler:
> I make a list of possible (and unused) neighbors of the "next larger
> multiple of 5", and remove them if they are used in the sequence.
> As soon as there is only one possible neighbor left, we simply HAVE to go
> on with the multiple of 5 (we necessarily have just used its penultimate
> possible neighbor) and the last remaining neighbor.
> This gives the following sequence (confirming your initial terms):
> [1, 2, 3, 5, 4, 6, 8, 10, 7, 9, 12, 11, 15, 14, 13, 16, 17, 18, 20, 19,
> 21, 22, 23, 25, 24, 26, 27, 28, 30, 29, 31, 32, 33, 35, 34, 36, 37, 38, 40,
> 39, 41, 42, 43, 45, 44, 46, 47, 48, 50, 49, 51, 53, 55, 52, 54, 56, 58, 60,
> 57, 59, 62, 65, 61, 64, 66, 63, 70, 68, 73, 67, 69, 75, 72, 74, 71, 76, 78,
> 80, 77, 79, 81, 83, 85, 82, 84, 86, 88, 90, 87, 89, 91, 93, 95, 92, 94, 96,
> 98, 100, 97, 99, 102, 101, 105, 104, 103, 106, 110, 107, 111, 108, 112,
> 109, ...]
> I include PARI code at the end of the mail. I might submit that sequence
> (as co-author with Eric).
>
> - Maximilian
>
> PS: I had to notice that the script produces incorrect results not later
> than for a(n=6784) ?=? 6781.
>