15
3
Introduction
A xenodrome in base n is an integer where all of its digits in base n are different. Here are some OEIS sequences of xenodromes.
For example, in base 16, FACE
, 42
and FEDCBA9876543210
are some xenodromes (Which are 64206
, 66
and 18364758544493064720
in base 10), but 11
and DEFACED
are not.
Challenge
Given an input base, n, output out all xenodromes for that base in base 10.
The output should be in order of least to greatest. It should be clear where a term in the sequence ends and a new one begins (e.g. [0, 1, 2]
is clear where 012
is not.)
n will be an integer greater than 0.
Clarifications
This challenge does IO specifically in base 10 to avoid handling integers and their base as strings. The challenge is in abstractly handling any base. As such, I am adding this additional rule:
Integers cannot be stored as strings in a base other than base 10.
Your program should be able to theoretically handle reasonably high n if there were no time, memory, precision or other technical restrictions in the implementation of a language.
This is code-golf, so the shortest program, in bytes, wins.
Example Input and Output
1 # Input
0 # Output
2
0, 1, 2
3
0, 1, 2, 3, 5, 6, 7, 11, 15, 19, 21
4
0, 1, 2, 3, 4, 6, 7, 8, 9, 11, 12, 13, 14, 18, 19, 24, 27, 28, 30, 33, 35, 36, 39, 44, 45, 49, 50, 52, 54, 56, 57, 75, 78, 99, 108, 114, 120, 135, 141, 147, 156, 177, 180, 198, 201, 210, 216, 225, 228
1is there a limit to n? – FlipTack – 2016-11-26T14:02:23.677
@Flp.Tkc No. It should be able to handle reasonably high n. I don't want the challenge to be limited by how high a base the builtin base conversion of a language can handle. – Artyer – 2016-11-26T14:26:20.623
@Artyer That should have been part of the challenge text, then. It seems some answers are already doing that – Luis Mendo – 2016-11-26T14:38:25.967
I know the base conversion in Pyth can handle values larger that 36, but since this wants all of the xenodromes, the underlying python breaks when the list gets too large, saying it can't fit a value in a
– FryAmTheEggman – 2016-11-26T14:43:30.797ssize_t
. Is it breaking in this way acceptable?@FryAmTheEggman Yes. The algorithm is not the problem there, but the implementation, which is ok. – Artyer – 2016-11-26T14:46:04.150
2Somebody seems to have downvoted all answers that cannot handle larger bases because of a built-in precision limit, which also seems like an implementation rather than an algorithm problem. Could you clarify? – Dennis – 2016-11-26T15:48:20.040
@Dennis I have clarified the rules. I think the new rule about ints as strings is what I wanted. I will post in the sandbox next time though. – Artyer – 2016-11-26T16:30:06.747
I didn't downvote, but certainly the answers didn't fulfill that requirement. I think it's better to relax that requirement, as you have done now – Luis Mendo – 2016-11-26T17:33:17.163
Most languages that allow arbitrarily large integers (like Python, which the current winning solution in Pyth is based on) store them internally as strings in base 256 or base 2^32 or something similar. Also, if fixed-length strings still count as strings, then technically everything on a computer is stored as strings of base 2 digits. Perhaps you should at least clarify whether using built-in bignum implementations or libraries is allowed, or whether we need to either stick to fixed-length integers or implement our own large integer arithmetic in base 10? – Ilmari Karonen – 2016-11-27T23:49:10.840