Improve estimation table #379

ChristianZimpelmann · 2022-08-23T06:08:07Z

Allow to easily add a row of strings like "Controls": ["Yes", "No"]) to the footer before calling render_latex.
Do not round all cells which contain integer values. Before this PR, e.g. the number of observations were also rounded to two significant digits.

Closes #373.

ChristianZimpelmann · 2022-08-23T06:20:49Z

Three open questions remain (for now):

as _center_align_integers_and_non_numeric_strings is currently set up, a string "Total 2.2 observations" in a cell, would be treated as a float (not center-aligned) and also the first part "Total " would be stripped of. I think we should adjust this, but wanted to discuss this first as I might miss a reason why you came up with this solution in the first place.
How should the interaction with add_trailing_zeros be? Currently implemented: In body, trailing zeros are added to integers. In footer, no trailing zeros are added. I don't have a strong opinion here, as I am not planning to use add_trailing_zeros=True.
I feel like the code block below can somehow be simplified, i.e. without looping over the columns. But didn't find a solution.

    for c in df_formatted:
        df_formatted.loc[position_of_integers[c], c] = df_raw.loc[
            position_of_integers[c], c
        ]

codecov · 2022-08-23T07:04:27Z

Codecov Report

Merging #379 (a32f69c) into main (a770938) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #379      +/-   ##
==========================================
+ Coverage   93.24%   93.26%   +0.01%     
==========================================
  Files         247      247              
  Lines       17987    18000      +13     
==========================================
+ Hits        16772    16787      +15     
+ Misses       1215     1213       -2

Impacted Files	Coverage Δ
src/estimagic/differentiation/derivatives.py	`96.42% <ø> (ø)`
...imagic/optimization/internal_criterion_template.py	`82.48% <ø> (ø)`
src/estimagic/optimization/optimize.py	`92.26% <ø> (ø)`
src/estimagic/visualization/estimation_table.py	`84.96% <100.00%> (+0.03%)`	⬆️
tests/visualization/test_estimation_table.py	`100.00% <100.00%> (ø)`

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

rovement

hmgaudecker · 2022-08-31T07:54:10Z

Thanks! While you are at it, can you please turn off the performance warnings, which are irrelevant for tables:

╭────────────────────────────────────────────────────────────────── Warnings ───────────────────────────────────────────────────────────────────╮
│ task_reg_invest_on_groups_or_params.py::task_reg_invest_on_groups                                                                             │
│ task_reg_invest_on_groups_or_params.py::task_reg_invest_on_groups                                                                             │
│ task_reg_invest_on_groups_or_params.py::task_reg_invest_on_groups                                                                             │
│ task_reg_invest_on_groups_or_params.py::task_reg_invest_on_groups                                                                             │
│ task_reg_invest_on_groups_or_params.py::task_reg_invest_on_groups                                                                             │
│ ... in 15 more locations.                                                                                                                     │
│     /x/estimagic/estimagic/src/estimagic/visualization/estimation_table.py:296: PerformanceWarning: indexing past lexsort depth may    │
│     impact performance.                                                                                                                       │
│       ci_in_body = body.loc[("",)][body.columns[0]].str.contains(";").any()                                                                   │
│                                                                                                                                               │
│ ♥ https://pytask-dev.rtdf.io/en/stable/how_to_guides/capture_warnings.html                                                                    │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

hmgaudecker · 2022-08-31T15:08:33Z

Thanks. Please make sure that when you call a test test_render_latex(), it actually calls the function render_latex. The test that is called this way should be test_center_align_integers_and_non_numeric_strings

While the bug we saw today seems fixed in that function, it has no effect on render_latex because the loop in lines 349-350 of estimation_table is flawed:

        for _, r in footer.iterrows():
            r = _center_align_integers_and_non_numeric_strings(r)

The (correct) result on the RHS is assigned to r, which just disappears in the next iteration.

I tried to fix with

        for idx, row in footer.iterrows():
            footer[idx] = _center_align_integers_and_non_numeric_strings(row)

but this gives an error

TypeError: incompatible index of inserted column with frame index

in my application.

ChristianZimpelmann · 2022-09-25T19:34:55Z

