Mathematica V13
A Wolfram Language + Mathematica 13.0-s verziója
Folytatódik az innováció

Alig néhány hete volt az évszázad 1/3-a a Mathematica 1.0 megjelenése óta izgatott vagyok, hogy bejelenthetem a régóta működő R&D folyamatunk legújabb eredményeit: aWolfram Language és Mathematica 13-as verzióját.. (Igen, az 1,3 téma – kiegészítve azzal, hogy ma a hónap 13-a van – mulatságos, ha véletlen is.)
207 nap – vagyis valamivel több mint 6 hónap – telt el a 12.3-as verzió megjelenése óta. És örömmel mondhatom, hogy ez alatt a rövid idő alatt lenyűgöző mennyiségű R&D valósult meg: nem csak összesen 117 teljesen új funkció, hanem sok száz frissített és továbbfejlesztett funkció, több ezer hibajavítás és apró fejlesztések, és egy sor új ötlet a rendszer egyszerűbbé és gördülékenyebbé tételéhez.
A század elmúlt harmadában minden nap, minden héten, minden hónapban keményen dolgoztunk, hogy még többet adjunk a hatalmas integrált keretrendszerhez, a Mathematicához és a Wolfram nyelvhez. És most láthatjuk mindezen egyéni ötletek, projektek és munkák eredményeit: az innováció folyamatos dobpergése, amely immár több mint egyharmada évszázada kitartott:

Ez a cselekmény rengeteg kemény munkát tükröz. De ez mást is tükröz: a Wolfram nyelv alapvető tervezési elveinek sikerét. Mert ezek tették lehetővé a mostani hatalmas rendszernek, hogy megőrizze koherenciáját és következetességét – és egyre erősebbé váljon. Amit ma építünk, az nem a semmiből épül fel; a képességek hatalmas tornyára épül, amelyet korábban építettünk. És ezért vagyunk képesek idáig eljutni, olyan sokat automatizálni – és annyi mindent kitalálni.
Az 1.0-s verzióban összesen 554 funkció volt. A 12.0-s és a 13.0-s verzió között azonban összesen 635 új funkciót adtunk hozzá (a 702 frissített funkción kívül). És valójában még ennél is lenyűgözőbb. Mert amikor függvényt adunk hozzá ma az elvárások sokkal magasabbak, mint 1988-ban – mert sokkal több automatizálást tehetünk, és sokkal többet az egész rendszerben, amihez kapcsolódnunk kell, és amelyhez integrálódnunk kell. És persze ma már talán százszor kiterjedtebb és részletesebb dokumentációt írhatunk és írunk is, mint ami valaha is belefért volna az 1988-as (nyomtatott) Mathematica Bookba.
A 13-as verzió újdonságai a 12-es verzióhoz képest nagyon szélesek és lenyűgözőek. De itt csak a 13.0-s verzió újdonságaira koncentrálok a 12.3-as verzióhoz képest; Korábban már írtam a 12.1-es, a 12.2-es és a 12.3-as verzióról.
Ne felejtse el az integrálokat!

1988-ban a Mathematica 1.0 egyik olyan tulajdonsága, amelyet az emberek nagyon szerettek, az integrálok szimbolikus elkészítésének képessége volt. Az évek során fokozatosan bővítettük a kivitelezhető integrálok körét. És egyharmad évszázaddal később – a 13.0-s verzióban – újabb ugrást teszünk előre. Íme egy integrál, amelyet korábban nem lehetett „zárt formában”, de a 13.0-s verzióban igen:
Egy algebrai függvény bármely integrálja elvileg elvégezhető az általános DifferentialRoot objektumokkal. De a nagyobb algoritmikus kihívás az, hogy „emberbarát választ” kapjunk az ismert függvények tekintetében. Ez egy törékeny üzlet, ahol az együttható kis változtatása nagy hatással lehet a lehetséges csökkentésekre. De a 13.0-s verzióban ma már sok olyan integrál van, amelyet korábban csak speciális függvények tekintetében lehetett elvégezni, de most már elemi függvényekben adnak eredményeket. Íme egy példa:


Matematikai függvények: Mérföldkő elérve
Amikor még kézzel kellett integrálni és hasonlókat csinálni, mindig izgalom volt, amikor rájött, hogy a problémája megoldható valami egzotikus “speciális funkcióval” amiről korábban nem is hallott. A speciális függvények bizonyos értelemben a matematikai ismeretek csomagolásának egyik módja: ha egyszer tudod, hogy az egyenleted megoldása egy Lamé-függvény, az azonnal sok matematikai dolgot elmond róla.
A Wolfram Language-ben, mindig is nagyon komolyan vettük a speciális funkciókat, nemcsak támogatjuk ezek hatalmas gyűjteményét, hanem lehetővé tesszük azok tetszőleges numerikus pontosságú kiértékelését, és a szimbolikus matematikai műveletek teljes skálájában való részvételt.
Amikor körülbelül 45 évvel ezelőtt először elkezdtem használni a speciális függvényeket, az a könyv volt, amely a standard referenciaként szolgált, Abramowitz & Stegun 1964-es Matematikai függvények kézikönyve. Több száz funkciót sorolt fel, néhányat széles körben használnak, mások kevésbé. Az évek során a Wolfram Language fejlesztése során folyamatosan ellenőriztük az Abramowitz & Stegun további funkcióit És a 13.0-s verzióval végre elkészültünk! Az Abramowitz & Stegun összes funkciója most már teljesen kiszámítható Wolfram nyelven. Az utolsó hozzáadott függvények a Coulomb-hullámfüggvények voltak (amelyek a kvantumszórási folyamatok tanulmányozására vonatkoznak). Itt vannak az Abramowitz & Stegunban:



Másfajta szám

Egy másik megközelítés – amelyet a 12.0-s verzió vezet be – az Around, amely valójában egy adott szám körül „véletlenszerűen elosztott” számok eloszlását jelenti:

Amikor az Around számokkal műveleteket végez, a „hibákat” egy bizonyos hibaszámítással kombinálják, amely hatékonyan a Gauss-eloszlásokon alapul – és a kapott eredmények bizonyos értelemben mindig statisztikai jellegűek.
De mi van akkor, ha hozzávetőleges számokat szeretne használni, de mégis bizonyítható eredményeket kap? Az egyik megközelítés az Interval használata. A 13.0-s verzióban azonban egy egyszerűbb megközelítés a CenteredInterval használata. Íme egy CenteredInterval, amelyet egy Bessel-függvény bemeneteként használnak:

A Wolfram nyelven sokféleképpen bizonyíthatsz dolgokat. Használhatja a Reduce funkciót. Használhatja aFindEquationalProof-ot. És használhatja CenteredInterval-t , amely valójában a numerikus értékelést használja fel. Íme egy függvény, amelynek bonyolult transzcendentális gyökerei vannak:

Most ellenőrizhetjük, hogy valóban „az intervallum egésze” nagyobb-e 0-nál:

Valamint sok más matematika…
A Wolfram Language minden új verziójához hasonlóan a 13.0-s verzió is számos speciális matematikai fejlesztést tartalmaz. Példa erre egy új, kényelmes módszer egy függvény pólusainak. lekérésére. Itt van egy speciális függvény ábrázolva az összetett síkban:




