I thought there were patterns to how functions were named, but after looking carefully it seems I can always find exceptions. For instance

  • FindThreshold = Action + Object
  • SetAlphaChannel = Action + Object
  • ReplaceImageValue = Action + Object

but... ImageResize = Object + Action, and why not ImageBinarize instead of Binarize?


closed as off-topic by m_goldberg, MarcoB, dr.blochwave, Öskå, ilian Aug 7 '15 at 22:21

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "The question is out of scope for this site. The answer to this question requires either advice from Wolfram support or the services of a professional consultant." – m_goldberg, MarcoB, dr.blochwave, Öskå, ilian
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ There are some I find inconsistent. There's Binarize vs the non-existent ImageBinarize. There's the inconsistent pairs FromCharacterCode/ToCharacterCode vs FromRomanNumeral/RomanNumeral. Several "conversion" functions are ToThing, and several are just Thing: ToString, ToUpperCase vs LetterNumber and SparseArray. (In my mind, SparseArray is a conversion function, since the InputForm of a SparseArray object is of a very different format to the form in which one would usually input it.) $\endgroup$ – Patrick Stevens Aug 7 '15 at 15:10
  • $\begingroup$ And why FindPeaks but PeakDetect? Perhaps consistency is the hobgoblin of small minds... $\endgroup$ – bill s Aug 7 '15 at 15:10
  • $\begingroup$ @bills, it does make a kind of sense. FindThing finds a thing (perhaps numerically) and returns the thing and its location. ThingDetect returns the original object but where the thing is highlighted. $\endgroup$ – Patrick Stevens Aug 7 '15 at 15:14
  • 1
    $\begingroup$ @bills … although it might be A New Kind of Sense. $\endgroup$ – Patrick Stevens Aug 7 '15 at 15:20
  • $\begingroup$ I think this is a great question and would vote to re-open it. Understanding the logic and principles that have gone into System names can IMO be of great assistance in being able to correctly guess a new/recalled function but also in designing your code. Perhaps it could be narrowed down to a request for some small set of principles used in such naming? $\endgroup$ – Ronald Monson Aug 13 '15 at 0:12

You'll find plenty of exceptions if you keep looking — e.g. MapThread (action-action), FileExtension (object-object), NIntegrate, NSolve (Hungarian-like), etc.

I've always felt it's better to be more pragmatic about things like naming conventions as it allows for flexibility in the language design. I dare say it even improves readability at times, because it allows the designer to pause and reflect on how a symbol might be used and how it appears when read in code (as opposed to sticking to a naming dogma). In the case of image processing functions, I suppose the thought process was something like this:

  • Compose, Convolve, Histogram, Apply, Dimensions are generically named functions that are also meaningful in the image processing context. But rather than overload these existing (possibly heavily optimized) functions to work on _Image, it makes sense to create separate symbols. So... HistogramOfImage? ConvolveWithImage? ApplyOnImage? A bit too verbose, even for Mathematica, and doesn't evoke the same simplicity as the parent functions.

  • You then start using a prefix to common functions that immediately convey to the user what it does (because you're already familiar with the verb/noun) and what it acts on (the prefix) e.g. ImageHistogram, ImageDimensions, ImageConvolve, etc. This also helps disambiguate context specific uses of the noun/verb from generic ones.

  • Once you do this, you've now already established sort of a soft convention that seems to fit well, so you then extend the idea to other symbols (but not necessarily based on pre-existing ones) such as ImageCrop, ImageTrim, ImageResize, ImageData, etc. The noun/verb conveys the meaning succinctly and can be used with other data types just as easily (e.g. StringTrim).
  • Then finally you come to specialized functions which really have no use cases other than in image processing — SetAlphaChannel, RemoveAlphaChannel, Opening, Closing, etc. And now you've broken your own convention. And that's OK.

Could they have added an Image- prefix to all of these specialized functions for consistency? Yes. Should they have? Probably not, since it adds no additional information. Is it more readable as a result of not sticking to the rules? I would argue yes. If one must insist on consistency, then insisting on local consistency (within a specific package/functionality/group of functions) is better than insisting on global consistency.


Not the answer you're looking for? Browse other questions tagged or ask your own question.