Reminder: At some point, we should make sure that columns consisting of integer values only are right aligned (instead of center-aligned)

ChristianZimpelmann · 2023-03-30T13:08:17Z

@janosg, I just merged main and updated the first comment in this PR.

The remaining comments are:

How should the interaction of treatment of integers with add_trailing_zeros be? Currently implemented: In body, trailing zeros are added to integers. In footer, no trailing zeros are added. I don't have a strong opinion here, as I am not planning to use add_trailing_zeros=True.

My suggestion: leave as is

Reminder: At some point, we should make sure that columns consisting of integer values only are right aligned (instead of center-aligned)

If I am not mistaken, this comments was brought forward by Hans-Martin. I suggest opening an issue and not implementing it here as thinking about comparisons over full columns will most likely need a deeper thought.

hmgaudecker · 2023-03-30T13:20:07Z

How should the interaction of treatment of integers with add_trailing_zeros be? Currently implemented: In body, trailing zeros are added to integers. In footer, no trailing zeros are added. I don't have a strong opinion here, as I am not planning to use add_trailing_zeros=True.

My suggestion: leave as is

Given that the docstring reads:

add_trailing_zeros (bool): If True, format floats such that they have same number of digits after the decimal point. Default True.

I would be very surprised if (under the default!) suddenly all integers showed up as floats. Or do you mean by interaction "columns that contain both integers and floats" ? And by footer the number of observations or so? In that case I would not have a strong opinion, we don't really support tables containing all kinds of different numbers yet, anyhow.

Reminder: At some point, we should make sure that columns consisting of integer values only are right aligned (instead of center-aligned)

If I am not mistaken, this comments was brought forward by Hans-Martin. I suggest opening an issue and not implementing it here as thinking about comparisons over full columns will most likely need a deeper thought.

I guess I do not quite understand why we can easily center-align columns but not right-align them?

ChristianZimpelmann · 2023-03-30T14:06:19Z

Given that the docstring reads:

add_trailing_zeros (bool): If True, format floats such that they have same number of digits after the decimal point. Default True.

I would be very surprised if (under the default!) suddenly all integers showed up as floats. Or do you mean by interaction "columns that contain both integers and floats" ? And by footer the number of observations or so? In that case I would not have a strong opinion, we don't really support tables containing all kinds of different numbers yet, anyhow.

No, I really mean that integers in any of the model outputs are shown as floats. (I guess usually those coefficients are just not integers). But this can easily be changed.

def _get_models_multiindex():
    df = pd.DataFrame(
        data={}, columns=["value", "ci_lower", "ci_upper", "p_value"]
    )
    df.loc[0] = [0.23123, 0, 1, 1]
    df.loc[1] = [1, 0, 1, 1]
    df.loc[2] = [2, 0, 1, 1]
    df.index = pd.MultiIndex.from_tuples(
        [("p_1", "v_1"), ("p_1", "v_2"), ("p_2", "v_2")]
    )
    
    info = {"n_obs": 400}
    mod1 = {"params": df, "info": info, "name": "m1"}
    mod2 = {"params": df, "info": info, "name": "m2"}
    models = [mod1, mod2]
    return models

models = _get_models_multiindex()
out = et.estimation_table(
        models, return_type="render_inputs", confidence_intervals=True
    )
out["body"]

leads to

	m1	m2
('p_1', 'v_1')	0.231$^{ }$	0.231$^{ }$
('p_1', '')	(0.000;1.000)	(0.000;1.000)
('p_1', 'v_2')	1.000$^{ }$	1.000$^{ }$
('p_1', '')	(0.000;1.000)	(0.000;1.000)
('p_2', 'v_2')	2.000$^{ }$	2.000$^{ }$
('p_2', '')	(0.000;1.000)	(0.000;1.000)

I guess I do not quite understand why we can easily center-align columns but not right-align them?

Have I misunderstood your comment that you would like to check the whole column whether it only consists of integers? This is something we do not do at the moment. We currently do not center-align whole columns, but only check and align single cells. Switching from center-align to right-align for those specific cells wouldn't be a problem. But I am not sure whether this really is what we want in columns in which we have floats in the main part of the body and then n_observations at the end.