Gráfelméleti képességeinket felhasználva nagymértékben javíthattuk az ODE-rendszerek kezelését is, és módot találtunk arra, hogy blokkátlós formákká „bontsuk ki” azokat, amelyek lehetővé teszik, hogy szimbolikus megoldásokat találjunk a korábbinál sokkal bonyolultabb esetekben. A PDE-k esetében általában nem lehet általános „zárt formájú” megoldásokat kapni a nemlineáris PDE-khez. De néha kaphatunk bizonyos megoldásokat, amelyeket teljes integráloknak neveznek (amelyekben csak tetszőleges állandók vannak, nem „egész” tetszőleges függvények). És most van egy explicit funkciónk ezek megtalálásához:

A számításról az algebra felé fordulva hozzáadtuk a PolynomialSumOfSquaresList függvényt, amely egyfajta „pozitivitási tanúsítványt” biztosít egy többváltozós polinom számára. Az ötlet az, hogy ha egy polinom felbontható négyzetek összegére (és a legtöbb, de nem az összes, amely soha nem negatív), akkor ez bizonyítja, hogy a polinom valóban mindig nem negatív:


További PDE modellezés: Szilárdtestek és szerkezeti mechanika
Számunkra a „klasszikus tesztprobléma” egy teáskanál elhajlása volt. Így állíthatjuk be most. Először meg kell határoznunk a változóinkat: a kanál elmozdulásait minden irányban minden x, y, z pontban:



Az eredményt az x, y, z eltolások interpolációs függvényeinek listájaként adjuk meg. Mostantól egy új, 13.0-s verziójú grafikus funkciót használhatunk az eredmény azonnali megjelenítéséhez:

De ezekbe az interpolációs függvényekbe kényelmesen becsomagolva sokkal több részletet kaptunk a megoldásról. Például itt van a kanál feszültségtenzora, interpolációs függvények szimmetrikus tömbjeként megadva:




Videók készítése képekből és videókból
Ez az asztalon és a felhőben is működik, és az összes szabványos videóvezérlőt közvetlenül a notebookban kapjuk meg, de a videót ki is ugorhatjuk, hogy külső (mondjuk teljes képernyős) nézővel nézzük meg. (Most már egyszerűen becsomagolhat egy videót az AnimatedImage-el, hogy „GIF-szerű” képkocka alapú animációt készítsen belőle.) OK, térjünk vissza a képekből videók készítéséhez. Tegyük fel, hogy van egy nagy képe:










A 13.0-s verzióban hozzáadott videók kezeléséhez néhány praktikus kényelem tartozik. Az egyik az OverlayVideo, amely lehetővé teszi, hogy egy videót „vízjellel” helyezzen el egy képpel, vagy beillessze azt, ami „kép a képben” videónak felel meg:


Képfűzés
A képek összeillesztésénél a motorháztető alatti része a kulcspontok megtalálása a képeken. A 13.0-s verzióban pedig két további módszert (SIFT és RootSIFT) adtunk hozzá az ImageKeypoints számára. De nem a kulcspontok igazítása az egyetlen dolog, amit a képösszefűzés során teszünk. Emellett olyan dolgokat is végzünk, mint a fényerő-kiegyenlítés és az objektív korrekciója, valamint a képek keverése a varratok között. A képösszefűzés finomítható olyan opciókkal, mint például a TransformationClass – amelyek meghatározzák, hogy a különálló képek összeállításakor milyen átalakításokat kell engedélyezni.

A fák tovább nőnek








mindez szorosan összefügg egy csomó alapvető fizikával kapcsolatos fogalommal, amelyek a Fizikai Projektünkben merülnek fel. És a bejárási sorrend paraméterezése – amellett, hogy hasznos egy csomó létező algoritmus számára – elkezdi megnyitni az ajtót a számítási folyamatok összekapcsolása előtt a fizikából származó ötletekkel és új fogalmakkal arról, amit én többszámításnak nevezek.
Gráf színezése
A képességek gyakran kért halmaza a gráf színezése körül forog. Például, ha adott egy gráf, hogyan lehet a csúcsaihoz „színeket” rendelni úgy, hogy egyetlen szomszédos csúcspár se legyen azonos színű? A 13.0-s verzióban van egy FindVertexColoring funkció, amely ezt teszi:




egyszerre csak egy mérkőzést játszik. A szükséges egyezések gyűjteménye csak a teljes grafikon:






Részgráf izomorfizmus és egyebek


Most találunk egy 6-os ciklust:


Most kérhetjük aminat DominatorTreeGraph-ot, amely megmutatja nekünk a térképet arról, hogy mely csúcsok hova jutnak kritikusan, A-tól kezdve:


A térbeli mezők becslései
Képzelje el, hogy az űr bizonyos pontjain, például a Föld felszínén mintavételezett adatokat kapott. Az adatok meteorológiai állomásokból, talajmintákból, ásványfúrásból vagy sok más dologból származhatnak. A 13.0-s verzióban egy függvénygyűjteményt adtunk hozzá a mintákból származó „térbeli mezők” (vagy más néven „kriging”) becsléséhez.Vegyünk néhány mintaadatot, és ábrázoljuk:


Ez nagyjából úgy viselkedik, mint egy InterpolatingFunction, amelyből bárhol mintát vehetünk:



A 13.0-s verzióban a modell részletes vezérléséhez olyan opciókat használhat, mint a SpatialTrendFunction és a SpatialNoiseLevel. A kulcskérdés az, hogy mit kell feltételeznünk a térbeli mező helyi változatairól – amelyeket szimbolikus formában adhat meg a VariogramModel segítségével
Megfelelő idő: szökőmásodpercek és egyebek
Állítólag pontosan 24 óra van egy napban. Kivéve, hogy a Föld ezt nem tudja. És valójában a forgási periódusa idővel kissé változik (általában a forgása lassul). Tehát, hogy a „napszakot” összhangba hozzuk a Nap helyével az égen, a „hack”-et a „szökőmásodpercek” hozzáadására vagy kivonására találták ki. Bizonyos értelemben az időpillanat leírásának problémája kicsit olyan, mint a földrajzi hely problémája. A földrajzi elhelyezkedésben felmerül a térbeli pozíció leírásának kérdése. A Földön a szélesség-hosszúság ismerete nem elég; szükség van egy „geo modellre” is (amelyet a GeoModel opció határozza meg), amely leírja, hogy milyen alakot kell felvenni a Földre, és így milyen szélességben kell leképezni a tényleges térbeli pozíciót.
Egy időpillanat leírásánál hasonlóképpen meg kell mondanunk, hogy az „óraidőnk” hogyan illeszkedik a tényleges „fizikai időhöz”. Ennek érdekében a 13.0-s verzióban bevezettük az időrendszer fogalmát, amelyet a TimeSystem opció határoz meg.
Ez határozza meg 2021 decemberének első pillanatát az UT1 időrendszerében:

2021 decemberének első pillanata a TAI időrendszerében:


Mi történik itt? Nos, a TAI egy atomórákon alapuló időrendszer,
amelyben minden napot pontosan 24 órásnak vesznek, és az
időrendszer „nulláját” az 1950-es évek végén állították be. Az UT1 viszont egyidőrendszer, amelyben minden napnak a Föld aktuális forgása által meghatározott hossza van. Ez pedig
azt mutatja, hogy a TAI és az UT1 szinkronizálása óta eltelt idő alatt, az 1950-es évek végén a Föld tényleges forgása lelassult addig a pontig, ahol jelenleg körülbelül 37 másodperccel elmarad attól a ponttól, ahol egy precíz 24 órás napnál lenne. Fontos időrendszer az UTC – ez a szabványos „polgári idő”,
és az internet de facto szabványos ideje. Az UTC nem követi nyomon a Föld pontos forgási sebességét; ehelyett összeadja vagy kivonja adiszkrét szökőmásodperceket, amikor az UT1 újabb másodpercnyi eltérést akar felhalmozni a TAI-tól –
így az UTC jelenleg pontosan 37 másodperccel van a TAI mögött:

