New package: Phi v0.1.0

[JuliaRegistrator]

• Registering package: Phi
• Repository: https://github.com/withbayes/Phi.jl
• Created by: @willtebbutt
• Version: v0.1.0
• Commit: b803b4944e773312cc54e40cb3ce1fef12abce69
• Reviewed by: @willtebbutt
• Reference: compintell/Mooncake.jl@b803b49#commitcomment-140206554

[github-actions]

Your new package pull request does not meet the guidelines for auto-merging. Please make sure that you have read the General registry README and the AutoMerge guidelines. The following guidelines were not met:

• Name is not at least 5 characters long
• Package name similar to 6 existing packages.
  1. Similar to Fri. Damerau-Levenshtein distance 2 is at or below cutoff of 2. Normalized visual distance 1.40 is at or below cutoff of 2.50.
  2. Similar to Pkg. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  3. Similar to PWF. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  4. Similar to PEG. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  5. Similar to Why. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  6. Similar to FMI. Normalized visual distance 2.17 is at or below cutoff of 2.50.

Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human.

After you have fixed the AutoMerge issues, simply retrigger Registrator, which will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless of course the AutoMerge issue is that you skipped a version number, in which case you should change the version number).

If you do not want to fix the AutoMerge issues, please post a comment explaining why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the Julia Slack to ask for help. Include a link to this pull request.

Since you are registering a new package, please make sure that you have also read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

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. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[goerz]

I didn't mind Taped.jl, but Phi.jl seems just way too nondescriptive and short. While there is ample precedent for AD-packages in Julia using relatively short and "nice" ("non-systematic") names, just "Phi" feels a bit too extreme. Especially since I have no association between "Phi" and AD, and "Phi" is one of the most overloaded letters in all of science.

Cf. #103548 (comment)

[yebai]

Justification for nonstandard name: https://github.com/withbayes/Phi.jl/tree/main?tab=readme-ov-file#project-name

[goerz]

I did see that, but I don't buy it. It's just too short, and phi-nodes in SSA-IR is too obscure a connection. At least in my opinion; maybe there's a maintainer consensus that the name is OK.

Don't you like Untaped.jl?

[ViralBShah]

Phi.jl seems like a much nicer name than Untaped.jl. The group has released several high quality packages with long term support - which personally makes me more comfortable with a shorter memorable name here.

But this is just my personal view (and is subjective).

[ViralBShah]

Oops, accidentally clicked the close button instead...

[gdalle]

I do not have merge rights but I agree that Phi is pushing it with the shortness, regardless of package and contributor quality. How about Pullback.jl cause it's the main thing the package offers?

[ViralBShah]

We have other packages with short memorable names - for example - Lux.jl. I feel Phi.jl sounds much nicer than Pullback.jl (and there could perhaps be a slightly longer memorable name too).

[goerz]

Like I was saying,

Phi" is one of the most overloaded letters in all of science

which makes it worse name than Lux.

The group has released several high quality packages with long term support - which personally makes me more comfortable with a shorter memorable name here.

I agree, and I'd take that as a prerequisite to considering something like Phi. I'm certainly not "vetoing" the name (not that I could). If there's a consensus that we want "Phi" to be the brand name for a new Julia AD package, go for it!

[ViralBShah]

Phi" is one of the most overloaded letters in all of science

I say this only tongue in cheek - but multiple dispatch is (somewhat) about giving new meanings to existing names. If Phi becomes an amazing new Julia AD package, it would be worth overloading.

[gdalle]

Jacob.jl / Jack.jl, for vector-Jacobian products?

[gdalle]

Or the variant HiJack.jl, cause you hijack compilation?

[rayegun]

I for one like the name Phi. Many of the other AD packages have similarly cute names, that are undescriptive (Lux / Enzyme) or minimally descriptive (Diffractor).

When a name is wrong, like if Symbolics.jl was named Dictionaries.jl for some reason, I think that's a fair block.

But when a name has plenty of meanings, or it's not directly contradictory, I see no reason to reserve names like this. Enzyme for instance has little to do with enzymes for a biologist using Julia. But it's a great and recognizable name.

I also would never have associated Flux, Lux, Enzyme, Umlaut, Avalon, Torch, Jax, etc with AD and ML before they existed. So I'm not sure why that should be a strict criteria.

[rayegun]

Pullbacks.jl, HiJack.jl, Jacob.jl, Untaped.jl

Respectfully these all feel very dry to me. There's a tendency in our community to name things very literally, like ReverseDiff or Symbolics. But that naming style isn't everyone's cup of tea, and I find punchy names like Torch or JAX a lot more memorable than long Matlab toolkit style names like ReverseDiff.

[gdalle]

I think using existing short package names to justify new ones is a bit dubious, because many of those predecessors were registered a long time ago. Back then, I assume registration was less strict, because the space of possible names felt unlimited. But now we know it isn't, and the space of possible 3-letter packages in particular is not that big. This is especially true when accounting for edit distance constraints.
I also don't see why there should be an exception for AD / ML packages, or packages from well-regarded developers, who would somehow get a quirkiness pass.

Personally, I think it's cool that packages have quirky and memorable names. But as a community I feel we may need to draw a line somewhere, and three letters is a good spot for it. If someome came in and wanted to register the quantum physics package Psi.jl, because Psi is the symbol of the wave function, would that be a yes too? Arguably the name has a stronger case for it. But what if the dev were unknown to the people watching the "new packages" feed? Regardless of package quality, would they get the same treatment?

[gdalle]

To be clear, I'm not fundamentally opposed to this package name in particular, and if the consensus is against me I'll noblock my comments. I just thought it was an opportunity to discuss the spirit of the rules we try to apply here

[oxinabox]

Phi is an annoyingly obscure name, that is hard to google (even googling Phi + Julia might not hit it).
I worry it will harm this package.

I also think a portly justified name will bias people against the package. At least Lux has the cleverness that it is Flux without the Functors, and names like CSV.jl refer to well known things.

I don't hate it, but i feel its not the best call when there is a world of other names.

[yebai]

Thanks all for the suggestions. As an experiment for naming new packages, I outsourced this challenging decision to LLM.

Google Gemini seems to believe Jaco (abbreviation of Jacobian) strikes the optimal balance. https://g.co/gemini/share/3bb48156166f

EDIT: Further comments on the pronunciation of Jaco: https://g.co/gemini/share/21cdd2b784eb

[willtebbutt]

What are people's thoughts on Tapas.jl? It's a very loose food-based pun on tape, mirroring the fact that the package makes use of a tape only in the loosest sense. It has the advantage of paying tribute to the C / Fortran AD tool "tapenade", whose name is also a food-based pun.

[gdalle]

I love it!

[willtebbutt]

Additionally, thoughts on Tapir.jl? @yebai pointed out that there doesn't seem to be an AD package using it yet.

[goerz]

I like Tapas better.

[yebai]

@willtebbutt and I liked the name Tapas, but I thought its connection to the project was remote. Neither Will nor I had any Tapas during the project.

Personally, I think Tapir, i.e. Tape-IR, provides a much stronger connection with the technical core of the project. It also happens that the development team thinks Tapir is a cute mammal. https://en.wikipedia.org/wiki/Tapir

[gdalle]

I love it!

[goerz]

Neither Will nor I had any Tapas during the project.

That's easily fixed! 😉

Both names are perfectly fine, so it's really up to you whatever you decide on

[GunnarFarneback]

Tapir sounds like a familiar name. I guess I was thinking of https://github.com/wsmoses/Tapir-LLVM.

[goerz]

Tapir sounds like a familiar name.

That's actually a somewhat more serious reason to avoid the name Tapir. We actually very recently added an explicit guideline related to that, even though whether that really applies here is pretty arguable.

[yebai]

I don't think Tapir-LLVM should be a serious blocker since

1. the last Git commit was five years ago
2. the software name is called Tapir-LLVM instead of Tapir, although the technique was referred to as Tapir by the paper

[goerz]

Yeah, like I said, "arguable" 😉

[rayegun]

This is the successor, which still mentions Tapir frequently: https://github.com/OpenCilk/opencilk-project

[goerz]

To be fair, there are also a couple of projects using the name TAPAS: https://github.com/search?q=tapas&type=repositories

They're all uppercase, though, and seem reasonably obscure that I would not consider them a blocker to Tapas.jl at all. Tapir.jl, maybe, because of how closely tied Julia and LLVM are, but even that is pretty tenuous, so I wouldn't seriously have a problem with either Tapir or Tapas

[gdalle]

Also the Tapir-LLVM package seems unregistered?

https://juliahub.com/ui/Search?q=Tapir&type=packages

[goerz]

Neither name has any conflict with an existing Julia project. The Tapir-LLVM is just the C++ project and then other obscure stuff

[willtebbutt]

We can close this in favour of #103806 .

Thanks everyone for your feedback -- @yebai and I greatly appreciate it.

[vchuravy]

The name Tapir did have some precedent in the Julia world in particular as the name for a proposed standard library JuliaLang/julia#39773