hmgaudecker · 2023-03-31T03:54:44Z

Given that the docstring reads:

add_trailing_zeros (bool): If True, format floats such that they have same number of digits after the decimal point. Default True.

I would be very surprised if (under the default!) suddenly all integers showed up as floats. Or do you mean by interaction "columns that contain both integers and floats" ? And by footer the number of observations or so? In that case I would not have a strong opinion, we don't really support tables containing all kinds of different numbers yet, anyhow.

No, I really mean that integers in any of the model outputs are shown as floats. (I guess usually those coefficients are just not integers). But this can easily be changed.
def _get_models_multiindex():
    df = pd.DataFrame(
        data={}, columns=["value", "ci_lower", "ci_upper", "p_value"]
    )
    df.loc[0] = [0.23123, 0, 1, 1]
    df.loc[1] = [1, 0, 1, 1]
    df.loc[2] = [2, 0, 1, 1]
    df.index = pd.MultiIndex.from_tuples(
        [("p_1", "v_1"), ("p_1", "v_2"), ("p_2", "v_2")]
    )
    
    info = {"n_obs": 400}
    mod1 = {"params": df, "info": info, "name": "m1"}
    mod2 = {"params": df, "info": info, "name": "m2"}
    models = [mod1, mod2]
    return models

models = _get_models_multiindex()
out = et.estimation_table(
        models, return_type="render_inputs", confidence_intervals=True
    )
out["body"]
leads to
m1 m2
('p_1', 'v_1') 0.231$^{ }$ 0.231$^{ }$
('p_1', '') (0.000;1.000) (0.000;1.000)
('p_1', 'v_2') 1.000$^{ }$ 1.000$^{ }$
('p_1', '') (0.000;1.000) (0.000;1.000)
('p_2', 'v_2') 2.000$^{ }$ 2.000$^{ }$
('p_2', '') (0.000;1.000) (0.000;1.000)

Ah, sorry, seems like I was mistaken in my assumptions.

When talking about integer cells, I was thinking about columns with (Pandas) dtype object, which may contain integer cells:

In [8]: x = pd.Series(["a", 1, 0.01])

In [9]: type(x[1])
Out[9]: int

Seems like you are thinking about the case where we have all-float columns, some of which may happen to look like integers. I agree these cases should not be treated in any special way.

hmgaudecker · 2023-03-31T04:02:53Z

I guess I do not quite understand why we can easily center-align columns but not right-align them?

Have I misunderstood your comment that you would like to check the whole column whether it only consists of integers? This is something we do not do at the moment. We currently do not center-align whole columns, but only check and align single cells. Switching from center-align to right-align for those specific cells wouldn't be a problem. But I am not sure whether this really is what we want in columns in which we have floats in the main part of the body and then n_observations at the end.

Apologies, I had not looked at the code and did not realise that this is fully internal, i.e., it cannot be controlled by the user. This is something that should change eventually (and we may prepare for it in the code by making two functions _center_align_integers and _center_align_non_numeric_strings out of the one function we have), but fine to leave as is for the moment IMHO.

ChristianZimpelmann · 2023-03-31T07:51:34Z

Perfect. I opened #451.

Janos, if you agree, I think we can merge.

hmgaudecker · 2023-03-31T07:54:41Z

With "We may prepare for it in the code ..." I meant "make the preparations now" 😆

In the issue, that line will be misleading to future developers, I believe.

ChristianZimpelmann · 2023-03-31T08:15:38Z

Alright, that makes sense. I deleted it in the issue.