A 12.3-as verzióban bevezettük a GeoOrientationData-t, amely a Föld mért forgási sebességére vonatkozó adatfolyamon alapul. Ez alapján a nap hosszának 24 órától való eltérése az elmúlt évtizedben:

változások miatt lettek hozzáadva? Nézzünk néhány másodpercet közvetlenül 2017 elején a TAI
időrendszerében:

Most alakítsuk át ezeket az időpillanatokat UTC-ábrázolásukra – az új TimeSystemConvert függvény segítségével

Ezt nézd meg alaposan. Először is, amikor 2016 véget ér és 2017-et kezdődik, az UTC-ben kissé eltér, mint a TAI-ban. De van valami, ami még furcsább. 2016 legvégén az UTC 23:59:60-as időt mutat. Miért nem „körül” az „óraszámítás” stílusban másnapra? Válasz: mert egy szökőmásodperc van beszúrva.
(Amimiatt csodálkozom, amikor abban az évben a 0-s időzónában ünnepelték az újévet…)
Ha úgy gondolja, hogy ez kifinomult, gondoljon egy másik szempontra. Ott a számítógépében sok időzítő vezérli a rendszer működését – és ezek a„globális idő”. És rossz dolgok történhetnek ezekkel az időzítőkkel, ha a globális idő „meghibásodik”. Tehát hogyan kezelhetjük ezt? Amit a Wolfram Language-ben csinálunk, az az, hogy használjuk az „elcsúszott UTC-t”, és hatékonyan elkenjük a ugrómásodpercet aznap – lényegében azáltal, hogy
minden egyént „második” nem éppen „fizikai második” hosszú. Íme 2016 utolsó másodpercének kezdete UTC-ben:


másodperceinek számából:

Új, élesebb földrajzi térképek


A vektorcímkék használatának egyik előnye, hogy minden földrajzi vetületben működhetnek (vegye figyelembe, hogy a 13-as verzióban, ha nem adja meg a régiót a GeoGraphics számára, az alapértelmezés szerint az egész világra vonatkozik):


Geometriai régiók: felszerelés és építés

Az új RegionFit funkció képes kitalálni, hogy a pontok melyik körön vannak



Egy másik nagyon hasznos új funkció a 13.0-s verzióban a ConcaveHullMesh, amely 3D pontok gyűjteményéből próbál meg rekonstruálni egy felületet. Itt van 1000 pont:



Nagy a szabadság abban, hogyan lehet rekonstruálni a felületet. Egy másik funkció a 13-as verzióban a GradientFittedMesh, amely a felületet kikövetkeztetett felületi normálisok gyűjteményéből képezi:

Az imént beszéltünk a geometriai régiók „pontadatokból” való megtalálásáról. Egy másik új lehetőség a 13.0-s verzióban a konstruktív szilárd geometria (CSG), amely kifejezetten geometriai primitívekből épít fel régiókat. A fő funkció a CSGRegion, amely sokféle művelet elvégzését teszi lehetővé primitíveken. Íme egy régió, amely primitívek metszéspontjából alakult ki:




Adott egy hierarchikusan felépített geometriai régiót, lehetséges, hogy a CSGRegionTree segítségével „kifaragjuk”:



A CSG-n való gondolkodás rávilágít arra a kérdésre, hogy meg kell határozni, hogy két régió mikor „azonos”. Például annak ellenére, hogy egy régiót általános Polygon-ként ábrázolnak, valójában egy tiszta Rectangle is lehet. És még ennél is több, a régió más helyen lehet a térben, más orientációval. A 13.0-s
verzióban a RegionCongruent függvény ezt teszteli

A RegionSimilar lehetővé teszi a régiók méretének megváltoztatását is:

De annak tudatában, hogy két régió hasonló, a következő kérdés lehet: Milyen átalakulás szükséges ahhoz, hogy az egyikből a másikba kerüljünk? A 13.0-s verzióban a FindRegionTransform ezt próbálja meghatározni:

Kémiai képletek és kémiai reakciók
A 12-es verzióban bemutattuk a molekulát, mint egy molekula szimbolikus ábrázolását a kémiában. Az egymást követő verziókban folyamatosan bővítettük a Molecule szolgáltatásait. A 13.0-s verzióban olyan dolgokat adunk hozzá, mint például a 2D-s és 3D-s molekulaábrázolások további információkkal való megjegyzésének képessége


A 12-es verzióban bemutattuk a Molecule-t, mint egy molekula szimbolikus ábrázolását a kémiában. Az egymást követő verziókban folyamatosan bővítettük a Molecule szolgáltatásait. A 13.0-s verzióban olyan dolgokat adunk
hozzá, mint például a 2D-s és 3D-s molekulaábrázolások további információkkal való megjegyzésének képessége:




A reakciót karakterláncként is megadhatja:


De ez még nem kiegyensúlyozott reakció. Kiegyensúlyozásához használhatjuk a ReactionBalance-t:

És mondanom sem kell, hogy a ReactionBalance meglehetősen általános, így képes kezelni azokat a reakciókat, amelyek kiegyensúlyozásához kissé nem triviális diofantusz-egyenletek megoldására van szükség:

Bioszekvenciák: telkek, másodlagos kötvények és egyebek
A 12.2-es verzióban bevezettük a BioSequence fogalmát, amely olyan molekulákat képvisel, mint a DNS, az RNS és a fehérjék, amelyek különálló egységek szekvenciáiból állnak. A 13.0-s verzióban számos új BioSequence
képességet adunk hozzá. Az egyik a BioSequencePlot, amely azonnali vizuális megjelenítést biztosít a bioszekvenciákról:




A Molecule a BioSequence-t atomok explicit gyűjteményévé alakítja:


Repülési adatok
A Wolfram Language egyik célja, hogy minél több tudással rendelkezzen a világról. A 13.0-s verzióban egy új tartományt adunk hozzá: információk a jelenlegi és korábbi repülőjáratokról (egyelőre csak az Egyesült Államokban). Tegyük fel, hogy szeretnénk tájékozódni a tegnapi Boston és San Diego közötti járatokról. Megkérdezhetjük a FlightData-t:



És íme a repülési útvonal, amelyet követett:

A FlightData lehetővé teszi az összesített adatok lekérését is. Például ez megmondja, honnan származott az összes tegnap Bostonba érkezett járat:



Többtengelyes és többpaneles telkek
Régóta kérték. És számos csomagmegvalósítás készült belőle. De most a 13.0-s verzióban a többtengelyes nyomtatás közvetlenül a Wolfram Language-be van beépítve. Íme egy példa:

Amint jeleztük, a kék görbe skálája a bal oldalon, a narancssárgaé pedig a jobb oldalon található.
Azt gondolhatja, hogy ez egyértelműnek tűnik. De nem az. Valójában több koordinátarendszer létezik, amelyek mindegyike egy diagramba van kombinálva, majd a különböző stílusformák által összekapcsolt tengelyekkel egyértelműsítik őket. Ennek alapjainak utolsó lépését a 12.3-as verzió fektette le, amikor bevezettük az AxisObject-et és a „testetlen tengelyeket”. Íme egy bonyolultabb eset, immár 5 görbével, mindegyiknek saját tengelye van:



Dátumok és végtelenségek a Plot Scales-ben




:

