Left side menu

[mugulmd]

I put the menu on the left side instead of the bottom. It led to some changes in the InputBox draw method and in the DropdownBox class. Also I had to reduce a bit the size of the font to make everything fit in the window.

[GlacialBlaze]

Minimal code changes for intended purpose - great work!

Just a little, hopefully not troublesome, touch-up to the look, is it possible to do: 1) Increase the width of the window instead of decreasing font size? 2) Increase the vertical border size between the menu and the bars? 3) Adjust the position of the content in Size so that it is vertically and horizontally centered?

[mugulmd]

Done :)

[LucasPilla]

@mugulmd Do you know how to make this menu like a slide window? So the menu would appear when the user press something like an arrow button.

[mugulmd]

@mugulmd Do you know how to make this menu like a slide window? So the menu would appear when the user press something like an arrow button.

I guess I do but it would probably be messy and I don't really see the point, the interface is already quite simple, there wouldn't be much use of hiding the menu

[GlacialBlaze]

I agree. I think the menu field is suitably sparse as of now, so it's not too heavy to the eye. Extra design on it would not further simplify the visualizer.

@mugulmd I think much of the work has been done. I think a little pause would be a nice change, also because I would like to discuss on some minor things I notice:

• All along, the bars created do not have a uniform value of distribution. Meaning to say that, because the values are taken at random from a specific range, some values are repeated. As a result, when the bars are sorted, they form a jagged-looking staircase. Is it possible to fix this?

• The current bar drawing mechanism redraws each and every bar per each function call. Imagine that we have 10 bars and they take e.g. 10 swaps in total, so 10*10 = 100 times of bar drawing, whereas a swap actually only moves 2 bars. Trivial to say, the more bars there are, the many many more times we are drawing. Of course including comparison, the sort would actually be accessing more than 2 bars at once, but not more than roughly 10 bars? So the main thing is that there are actually many other bars not touched but are redrawn anyways which is unnecessary work. Is it possible to fix this such that only accessed bars are redrawn?

[LucasPilla]

@GlacialBlaze Maybe we could start another branch with these interface changes and then we merge to the master when adequate.

[GlacialBlaze]

@LucasPilla Yeah, I agree that it will be more systematic. Shall I create another issue or pull request, is this what you mean?

[LucasPilla]

I mean we should add these changes to a another branch, not the master one

[GlacialBlaze]

Hmm, could you do that 'another branch' thing? I'm not familiar. 😅😅😅😅😅

Or, we could treat this branch as the template to accumulate all future changes here before merging with the master.

[LucasPilla]

@mugulmd I just created a branch called 'interface', are you able to change the base branch? So this pull request would be merged to 'interface' and not 'master'.

[mugulmd]

I agree. I think the menu field is suitably sparse as of now, so it's not too heavy to the eye. Extra design on it would not further simplify the visualizer.

@mugulmd I think much of the work has been done. I think a little pause would be a nice change, also because I would like to discuss on some minor things I notice:

* All along, the bars created do not have a uniform value of distribution. Meaning to say that, because the values are taken at random from a specific range, some values are repeated. As a result, when the bars are sorted, they form a **jagged-looking** staircase. Is it possible to fix this?

* The current bar drawing mechanism redraws _each and every bar_ per each function call. Imagine that we have 10 bars and they take e.g. 10 swaps in total, so 10*10 = 100 times of bar drawing, whereas a swap actually only moves 2 bars. Trivial to say, the more bars there are, the many many more times we are drawing. Of course including comparison, the sort would actually be accessing more than 2 bars at once, but not more than roughly 10 bars? So the main thing is that there are actually many other bars not touched but are redrawn anyways which is unnecessary work. Is it possible to fix this such that only **accessed** bars are redrawn?

For the 1st problem I think it would be pretty easy to fix (simply change the random list from min to max by a list of evenly separated values from min to max and then shuffle this list), however it would bias the algorithm execution by always giving it the same kind of input, whereas with random values you can see how sometimes one algorithm can be fast or slow, depending on the distribution of values to sort. Maybe it would be an interesting idea to let the user choose different kind of input distribution, and therefore see the pros and cons of each sorting algorithm.

For the 2nd problem I don't think much can be done because there's no easy way to "erase" something in particular on the screen, and even if there were a way, it would be a mess to keep track of every change in the array being sorted... But I don't think that re-drawing every bar every time is a big issue because the drawing primitives of pygame are really fast. To better know the limits of this "brute force" method one should do some stress testing I guess ^^

[mugulmd]

@mugulmd I just created a branch called 'interface', are you able to change the base branch? So this pull request would be merged to 'interface' and not 'master'.

I don't really know how to do that but I'll check it out :)

[GlacialBlaze]

@mugulmd

I see what you mean.

Your idea is all along one of my suggestions for the visualizer (as shown in the issue section) which is the sort shuffle where the user can choose what kind of data arrangement to be sorted such as sorted, random (which is the current and only one), reverse, final merge stage, ascending saw, and others. The 'presortedness' of the data is a good feature for the program to show how each algorithm performs.

Your next point brings us to the next part of the data characteristic besides data arrangement - number of unique elements. For instance, a random list can have many unique items or very few of them. So this is another department where sort performance can be measured because some sorts perform better with more duplicates or otherwise.

Now that I separated each point clearly, I think the next task (I think we can continue with this pull request because it is still part of the menu thing) to be done is to create another option for users to choose the data shuffle. For now, we just create three basic ones: sorted (trivial), reverse sorted, and random. Perhaps you use the sort choices template for it and put it below Size?

Also, can you implement your idea of a 'list of evenly separated values within a range for shuffling'? It will be good because the distribution will look more even and the shuffling still gives us the same randomized arrangement.

[mugulmd]

@GlacialBlaze ok I can work on that :)

[GlacialBlaze]

@mugulmd

I don't really know how to do that but I'll check it out :)

Perhaps this might help:

https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request

[mugulmd]

@mugulmd

I don't really know how to do that but I'll check it out :)

Perhaps this might help:

https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request

Ok it's done, thanks for the tip :)

[mugulmd]

@GlacialBlaze now the sorted array won't look jagged, I hope it is what you had in mind

[GlacialBlaze]

@mugulmd

Good work. The bars arrangement can be customized easily.

Now, is it possible to add another box called 'Shuffle' using the Algorithm box class? We can have, for the time being, three common item arrangements: sorted, reverse, and random.

[mugulmd]

@GlacialBlaze Yeah sure I can try, I'll keep you updated :)

[mugulmd]

Sorry for the long silence, I got overwhelmed with work ^^ @GlacialBlaze is this what you had in mind ?

[GlacialBlaze]

@mugulmd No issue at all! I too have been extremely busy. And yes, the shuffle option is nicely done.

@LucasPilla At this point, in terms of functionality, the sorting visualizer can be said as 'complete' or at least 'near-complete'. Many critical features have already been achieved. From here onward most of the things would be aesthetics and back-end improvements, unless of course something new, worth considering, passes by.