I think it isn`t worth right now to split up the function before we know exactly which changes we are planning to make.

The failing tests seem to be unrelated to this PR.

janosg · 2023-03-31T08:18:39Z

Hi @ChristianZimpelmann, thanks a lot for finishing this up. A few questions:

"Total 2.2 observations" in a cell, would be treated as a float (not center-aligned) and also the first part "Total " would be stripped of.

Is this still the case? I don't think there ever was an intentional choice to have it and it is just a bug and we should fix it before merging.

Allow to easily add a row of strings like "Controls": ["Yes", "No"]) to the footer before calling render_latex

Is the workflow for this documented, ideally with an example? I think this is a very important feature and it should be documented before we merge.

Thanks! While you are at it, can you please turn off the performance warnings, which are irrelevant for tables

Is this done? Should not take long and should be done before we merge.

Thanks. Please make sure that when you call a test test_render_latex(), it actually calls the function render_latex. The test that is called this way should be test_center_align_integers_and_non_numeric_strings ... [see comment by HM]

Is the bug mentioned in this comment by HM fixed?

I had not looked at the code and did not realise that this is fully internal, i.e., it cannot be controlled by the user. This is something that should change eventually

While I agree that the default visualization of integer only columns should change (see #451), I am always hesitant to add yet another argument to give more control to the user. The whole philosophy of estimation_table is to give you something great by default and if you really need absolutely fine control, let you modify the generated DataFrame before it is rendered to latex or html.

Sorry that I ask for more changes, but I think we need to make sure that no bug that was uncovered during this PR slips through the review.

janosg · 2023-03-31T08:56:38Z

I think to really improve estimation_table it would be good to have a set of tables that need to look good out of the box. This could be a separate repo that uses pytask to create the tables and compiles them into one pdf / html document.

Do we have a volunteer to set this up / contribute examples? I think it should be a mix of real world examples and hand crafted examples that contain elements that do not look good in the current version.

Once we have that, I would be more motivated to spend a day on cleaning up the code and making sure everything looks nice.

@timmens could you look into the failing tests on Monday? I agree that they are not related to the current PR but it looks like they fall in your area of expertise.

hmgaudecker · 2023-03-31T09:39:47Z

The whole philosophy of estimation_table is to give you something great by default and if you really need absolutely fine control, let you modify the generated DataFrame before it is rendered to latex or html.

I guess I tend to forget because so far, I have only used it in projects where core developers of this feature were involved and things ended up being fixed in PRs like this one :-)

Would also be great to document how that would work in practice. (not that I checked the website right now...)

ChristianZimpelmann · 2023-03-31T11:07:49Z

Thanks!

"Total 2.2 observations" in a cell, would be treated as a float (not center-aligned) and also the first part "Total " would be stripped of.

Is this still the case? I don't think there ever was an intentional choice to have it and it is just a bug and we should fix it before merging.

No, this was fixed in this PR.

Allow to easily add a row of strings like "Controls": ["Yes", "No"]) to the footer before calling render_latex

Is the workflow for this documented, ideally with an example? I think this is a very important feature and it should be documented before we merge.

I am afraid it is not. Would you document it in a docstring or the Notebook?

Thanks! While you are at it, can you please turn off the performance warnings, which are irrelevant for tables

Is this done? Should not take long and should be done before we merge.

I don't see where it is turned off. But I don't get any performance warning when running pytest .\tests\visualization\test_estimation_table.py. Or when would you expect those warnings?

Thanks. Please make sure that when you call a test test_render_latex(), it actually calls the function render_latex. The test that is called this way should be test_center_align_integers_and_non_numeric_strings ... [see comment by HM]

Is the bug mentioned in this comment by HM fixed?

Yes!

I had not looked at the code and did not realise that this is fully internal, i.e., it cannot be controlled by the user. This is something that should change eventually

While I agree that the default visualization of integer only columns should change (see #451), I am always hesitant to add yet another argument to give more control to the user. The whole philosophy of estimation_table is to give you something great by default and if you really need absolutely fine control, let you modify the generated DataFrame before it is rendered to latex or html.

Sorry that I ask for more changes, but I think we need to make sure that no bug that was uncovered during this PR slips through the review.

Do we have a volunteer to set this up / contribute examples? I think it should be a mix of real world examples and hand crafted examples that contain elements that do not look good in the current version.

I could make a first draft of it next week.

janosg · 2023-03-31T11:24:01Z

The documentation should be here. Nobody reads the docstring.

The Performance warnings are probably only triggered when you have params with a MultiIndex. But it would not hurt to ignore these warnings preemptively for the entire estimation table function.

Thanks a lot for the PR and for setting up the repo!

@hmgaudecker I would say it's documented here but I am very open to any suggestions to improve this documentation.

hmgaudecker · 2023-03-31T11:38:02Z

S+R on that page: fist->first, exmample

You can get almost limitless flexibility if you split the table generation into two steps. The fist generates a DataFrame which you can customize to your liking, the second renders that DataFrame in LaTeX or HTML.

I'd expand this with:

If you are interested in this feature, search for "render_inputs" below.

There should be some heading above the imports on that page, the way it is rendered it seems like they are somehow part of the introduction.

review-notebook-app · 2023-04-06T12:52:39Z

Check out this pull request on

See visual diffs & provide feedback on Jupyter Notebooks.

Powered by ReviewNB

ChristianZimpelmann · 2023-04-06T13:02:31Z

I now updated the how-to notebook and added in particular the feature which was added in this PR.

I also implemented all suggestions by @hmgaudecker (see below). So far, I haven't renamed the how-to though. I don't have a strong opinion or a good idea what could be more "catchy".

I will work on the repo of example tables later today.

S+R on that page: fist->first, exmample

You can get almost limitless flexibility if you split the table generation into two steps. The fist generates a DataFrame which you can customize to your liking, the second renders that DataFrame in LaTeX or HTML.

I'd expand this with:

If you are interested in this feature, search for "render_inputs" below.

There should be some heading above the imports on that page, the way it is rendered it seems like they are somehow part of the introduction.

ChristianZimpelmann · 2023-04-09T07:30:40Z

src/estimagic/visualization/estimation_table.py

-            show_index_names=show_index_names,
-            show_col_names=show_col_names,
-            escape_special_characters=escape_special_characters,
+    with warnings.catch_warnings():


But it would not hurt to ignore these warnings preemptively for the entire estimation table function.

@janosg, is this the implementation you had in mind?

I would have renamed the current estimation_table to _estimation_table and defined a new estimation_table that calls _estimation_table in this catch warnings context. Otherwise we get a lot of indentation.

Or decorate it? https://numpy.org/devdocs/reference/generated/numpy.testing.suppress_warnings.html

Very good idea! We should do that!

sounds good!

I implemented it using a decorator in the last commit.

Do you have any more suggestions? Otherwise, we can merge.

From my side all good!

janosg

Thanks again, @ChristianZimpelmann! I think we can merge!

ChristianZimpelmann · 2023-04-10T08:07:34Z

One test is still (or again) failing.. unrelated to changes in this PR as far as I understand.

Should I just ignore it?

janosg · 2023-04-10T09:10:43Z

We are working on these random failures. Yes, it's unrelated. I'll merge.

ChristianZimpelmann added 5 commits August 1, 2022 12:22

start implementing that strings are wrapped by multicolumns

ebfc129

add a comment to estimation_table.

8ae9515

make sure that integers are not formatted.

70dfb1e

Merge branch 'main' into improve_estimation_table

dbf71d3

minor adjustments.

797c1fe

adjust tests to changes. Some cosmetic changes.

da83005

segsell and others added 6 commits August 26, 2022 13:46

Merge branch 'main' into improve_estimation_table

a3a2f7f

small fixes in number formatting functions

bb8a06b

small code imp

675187a

rovement

small code improvement

246b033

Improve formatting functions in estimation table

1337c19

update tests

16ff5ad

fix bug in _center_align_integers_and_non_numeric_strings

d491507

ChristianZimpelmann added 5 commits November 25, 2022 09:32

fix bug in center align integers in footer.

8c785bb

fix typo in docstring.

f15f46a

fix another typo in docstring.

076b3a0

change name of test.

fce26ed

merge main and solve merge conflict.

2b7c853

Merge branch 'main' into improve_estimation_table

cf22e38

ChristianZimpelmann mentioned this pull request Mar 31, 2023

Estimation table: reconsider visualization of integers #451

Open

ChristianZimpelmann requested a review from janosg March 31, 2023 07:52

ChristianZimpelmann added 2 commits April 6, 2023 13:15

Merge branch 'main' into improve_estimation_table

1fc15f1

add documentation of how to add additional information to the footer.

9ec6870

ChristianZimpelmann added 2 commits April 6, 2023 14:54

let notebook run through completely.

e8e5aca

add one sentence proposed by HM.

5a1c44b

ChristianZimpelmann added 3 commits April 9, 2023 09:14

merge main.

05ef572

ignore PerformanceWarnings in estimation_table.

57756fc

adjust how PerformanceWarnings in estimation_table is ignored.

c2a8aef

ChristianZimpelmann commented Apr 9, 2023

View reviewed changes

janosg approved these changes Apr 10, 2023

View reviewed changes

ChristianZimpelmann added 3 commits April 10, 2023 09:22

move ignoring of performance warnings to new outer function.

6311d58

fix typo.

c937907

implement ignoring PerformanceWarning with decorator.

a32f69c

janosg merged commit 2dcfe51 into main Apr 10, 2023

janosg deleted the improve_estimation_table branch April 10, 2023 09:10

timmens mentioned this pull request Mar 13, 2024

Implement a few fixes #490

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve estimation table #379

Improve estimation table #379

ChristianZimpelmann commented Aug 23, 2022 •

edited

Loading

ChristianZimpelmann commented Aug 23, 2022 •

edited

Loading

codecov bot commented Aug 23, 2022 •

edited

Loading

hmgaudecker commented Aug 31, 2022

hmgaudecker commented Aug 31, 2022

ChristianZimpelmann commented Sep 25, 2022

ChristianZimpelmann commented Mar 30, 2023

hmgaudecker commented Mar 30, 2023

ChristianZimpelmann commented Mar 30, 2023 •

edited

Loading

hmgaudecker commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

ChristianZimpelmann commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

ChristianZimpelmann commented Mar 31, 2023

janosg commented Mar 31, 2023

janosg commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

ChristianZimpelmann commented Mar 31, 2023

janosg commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

review-notebook-app bot commented Apr 6, 2023

ChristianZimpelmann commented Apr 6, 2023 •

edited

Loading

ChristianZimpelmann Apr 9, 2023

janosg Apr 10, 2023

hmgaudecker Apr 10, 2023

janosg Apr 10, 2023

ChristianZimpelmann Apr 10, 2023

ChristianZimpelmann Apr 10, 2023

ChristianZimpelmann Apr 10, 2023

janosg Apr 10, 2023

janosg left a comment

ChristianZimpelmann commented Apr 10, 2023 •

edited

Loading

janosg commented Apr 10, 2023

Improve estimation table #379

Improve estimation table #379

Conversation

ChristianZimpelmann commented Aug 23, 2022 • edited Loading

ChristianZimpelmann commented Aug 23, 2022 • edited Loading

codecov bot commented Aug 23, 2022 • edited Loading

Codecov Report

hmgaudecker commented Aug 31, 2022

hmgaudecker commented Aug 31, 2022

ChristianZimpelmann commented Sep 25, 2022

ChristianZimpelmann commented Mar 30, 2023

hmgaudecker commented Mar 30, 2023

ChristianZimpelmann commented Mar 30, 2023 • edited Loading

hmgaudecker commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

ChristianZimpelmann commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

ChristianZimpelmann commented Mar 31, 2023

janosg commented Mar 31, 2023

janosg commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

ChristianZimpelmann commented Mar 31, 2023

janosg commented Mar 31, 2023

hmgaudecker commented Mar 31, 2023

review-notebook-app bot commented Apr 6, 2023

ChristianZimpelmann commented Apr 6, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janosg left a comment

Choose a reason for hiding this comment

ChristianZimpelmann commented Apr 10, 2023 • edited Loading

janosg commented Apr 10, 2023

ChristianZimpelmann commented Aug 23, 2022 •

edited

Loading

ChristianZimpelmann commented Aug 23, 2022 •

edited

Loading

codecov bot commented Aug 23, 2022 •

edited

Loading

ChristianZimpelmann commented Mar 30, 2023 •

edited

Loading

ChristianZimpelmann commented Apr 6, 2023 •

edited

Loading

ChristianZimpelmann commented Apr 10, 2023 •

edited

Loading