The basav from riedlerod

Add new actions PULL,PUSH,PULSH

For better algorithm control and the possibility of #20, a new action PULSH will be added. This will allow the Algorithm to PULL an item from the end of a bucket, and then PUSH it onto another one. There will also be the PUSH and PULL actions for storing one item while doing other stuff. They will be callable for algorithms through the following action:

yield (PULSH,buck1,buck2)

or

yield (PULL,buck1)
yield (PUSH,buck2)

where buck1 is a bucket with at least one item and buck2 is a bucket with at least one empty spot (which is a given in BASAV if buck1 isn't empty).

Pulshing any item that isn't at the end of a bucket to a position that isn't at the end of another bucket is possible through insertions, which defeats any performance gains PULSH would have. Which means it's not an action to make current algorithms faster, but to distinguish technically faster PULSH operations and usually slow BUCKINSERT operations in the stats. Also, as mentioned above, for insertless mode.

The PULSH operations will count as one PULL and one PUSH in the stats.

Get FPS and UPS up to 60 when handling 2048 items

commit 5339da37ef1e2343c8fa91659cf63acddaf7da4e
I changed the wact/ract rendering system from setting all possible vertices and then assigning the colors when needed to generate an amount of verteces in the correct x positions below the screen and updating the y corrdinates when needed.
UPS|FPS
59|59 Without Load
40|25 Bubble Sort
30|17 Merge Sort
35|16 Radix LSD 10
23|13 Radix LSD 10 OOP

rewrite entity updating with binary todo indicator

Converted Entities:

Add item count changer

Add stats

Either:

Read: n
Write: n
Pass: n

Or:

Read: n
Swap: n
Insert: n
Bucket: n
Pass: n

I haven't decided yet.

add per-algorithm settings

planned would be a dict where algorithms can choose up to 20 settings by defining a member like so:

opts={
    "base":(int,4,2,None,"Base"),
    "oop":(bool,False,"Out-of-Place","In-Place"),
    "version":(list,2,("This","That","Ananas"),"Version: %s"),
    …
}

, where the option "base" is an integer from 2 to infinity, and a default value of 4, "oop" is a bool with the default value False, where "Out-of-place" is displayed for True and "In-Place" for False, and "version" is a list (a flip-through button in the UI) with the item on index 2 in "vals" being the default. If an option is defined with illegal values, e.g. the default value being out of range in an int, or the possible values in a list being less than 2. If there are more than 20 settings, the additional ones should be hidden and set to their default values. (maybe the maximum amount of settings will increase in the future if demand arises)

The options can be set by the user and on algorithm start, the selected values will be accessible to the algorithm like so:

def gen(self):
    b=self.vals["base"]
    oop=self.vals["oop"]
    v=self.vals["version"]
    …

Then the algorithm can modify itself with the specified values as it pleases.

This feature is aimed to reduce the amount of unique algorithms to select in the algorithm selector drastically and increase the amount of different options a user can choose from. E.g. the Radix LSD algorithm alone used up 6 spaces, but only base 2,4, and 10 can be selected, with an additional OOP option.

Planned is the setup:

Bubble Sort (unchanged)
Cocktail Shaker (unchanged)
Odd-Even Sort (unchanged)
InsertionSort (OOP/IP)
SelectionSort (OOP/IP,Single/Double)
QuickSort (Lomuto/Hoare,Singular/Concurrent)
Radix (LSD/MSD,base 2-inf,OOP/IP)
Merge Sort (IP/OOP)
Bogo Sort (unchanged)
This would mean a reduction from 25 to 9 unique Algorithms.

Sorting algorithms have to make sure all possible configurations are functional. E.g. if there's a base 4 OOP version, but not a base 7 OOP version, then the algorithm should either limit the possible bases, scrap the OOP versions alltogether, or make the combination work. Note that there can be set boundaries which integer values are possible, but no single value can be excluded. If its a finite list, consider using a list instead.

add unsafe mode

add a button that disables safety checking for a (more or less effective) performance increase. All algorithms should be stable anyway, so safety checking really is just for implementing and testing new features. I still want an extra layer of stability that's enabled by default so the program doesn't crash if I mess up.

Fix algorithm switcher buttons being a bit too high

Add max FPS setting

Change algorithm API to use yield

because the current one is unnecessarily complicated & yielding stuff would make stuff way easier.
The only problem I still have to solve is passing the read values.

Write a Readme

explain capablilities of project
"Even though this is made with Python, I will always make sure even very weak machines can run this at 60fps."
"All known bugs will be fixed until a release is issued, except for minor and very specific ones."
"Only Linux is officially supported, but other ones should work too. If they don't, please file an issue. Depending on the severity of the issue, and the accessibility of the OS, it will get fixed more or less quickly."
How to install
How to contribute algorithms
link coding log playlist
link vis-only playlist
display screenshots

decouple the main logic class from the main window class

It'd be nice not having to fear that some weird window member could get overritten by a new logic member.

It should be split like so:
The new class MainWin() will go into the CONSTANTS.py file, along with its invokation as win and the constants that get set regarding window size. The new class MainLogic() with most of the members and functions from the current GameWin() will stay in the main.py file.

Seperate all the action parsing logic into a new file

Add Algorithms

Now the really really bad ones. These actually exist. Mostly for fun, so these are mostly simple.

Now the ones that will like never be implemented for various reasons

Gravity/Bead Sort
this one changes the values of items, which is impossible using my API. I suggest reading the wikipedia article on it, as it's very interesting.
Pigeonhole Sort
this one just creates a bucket for every number in the range and the puts the items in there accordingly and then puts them back in the original bucket – not generally that bad, but very much so in this program, as it's not designed to handle more than 20 buckets. It already struggles with 10. Technically its possible to implement, but I don't want to crash peoples PCs.
I could possibly implement a In-Place version, but that'd look like magic 😅

Add pseudo- multithreading

Should be somewhat possible to implement something like this with a few new actions:

NEW_THREAD(*args,**kwargs)
Creates a new thread and supplies the specified *args and **kwargs to the thread constructor
LOCK_LOCK(n)
waits until the nth lock is released & locks it
RELEASE_LOCK(n)
releases the nth lock
WAIT_LOCK(n)
waits until the nth lock is released

and Algorithm callbacks:

new_thread(*args,**kwargs):
(algorithms may define it without *args and **kwargs)
gets called when NEW_THREAD is yielded, and should return a new generator that inherits BaseAlgorithm.
(this is a classmethod)

Threads should be handled like separate algorithms, where each non-waiting thread gets called equally often than the others. This should be implemented by calling them 'in a circle'. If an algorithm yields to wait, the member thread.lock should be set to the number that is specified. Every time a thread should be called, its member thread.lock has to be read & checked. If the lock is currently locked, the thread should not be called & it should continue with the next one. If a full round has been completed without a thread being called, the algorithm should be stopped and the user should be notified (per print) that a deadlock has occured.