Должны ли «математические» функции следовать математическим обозначениям?

11

Я полагаю, что этот вопрос будет немедленно помечен как субъективный, но какой, по вашему мнению, лучше:

double volume(double pressure, double n_moles, double temperature) {
  return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

или же

double volume(double P, double n, double T) {
  return n*R*T/P;
}

Другими словами, должны ли функции, которые реализуют какое-либо уравнение, следовать обозначениям этого уравнения, или они должны использовать более подробные имена?

Линделоф
источник
3
Вы также иногда тратите больше времени на размышления о том, как назвать переменную, чем на сам код? ;-)
Томас
1
Я думаю, что второй вариант в порядке. Я бы объяснил переменные в комментарии.
Джорджио
Похоже, кто-то посчитал нужным пройти и переоценить ответы каждого. Не хотел бы этот человек поделиться своей причиной? Ответы показались мне совершенно разумными.
Технически, это не имеет ничего общего с «математической» нотацией и не имеет ничего общего с тем, что подумает физик. Здесь нет ничего, кроме арифметики.
duffymo
2
Я вижу всех американцев, проходящих температуру в градусах Фаренгейта. Я бы точно не использовал double как тип для температуры. То же самое относится и к давлению. Я думаю, что я был бы более заинтересован в обеспечении безопасности типов, чем имен.
Мартин Йорк,

Ответы:

14

Зависит от того, кто это читает. Если вы можете быть уверены, что следующий программист, который читает ваш код, также знаком с термодинамикой, тогда да, перейдите к усеченной версии.

Мой личный стиль - использовать такие переменные (чьи сокращения обычно известны в данной области), но включать их описание в комментарии.

/* P : Pressure
   V : Volume
   n : Number of moles
   R : Boltzmann constant
   T : Temperature (in K)
*/
double compute_V(double P, double n, double T) {
  return n*R*T/P;
}
Иаков
источник
5
В чем смысл? Тот, кто не занимается термодинамикой, не имеет шансов успешно поддерживать код, независимо от того, как называются имена переменных.
дсимча
Это, конечно, лучше, чем не включать информацию, но на данный момент кажется, что было бы проще просто использовать эти имена в функции. Я не вижу много полезности в использовании букв ...
Patrick87
@dsmicha: Да, PV = nRT - очень простой пример. В реальном мире существуют более сложные функции, которые обычно не известны и имеют тенденцию быть длинными и запутанными. Таким образом, даже если человек обучен в этой области, есть большая вероятность, что он / она встретит совершенно инопланетную функцию.
4
@ Patrick87: Я предпочитаю буквы, потому что я могу быстро проверить достоверность выражения, посмотрев на бумагу, из которой (или по памяти), поскольку она намного ближе к исходной форме.
2
+1. Это лучший способ сделать это. Даже в довольно элементарных уравнениях физики могут использоваться греческие буквы, корни, частные производные, операторы (Лапласа, Гамильтона), векторы, тензоры и т. Д., Так что в общем случае невозможно четко представить уравнение в комментариях. Придерживаться стандартных имен переменных / аббревиатур (например, GAS_CONSTANTэто не стандартное имя переменной; каждый известный мне учебник использует Rдля этого) и кратко объяснять их в комментариях - это лучшее, что можно сделать.
Joonas Pulakka
7

Просто выбросив его, у вас есть еще один вариант:

Volume ComputeVolume(Pressure p, Moles m, Temperature t) { ... }

Это несколько похоже на то, что F # делает с единицами измерения, и имеет то преимущество, что позволяет избежать таких проблем, как непреднамеренная замена давления на температуру. Трудно определить, какие аргументы должны идти, когда подпись (double, double, double)

Mathias
источник
Просто чтобы прояснить, существуют ли языки, которые могут проводить такой анализ измерений? Т.е. знаете, например, что произведение между давлением и объемом может быть отнесено к единице энергии?
Линделоф
Да, F # делает это с единицами измерения. msdn.microsoft.com/en-us/library/dd233243.aspx
Матиас
Даже без поддержки автоматического преобразования между единицами может быть полезно определить выделенные типы для определенных единиц, таких как класс Money. Он ограничивает непреднамеренные ошибки при назначении и преобразовании переменных и помогает с рефакторингом.
Матиас
Это можно сделать очень надежно с помощью шаблонов C ++.
Кевин Клайн
@lindelof: Вы можете достичь некоторых из этих функций с C ++typedef
Jacob
7

Я предпочитаю это:

/* This function calculates volume using the following formula:
 *
 *     n * R * T
 * v = ---------
 *         P
 */
double volume(double pressure, double n_moles, double temperature) {
    return n_moles * BOLTZMANN_CONSTANT * temperature / pressure;
}

Другими словами, объясните значение кода в комментарии на английском языке (и в математике; это комментарии, вы можете расширять его столько, сколько нужно), но используйте описательные имена переменных, чтобы любой, кто читает единственный код, все еще мог понять это легко - особенно с большими функциями. Другая причина, по которой я бы использовал реальные слова в качестве имен переменных, заключается в том, что интерфейс намного понятнее, если вам нужно скопировать объявление функции в файл заголовка.


