it-swarm-eu.dev

Je špatné používat znaky Unicode v názvech proměnných?

Nedávno jsem se pokusil implementovat klasifikační algoritmus AllegSkill na Python 3).

Matematika vypadá takto:

alt text

Ne, opravdu.

To je to, co jsem napsal:

t = (µw-µl)/c  # those are used in
e = ε/c        # multiple places.
σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

Vlastně jsem si myslel, že je nešťastné Python 3 nepřijmout nebo ² jako názvy proměnných.

>>> √ = lambda x: x**.5
  File "<stdin>", line 1
    √ = lambda x: x**.5
      ^
SyntaxError: invalid character in identifier

Jsem z mé mysli? Měl jsem se uchýlit k verzi ASCII pouze verze? Proč? ASCII pouze verze výše uvedeného je obtížnější ověřit rovnocennost se vzorci?

Chápu, že chápu, že některé glyfy Unicode vypadají velmi podobně jako ostatní a jiné jako (nebo je to ▗▖) nebo ╦ prostě nemohou mít v psaném kódu žádný smysl. To však sotva platí pro matematiku nebo šipkové glyfy.


Na žádost by ASCII jediná verze byla něco podobného:

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2
                   )**.5

... za každý krok algoritmu.

84
badp

Cítím se silně, že pouhé nahrazení σ Za s nebo sigma by bylo hloupé, hraničící s mozkem mrtvým.

Jaký je potenciální zisk? Pojďme se podívat ...

  • Zlepšuje čitelnost? Ne, ani v nejmenším. Pokud by tomu tak bylo, původní vzorec by také nepochybně použil latinská písmena.

  • Zlepšuje to zapisovatelnost? Na první pohled ano. Ale na druhé, ne. Protože tento vzorec je nikdy se nezmění (dobře, „nikdy“). Normálně nebude nutné kód měnit ani rozšiřovat pomocí těchto proměnných. Zapisovatelnost tedy není - jen jednou - problémem.

Osobně si myslím, že programovací jazyky mají oproti matematickým vzorcům jednu výhodu: můžete použít smysluplné a expresivní identifikátory. V matematice tomu tak obvykle není, takže se uchýlíme k proměnným s jedním písmenem a občas z nich uděláme řečtinu.

Řek není problém. Neopisné jednopísmenné identifikátory jsou.

Takže buď si ponechejte původní notaci ... konec konců, pokud programovací jazyk nemá podporuje Unicode v identifikátorech, takže neexistuje žádná technická překážka. Nebo použijte smysluplné identifikátory. Nenahrazujte pouze řecké glyfy latinskými glyfy. Nebo arabské nebo hindské.

54
Konrad Rudolph

Osobně bych nerad viděl kód, kde musím vyvolat mapu znaků, abych ji mohl znovu napsat. Přestože unicode úzce odpovídá tomu, co je v algoritmu, je to opravdu bolí čitelnost a schopnost editace. Někteří editoři nemusí mít ani písmo, které podporuje tento znak.

A co alternativa a prostě nahoru nahoru //µ = u a napsat vše v ASCII?

34
TheLQ

Tento argument předpokládá, že nemáte problém s zadáváním kódů ani čtením řeckých písmen

Zde je argument: chtěli byste pi nebo circle_ratio?

V tomto případě bych upřednostňoval pí před kruhovým_ratiem, protože jsem se dozvěděl o pi od doby, kdy jsem byl na základní škole, a mohu očekávat, že definice pi je dobře zakořeněná pro všechny programátory, kteří stojí za jeho sůl. Proto by mi nevadilo napsat π, aby znamenalo circle_ratio.

Ale co

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2
                   )**.5

nebo

σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

Pro mě jsou obě verze stejně neprůhledné, stejně jako pi nebo π je s výjimkou - tento vzorec jsem se na základní škole nenaučil. winner_sigma a Wwin pro mě nebo pro kohokoli jiného, ​​kdo čte kód, nic neznamená a nepoužívá ani σw to nezlepšuje.

Takže pomocí popisných jmen, např. total_score, winning_ratio, atd. by zvýšilo čitelnost mnohem lépe než použití ascii jmen, která pouze vyslovují řecká písmena . Problém není v tom, že neumím číst řecká písmena, ale nemůžu spojit znaky (řecké nebo ne) s „významem“ proměnné.

