Message Boards Message Boards

32 Replies
55 Total Likes
View groups...
Share this post:

Announcing The Wolfram Tech Conference Function Sprint

enter image description here

Update 2019-11-10: Winners' Announcement

Belatedly, here are the winners (also I changed the category names a bit, and added one, but hey, this is not terribly formal). We thank all who participated in the sprint, as well as all contributors to the Wolfram Function Repository. Since it was announced in a blog by Stephen Wolfram, over 40 % of submissions have been from outside the company. We are quite happy to see this trend. As for the sprint, I believe we received over 120 submissions during that time frame. Suffice it to say that reviews had to be amped up just to stay afloat.

The prizes are tee shirts designed specifically for the WFR. If you won an award and were not present to receive a prize, please reach out to us so we can ship a tee shirt to you (and let us know the size you would like). We will of course attempt to reach all winners ourselves, but sending us a note could expedite matters...

First an honorable mention to Bob Sandhenirich and Rick Hennigan (generally known hereablots as "Bobrick") for all the work they put into the WFR infrastructure. They created the authoring notebook, the review notebooks, and most of the publishing system is their doing as well. Also we poached them, so to speak, to be submission reviewers. Which has proven to be quite helpful in terms of keeping the quality of published functions high.

The awards and winners:

  • Aster Ctor - for volume of external submissions during the sprint

  • Dennis Schneider, Sander Huisman, and Seth Chandler - for overall volume of external submissions (we made no effort to count carefully...)

  • Carl Woll and Jesse Friedman - for volume of internal submissions during the sprint. They were both in the teens, one apart, and I don't recall which had that one extra. We announced them as a "virtual tie". If you tell me there is no such thing as a virtual tie (as one person tried to do following the awards announcements), I will simply put on my vampire fangs and bite your neck.

External contributions, top three in quality:

  1. Anton Antonov (RandomMandala)
  2. Dennis Schneider (SectionPlot3D)
  3. Mark Greenberg (ImageKaleidoscope)

Honorable mention:

  • Aster Ctor (PolyPainting) and Jessica Shi (DNAAlignment -- I have pilfered code from that one)

Internal contributions, top three in quality:

  1. Michael Trott (RiemannSurfacePlot)
  2. Jon McLoone (DynamicViewPointSyncghronize)
  3. Jesse Friedman (GeoGlobe3D)

Best Newcomer:

  • Jessica Shi

Special honorable mentions:

  • Sascha Kratky - for a submission that was flawlessly formatted despite our lack of documentation on how to go about that, which we hope to address in future.

  • Mark Greenberg - for an excellent submission called ScansionDiagram based on summer school work shown in Community. We are unable to publsih it until some OS-specific bugs at our end get fixed.

  • Alexey Popkov and Jan Mangaldan, for managing to format submissions despite not having access to version 12. Some day the Wolfram Cloud will fully support this. But that day has not arrived.

Also: I believe Jesse and Jessica are both 18 years of age. Pretty phenomenal, what they can do already. I'm not sure if I should be happy or scared (we announced the awards on Halloween, so maybe both).

Competition Discription

A few months ago we opened the Wolfram Function Repository to contributions from users outside the employ of the company. We have received quite a number to date, with most making their way into the set of published functions. This has been quite encouraging, so we thought we would go a bit further (1,2). The following has been announced to registrants for the 2019 Wolfram Tech Conference. This competition is open to all comers, however; one need not attend the conference in order to compete.

Prizes will be awarded in several categories to authors of Wolfram Function Repository functions. Eligible submissions must be received between September 27 & October 13. Categories include (and may be expanded):

  • Best in-house submission (function repository team members excluded from this one).

  • Best external submissions (top three, based on function repository team votes)

  • Most functions published from the time frame of this sprint (open to all comers)

  • Most Prolific - most functions published from date of inception of function repository

  • Best Debut - best functions published by someone with no more than three submissions before the sprint begins.

Winners will be announced at the conference and subsequently posted here on Wolfram Community. Where feasible we will ship prizes to those winners not attending the WTC. Depending on content of functions submitted, we may opt to add prize categories.


  1. Read: make more work for ourselves.
  2. Which is a good problem to have.

enter image description here

enter image description here

POSTED BY: Daniel Lichtblau
32 Replies

Hi! I was one of the winners. A t-shirt would be really cool. My email is Thank you for this opportunity!

POSTED BY: Jessica Shi

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.

POSTED BY: Daniel Lichtblau

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:

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


POSTED BY: Brad Klee

The winners are now announced in the top head post. Congratulations to all winnders! And deepest thanks to all who has taken a part in this event!

enter image description here

POSTED BY: Moderation Team
Posted 4 years ago

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?

POSTED BY: Alexey Popkov

@Daniel Lichtblau I love the idea of the function repository to facilitate sharing functions. The above thread helped answer a question I had about how non-public helper functions are treated (and how they don't contaminate the users namespace)

My question for you is: 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)? Can these multiple public functions be part of a single Wolfram repository "function"? I've developed a set of functions for doing Huckel calculations and visualizations on Molecule[]s, and had originally planned to disseminate it in the WFR, which would make it easy for students and teachers. There are about 6 public functions; since they are all highly related and rely on a shared core, breaking it up into separate WFR entries seemed undesirable. What's your recommendation? .

