Using jargon in the name of the @derivative attribute

I strongly disagree. withReespectTo is as obscure as wrt for anyone who doesn't know anything about derivatives. It's domain specific. This will only make sense to someone who either studied it or wants to know about it. To me wrt is the most apt term for it and I didn't know about it until recently by following this thread.

2 Likes

Do you mind if I rename this thread? Neither the original post nor the progress of the thread seems to actually be independent of the original context.

13 Likes

Bearing in mind that I'm not a mathematician (I haven’t had to touch differentiation in about 14 years), I would very much be against using such an acronym in any standard API. This may be due to a being a long time Objective-C developer, but I always find clarity is infinitely preferable to saving a few keystrokes (though modern Swift tends to strike a better balance). Acronyms are generally best left to terms that are nouns (e.g. URL, PNG, JSON), with everything else being spelled out in full

There has also been mention of things like sin, cos, log, etc. in support of wrt, but it's worth remembering that such things are:
a. abbreviations, and
b. taught universally to pretty much everyone with a secondary education

They are also names of mathematical operations, again falling into the “only shorten nouns” philosophy similar to acronyms.

In this particular case withRegardsTo: would be a vastly clearer and more accessible choice to the majority of users, with wrt's only benefit being saving a few characters (which given we're no longer on 80 character wide display and fighting for every bite of RAM and disk space is a vanishingly small factor in modern API design).

6 Likes

That may be the case, but at least it's a phrase that can be understood on its own terms, and can be googled. For wrt, one would have to find out what that is (oh, it's an acronym, and not some standard math variable or function name?), and only then google to find out what it has to do with derivatives.

3 Likes

It seems to me that this thread has devolved into a general discussion about the merits/de-merits of brevity and have forgotten the context. The context is that a new attribute,

@derivative(wrt: x, wrt: y, wrt: z, wrt: t)

to indicate that the attributed function is a derivative, is what is being discussed. Before worrying about what "wrt" is, one would have to understand what a derivative is, and how it is applicable to the problem at hand.

Using withRespectTo: seems to me to be a little more clumsy:

@derivative(withRespectTo: x, withRespectTo: y, withRespectTo: z, withRespectTo: t)

but more in line with current movement to verbose typing. Same for withRegardsTo. Personally, if I understand differentiation, calculating derivatives and partial derivatives, the wrt: label is not my big concern.

The of keyword is a totally different concept.

@derivative(of: Type)

would indicate that the function calculates the derivative of a type Type, which is totally different than indicating that the function is a derivative of an integrated type Type with unknown sets of independent variables.

I'm not sure what the TensorFlow folks are thinking, but,

@derivative(of:ExpField, wrt: X, wrt: Y, wrt: Z, wrt: T)
func exp(x: X, y: Y, z: Z, T: t) {
    return exp(x)*exp(y)*exp(z)*exp(t)
}

would pretty succinctly describe the compiler, et al, would get the information needed to identify the function and its required meta-data description

5 Likes

I don't think anyone who doesn't intend to use derivatives would be bothered by it. In a similar vein, "float" is extremely obscure for anyone who doesn't know anything about programming. Yet, we use float in programming.

There doesn't seem to be any solution outside of wrt and withRespectTo. The only alternative I can think of is against, which isn't used in English when describing derivatives, but it kind of conveys the same notion. At least "agianst" is semantically similar to "with respect to" when I mentally translated them to Chinese.

Honestly, we're 47 posts into this thread, and there are only 3 possible answers. Where do I go to get a refund for the other 44?

5 Likes

That doesn’t look pretty regardless of the label. Why repeat the label at all? This seems fine:

@derivative(wrt: (x, y, z, t))
@derivative(withRespectTo: (x, y, z, t))
@derivative(by: (x, y, z, t))
13 Likes

But it is such a generic term that simply searching for "with respect to" returns essentially useless results. A quick check I did requires me to go three pages deep into the google results before I get a result that is even related to math, the Wikipedia page for Matrix Calculus. And I had to go seven pages deep before I got a result with "derivative" in the title. Note that Bing did much better and returned videos about differentiation on its second page.

So already, in order to get information about either term, one will need to add some extra context to their search, such as adding "derivative" to the search. And the first result for me for "derivative wrt" on both google and Bing is the Wikipedia page for partial derivative (followed by many, many other relevant links).

Or even better, since the person in question is looking at Swift code, a search for "swift derivative wrt" would likely return the appropriate Swift documentation page for @derivative or at least some third-party tutorial/writeup on it.

It's not like they would just seeing wrt in a void, there's plenty of context there to work with.

5 Likes

Slightly related and slightly off topic:

Why is it that oncode examples and/or questions on a forum such as SO you often see people write btn instead of button, or lbl instead of label? Why not just write button, since the view is a UIButton, not a UIBtn? It puzzles me.

1 Like

Exactly the same here. Actually, I mis-read wrt as wtf.
wrt is impossible to understand if you are not firm in both, mathmatics and English.

I would understand all of the following: by, over, for, on, withRespectTo, basedOn, basedUpon, even dx would be better than wrt.

1 Like

Most of those would be incorrect. While I agree that redability and ease of learning is important, correctness is also important. Especially dx is so wrong, it hurts. withRespectTo is fine. This is how anyone reads "∂f/∂x" out loud, albeit somewhat long to type. But I guess it's a better balance between understandable and correct.

2 Likes

Did you perform a search for "for", "let", "contains" or "where" for comparison?
Those would most likely also have no relevant results in the top ranks — and I don't consider that important, because all those words are clear enough to be understood without help.
However, I don't want to conceal a precedent:

I still think it's not a good idea to make decisions based on what a search engine might return, but of course my opinions are not nearly as relevant.

1 Like

I'd say that is a special case for various reasons:
It's a very advanced concept, and it was "invented" in the digital age, in a context heavily dominated by the English language.
Maybe even more important: It can act as a word on its own — you can talk about an "ulp" without even knowing that it's an abbreviation (I don't think anyone actually uses "double-you-ar-tee" in conversation).

It's shorter, and many readers will insert the missing vocals subconsciously — but afaik, this fashion is not encouraged in Swift.

I would go a step further and note that “ulp” and “you-el-pee” are much more commonly used when spoken than “unit in the last place”. That’s definitely not the case with “wrt”.

5 Likes

If there is desire that this be simple and accessible English, have we considered:

change(of: f, varying: x)

Another option if 'change' is too vague:

derivative(of: f, varying: x)

4 Likes

Of all the alternative spellings, this is the least problematic I’ve seen. I still think wrt or withRespectTo is better, but this at least get the meaning through, while at the same time not being too abstract, or overloaded with all kinds of different connotations.

1 Like

I don't think this is true. There are many different use cases for small caps.

In addition, not all typefaces support small caps, and this style breaks from the API design guide