Určitě jste pochopili problém sami, když jste komentovali: You should have seen the paper. It's just eight pages.... Problém je, že pokud vaše proměnné pojmenování založíte na papíře, který si vybere jednopísmenová jména spíše pro přehlednost než pro čitelnost (bez ohledu na to, zda jsou řecká), pak by si lidé museli přečíst článek, aby mohli spojovat písmena s "význam"; to znamená, že vkládáte umělou bariéru, aby lidé mohli pochopit váš kód, a to je vždy špatná věc.

I když žijete ve světě, který je jen pro ASCII, oba a * b / 2 a alpha * beta / 2 jsou stejně neprůhledné vykreslení height * base / 2, vzorec oblasti trojúhelníku. Nečitelnost použití jednopísmenných proměnných roste exponenciálně, jak roste vzorec ve složitosti, a vzorec AllegSkill rozhodně není triviální vzorec.

Proměnná jednoduchých písmen je přijatelná pouze jako jednoduché počítadlo smyček, ať už jsou to řecká jednopísmenná nebo ascii jednopísmenná, je mi to jedno; žádné jiné proměnné by neměly sestávat pouze z jediného písmene. Je mi jedno, jestli pro své jména používáte řecká písmena, ale když je používáte, ujistěte se, že mohu tato jména spojit s „významem“, aniž bych musel číst libovolný papír někde jinde.

Když jsem na základní škole, rozhodně by mi nevadilo vidět matematické výrazy pomocí symbolů jako: +, -, ×, ÷, pro základní aritmetiku a √ () by byla funkce odmocniny. Po dokončení střední školy by mi nevadilo přidání lesklých nových symbolů: ∫ pro integraci. Všimněte si trendu, jedná se o všechny operátory. Operátoři jsou mnohem častěji používány než názvy proměnných, ale jsou méně často opakovaně používány pro zcela odlišný význam (v případě, kdy matematici znovu používají operátory, nový význam často drží některé základní vlastnosti starého významu; to neplatí pro při opakovaném použití proměnných).

Závěrem, ne, není špatné používat znaky Unicode pro názvy proměnných; je však vždy špatné používat názvy jednotlivých písmen pro názvy proměnných a povolení používat názvy Unicode není licencí k používání názvů proměnných s jedním písmenem.

31
Lie Ryan

Rozumíte kódu? Má to každý, kdo to potřebuje? Pokud ano, není problém.

Osobně bych rád viděl zadní stranu zdrojového kódu pouze pro ASCII.

14
user4051

Ano, jste mimo vaši mysl. Osobně bych v poznámce odkazoval na číslo papíru a vzorce a vše psal rovným ASCII. Každý, kdo má zájem, by pak byl schopen korelovat kód a vzorec.

9
zvrba

Řekl bych, že použití názvů proměnných Unicode je špatný nápad ze dvou důvodů:

  1. Jsou typem PITA.

  2. Často vypadají téměř stejně jako anglická písmena. To je stejný důvod, proč nerad vidím řecké dopisy v matematickém zápisu. Zkuste říci rho kromě p. Není to lehké.

5
dsimcha

V tomto jednom případě, složitém matematickém vzorci, bych řekl.

Mohu říci, že za 20 let jsem nikdy nemusel kódovat něco tak komplexního a řecké dopisy ho drží blízko původních matematik. Pokud tomu nerozumíte, neměli byste jej udržovat.

Řekl jsem, že pokud budu muset udržovat µ a σ v bažinovém standardním kódu, který jste mi odkázali, tak bude zjistím, kde žijete ...

4
gbn
  • Pro: Vypadá to dobře
  • Con: znaky unicode, takže celý význam by se mohl ztratit v řetězci nástrojů (editor, formátovací program, kontrola verzí, starší kompilátor)

Jak velké je pro vás riziko? Převažuje zisk nad rizikem?

3
LennyProgrammers

Někdy v nepříliš vzdálené budoucnosti budeme všichni používat textové editory/IDE/webové prohlížeče, které usnadňují psaní upravujícího textu včetně klasických řeckých znaků atd. (Nebo se možná všichni naučíme používat tento „skrytý“ "funkčnost nástrojů, které v současné době používáme ...)

Ale dokud k tomu nedojde, pro mnoho programátorů by bylo obtížné zvládnout jiné než ASCII znaky), a proto je špatný nápad, pokud píšete aplikace, které by mohly vyžadovat údržbu někdo jiný .