источник
2
Кроме того, было бы неплохо в комментарии добавить ссылку на где-нибудь в Интернете, где говорится о формуле (например, en.wikipedia.org/wiki/Ideal_gas_law ).
Крис Шаффер
Это очень хороший подход, но немного грязный. Я мог бы предпочесть просто увидеть ссылку, например, на Википедию, описывающую (в данном случае) закон об идеальном газе.
Patrick87
3

ИМХО, всегда лучше использовать установленную запись проблемной области, в которой вы работаете, если функция очень специфична для конкретной области. Кто-то, кто не понимает проблемную область, не имеет никакого шанса успешно поддерживать ваш код в любом случае, и для кого-то, кто знаком с доменом, длинные имена будут просто шумом, а также больше печатать для вас.

OTHO, я скажу, что я хотел бы, чтобы обычные математические обозначения были более многословными и описательными, но независимо от того, я думаю, математический код должен придерживаться математического соглашения.

Изменить: Этот ответ применяется только в том случае, если при написании формулы математически существует строгая договоренность об обозначениях. Если его нет, и вам придется объяснить, что представляют переменные в комментарии, даже если предположить, что читатель знаком с доменом, то лучше ошибиться в сторону более описательного соглашения.

dsimcha
источник
2

Чистое мнение, но всегда используйте слова над однобуквенными символами. Если вы используете слова, все поймут; если вы используете символы, гарантированно будут следовать только эксперты в данной области. Даже тогда некоторые люди используют разные символы для одинаковых физических величин. Вам нечего терять, используя более длинные имена.

Patrick87
источник
2

Ваша задача должна заключаться в ясности, а затем в правильности (неправильный, но понятный код легко исправляется), поэтому ваша функция должна быть написана для удобства сопровождения универсальным кодером, насколько это возможно. Комментарии к заголовку функции должны объяснять формулу и ее использование, а также описывать параметры ввода / вывода. После этого то, как выстроено тело функции, не должно иметь большого значения, если оно согласуется с комментариями заголовка.

(Я знаю, что это не обсуждение, но моё личное предпочтение было бы дать явные имена varaibles, хотя в этом случае одной строки может быть достаточно, поскольку это «чистая» функция; вызов с теми же параметрами даст тот же результат всегда, поэтому не должно быть никакой связанной с состоянием сложности, требующей объяснения)

  • Что касается других языков, поддерживающих анализ измерений, это может быть реализовано, например, в C ++ с шаблонами, библиотека Boost Units использует этот подход, как я полагаю.

источник
1

Зависит от того, насколько «далеко» от бизнес-уровня находится код ... Чем дальше в стеке находится код, тем больше он направлен на реализацию абстрактной математической функции, тем больше я буду пытаться эмулировать общепринятый математические обозначения и соглашения об именах. Чем ближе к интерфейсу или бизнес-уровню, тем больше я буду соответствовать соглашениям, установленным в проблемной области.

Чарльз Бретана
источник
1

Мне нравится думать об этом так: математики неправильно поняли короткие переменные, а физики последовали их примеру. Зачем повторять свою ошибку? Теперь мы знаем, что более длинные имена носят более описательный характер и вызывают меньше путаницы, поэтому следите за улучшениями. На более легкой ноте, я иногда пытаюсь проникнуть в более длинные переменные в мою математику, в которой все потрясены.

Глено
источник
Вы собираетесь любить это ...
0

Правильный формат для уравнения программирования - тот, который вы все еще понимаете, не видев его шесть месяцев.

Если вы вернетесь к:

n*R*T/P;

И вы понимаете, что происходит, тогда, вероятно, все в порядке. Обычно для продвинутых формул я обыкновение помнить , что каждая часть была , если я не буду активно использовать его. Для меня:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

это гораздо лучший формат уравнений, потому что я могу легко понять каждую часть, даже если я не обязательно знаю, почему уравнение написано так, как оно есть.

zzzzBov
источник
Вы думаете, что energy_in_joules = mass_in_kilograms * pow (speed_of_light_in_vacumm_in_metres-per_second, 2) легче, чем E = mc ^ 2
Мартин Беккет
@ Мартин Беккет, ты действительно прочитал то, что я написал? «Обычно для продвинутого formlas я обыкновение помнить , что каждая часть была , если я не буду активно использовать его.» Я не говорил, что забуду уравнения, которые сумели подтолкнуть себя к общественному знанию. В тех случаях , как E=m*(c^2)я будет понять это в течение шести месяцев.
zzzzBov
для хорошо известных классических уравнений лучше использовать нормальные обозначения, чтобы люди могли их заметить. Даже до степени именования переменных тэта или фи, если это то, что используется в домене
Мартин Беккет
-1

Бросай монету.

Вы также иногда тратите больше времени на размышления о том, как назвать переменную, чем на сам код?

Tomas
источник
6
Да, я обычно трачу больше времени на разработку своего кода, чем на его кодирование, и оно начинается с понимания проблемы и правильного присвоения названий.
Матиас