animated gif demo of HuckelTheory

POSTED BY: Joshua Schrier

@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.

POSTED BY: Daniel Lichtblau

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.

POSTED BY: Szabolcs Horvát
Posted 4 years ago

There are about 6 public functions; since they are all highly related and rely on a shared core, breaking it up into separate WFR entries seemed undesirable.

As noted, not putting all of these functions together in a single package would be dreadful for maintainability purposes.

In addition to what Szabolcs said, you always have the option of putting up your package on GitHub, Bitbucket, or some other equivalent service; additionally, let me also mention posting your package on PackageData, or even create a Zenodo entry for it to let other potential users know about your package.


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.

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.

POSTED BY: Daniel Lichtblau

Should be removed...

POSTED BY: Anton Antonov


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

POSTED BY: Daniel Lichtblau

Agreed, I assume the admins can remove this comment and my previous comment.

POSTED BY: Anton Antonov
Posted 4 years ago

I'm not sure if it was this comment or another comment where the issue with PackageData's URL size limit was raised. In any case, I'm sorry about that! I've now fixed it.


Great, thanks!

POSTED BY: Anton Antonov

We have had quite the Sprint. All told, we received (I think) more than 100 submissions during the Sprint submission period*. As a result the reviewers are somewhat submerged (glug), which I guess counts as a big success. We are now holding a review session every working day. It looks like we will get most of the submissions reviewed, and nearly all of the exceptions will be from in-house authors.

Now for some remarks.

(1) I thank all participants. We've at this point published more than half of the received submissions and are happy to see that overall quality is high.

(2) We are recognizing a number of pain points for authors, from formatting issues to problems with resubmission. We hope to clarify many of these obscure details going forward.

(3) There will be a Wolfram Function Repository talk/meet-up at the upcoming Wolfram Tech Conference. In addition to discussing some of the problematic aspects to authoring WFR content, we will make time to get feedback from attendees. While we have been made aware of several trouble spots, I'm sure there are more out there.

(4) For those not attending, feel free to send remarks in responses to this thread. No need to mention the fact that the Cloud submission is not working, it's already in here.

(5) For those who have submissions that are not yet reviewed, my apologies. We try to prioritize based on whether an author is new or relatively new. And some take a long time to edit; when pressed for time, we have to defer on such submissions. We thank you for your patience in any case.

Again, our thanks to those of you who participated. And my thanks to the extremely busy review team members.

  • I did not actually count them. I am dimly aware this could be done programatically.
POSTED BY: Daniel Lichtblau

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.
POSTED BY: Sander Huisman

I forgot to add:

  • Search in Mathematica includes WFR functions. Especially when the built-in search has no hits, it could look at WFR
  • F1/(Cmd+shift+f) with an orange pill selected leads to doc page. (I see tooltip already works in 12.1 beta: great!)
POSTED BY: Sander Huisman

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 :-)

POSTED BY: Sander Huisman
Posted 4 years ago

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)


Not to worry, these count for purposes of the sprint. More generally, we are counting functions that were submitted in the time frame but not published for any reason other than outright rejection (I do not recall any having that fate, by the way).

I also have some general comments that I will make in a reply to the original post.

POSTED BY: Daniel Lichtblau

Great idea!

POSTED BY: Daniel Bigham
Posted 4 years ago

I'd like to submit a few utilities too small to be made into a separate package to the repository, but it seems that when I try to use the submission notebook in Wolfram Cloud, the buttons for submitting do not work. Barring having an actual copy of Mathematica 12, are there other ways to submit entries?


I asked and was informed that the Cloud platform does not yet support WFR submissions. Sorry about that. If you have actual notebooks you can send them to us (or to me directly, if you like).

POSTED BY: Daniel Lichtblau
Posted 4 years ago

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?

POSTED BY: Alexey Popkov

@Alexey Popkov,

You are absolutely correct. Indeed, we vastly prefer that helper functions not be nested inside the main function.

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[].

POSTED BY: Daniel Lichtblau
Posted 4 years ago

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?

POSTED BY: Alexey Popkov

Actually it all goes into some cell context, so they should not appear in the users name space(s).

As for whether it is possible anyway to keep a submission in Package form, off the top of my head I'm not sure if that is supported by the WFR infrastructure. I guess you could try it, and add a note to the Author notes to let the review team know it's your preference. If we decide it might not work we can just strip off the packaging part in the review process.

POSTED BY: Daniel Lichtblau
Posted 4 years ago

Aha, finally the motivation to spend a few hours adding some functions! Looking forward to this!

POSTED BY: Carl Lange

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

POSTED BY: Daniel Lichtblau

Very interesting Daniel. Do I have to do something to enter the competition?

POSTED BY: Sander Huisman

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.

POSTED BY: Daniel Lichtblau
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract