Vyxal

10:54 PM

@user in regards to the list bigint pr, how about a compromise: a --optimisations flag that disables checking for bigint length

I want to be able to keep theoretically infinite lists and arbitrarily large lists as an option

because it makes proving an answer is theoretically correct much easier

you know that there won't be problems with size limitations

and in terms of performance, if you're doing things with actually big lists, there's a chance your algorithm isn't gonna halt for a long time anyway

having a max list size kinda negates the point of infinite lists

user

11:16 PM

@lyxal Uhh that would make the implementations even more complicated but I guess it would fix the performance thing

@lyxal Those limitations are handwaved away even for practical languages. I really don't think anyone cares if you don't support lists bigger than 2^32

lyxal

@user if ctx.globals.allowBig && ... wherever big length is currently used

user

@lyxal Not really, you usually only end up evaluating the first handful of elements, not the first 2^32 elements

@lyxal :thumbsup:

lyxal

@user in code golf you might need to index beyond 2^32 if you're brute forcing something

user

Scala, for example, has a max list size and infinite lists are still definitely useful

lyxal

but what's the point if you can't index at arbitrary places?

you might as well have a finite generator

user

11:19 PM

@lyxal Yeah, but you'll never actually get there in a reasonable amount of time, right?

lyxal

@user no one cares about time, only correctness

Ginger

!!/status

user

No one cares about correctness to that point

Ginger

I cry every time

user

People are fine with using ints instead of BigInts in other languages

lyxal

11:20 PM

@user unlimited time and resources means you can run something forever, but it still needs to be correct

user

The algorithm can be proven to work, even if the implementation can't

lyxal

I'd still prefer it to be implementation correct

even if it's extra work to maintain two versions with an optimisation flag

user

@lyxal It might help to think of them not as infinite lists but unlimited lists. So you'll always only index up to some finite amount, but that limit can be chosen by you

@lyxal Fiiiiiine

The optimization flag seems like an acceptable compromise

Ginger

@lyxal lyxal endorsing maintaining two versions?! heresy

user

Bad for the implementers but good for all users

lyxal

11:22 PM

@user it could even make way for other optimisations with things that are currently expensive for the sake of theory

@user if done right, it should barely be noticed

user

🤞

lyxal

in fact, you could evenly probably abstract away the if ctx.globals.allowBig with implicits

user

@Ginger Wait what happened?

lyxal

barely noticeable

@Ginger no, it's an if statement

not two different versions :p

Ginger

heresy ‼

lyxal

11:25 PM

(i've forgotten how it's heresy :P)

@user it should wait until after 3.5 is released

because there's already major code refactorings

and we don't need a repeat of how 2.5 played out

Ginger

shame we don't have a bot to tell us about the refactorings

lyxal

SE's busy :p

Ginger

as soon, as SOON as the Imgur phaseout is done I expect the bots to magically spring back to life

lyxal

eh

there's other things and probably other more things too

I'll take the bait, @YaakovEllis :) We are operating in a world of drastically reduced resources and that means hard prioritization decisions need to be made. The fact that this was undetermined for so long is a sign that there are people internally who are fighting to keep investing in it. By far the easiest thing to do (once it was shuttered) would have been to abandon it. — Des ♦ Jan 25 at 23:07

and also StackOverflow for Teams

and Discussions

and AI stuff

and a few other things

stackoverflow.blog/2023/11/15/… for some of the publicly known stuff the dev team is working on

Transcript for