Jump to content

Wolfram језик (Mathematica)

Оцени ову тему


Juanito

Препоручена порука

Математичари, инжењери и остала братија овај софтвер користи већ неколико деценија. Заиста је у питању импресиван пакет, али није толико о пакету тема. Тема је више о самом језику у кога сам се заљубио. :)

Основна философија језика је веома једноставна - све је симболички израз који се састоји од главе и произвољног броја аргумената.

head[args1, arg2...]

2 + 3 је Plus[2, 3], {1, 2, 3} је List[1, 2, 3]. Једино су бројеви, ниске и још пар ствари ”атоми”, тј. недељиви изрази. Главна техника за писање функција и правила је pattern matching. Језгро језика је rewrite engine који интерпреира симболичке изразе користећи правила.

У стандардном софтверском инжењерству се скривање детаља имплементације (с разлогом) сматра добром праксом. Међутим, ја имам специфичан случај да својим корисницима морам да прикажем све детаље имплементације, што више то боље (структуру типова, структуру инстанци, корак по корак решење проблема итд.). Претходних месеци сам испробавао свашта користићи неколико мејнстрим језика, statically and dynamically typed. Фора је у томе да је све што сам пробао на крају некако смрдело на anti-pattern, језици једноставно нису написани за такве ствари. У бољем случају је испало да у ствари морам да реимплементирам интерпретер језика, што је опет бесмислено. Једна примамљива алтернатива је да користим модерни компајлер као што је Roslyn за C#. Овај компајлер има фантастичан API који може да се позива из самог језика, те да игра улогу интерпетера. То су људи искористили да, на пример, направе интерактивна окружења за C#. Ипак, ни то некако није баш најоптималније за овај мој случај. И онда сам открио Mathematicа језик. <3 Знао сам и раније, наравно, да то постоји и чему служи, али никада нисам користио. Једина мана је што је ужасно скупо. Има смисла платити (индустријску лиценцу) ако заиста користиш неке јако напредне ствари, data analysis и слично. Мени треба само језгро језика.

@Grizzly Adams

Користио некад? Шта мислиш зашто сличне парадигме нису заживеле у мејнстриму (за делове апликација који би највише профитирали од приступа)? За неке ствари ОО и слично очигледно нису најбољи избор, али се и даље о алтернативама слабо чак и размишља, камоли да неко нешто конкретно понуди. 

Link to comment
Подели на овим сајтовима

Рецимо, дефинишем мустре за одузимање у колонама (мустре су еквиваленте типовима, на пример Column би била C# класа). И онда имам приступ целом стаблу (еквивалентно хијерархији класа, са све пољима):

topP = top[_Integer]
bottomP = bottom | bottom[_Integer]
answerP = answer | answer[_Integer]
columnP = column[topP, bottomP, answerP]
subtractionProblemP = subtractionProblem[columnP ..]
TreeForm[subtractionProblemP]

9s5wk2.jpg

Једно од правила, каже: ако је горњи број у колони већи од или једнак доњем, напиши њихову разлику као резултат те колоне ('anwerColumn' је помоћна функција):

writeDifference = c : column[top[t_Integer], bottom[b_Integer], answer] /; t >= b :> answerColumn[c, t - b]

Само правило је такође смболички израз:

TreeForm[writeDifference]

2w39h50.jpg

Ово стабло могу онда да интерпретирам чвор по чвор и лист по лист и да до детаља објасним кориснику шта значи.

Link to comment
Подели на овим сајтовима

Нисам га никад користио. Овако на први поглед подсећа на Лисп и/или Пролог, који су мени омиљени мада их у пракси нисам пуно користио...

Зашто то још увек није заживело је добро питање, а с` обзиром да сам се једно време заносио доста идејом да правим нешто на ту тему дошао сам и до одговора (или бар тако мислим...). Ти језици добри су за "одлучивање", тј. проналажење неких "најбољих комбинација" и слично, што је на вишем нивоу од свега што до сада имамо. Ако је процедурално први ниво, објектно други, онда би то било неки трећи ниво који би манипулисао некаквим "компонентама". Е сад, фора је у томе што ми још нисмо дефинисали тај наредни ниво апстракције. Класе и објекти су нам јасни, тачно знамо шта представљају и како са њима да радимо. Овај следећи ниво били би некакви "супер-објекти" које би онда пропустио кроз "енџин" и добио решење, комбинацију.

Да пробам конкретан пример - велика компанија, имаш разне огранке који се баве разним активностима, имају своје трошкове, ресурсе, приходе итд. Њихове свакодневне активности ми сад релативно лако аутоматизујемо са постојећим технологијама. Али на врху тог система имаш генералног директора и његову екипу који и даље доносе одлуке тако што им пошаљу ексел фајлове... Ту сад треба некаква нова апстракција где би све "departments" проукао кроз "logic engine" са "rules" или нешто слично и добио одлуке, тј. сугестије, шта је најбоље да се ради, куда да се иде даље итд. То је већ корак ближе AI.

Зато мислим да ти језици и технологије још нису заживели. Нисмо још дошли на ниво где ће они бити најефикаснији.

  • Волим 1

ΜΟΛΩΝ ΛΑΒΕ

Link to comment
Подели на овим сајтовима

4 minutes ago, Grizzly Adams рече

Ако је процедурално први ниво, објектно други, онда би то било неки трећи ниво који би манипулисао некаквим "компонентама". Е сад, фора је у томе што ми још нисмо дефинисали тај наредни ниво апстракције. Класе и објекти су нам јасни, тачно знамо шта представљају и како са њима да радимо. Овај следећи ниво били би некакви "супер-објекти" које би онда пропустио кроз "енџин" и добио решење, комбинацију.

Иронија је што је, формално гледано, заправо обрнуто. Ти напредни нивои апстракције су изразито добро и прецизно дефинисани, док за објекте нема још увек целовите теорије. Једина квака је што је за разумевање апстракција потребан PhD ниво знања којекаквих апстрактних грана математике (теорије категорија нпр.). Хеботе, чак и неки математичари теорију категорија зову abstract nonsense. :) 

Link to comment
Подели на овим сајтовима

Да, у теорији јесу добро дефинисани, али нико још у пракси није успео да их имплементира тако да буде корисно и ефикасно...

Али биће. Кад неко тако нешто буде покренуо ту треба уложити паре... :)

ΜΟΛΩΝ ΛΑΒΕ

Link to comment
Подели на овим сајтовима

Кад смо код формалних дефиниција, погледај ово, мислим да ће ти бити занимљиво:

Лик је сјајан. Холанђанин, рођен на Антилима, урадио PhD баш у овој хеви апстрактној functional programming области, постао професор на мом универзитету и онда му одједном синуло: ”fuck academy, оћу да направим нешто конкретно!” Дао отказ, запослио се у Мајкрософту и, између осталог, сад имамо LINQ. После је напустио Мајкрософт и основао неку своју фирму. Сјајан пример повезивања хардкор академског знања и индустрије. А увек носи луде кошуље, ова на линкованом видеу је једна од досаднијих. :)

Link to comment
Подели на овим сајтовима

6 minutes ago, Grizzly Adams рече

Да, у теорији јесу добро дефинисани, али нико још у пракси није успео да их имплементира тако да буде корисно и ефикасно...

Кад би само једном ручао с овим нердовима из моје групе, схватио би и зашто је то тако...

Link to comment
Подели на овим сајтовима

  • Чланови који сада читају   0 чланова

    • Нема регистрованих чланова који гледају ову страницу
×
×
  • Креирај ново...