Czy funkcje „matematyczne” powinny być zgodne z notacją matematyczną?

11

Przypuszczam, że to pytanie zostanie natychmiast oznaczone jako subiektywne, ale które według Ciebie jest lepsze:

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

lub

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

Innymi słowy, czy funkcje implementujące pewne równanie powinny być zgodne z notacją tego równania, czy też powinny używać bardziej szczegółowych nazw?

Lindelof
źródło
3
Czy czasem spędzasz więcej czasu na zastanawianiu się, jak nazwać zmienną, niż na samym kodowaniu? ;-)
Tomas,
1
Myślę, że druga alternatywa jest OK. Wyjaśniłbym te zmienne w komentarzu.
Giorgio,
Wygląda na to, że ktoś uznał za stosowne przejrzenie i odrzucenie odpowiedzi wszystkich. Czy ta osoba chciałaby podzielić się z tym powodem? Odpowiedzi wydawały mi się całkowicie rozsądne.
Technicznie nie ma to nic wspólnego z notacją „matematyczną” i wszystkim, co by pomyślał fizyk. Nie ma tu nic więcej niż arytmetyka.
duffymo,
2
Widzę wszystkich Amerykanów przechodzących temperaturę w Fahrenheit. Na pewno nie użyłbym podwójnego jako rodzaju temperatury. To samo prawdopodobnie dotyczy presji. Myślę, że byłbym bardziej zainteresowany zabezpieczeniem typów niż nazw.
Martin York,

Odpowiedzi:

14

Zależy, kto to czyta. Jeśli możesz zagwarantować, że przez całą wieczność, następny programista, który czyta twój kod, jest również zaznajomiony z termodynamiką, to tak, wybierz wersję okrojoną.

Moim osobistym stylem jest używanie takich zmiennych (których skróty są powszechnie znane w tej dziedzinie), ale umieszczanie ich opisu w komentarzach.

/* 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;
}
Jakub
źródło
5
Jaki jest sens? Ktoś, kto nie zna termodynamiki, nie ma szans na udane utrzymanie kodu bez względu na nazwy zmiennych.
dsimcha,
Jest to z pewnością lepsze niż nieuwzględnianie informacji, ale w tym momencie wydaje się, że łatwiej byłoby po prostu użyć tych nazw w funkcji. Nie widzę wiele użyteczności w korzystaniu z liter ...
Patrick87,
@dsmicha: Tak, PV = nRT jest bardzo podstawowym przykładem. W prawdziwym świecie istnieją bardziej skomplikowane funkcje, które nie są powszechnie znane i wydają się być długie i skomplikowane. Więc nawet jeśli osoba jest przeszkolona w terenie, istnieje duża szansa, że ​​natrafi na funkcję, która jest całkowicie obca.
4
@ Patrick87: Wolę litery, ponieważ mogę szybko sprawdzić prawdziwość wyrażenia, patrząc na papier z (lub z pamięci), ponieważ jest on znacznie bliższy oryginalnej formie.
2
+1. To najlepszy sposób, aby to zrobić. Nawet dość elementarne równania fizyki mogą wykorzystywać litery greckie, pierwiastki, pochodne cząstkowe, operatory (Laplace'a, Hamiltona), wektory, tensory itp., Aby generalnie nie było możliwe czytelne przedstawienie równania w komentarzach. Trzymanie się jako standard-as-możliwe nazwy zmiennych / skróty (np GAS_CONSTANTto nie standardowy nazwa zmiennej; każdy podręcznik wiem zastosowań Rdla tego) i wyjaśniając im krótko w komentarzach jest najlepszą rzeczą, którą można zrobić.
Joonas Pulakka
7

Po prostu wyrzucając go, masz inną opcję:

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

Jest to nieco podobne do tego, co F # robi z jednostkami miary, i ma tę zaletę, że pozwala uniknąć problemów, takich jak przypadkowe zastąpienie ciśnienia przez temperaturę. Trudno wyobrazić sobie, jakie argumenty powinny iść tam, gdzie jest podpis (podwójne, podwójne, podwójne)

Mathias
źródło
Żeby było jasne, czy istnieją języki, które mogą przeprowadzić tego rodzaju analizę wymiarową? Czyli wiesz, że na przykład iloczyn między ciśnieniem a objętością można przypisać do jednostki energii?
Lindelof
Tak, F # robi to z jednostkami miary. msdn.microsoft.com/en-us/library/dd233243.aspx
Mathias
Nawet bez obsługi automatycznej konwersji między jednostkami, może być korzystne zdefiniowanie dedykowanych typów dla niektórych jednostek, takich jak klasa pieniędzy. Ogranicza nieumyślne przypisanie zmiennych i błędy konwersji oraz pomaga w refaktoryzacji.
Mathias
Można to zrobić bardzo solidnie za pomocą szablonów C ++.
kevin cline
@lindelof: Niektóre z tych funkcji można osiągnąć dzięki C ++typedef
Jacob
7

Wolę to:

/* 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;
}

Innymi słowy, wyjaśnij znaczenie kodu w komentarzu po angielsku (i matematyce; to komentarze, możesz rozwinąć go tak bardzo, jak to konieczne), ale używaj opisowych nazw zmiennych, aby każdy, kto czyta jedyny kod, był w stanie zrozumieć łatwo - zwłaszcza przy większych funkcjach. Innym powodem, dla którego używałbym prawdziwych słów jako nazw zmiennych, jest to, że interfejs jest znacznie bardziej przejrzysty, jeśli trzeba skopiować deklarację funkcji do pliku nagłówka.


źródło
2
Dodatkowo byłoby miło w komentarzu zamieścić link do gdzieś w Internecie, który mówi o formule (np .: en.wikipedia.org/wiki/Ideal_gas_law ).
Chris Shaffer,
To bardzo miłe podejście, ale trochę niechlujne. Wolałbym zobaczyć link do np. Wikipedii opisującej (w tym przypadku) prawo dotyczące gazu doskonałego.
Patrick87,
3

IMHO zawsze lepiej jest używać ustalonej notacji domeny, w której pracujesz, jeśli funkcja jest bardzo specyficzna dla domeny. Ktoś, kto nie rozumie problematycznej domeny, nie ma szans na udane utrzymanie kodu, a dla kogoś, kto jest obeznany z domeną, długie nazwy będą po prostu szumem, a także więcej pisania.

OTHO, powiem, że chciałbym, aby konwencjonalna notacja matematyczna była czasem bardziej szczegółowa i opisowa, ale niezależnie od tego, czy uważam, że kod matematyczny powinien trzymać się konwencji matematycznej.

Edycja: Ta odpowiedź ma zastosowanie tylko wtedy, gdy istnieje bardzo silna konwencja notacji podczas pisania formuły matematycznie. Jeśli nie ma takiego, a trzeba by wyjaśnić, co zmienne reprezentują w komentarzu, nawet zakładając, że czytelnik jest zaznajomiony z domeną, najlepiej jest pomylić się po stronie bardziej opisowej konwencji.

dsimcha
źródło
2

Czysta opinia, ale zawsze używaj słów nad symbolami jednoliterowymi. Jeśli użyjesz słów, wszyscy zrozumieją; jeśli używasz symboli, tylko eksperci w tej dziedzinie mają gwarancję przestrzegania. Nawet wtedy niektóre osoby używają różnych symboli dla tych samych wielkości fizycznych. Używając dłuższych nazw, nie masz nic do stracenia.

Patrick87
źródło
2

Twoja troska powinna być jasność, a następnie poprawność (niepoprawny, ale czytelny kod można łatwo poprawić), dlatego twoja funkcja powinna być napisana w celu zachowania możliwości obsługi przez ogólny koder, o ile to możliwe. Komentarze nagłówka funkcji powinny wyjaśniać formułę i jej użycie oraz opisywać parametry wejścia / wyjścia. Odtąd sposób ułożenia ciała funkcji nie powinien mieć większego znaczenia, o ile jest zgodny z komentarzami nagłówka.

(Wiem, że to nie jest dyskusja, ale - moim osobistym wyborem byłoby nadanie zmiennym nazw wyraźnych, chociaż w tym przypadku wystarczy jedna linijka, ponieważ jest to funkcja „czysta”; wywołanie o tych samych parametrach dałoby to samo wynik zawsze, więc nie powinno być złożoności związanej ze stanem wymagającej wyjaśnienia)

  • Jeśli chodzi o inne języki obsługujące analizę wymiarową, można to zaimplementować np. W C ++ z szablonami, biblioteka Boost Units korzysta z tego podejścia.

źródło
1

Zależy od tego, jak „daleko” od warstwy biznesowej jest kod ... Im dalej w stosie jest kod, tym bardziej jest on ukierunkowany na abstrakcyjne funkcje matematyczne, tym bardziej staram się naśladować ogólnie akceptowany notacje matematyczne i konwencje nazewnictwa. Im bliżej frontu lub warstwy biznesowej, tym bardziej bym się zgadzał z konwencjami ustanowionymi w dziedzinie problemów.

Charles Bretana
źródło
1

Lubię myśleć o tym w ten sposób - matematycy popełniali błąd, stosując krótkie zmienne, a fizycy postępowali podobnie . Po co powtarzać swój błąd? Wiemy teraz, że dłuższe nazwy są bardziej opisowe i powodują mniej zamieszania, więc trzymaj się ulepszeń. Mówiąc prościej, czasami próbuję podkraść dłuższe zmienne do moich obliczeń matematycznych, przy których wszyscy są przerażeni.

Gleno
źródło
Będziesz miłość to ...
0

Prawidłowy format równania programującego to taki, który nadal rozumiesz po tym, jak nie widziałeś go przez sześć miesięcy.

Jeśli wrócisz do:

n*R*T/P;

I rozpoznajesz, co się dzieje, to chyba dobrze. Zazwyczaj w przypadku zaawansowanych formuł nie pamiętam, czym była każda część, chyba że aktywnie jej używam. Dla mnie:

n_moles * BOLTZMANN_CONSTANT * temperature / pressure;

jest znacznie lepszym formatem równania, ponieważ mogę łatwo zrozumieć każdą część, nawet jeśli niekoniecznie wiem, dlaczego równanie jest napisane w obecnej formie.

zzzzBov
źródło
Myślisz, że energy_in_joules = mass_in_kilograms * pow (speed_of_light_in_vacumm_in_metres-per_second, 2) jest łatwiejszy niż E = mc ^ 2
Martin Beckett
@Martin Beckett, czy rzeczywiście przeczytałeś to, co napisałem? „Zazwyczaj w przypadku zaawansowanego formlasu nie pamiętam, czym była każda część, chyba że aktywnie jej używam”. Nie powiedziałem, że zapomnę równań, które zdołały wprowadzić się w wiedzę publiczną. W przypadkach takich jak E=m*(c^2)ja będzie zrozumieć go w ciągu sześciu miesięcy.
zzzzBov,
w przypadku dobrze znanych równań klasycznych lepiej jest użyć normalnej notacji, aby ludzie mogli ją dostrzec. Nawet w zakresie nazewnictwa zmiennych theta lub phi, jeśli tego używa się w domenie
Martin Beckett
-1

Rzuć monetą.

Czy czasem spędzasz więcej czasu na zastanawianiu się, jak nazwać zmienną, niż na samym kodowaniu?

Tomas
źródło
6
Tak, zwykle spędzam więcej czasu na projektowaniu kodu niż na jego kodowaniu, a zaczyna się od zrozumienia problemu i prawidłowego nazwania rzeczy.
Mathias