Új vizualizációs típusok

Or in 3D:


A 12.3-as verzióban bevezettük a GeoGraphPlot függvényt olyan gráfok ábrázolására, amelyek csúcsai földrajzi pozíciók. A 13.0-s verzióban hozzáadjuk a GeoGraphValuePlot-ot, amely lehetővé teszi az „értékek” megjelenítését a grafikon szélein:

A világítás szimbolikus
A Lighting kulcsfontosságú eleme a 3D grafika érzékelésének. Az 1.0-s verzió óta elérhető a 3D-s jelenetek általános megvilágításának megadására szolgáló alapbeállítás, a Lighting. A 13.0-s verzióban azonban lehetővé
tesszük a világítás sokkal finomabb szabályozását – ami most különösen fontossá vált, mivel támogatjuk a 3D objektumok anyag-, felület- és árnyékolási tulajdonságait.
A kulcsgondolat az, hogy a fényforrások ábrázolását szimbolikussá tegyük. Így például ez a fényforrások konfigurációja, amely azonnal használható a meglévő Lighting opcióval:

Tartalomdetektorok gépi tanuláshoz
A Classify lehetővé teszi „teljes adat” osztályozók betanítását. – Ez egy macska? vagy „Ez a szöveg filmekről szól?” A 13.0-s verzióban hozzáadtuk a tartalomérzékelők betanításának képességét, amelyek osztályozóként szolgálnak az adatok alrészeihez. – Milyen macskák vannak itt? – Hol beszélnek itt filmekről? Az alapötlet az, hogy példákat adjunk egész bemenetekre, minden esetben elmondva, hogy a bemenet hol felel meg egy adott osztálynak. Íme néhány alapképzés a témaosztályok szövegben történő kiválasztásához:


Hogy működik ez? Alapvetően az történik, hogy a Wolfram Language már nagyon sokat tud a szövegről, a szavakról és a jelentésekről. Tehát csak egy példát hozhat rá, amely magában foglalja a focit, és a beépített tudásábólkitalálhatja, hogy a kosárlabda ugyanaz. A 13.0-s verzióban nemcsak szöveghez, hanem képekhez is létrehozhat tartalomérzékelőket. A probléma lényegesen bonyolultabb a képek esetében, így tovább tart a tartalomdetektor felépítése. Ha azonban megépült, bármilyen képen gyorsan futhat. Csakúgy, mint a szövegesetében, a képtartalom-érzékelőt úgy tanítja meg, hogy mintaképeket ad, és megmondja, hogy ezeken a képeken hol találhatók a kívánt dolgok osztályai:



Mellesleg, ami a motorháztető alatt történik, hogy mindez működjön, az meglehetősen kifinomult. Végső soron rengeteg beépített tudást használunk a jellemzően előforduló képtípusokról. És amikor mintaképeket szolgáltat,
ezeket mindenféle „tipikus hasonló” képpel egészítjük ki, amelyek a minták átalakításából származnak. Ezután pedig hatékonyan átképezzük képrendszerünket, hogy felhasználjuk a példáiból származó új információkat.
Új vizualizáció és diagnosztika a gépi tanuláshoz

Az egyik nagyszerű dolog a gépi tanulásban a Wolfram Language-ben, hogy nagymértékben automatizált módon használhatja. Csak adja meg a Classify képzési példák gyűjteményét, és az automatikusan létrehoz egy osztályozót, amelyet azonnal használhat. De pontosan hogyan csinálta? A folyamat kulcsfontosságú része annak kitalálása, hogyan lehet olyan funkciókat kivonni, amelyek segítségével az adatokat számtömbökké alakíthatja. A 13.0-s verzióban pedig megkaphatja az explicit szolgáltatáskivonatot, amelyhez készült (így például más adatokon is használhatja):



Ez megmutatja a Classify-ban történõ események egy részét. De egy másik dolog, amit tehet, az az, hogy megkérdezi, mi befolyásolja leginkább a Classifyáltal adott kimenetet. Ennek egyik megközelítése a SHAP-értékek használata annak meghatározására, hogy a megadott adatokban megadott egyes attribútumok milyen hatással vannak a kimenetre. A 13.0-s verzióban egy kényelmes grafikus módot adtunk ennek megjelenítésére egy adott bemenethez:

A nyomkövetési probléma automatizálása robotok és egyebek számára
A vezérlőrendszerek tervezése bonyolult dolog. Először is rendelkeznie kell egy modellel a vezérelni kívánt rendszerhez. Ezután meg kell határoznia a vezérlő céljait. És akkor ténylegesen létre kell hoznia egy vezérlőt, amely eléri ezeket a célokat. A Wolfram Language és a Wolfram System Modeler technológia teljes halmazával eljutunk arra a pontra, ahol egy példátlanul automatizált folyamat áll rendelkezésünkre ezekre a dolgokra. A 13.0-s verzió kifejezetten olyan vezérlők tervezésére ad lehetőséget, amelyek egy meghatározott jelet követnek a rendszerben – például ha egy robot egy adott pályát követ. Tekintsünk egy nagyon egyszerű robotot, amely egy mozgó kocsiból áll, mutatóval:

Először is szükségünk van egy modellre a robothoz, és ezt létrehozhatjuk a Wolfram System Modelerben (vagy importálhatjuk Modelica modellként):




fogjuk használni egy „követő vezérlő” tervezésére, amely nyomon követi a meghatározott kimeneteket (igen, ezeknek a számoknak a beállításához ismernie kell a vezérléselméletet):



És ennek a szimulációnak alapján itt van egy diagram, hogy hova megy a mutató vége:

Kevesebb zárójelet írjon be!

A 13-as verzió most az, hogy automatikusan hozzáadja a megfelelő zárójeleket, ha úgy gondolja, hogy ez egyértelmű. Az egy dolog, amit meg kell tanulnunk, az az, hogy ezután „beírhatja” a zárójelet; más szóval, ha ebben az esetben a kurzort közvetlenül az automatikusan hozzáadott ] előtt írjuk be, akkor nem jelenik meg új ]; a rendszer csak „beírja” a ]-t. Lehetőség van arra is, hogy a ctrlspace billentyűvel az automatikusan hozzáadott zárójeltől jobbra lépjen. És mellesleg a ctrlspace a következő záró zárójeltől is „jobbra mozog”, még akkor is, ha a kurzor nincs közvetlenül a zárójel mellett; ezt akkor is megteszi, ha a kurzor mélyen egy beágyazott szerkezetben van.
Az automatizálási viselkedés (amelyet a Preferences párbeszédpanelen kapcsolhat ki, ha nagyon nem tetszik) nem csak a [ ], hanem a { }, ( ), [[ ]], <| |>, (* *) és (fontos) ” “. És a ctrlspace is működik minden ilyen határolóval.
A felhasználói élmény komoly rajongói számára talán van még egy érdekesség. A ctrlspace beírása potenciálisan olyan messzire mozgathatja a kurzort, hogy a szem elveszíti azt. Ez a fajta nagy hatótávolságú kurzormozgás akkor is megtörténhet, amikor matematikai és más 2D-s anyagokat ír be, amelyek valós időben vannak szúrva. Az 1990-es években pedig feltaláltunk egy mechanizmust, amellyel elkerülhetjük, hogy az emberek „elvesszenek a kurzort”. Belsőleg „hihetetlenül zsugorodó foltnak” hívjuk. Ez egy nagy fekete folt, amely a kurzor új pozíciójában jelenik meg, és körülbelül 160 ezredmásodperc alatt a tiszta kurzorrá zsugorodik. Tekintsd
ezt „látáshack”-nek. Alapvetően az emberi előfigyelő látórendszerbe kapcsolódunk be, ami arra készteti az embert, hogy a tekintete automatikusan a „hirtelen megjelenő tárgyra” forduljon, de anélkül, hogy észrevenné, hogy ezt tette.
A 13-as verzióban ezt a mechanizmust nem csak a valós idejű betűszedéshez használjuk, hanem a ctrlspace-hez is – a blobot akkor adjuk hozzá, amikor az „ugrási távolság” egy bizonyos küszöbérték felett van.Valószínűleg észre sem veszi, hogy a folt ott van (úgy tűnik, hogy az embereknek csak egy kis része “látja”). De ha időben elkapja, a következőket fogja látni:

Haladás a számítások előrehaladásának látásában…
Egy példa a 13.0-s verzióban az, hogy a ParallelMap, a ParallelTable stb. automatikusan felügyeli az előrehaladást:

Sok más példa is van erre, és még több lesz. Folyamatosan figyelhető a videó, a gépi tanulás, a tudásbázis-hozzáférés, az importálás/exportálás és a különféle algoritmikus funkciók:



Általában az előrehaladás nyomon követése csak jó dolog; segít tudni, hogy mi történik, és lehetővé teszi annak ellenőrzését, hogy a dolgok elromlottak-e. De néha ez zavaró lehet, különösen, ha van olyan belső funkció, amelyről nem is tudtad, hogy hívják – és hirtelen azt látod, hogy figyeled a fejlődést. Sokáig azt hittük, hogy ez a kérdés rossz ötletté teszi a széles körű előrehaladást. De úgy tűnik, hogy annak az értéke, hogy látod, mi történik, szinte mindig felülmúlja azt a lehetséges zavart, hogy valami olyasmit lát, ami „a motorháztető alatt” történik, amiről nem tudtál. És nagyon sokat segít, hogy amint egy művelet véget ér, a folyamatjelzők
egyszerűen eltűnnek, így a végső notebookban nyoma sincs. Egyébként minden folyamatfigyelő funkciónak van ProgressReportingopciója, amit False értékre állíthatunk. Ezen kívül van egy $ProgressReporting globális változó, amely megadja az alapértelmezett értéket az egész rendszerben.
Érdemes megemlíteni, hogy az „Ott vagyunk már?” különböző szintjei vannak. adható megfigyelés. Egyes funkciók szisztematikus lépések sorozatán mennek keresztül, például a videó minden egyes képkockájának feldolgozását. És ilyen esetekben lehetőség van a „töredék kész” megjelenítésére folyamatjelző sávként. Néha az is lehetséges, hogy legalább némi tippet adjon a „töredék kész” (és így a várható befejezési idő) tekintetében, ha „statisztikailag” megnézi, mi történt a számítás egyes részein eddig. És például a ParallelMap stb. így figyeli az előrehaladást. Természetesen általában nem lehet tudni, mennyi ideig tart egy tetszőleges számítás; ez a számítási irreducibilitás története és olyan dolgok, mint a Turing-gépek leállási problémájának eldönthetetlensége.
De azzal a feltételezéssel (ez a legtöbbször elég jónak bizonyul), hogy a különböző részszámítások futási ideje meglehetősen egyenletes eloszlást mutat, továbbra is lehetséges ésszerű becsléseket adni.
(És igen, a lehetséges eldönthetetlenség „látható jele” az, hogy a befejezett százalék akár lefelé, akár felfelé ívelhet az idő múlásával.)
Wolfram|Alpha notebookok
Sok éven át volt a Mathematica + Wolfram Language, és volt a Wolfram|Alpha. Aztán 2019 végén bemutattuk a Wolfram|Alpha Notebook Edition-t a kettő egyfajta keverékeként. Valójában a Mathematica és a Wolfram|Alpha szabványos asztali és felhőalapú telepítéseiben már létezik a Wolfram|Alpha-Mode Notebook koncepciója is, ahol az alapötlet az, hogy a dolgokat szabad formájú természetes nyelven írhatja be, de megkapja a lehetőségeket. a Wolfram nyelv használata a számítások ábrázolásában és felépítésében:


Mostantól lehetőség nyílik azonnali gazdag dinamikus tartalom létrehozására közvetlenül a szabad formájú nyelvi bevitelből:
Az „egyedi” interaktív tartalom mellett a Wolfram|Alpha-Mode Notebookokban azonnal elérhető interaktív tartalom is a Wolfram Demonstrations Project több mint 12 000 bemutatójából:
A Wolfram|Alpha Notebook Edition különösen erős az oktatásban. A 13.0-s verzióban pedig interaktív vetélkedők első gyűjteményét is tartalmazzuk, különösen a cselekményekről:

Mindent a kvízekhez közvetlenül a nyelven
A 13.0-s verzió lehetővé teszi a kvízek létrehozását, üzembe helyezését és értékelését közvetlenül a Wolfram nyelven, mind az asztalon, mind a felhőben. Íme egy példa egy telepített kvízre:
Hogyan készült ez? Van egy írói jegyzetfüzet, amely így néz ki:
Mindez a 12.2-es verzióban bevezetett űrlapjegyzetfüzet-funkciókon alapul. De van egy további elem: QuestionObject. A QuestionObject szimbolikus reprezentációt ad egy felteendő kérdésről, valamint egy Assessment Function funkciót, amellyel a megadott válaszra alkalmazható, értékelhető,
osztályozható vagy más módon feldolgozható.
A legegyszerűbb esetben a „kérdés” csak egy karakterlánc. De lehet kifinomultabb, és van egy lista a lehetőségekről (amelyek folyamatosan bővülnek), amelyeket kiválaszthat a szerzői jegyzetfüzetben:

(A QuestionInterface konstrukció segítségével részletesen szabályozhatja a„kérdésprompt” beállítását.)
Miután elkészítette a kvízt a szerzői jegyzetfüzetben (és természetesen nem kellcsak „kvíznek” lennie a tananyagban) értelme), telepítenie kell. A beállításoklehetővé teszik különböző beállítások megadását

eredményeket a kvízt teljesítőktől.
Tehát mi történik valójában, ha valaki teljesíti a kvízt? Amikor megnyomják a Submit gombot, a rendszer kiértékeli a válaszát, és elküldi az Ön által megadott célhelyre – amely lehet felhőobjektum, adattár stb. (Azt is
megadhatja, hogy helyi visszajelzést kapjon a kvízt teljesítő személynek. ) Tehát miután többen válaszoltak, így nézhet ki az eredmény
Összességében a 13.0-s verzió leegyszerűsített munkafolyamatot biztosít egyszerű és összetett kvízek készítéséhez. A vetélkedők különféle típusú válaszokat tartalmazhatnak – különösen a futtatható Wolfram Language kódot. Az értékelések is lehetnek kifinomultak – például- kód-összehasonlításokat is tartalmazhatnak.
Csak hogy érzékeltessem, mi lehetséges, itt van egy kérdés, amely egy szín kiválasztását kéri, amelyet bizonyos tűréshatáron belül összehasonlítunk a helyes válasszal

E-mailek, PDF-ek és egyebek feloldása
Hogy néznek ki valójában az e-mail szálak? Régóta tűnődöm ezen. A 13.0-s verzióban pedig egyszerű módunk van az MBOX-fájlok importálására és az e-mailek szálfűzési struktúrájának megtekintésére. Íme egy példa egy belső
levelezőlistánkról:

most már szabványos gráfműveleteket végezhetünk ezen:

A 12.2-es verzió fontos újdonsága volt, hogy hűségesen importálhat PDF-eket különféle formákban – beleértve az oldalképeket és az egyszerű szöveget is. A 13.0-s verzióban hozzáadjuk a PDF-fájlok vektorgrafikaként
történő importálásának lehetőségét.
Íme egy példa a képként importált oldalakra:



Most, hogy van Video parancsunk a Wolfram Language-ben, szeretnénk minél több videót importálni. Már támogatjuk a videotárolók és kodekek nagyonteljes listáját. A 13.0-s verzióban lehetőség nyílik .FLV (Flash) videók importálására is, így lehetőség nyílik modern formátumokká konvertálni őket.
A CloudExpression általánossá válik
Van egy kifejezése, amelyet a munkamenetek során manipulálni szeretne. Ennek egyik módja az, hogy az egész kifejezést perzisztenssé tesszük a PersistentValue segítségével – vagy kifejezetten tároljuk egy fájlban vagy
felhőobjektumban, és szükség esetén visszaolvassuk. Ennek azonban van egy sokkal hatékonyabb és zökkenőmentesebb módja is – ez nem követeli meg, hogy állandóan a teljes kifejezéssel foglalkozzon, hanem lehetővé teszi, hogy az egyes részekre „piszkáljon” és „lessen” – ez pedig a CloudExpression
használata.
A CloudExpression-t először 2016-ban mutattuk be a 10.4-es verzióban. Abban az időben ez egy meglehetősen ideiglenes mód volt a meglehetősen kis kifejezések tárolására. De azt tapasztaltuk, hogy sokkal általánosságban hasznosabb, mint amire számítottunk, ezért a 13.0-s verzióban jelentős frissítést kap, amely hatékonyabbá és robusztusabbá teszi.
Érdemes megemlíteni, hogy számos más módszer is létezik a dolgok tartós tárolására a Wolfram nyelvben. A PersistentValue segítségével egész kifejezéseket is megőrizhet. Használhatja a Wolfram Data Drop funkcióját, amely lehetővé teszi az adattárolók fokozatos hozzáadását. Az ExternalStorageUpload segítségével külső tárolórendszereken, például S3-ban vagy IPFS-ben tárolhat dolgokat. Vagy beállíthat egy külső adatbázist (például SQL- vagy dokumentumalapút), majd a Wolfram Language függvények segítségével elérheti és
frissítheti ezt.
A CloudExpression azonban sokkal egyszerűbb, mégis általánosabb módot kínál az állandó kifejezések beállítására és manipulálására. Az alapötlet az, hogy hozzon létre egy felhőkifejezést, amely állandóan tárolva van a felhőfiókjában, majd műveleteket hajthat végre ezen a kifejezésen. Ha a felhőkifejezés listákból és asszociációkból áll, akkor a szabványos Wolfram nyelvi műveletek segítségével hatékonyan olvashatja vagy írhatja a felhőkifejezés egyes részeit anélkül, hogy a munkamenetben az egészet a memóriába kellene húznia. Ez egy felhőkifejezést hoz létre, jelen esetben polinomokból álló táblázatból:




De az a fontos, hogy a felhőkifejezés egyes részeinek megszerzése és beállítása nem igényli a kifejezés memóriába húzását. Ehelyett minden művelet közvetlenül a felhőben történik.
Egy hagyományos relációs adatbázis-rendszerben az adatoknak bizonyos „téglalap”-nak kell lenniük. De egy felhőkifejezésben (mint egy NoSQL adatbázisban) tetszőleges beágyazott lista és asszociációs struktúra lehet,
ráadásul az elemek tetszőleges szimbolikus kifejezések is lehetnek. A CloudExpression úgy van beállítva, hogy az Ön által használt műveletek atomi jellegűek legyenek, így például biztonságosan használhatja két különböző folyamatot, amely egyszerre olvas és ír ugyanarra a felhőkifejezésre. Az eredmény az, hogy a CloudExpression jó módszer az APIFunction és a FormFunction által felépített adatok kezelésére. A CloudExpression egyébként végső soron csak egy felhőobjektum, így megosztja az engedélyképességeket a CloudObject-tel. Ez pedig azt jelenti, hogy például engedélyezheti másoknak, hogy olvassák – vagy írhassák – az Ön által létrehozott felhőkifejezéseket. (A CloudExpression-höz társított adatok a felhőfiókban vannak tárolva, bár az saját tárhelykvótát használ, a CloudObject-től elkülönülve.)
Tegyük fel, hogy sok fontos adatot tárol allistaként a CloudExpression-ben. A CloudExpression olyan könnyen használható, hogy aggódhat amiatt, hogy valami olyasmit ír be, mint például: ce[“customers”]=7, és hirtelen felülírják a kritikus adatokat. Ennek elkerülése érdekében a CloudExpression rendelkezik a PartProtection opcióval, amellyel megadható, hogy például a kifejezés szerkezetét akarjuk-e módosítani, vagy csak a „levélelemeit”.
A függvénytár fejlesztése
Amikor 2019-ben elindítottuk a Wolfram Function Repository-t, nem tudtuk, milyen gyorsan fog növekedni. Örömmel mondhatom azonban, hogy nagy sikert aratott – napi 3 új funkcióval, ami összesen 2259 funkciót jelent. Ezek olyan funkciók, amelyek nem részei az alapvető Wolfram nyelvnek, de azonnal elérhetők bármely Wolfram Language rendszerről.
Ezeket a funkciókat a közösség tagjai támogatják, mi pedig felülvizsgáljuk és gondozzuk. És figyelembe véve az alapvető Wolfram nyelv összes képességét, figyelemre méltó, hogy mit lehet elérni egyetlen közreműködött funkcióval. A funkciók többnyire nem rendelkeznek azzal a szélességgel és robusztussággal, amely a központi Wolfram nyelvbe való integráláshoz szükséges (bár az olyan funkciókat, mint az Adjugate a 13.0-s verzióban, a Function Repository „prototípusaiból” fejlesztették ki). De amijük van, az egy nagymértékben felgyorsított szállítási folyamat, amely lehetővé teszi, hogy az új területeken rendkívül gyorsan elérhetővé váljanak a kényelmes új funkciók.
A Function Repository egyes funkciói kiterjesztik az algoritmikus képességeket. Példa erre a FractionalOrderD a tört származékok kiszámítására:

Nagyon sok van a FractionalOrderD-ben. De bizonyos értelemben egészen specifikus – abban az értelemben, hogy egy bizonyos fajta töredékes megkülönböztetésen alapul. A jövőben beépíthetjük a rendszerbe a teljes léptékű frakcionált differenciálást, de ehhez egy sor új algoritmusra van szükség.
A FractionalOrderD funkciója a függvénytárban az, hogy most a töredékes megkülönböztetés egyik formáját biztosítja.
Íme egy másik példa a Function Repository funkciójára, ezúttal egy olyanra, amely a Wolfram|Alpha képességein alapul:

Egyes funkciók kiterjesztett megjelenítési lehetőségeket biztosítanak. Íme a VennDiagram:


Egy másik példa a vizualizációs függvényre, itt van a TruthTable, amely az alapnyelvi BooleanTable függvény eredményeinek vizuális megjelenítésére készült:

Egyes funkciók kényelmes – bár talán nem teljesen
általános – kiterjesztést adnak a nyelv bizonyos jellemzőihez.
Itt van az IntegerChop, amely az „egész számokhoz kellően közeli” valós számokat pontos egész számokra csökkenti:

De jelenleg a leggyakoribb eseteket a Function Repository függvény biztosítja:

A Function Repositoryban számos olyan funkció található, amelyek speciális kiterjesztést adnak az alapnyelv funkcióinak területeire. A BootstrappedEstimate például hasznos, specifikus kiterjesztést ad a statisztikai funkciókhoz:

Íme egy függvény, amely „újraképzi” a Mandelbrot halmazt – a FunctionCompile használatával, hogy tovább menjen, mint a MandelbrotSetPlot


Aztán vannak olyan funkciók, amelyek kényelmessé teszik az „aktuális problémákat”. Példa erre a MintNFT:



Egyébként nem csak a Function Repository fejlődik mindenféle nagyszerű hozzájárulással: ott van a Data Repository és a Neural Net Repository is, amelyek szintén lendületesen fejlődtek.
A csomagok létrehozására szolgáló eszközök bemutatása
A Function Repository egyetlen funkció létrehozásáról szól, amelyek funkcionalitást adnak. De mi van akkor, ha a funkcionalitás egy teljesen új világát szeretné létrehozni, sok egymással összefüggő funkcióval? És talán olyan is, amely nemcsak funkciókat, hanem például a felhasználói felület elemeinek módosítását is magában foglalja. Sok éven át a Wolfram Language rendszer számos részét belsőleg építettük egy olyan technológiával, amelyet pacleteknek hívunk – amelyek hatékonyan biztosítanak olyan funkciókat, amelyek automatikusan telepíthetők bármely felhasználó rendszerére.
A 12.1-es verzióban megnyitottuk a csomagrendszert, amely olyan speciális funkciókat biztosít, mint a PacletFind és a PacletInstall a csomagok használatához.
De a paletták létrehozása még mindig valami fekete művészet volt. A 13.0-s verzióban most kiadjuk az eszközök első körét, amelyek segítségével pacleteket hozhat létre, és lehetővé teszi azok fájlként vagy a Wolfram Cloudon keresztüli terjesztését. Maguk a paclet eszközök (mondanunk sem kell) egy pacletben vannak elosztva, amely mostantól alapértelmezés szerint minden Wolfram Language telepítésben megtalálható. Az eszközök egyelőre külön csomagban vannak, amit be kell töltened:
A paclet létrehozásának megkezdéséhez definiáljon egy „paclet mappát”, amely tartalmazza a pacletet alkotó összes fájlt:



Mindenféle elem létezik csomagokban, és a jövőbeni verziókban fokozatosan több eszköz lesz, amelyek megkönnyítik a létrehozásukat. A 13.0-s verzióban azonban az egyik legfontosabb eszköz, amelyet szállítanak, a Documentation Tools, amely eszközöket biztosít a beépített rendszerfunkciókhoz hasonló dokumentációk létrehozásához. Ezeket az eszközöket közvetlenül a rendszer fő Palettes menüjéből érheti el:

Mostantól jegyzetfüzetként is létrehozhat a csomagfüggvény referenciaoldalain, útmutató oldalain, műszaki megjegyzéseiben és egyéb dokumentációs elemeiben. Ha ezek megvannak, a PacletDocumentationBuild segítségével beépítheti őket a kész dokumentációba. Ezután jegyzetfüzetfájlként, önálló HTML-fájlként vagy a felhőben telepített anyagként használhatja őket.
Hamarosan további eszközök lesznek a csomagok létrehozásához, valamint egy nyilvános csomagtárat a felhasználók által hozzáadott csomagokhoz.
A Paclet Repository támogatásának egyik fontos funkciója – és amely már használható magáncélúan telepített csomagokkal – az új PacletSymbol funkció. A Function Repository esetében a ResourceFunction[“név”] segítségével elérheti a lerakat bármely funkcióját. A PacletSymbol ennek analógja a csomagok esetében. A csomagok használatának egyik módja az összes eszköz explicit betöltése. A PacletSymbol azonban lehetővé teszi, hogy „mélyhívást” hajtson végre egy csomagban, hogy hozzáférjen egyetlen funkcióhoz vagy szimbólumhoz. Csakúgy, mint a ResourceFunction esetében, a színfalak mögött továbbra is megtörténik az eszközök mindenféle betöltése, de a kódban csak a PacletSymbolt használhatja látható inicializálás nélkül. És mellesleg, egy kialakulóban lévő minta az, hogy egy csomaggal „visszaállítják” az egymástól függő Function Repository függvények gyűjteményét, az egyes függvényeket a Function Repository kódjából a PacletSymbol segítségével
elérve.
A kontextus aliasok bemutatása
Amikor egy nevet, például x-et használsz valamire, mindig felmerül a kérdés, hogy „melyik x?” Az 1.0-s verzió kezdetétől fogva minden szimbólum kontextusának fogalma volt. Alapértelmezés szerint a szimbólumokat a Global kontextusban hozza létre, így az általunk készített x teljes neve Global`x. Csomagok létrehozásakor általában úgy kell beállítani őket, hogy az általuk bevezetett nevek ne akadályozzák az Ön által használt más neveket. Ennek eléréséhez pedig jellemző, hogy a csomagok saját kontextusukat határozzák meg. Ezután mindig hivatkozhat egy szimbólumra a csomagon belül a teljes névvel, mondjuk a Package`Subpackage`x stb.
De ha csak x-et kérsz, mit kapsz? Ezt a $Context és a $ContextPath beállítása határozza meg.
De néha egy köztes esetre vágyik. Ahelyett, hogy csak x a Package`x-et jelölné, mintha a Package` a $ContextPath kontextusú útvonalon lenne, inkább hivatkozzon x-re „a csomagjában”, de anélkül, hogy beírná (vagy látnia
kellene) a potenciális hosszúságot. csomagjának neve.
A 13.0-s verzióban bevezetjük a kontextusbeli álnevek fogalmát, hogy ezt lehetővé tegye. Az alapötlet rendkívül egyszerű. Amikor a Needs[“Context`”] parancsot végrehajtva betölt egy adott kontextust meghatározó csomagot, hozzáadhat egy “kontextus-aliast” a Needs[“Context`”->”alias`”] parancs segítségével. Ennek az lesz az eredménye, hogy bármely szimbólumra hivatkozhat ebben a kontextusban alias`name-ként. Ha nem ad meg kontextus-aliast, a Needs hozzáadja a kért kontextust a $ContextPath-hez, így a szimbólumai „csak x” formában lesznek elérhetők. De ha sok különböző kontextussal dolgozik, amelyekben lehetnek átfedő nevű szimbólumok, jobb ötlet kontextus-aliasokat használni minden kontextushoz. Ha rövid álneveket definiál, nem lesz sokkal több gépelés, de biztos lesz benne, hogy mindig a megfelelő szimbólumra hivatkozik. Ez betölti a ComputerArithmetic` kontextusnak megfelelő csomagot, és alapértelmezés szerint hozzáadja ezt a környezetet a $ContextPath-hez:

Most már hivatkozhat a szimbólumaira az álnévvel

A $ContextAliases globális szimbólum megadja az összes jelenleg használatban lévő álnevet:

Mellesleg, csakúgy, mint a nagybetűkkel kezdődő szimbólumokkal kapcsolatos konvenciónk, az általános konvenció volt, hogy a csomagok kontextusnevei is nagybetűkkel kezdődnek. Most, hogy vannak környezeti álneveink is, azt javasoljuk, hogy ezekhez a kisbetűket használjuk.
Szimbolikus weboldal készítés
Ha szeretne elővenni egy jegyzetfüzetet, és weboldalt csinálni belőle, mindössze annyit kell tennie, hogy CloudPublish. Hasonlóképpen, ha űrlapot szeretne létrehozni az interneten, egyszerűen használja a CloudPublish-t a FormFunction (vagy FormPage) funkcióval. És számos egyéb közvetlen webes szolgáltatás is létezik, amelyeket régóta beépítettek a Wolfram Language-be. De mi van akkor, ha kidolgozott webelemekkel szeretne weboldalt készíteni? Az egyik módja az XMLTemplate használata a Wolfram nyelv kimenetének HTML stb. fájlba történő beillesztésére. A 13.0-s verzióban azonban elkezdjük a teljes weboldalszerkezet szimbolikus specifikációinak beállítását, amelyek lehetővé teszik, hogy a Wolfram nyelvből és a webből a legjobbat hozza ki. képességek és keretek.
Íme egy nagyon apró példa:


Az alapötlet az, hogy weboldalakat készítsünk a WebColumn, WebRow ésWebItem egymásba ágyazott kombinációival. Ezek mindegyike különféle Wolfram nyelvi opciókkal rendelkezik. De lehetővé teszik a CSS-beállításokhoz való közvetlen hozzáférést is. Tehát a Wolfram Language Background->LightBlue opción kívül használhat egy CSS-beállítást is, például “border right”->”1px solid #ddd”. Van még egy fontos funkció: InterfaceSwitched. Ez alényege annak, hogy olyan reszponzív weboldalakat tudjunk létrehozni, amelyek megváltoztathatják szerkezetüket, ha különböző típusú eszközökön nézik őket. Az InterfaceSwitched egy szimbolikus konstrukció, amelyet bárhová beszúrhat a WebItem, WebColumn stb. belsejébe, és amely eltérően
viselkedhet, ha más felülettel éri el. Így például 1-ként fog viselkedni, ha egy 0 és 480 pixel közötti szélességű eszközről érik el, és így tovább. Ezt működés közben láthatja a CloudPublish segítségével

És most…NFT-k!
Az egyik dolog, ami a 12.3-as verzió megjelenése óta történt a világon, az NFT-k ötletének általános érvényesítése.
Valójában több éve rendelkezünk eszközeinkkel az NFT-k – és általában a tokenek –támogatására a blockchaineken. A 13.0-s verzióban azonban még egyszerűbb NFTeszközöket adtunk hozzá, különösen a Cardano blockchainhez való kapcsolódásunk kapcsán. Az NFT (“nem helyettesíthető token”) alapötlete egy egyedi token, amely átvihető a felhasználók között, de nem replikálható. Olyan, mint egy érme, de minden
NFT egyedi lehet. A blockchain állandó főkönyvet biztosít arról, hogy kinek milyen NFT a tulajdonosa. Amikor átad egy NFT-t, csak annyit tesz, hogy hozzáad valamit a blockchainhez, hogy rögzítse a tranzakciót.
Mire használhatók az NFT-k? Sok dologra. Például „NFT bizonyítványt” adtunk ki azoknak, akik idén „végzett” a nyári iskolánkban és a nyári táborunkban. NFT-ket iskibocsátottunk néhány, élő közvetítésben létrehozott mobilautomata műalkotás tulajdonjogának rögzítésére. Általánosságban elmondható, hogy az NFT-k bármire
állandó rekordként használhatók: tulajdonjog, hitelesítő adatok vagy csak egy teljesítmény vagy esemény megemlékezése. Tipikus esetben van egy kis „hasznos teher” az NFT számára, amely közvetlenül a blockchainen megy. Ha vannak nagyobb eszközök – például képek –, akkor ezeket valamilyen elosztott tárolórendszeren, például IPFS-en tárolják, és a blockchain hasznos terhelése tartalmazni fog egy mutatót.
Íme egy példa, amely számos blokklánc-funkciónkat – valamint a Cardano blockchainhez való új csatlakozást – használja, hogy az IPFS-ből lekérje a néhány héttel ezelőtt készített NFT-hez társított képet

Hogyan tudsz magad verni egy ilyen NFT-t? A Wolfram Language-nek megvannak az eszközei ehhez. A ResourceFunction[“MintNFT“] a Wolfram Function Repository ban egyetlen közös munkafolyamatot biztosít
(kifejezetten a CIP 25 Cardano NFT szabványhoz) – és még több lesz. A blockchain teljes története a „tiszta fogyasztói” szint alatt bonyolult és technikai jellegű. A Wolfram nyelv azonban egyedülállóan egyszerűsített kezelési módot biztosít a blockchain-konstrukciók szimbolikus ábrázolásai alapján, amelyek közvetlenül manipulálhatók a Wolfram nyelv összes szabványos funkciójával. Sok különböző blockchain is létezik, különböző
beállításokkal. De az elmúlt néhány évben tett sok erőfeszítésünknek köszönhetően sikerült létrehoznunk egy egységes keretrendszert, amely együttműködik a különböző blockchainek között, miközben lehetővé teszi a
hozzáférést azok összes speciális funkciójához. Tehát most csak beállít egy másik BlockchainBase-t (Bitcoin, Ethereum, Cardano, Tezos, ARK, Bloxberg stb.), és készen áll egy másik blockchainre.
Letisztultabb, gyorsabb letöltés
Minden, amiről itt beszéltem, ma azonnal elérhető a Wolfram Cloudban és az asztalon – macOS, Windows és Linux rendszereken (és macOS esetén ez Intel és Apple Silicon ARM egyaránt). De amikor elindul a letöltéshez (legalábbis macOS és Windows esetén), van egy új lehetőség: letöltés helyi dokumentáció nélkül. A tényleges futtatható csomag, a Wolfram Desktop vagy a Mathematica, körülbelül 1,6 GB Windows és 2,1 GB macOS esetén (macOS esetén nagyobb, mert „univerzális” binárisokat tartalmaz, amelyek az Intel-t és az ARM-et is lefedik). De akkor ott van a dokumentáció. És sok van belőle. És ha az egészet letölti, további 4,5 GB lesz a letöltés, és 7,7 GB, ha telepíti a rendszerre.
Az a tény, hogy ez a dokumentáció létezik, nagyon fontos, és büszkék vagyunk a terjedelmére és mélységére. Határozottan kényelmes, ha ez a dokumentáció közvetlenül a számítógépén van – notebookként, amelyet azonnal előhívhat és szerkeszthet, ha akar. De mivel a dokumentációnk egyre bővült (és azon dolgozunk, hogy még nagyobb legyen), néha jobb optimalizálás, ha helyi helyet takarít meg a számítógépén, és ehelyett az internetről szerezheti be a dokumentációt. A 13.0-s verzióban tehát bevezetjük a dokumentáció nélküli letöltéseket, amelyek csak az internetre kerülnek, és megjelenítik a dokumentációt a böngészőben. A Mathematica vagy a Wolfram|One első telepítésekor kiválaszthatja a „teljes csomagot”, beleértve a helyi dokumentációt. Vagy dönthet úgy, hogy csak a végrehajtható csomagot telepíti, dokumentáció nélkül.
Ha később meggondolja magát, bármikor letöltheti és telepítheti a dokumentációt a Help menü Install Local Documentation menüpontjával. (Mellesleg a Wolfram Engine mindig is dokumentálás nélküli volt – Linuxon pedig mindössze 1,3 GB a letöltési mérete, amit hihetetlenül kicsinek tartok az összes funkcióját tekintve.)