Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revised/new patch for improve ratio calculation #4626

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

alexander-n8hgeg5e
Copy link

@alexander-n8hgeg5e alexander-n8hgeg5e commented Dec 15, 2023

Here is the description about why a change can be considered:
description right at the beginning of this closed pull request

Now, I tested a function that actually works and made screenshots.
It works with upright and landscape ratios and
also with my "ratio-1.0-square" use case.
Ratios > 1 are "landscape" and ratios < 1 are "upright".

It works like this:
the code from below more readable
`
def is_more_golden_than( a, b , gs=1):
goldstandard = gs
ao=a
bo=b
# TODO: use math to refactor the next 6 lines
a = a / goldstandard
b = b / goldstandard
wa = a if a < 1 else -1/a
wb = b if b < 1 else -1/b
wa = abs(abs(wa)-1)
wb = abs(abs(wb)-1)
judgement = True if wa < wb else False
print(f'{ao:>5.3} vs {bo:<5.3} > {wa:+.3f}, {wb:+.3f} golden = {gs:0.2f} {judgement}' )
return judgement

is_more_golden_than(1.5 , 0.66666 , gs=1 )
is_more_golden_than(2.0 , 2.1 , gs=2 )
is_more_golden_than(1.9 , 2.0 , gs=2 )
is_more_golden_than(1.9 , 2.1 , gs=2 )
is_more_golden_than(0.25, 0.75 , gs=0.5)

output:
1.5 vs 0.667 > +0.333, +0.333 golden = 1.00 True
2.0 vs 2.1 > +0.000, +0.048 golden = 2.00 True
1.9 vs 2.0 > +0.050, +0.000 golden = 2.00 False
1.9 vs 2.1 > +0.050, +0.048 golden = 2.00 False
0.25 vs 0.75 > +0.500, +0.333 golden = 0.50 False
`
update here: pictures removed, newer pictures below

@alexander-n8hgeg5e
Copy link
Author

alexander-n8hgeg5e commented Dec 16, 2023

For the failing test_ratiotile.py test,
maybe I should make a script that draws rectangles and creates images with the ratios and screen sizes from the test side-by-side with the expected ones.
Can I update pull requests if they are fixed or do I need to close it ?

@elParaguayo
Copy link
Member

Just keep adding commits to your branch.

@alexander-n8hgeg5e
Copy link
Author

alexander-n8hgeg5e commented Dec 17, 2023

I got the data out and generated some side by side pictures which are only 5k each.
update here: most of this comment removed, because I added a comment with a condensed and newer version of all this.

This was the initial description for a pull request that
did not work. But here it is suitable to explain the reasoning behind it.
I added a RatioTile(ratio=1) object in my config and noticed that the
layout favoured 3 upright elongated windows on a screen that is 1.125 higher than wide.
So they are really really slim, 1.125 tall and 0.333 wide.
The ratio is 1.125/(1/3)=3.375
But I expected them to be 3 wide "landscape" windows because that would be
1.125/3 tall and 1 wide, which is a better ratio because if you see the ratio
as longer_edge_of_window/shorter_edge_of_window then it is
1/(1.125/3)= 2.666

This patch can fulfill the described wish,
while keeping overall expected "ratioTile" behaviour.
With this patch a GOLDEN_RATIO=1 tries to make the windows "square".
If a slightly more landscape tendency is preferred,
a default GOLDEN_RATIO of 1.2 probably would work.
@alexander-n8hgeg5e
Copy link
Author

alexander-n8hgeg5e commented Dec 21, 2023

I rebased and force pushed it to clean it up.
It needs probably more cleanup after the code analysis tools
inspected it.
update: now, they seem to pass
I can make a new set of the pictures.
Because it's probably good to see what the changed resize test does.

The changed ratio calculation changes the behaviour.
This commit modifies the add window test.
A sequence of images that draws the window layout that
will be visible on the screen with the changed ratio calculation,
compared to the layout that is visible without it, is uploaded on github.
I extracted the data for the images with a modified version of this
test run by writing the "layout_info" in a file
together with the expected "layout_info".
This test change is probably less worrying than the other one
which changes the resizing test.
The changed ratio calculation changes the behaviour.
This commit modifies the "test_resizing" test.
A sequence of images that draws the window layout that
will be visible on the screen with the changed ratio calculation,
compared to the layout that is visible without it, is uploaded on github.
I extracted the data for the images with a modified version of this
test by writing the "layout_info" in a file
together with the expected "layout_info".

I made this test a bit more extensive than the original one.
@alexander-n8hgeg5e
Copy link
Author

alexander-n8hgeg5e commented Jan 1, 2024

This here is everything summarized and more organized.
This is a new set of pictures based on the rebased commits of the pull request.
For the pull request I had to adjust the "add_windows" test and the "resizing" test.
Below are links to 2 branches in my repo that explain the generation of the pictures and show the way they are derived from the pull request. For the pictures of the "add windows" test I had to remove a commit from the pull request, because, to make the test pass, the commit changes the values of two "layout-infos" and the original values are needed for the side-by-side view.

For the "add_windows" test:

branch that made the pictures for the "add_windows" test
The commit "output window data from test_add_windows" shows that the previous expected values remain in the code and are used for the generation of the side-by-side pictures.

side-by-side pictures for the "add_windows" test

img_add_windows_0
img_add_windows_1
img_add_windows_2
img_add_windows_3
img_add_windows_4
img_add_windows_5
img_add_windows_6
img_add_windows_7
img_add_windows_8
img_add_windows_9
img_add_windows_10
img_add_windows_11

For the resizing test:

branch that made the pictures for the resizing test

pictures for the "resizing" test

img_resizing_0
img_resizing_1
img_resizing_2
img_resizing_3
img_resizing_4
img_resizing_5
img_resizing_6

@alexander-n8hgeg5e alexander-n8hgeg5e changed the title Draft: revised/new patch for improve ratio calculation revised/new patch for improve ratio calculation Jan 1, 2024
@elParaguayo
Copy link
Member

Can you explain, in as few words as possible, what the issue is, what your PR does and what the images above show? I'm finding this quite hard to follow but I appreciate you've put a lot of effort in here.

@alexander-n8hgeg5e
Copy link
Author

Can you explain, in as few words as possible, what the issue is, what your PR does and what the images above show? I'm finding this quite hard to follow but I appreciate you've put a lot of effort in here.

The issue is, the layout calculation does not make the windows as close to the desired ratio as possible.
This PR would improve it.
Why it works? I'm not sure I know it myself but it turned out it works.
The pictures of the "add_windows" test show that it did not change that much in this test.
The pictures of the other test (resizing) are intended to show that the test, which I completely changed, makes sense (hopefully) and are meant to read together with this commit (one picture is taken at every "assert sizes()" statement):
commit

The issue in detail:

If the desired ratio=1 and there are 3 windows on a screen that is 1.125 higher than wide,
then the result is 3 windows 1.125 tall and 0.333 wide. (screen width=1)
Then the ratio is 1.125/(1/3)=3.375
But it would be better to have 3 "landscape" windows because they would be 1.125/3 in height and 1 wide, which is better because if you see the ratio as longer_edge_of_window/shorter_edge_of_window then it is 1/(1.125/3)= 2.666 (closer to 1)
(note: the ratios in this description are inverse(1/x) to the ones in class ratioTile)

I know that this is not the most important issue and it requires some time to supervise something like this.

Copy link

github-actions bot commented Apr 2, 2024

This PR is stale because it has been open 90 days with no activity. Remove the status: stale label or comment, or this will be closed in 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants