No need to do anything special. Just send submissions in the time frame. As for the Most Prolific category, prior work of course already counts.

Note to others: Sander is among the more prolific of external contributors (and has a number of excellent published functions). But to reiterate, most awards apply to the submission time frame, where it's a clean slate going in.

What's the best way of distributing a set of closely related functions all of them drawing on a core of helper functions (and each other)?

I think that the only good answer to this is that the functions should go into a package. I would not use the function repository.

You can publish a package now, without waiting for a package repository. An official Wolfram package repository is not a prerequisite (although it would be useful for the community as it would facilitate the adoption of packages). People have been writing packages for Mathematica since the system was first released.

I am concerned about the future of packages (and the planned package repository) because I repeatedly see people express the opinion that "the function repository is sufficient", when someone writes some useful code that "you should submit it to the function repository", or simply not even realizing the huge difference between these concepts, and that the more valuable some work is the less likely it is that it is suitable for the function repository.

I do not see how Mathematica could compete with other systems without any well supported facilities to create packages, and I am puzzled about why this is not prioritized over things like the function repo which is just not an alternative.

We look forward to the submissions (I write this as we are doing a WFR review meeting).

Hi Daniel,

Thanks for the insights! Exciting to hear! I really like the WFR and make use of it quite a bit. Some things I would like to see as improvements on the already great current design:

• User pages (i.e. I can see an overview of functions submitted by a certain person).
• Popular functions (e.g. by number of downloads).
• Search more lenient, more forgiving, more fuzzy, now you basically need an exact match.
• (User submitted?) Guide pages
• A way of suggesting knittings from older functions to your own new functions. (I now send suggestions directly to Bob, but some automated way would be nice). This could be partly automated in the sense that if new function f knits to old function g, there is quite a high probability g should also knit towards f.

The remarks by @SzabolcsHorvat and @J.M. about package vs individual function construction are all valid of course. I will point out that there is an intermediate path that is, in some cases, also viable. One can use a "container" function and support different operations therein. (I believe this is a subset of what goes as Object Oriented Programming, but I predate OOP so I'm not really certain). One example of what I have in mind is the WFR entry "ExpressionBag" by Richard Hennigan.

https://resources.wolframcloud.com/FunctionRepository/resources/ExpressionBag

This really only applies in cases where it makes sense to have a single "function" supporting multiple operations. Implementation of specific data structures is one area where this use case might be common. If time permits I might post a related example to Community.

Great idea!

Winners will be announced at the conference and subsequently posted here on Wolfram Community.

The conference is over. Are the results of the Sprint published anywhere?

Hi Daniel,

Am I right that the submission source code need not to be necessarily formatted as a single function with private subfunctions hidden as Module variables, and may be presented as a package with only the main function exposed at the top level? For example, may I offer my PolygonMarker function as a submission?

Also there is no need to make it a Wolfram Language package. So you could simply use the code between but not including the Begin["Private"] and End[].

But then these private subfunctions will litter the namespace of the user what I feel undesirable. Can I still keep it in the form of a package?

How are submissions handled that require (minor) changes before being accepted? (I'm asking since it looks like re-submitting creates a new submission for the current date, instead of updating the old one)

Just send you another one, that is in the making since the start of WFR, but never had the time to finish it. That will probably be my last one before the WTC. Hope you like it :-)

@JoshuaSchrier This is very a good question although, unfortunately, I do not have a particularly good answer. Here are some possibilities.

(1) Bite the bullet and reuse a lot of code in the several submissions. I seriously recommend against this. In addition to being unappealing, it leads to a multiple-maintainance problem, should there need to be changes in the helper functions. No sense battling a hydra when you can just deal with an ordinary viper.

(2) Wait for us to offer a package repository better suited for delivery of interrelated functionality. This is in our plans but there is no time frame of which I am aware (maybe others here have more detail).

(3) Code the helper functions as separate resource items. I believe these can be made "undescoverable", that is, they will not be visible to searches but will nevetheless be available. Your implementation code would then use things like ResourceFunction["helperXXX"]. While I am unclear on details, again maybe someone else here can jump in to explain this path in better detail. I'll make inquiries.

Anton,

This might be a bug you are reporting, but...how is it relevant to this particular thread? Assuming it is, please edit to make that connection clear.

RiemannSurfacePlot3D looks like a cool idea for mainline inclusion. However, often you may want different embeddings for different patches of the surface, see for example:

https://www.youtube.com/watch?v=m5moOyP0zek

which uses three different projections from R^4 to R^3. I dream of someday just inputting an algebraic equation, then the graph function returns a best-possible embedding to 3D, but perhaps this is asking too much. How about starting with "TorusPlot[EllipticCurve_]:= 1. Find critical points. 2. expand hyperbolae around them." ?

Cheers --Brad

--Brad

Great, thanks!

Thanks for reaching out. Our events team will contact to get size and shipping details. Congratulations again. Also, I actually used some of your code to beat information from our knowledge base in one of my WFR examples.