Remove requirement for sorts with unreasonable limits to be "unreasonably slow"

[Gaming32]

This removes the requirement for sorts with unreasonable limits to be marked as "unreasonably slow."

[Gaming32]

I feel like the unreasonable limit threshold is a bit low

I didn't touch the limits though :P. So I feel like that comment doesn't really apply to the PR's purpose.

[EmeraldBlock]

I mean that as in how you determine which sorts to no longer call unreasonably slow

[Gaming32]

I mean that as in how you determine which sorts to no longer call unreasonably slow

I just kinda winged it TBH. You can feel free to update which algorithms if you want.

[Gaming32]

https://github.com/Gaming32/ArrayV-v4.0/blob/d25c6771fdde9e7adfa87bb4ebcae4f0f05105db/src/threads/RunComparisonSort.java#L92

https://github.com/Gaming32/ArrayV-v4.0/blob/d25c6771fdde9e7adfa87bb4ebcae4f0f05105db/src/threads/RunDistributionSort.java#L187

Shouldn't these be changed too?

Yes

[EmeraldBlock]

Also, what about making whether a sort is considered unreasonably slow dependent on the unreasonable limit?

...or for that matter, why even have it?

[PCBoyGames]

Also, what about making whether a sort is considered unreasonably slow dependent on the unreasonable limit?

...or for that matter, why even have it?

We don't really want to have anyone calling us out because - let's use an example that is currently marked unreasonable before this pull - Fire (in all its O(n^3) glory) takes too long for some large count of items. My response as its creator? "Don't go trying Stupid Fire on it, though!"

[Gaming32]

Also, what about making whether a sort is considered unreasonably slow dependent on the unreasonable limit?

...or for that matter, why even have it?

@EmeraldBlock The unreasonably slow toggle is used by sort threads to change how their delay is calculated.

[EmeraldBlock]

true, but imo that should be reworked anyway

[rylid-umil]

legends say it is still closed to this day