@UnrelatedString I don’t understand what you’re trying to do

you create infinite choice points with ℕ₁≜ so obviously if you backtrack everytime with ⊥ it’s not gonna terminate

I had assumed that l<5 would be understood as a constraint along the lines of <10000, and although that assumption was false, the value of the input variable never changed

...also labeling before applying it should have made it clear that that wouldn't work in that form, but I tried labeling afterwards and same thing

anyhow I then tried {}ᵐ as the entire program, with an input of [1], and it generated infinitely many [1]s for no apparent reason

this doesn't happen on TIO

@UnrelatedString It is understood like that

but you use ≜ before it so you constrain an already-set integer

yeah

And then I labeled it later and still seemed to run into the same problem but I may be misremembering

Well the problem is also this in your head program: &ẉ⊥

&ẉ also generates infinite choice points

also l<2 generates infinite choice points because the <2 is applied after generating a length

this works

Ah, thanks

Apparently it doesn’t actually when you set l<3 etc.

nevermind

tl;dr using l to constrain numbers is wacky

yep

It works but don’t try to use ⊥ with it

I just had the strangest idea to try swapping the l and <, and it seems to actually work without the cut, because instead of constraining the length you're just constraining the number to be less than a number with that length

huh

Which isn't quite the same but accomplishes a similar upper bound

If you're dealing with negatives it won't be the same at all

It doesn’t work though

cause it doesn’t print 99

:p

:p

that... is strange

It’s not

99 is the largest number with 2 digits

oh, it finds the largest, rather than the smallest

if you use ≤ it prints 99

that makes more sense

because it tries to succeed as much as possible, it succeeds the most with the largest value

@UnrelatedString Shouldn’t you use ≤ in this answer then?

The largest number in the desired output is 9719, so < is just marginally faster

Marginally marginally

oh right

I don’t understand why it stops at that number though. Is there a proof this sequence stops here?

Until I thought of length I was using 8ḟ as an upper bound

The question body's phrasing of "incomplete list" suggests that there isn't one, but it's actually because the OEIS entry is restricted to numbers over 100

The full tag implies that there is a proof out there somewhere, but the page doesn't supply one

I would assume LeakyNun has one. Considering how obsessed with math he is, he wouldn’t post a challenge like this without being sure

He may have posted the challenge because he'd just proved it

I think I have an idea for it

In any case he'd done some work related to it, because if it was just an OEIS challenge he would have kept the restriction to >100

well maybe not

Ok so

it has to also be in the sequence because you would need to check its 2 digits substrings too anyway

And likewise if you have four digit substrings

so for a number to be in the sequence, it must comprise numbers previously in the sequence

So if you show that no 5 digit number is in the sequence, then there will never be any bigger number

so if you can verify that there's no five-digit member of the sequence, that automatically rules out anything larger

yeah

Well that was easy :p

It's not immediately obvious even if it isn't difficult

It becomes clear when you look at the 4 digit members of the sequence and look at all substrings

true

I’m guessing it was obvious for LeakyNun so he didn’t even bother explaining the proof

I have seen a similar problem but then all the substrings had to be prime

This is actually quite easy to bruteforce

note that each substring longer than 2 has to be an element of the sequence. This means if no number exists of length n, no element will exist of length n+1 either. So all you have to do to prove those are all the numbers is check every number of length 5.