New package: AMORS v0.3.1

[JuliaRegistrator]

• Registering package: AMORS
• Repository: https://github.com/emmt/AMORS.jl
• Created by: @emmt
• Version: v0.3.1
• Commit: fced13e4fc8360927154935d51c3f313bb6ea625
• Reviewed by: @emmt
• Reference: emmt/AMORS.jl@fced13e#commitcomment-152630603
• Description: Framework to apply the AMORS algorithm in Julia
• Release notes:

- `AMORS` is now public.
- Add `autoscale` property and fix iteration counting.
- More properties for `AMORS.Info`.

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines which are not met ❌

• Name does not meet all of the following: starts with an upper-case letter, ASCII alphanumerics only, not all letters are upper-case.

3. Needs action: here's what to do next

1. Please try to update your package to conform to these guidelines. The General registry's README has an FAQ that can help figure out how to do so.
2. After you have fixed the AutoMerge issues, simply retrigger Registrator, the same way you did in the initial registration. This will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless the AutoMerge issue is that you skipped a version number).

If you need help fixing the AutoMerge issues, or want your pull request to be manually merged instead, please post a comment explaining what you need help with or why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the public Julia Slack for better visibility.

4. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[emmt]

AMORS is in uppercase letters because it is the acronym for "Alternated Minimization using Optimal ReScaling" the name of the published method (see References).

[goerz]

Unfortunately, acronyms are heavily frowned upon in the Julia community. Personally, I don't have issues with pronounceable acronyms like AMORS. I would merge this (but don't have merge permissions).

You will have to go on Slack to convince a full registry maintainer to merge this manually. There seems to be less and less appetite for acronyms, though, so it may require repeated pings.

Besides the pronounceability of AMORS (which makes it a perfectly acceptable "less systematic name" in my book), good arguments might be that there is no very obvious alternative package name that would fit the usual "long and descriptive" mold, and that you could get around the automatic check by varying the spelling to Amors or AMORs. It seems silly to me to prevent the use of a package name solely based on capitalization.

[emmt]

@goerz Thank you for your reply.

I could rename the package as Amors unfortunately it fails the AutoMerge distance test. I have checked that I can use BilinearModelOptimalRescaling which is a bit long but which conveys all necessary information and add AMORS as a topic...

How do I cleanly cancel a registration?

[goerz]

I could rename the package as Amors unfortunately it fails the AutoMerge distance test.

I can override that check. Usually, it's a false positive. What package does Amors conflict with? I thought that the name similarity check was case-insensitive, so it's a bit surprising that AMORS doesn't trigger it as well.

In any case, I would make a strong case for AMORS being better than Amors. I dislike the idea of changing the capitalization of an acronym just to make the bot happy. By doing that, you lose the connection to what just is an acronym. Personally, I think the choice between "merge AMORS manually" and "let the renamed Amors auto-merge" is a no-brainer, the former being hugely preferable to the latter from a community perspective.

I have checked that I can use BilinearModelOptimalRescaling which is a bit long but which conveys all necessary information

That's definitely an option that would side-step the issue. "Long" is generally encouraged, so that's not a problem. Plus, it's always possible to use it as import BilinearModelOptimalRescaling as AMORS. What you might lose is name recognition. I don't know how widely known the acronym AMORS is, and whether that's a significant concern.

My recommendation would be – unless you have a preference for BilinearModelOptimalRescaling – to wait to the end of the three-day period, and then ask for AMORS to be merged manually.

How do I cleanly cancel a registration?

Unmerged registrations are automatically closed after 30 days of inactivity. Or, I can close a PR manually, which I usually do if there's a replacement, e.g., a new package name ("Closing in favor of …")

[emmt]

Here is the result of the metric:

julia> using RegistryCI, RegistryCI.AutoMerge

julia> all_pkg_names = AutoMerge.get_all_non_jll_package_names(joinpath(DEPOT_PATH[1], "registries", "General"));

julia> AutoMerge.meets_distance_check("AMORS", all_pkg_names)
(true, "")

julia> AutoMerge.meets_distance_check("Amors", all_pkg_names)
(false, "Package name similar to 4 existing packages.\n  1. Similar to Amaru. Damerau-Levenshtein distance 2 is at or below cutoff of 2. Normalized visual distance 2.05 is at or below cutoff of 2.50.\n  2. Similar to Kmers. Damerau-Levenshtein distance 2 is at or below cutoff of 2. Normalized visual distance 2.44 is at or below cutoff of 2.50.\n  3. Similar to Attrs. Damerau-Levenshtein distance 2 is at or below cutoff of 2.\n  4. Similar to Actors. Damerau-Levenshtein distance 2 is at or below cutoff of 2.")

so it seems that the check is case sensitive.

My recommendation would be – unless you have a preference for BilinearModelOptimalRescaling – to wait to the end of the three-day period, and then ask for AMORS to be merged manually.

I think I will follow your advice. Indeed I strongly prefer AMORS to be the name of the package as it is also the name of the published method. I am ready to wait a few more days for a "manual merge".

Many thanks for your help.