(Mimochodem, proč můžete mít řecké znaky, ale ne druhou odmocninu v Python identifikátory jsou jednoduché. Řecké znaky jsou klasifikovány jako písmena Unicode, ale druhá odmocnina je non-letter; viz. http://www.python.org/dev/peps/pep-3131/ )

2
Stephen C

Neřekli jste, jaký jazyk/kompilátor používáte, ale pravidlem pro názvy proměnných je obvykle to, že musí začínat abecedním znakem nebo podtržítkem a obsahovat pouze alfanumerické znaky a podtržítka. Unicode √ by nebyl považován za alfanumerický, protože je to matematický symbol místo písmene. Nicméně σ by mohlo být (protože je v řecké abecedě) a á by pravděpodobně bylo považováno za alfanumerické.

2
tcrosley

Zaslal jsem stejný druh otázky na StackOverflow

Určitě si myslím, že stojí za to použít unicode v těžkých matematických problémech, protože umožňuje číst vzorec přímo, což u obyčejného ASCII není možné.

Představte si ladicí relaci: samozřejmě můžete vždy ručně napsat vzorec, který má kód spočítat, abyste zjistili, zda je správný. Ale devadesát procent času se nebudete obtěžovat a chyba může zůstat skrytá po dlouhou, uvolněnou dobu. A nikdo nikdy není ochoten se podívat na tento abstrusční 7-řádek, prostý ASCII vzorec.) Používání unicode samozřejmě není tak dobré jako tex-vykreslený vzorec, ale je to mnohem lepší .

Alternativa používání dlouhých popisných jmen není životaschopná, protože v matematice, pokud identifikátor není krátký, bude vzorec vypadat ještě složitější (proč si myslíte, že lidé kolem XVIII. Století začali nahrazovat „plus“ za „+“ a „mínus“ od „-“?).

Osobně bych také použil některá předplatné a horní indexy (pouze je zkopíruji a vložím z tato stránka ). Například: (měl python povoleno √ jako identifikátor)

√ = math.sqrt #function alias
c² = c**2
σʷ² = σʷ**2
γ² = γ**2
σ′ʷ = √(σʷ² * (1 - (σʷ²/c²)*Wʷⁱⁿ(t, e)) + γ²)

Kde jsem použil horní index, protože v unicode není ekvivalentní index. (Bohužel je znaková sada indexu unicode velmi omezená. Doufám, že jednoho dne bude předplatné v unicode považováno za diakritiku, tj. Kombinace jednoho znaku pro index a dalšího znaku pro upsaný dopis)

Poslední věc, myslím, že tato konverzace o použití znaku, který není ASCII, je primárně zkreslená, protože mnoho programátorů se nikdy nezabývá „matematickými zápisy náročnými na formule“. Proto si myslí, že tato otázka není tak důležitá, protože nikdy nezažili významnou část kódu, která by vyžadovala použití identifikátorů jiných než ASCII. Pokud jste jedním z nich (a byl jsem donedávna), zvažte toto: předpokládejme, že písmeno „a“ není součástí ASCII. Pak budete mít docela dobrou představu o problému, že při výpočtu netriviálních matematických vzorců nemáte žádné z řeckých písmen, indexů a indexů.

1
Bérenger

osobně jsem v této souvislosti motivován uvažovat o programovacích jazycích jako o nástroji pro matematiky, protože ve skutečnosti nepoužívám matematiku, která v mém životě něco podobného vypadá. : D A jistě, proč nepoužívat ɛ nebo σ nebo cokoli - v tomto kontextu je to vlastně více čitelné.

(I když musím říci, že bych upřednostňoval podporu horních indexových čísel jako přímých volání metod, nikoli proměnných jmen. Např. 2² = 2 ** 2 = 4 atd.)

0
roberto

Je tento kód určen pouze pro váš osobní projekt? Pokud ano, použijte ořechy, použijte, co chcete.

Je tento kód určen pro ostatní? tj. a nějakým druhem aplikace s otevřeným zdrojovým kódem? Pokud ano, pravděpodobně požadujete potíže, protože různí programátoři používají různé editory a nemůžete si být jisti, že všichni editoři budou unicode správně podporovat. Navíc ne všechny příkazové skořápky to zobrazí správně, když je soubor zdrojového kódu typu'd/cat'd, a můžete se potýkat s problémy, pokud jej potřebujete zobrazit v html.

0
GrandmasterB