MATHEMATICA V13

A Wolfram Language + Mathematica 13.0-s verziója

Folytatódik az innováció

Stephen Wolfram által

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:

A 12.3-as verzióban ugyanaz az integrál továbbra is elvégezhető, de csak elliptikus integrálok tekintetében:

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:

És itt van – a 13-as verziótól kezdve –, hogy hogyan szerezheti meg az első képet Wolfram nyelven:

Természetesen a történetben több is van, amint azt most láthatjuk:

Másfajta szám

Azt gondolhatnánk, hogy egy szám csak egy szám. És ez alapvetően az egész számokra igaz. De ha egy szám valós szám, akkor a történet bonyolultabb. Néha szimbolikusan is „nevezhet” egy valós számot, mondjuk . De a legtöbb valós számnak nincs „szimbolikus neve”. Pontos megadásához pedig végtelen számú számjegyet vagy ennek megfelelőt kell megadnia. Az eredmény pedig az, hogy hozzávetőleges valós számokat akarunk elérni, amelyekről azt gondolhatjuk, hogy a tényleges valós számok bizonyos teljes gyűjteményét reprezentálják.

Ennek egyszerű módja véges pontosságú számok használata, például:

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:

Be tudjuk bizonyítani, hogy a függvény 0 felett van 3 és 4 között? Értékeljük a függvényt egy központosított intervallumon keresztül:

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

És az intervallum kiszámításának „legrosszabb eset” módjából ez most határozott tételt ad.

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:

És itt vannak ennek a függvénynek a pontos pólusai (és azok többszörösei) az egységkörön belül:

Most összeadhatjuk a maradékokat ezeken a pólusokon, és a Cauchy-tétel segítségével kontúrintegrált kapunk:

A számítás területén is különféle kényelmi eszközökkel bővítettük a differenciálegyenletek kezelését. Például most már közvetlenül támogatjuk a vektorváltozókat az ODE-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:

És igen, a négyzetek összegzése ismét megkapja az eredeti polinomot:

A 13.0-s verzióban néhány új mátrixfüggvényt is hozzáadtunk. Ott van az Adjugate, amely lényegében egy mátrix inverz, de nem osztja a determinánssal. És ott van a DrazinInverse, amely a mátrix nem szinguláris részének inverzét adja meg – különösen a differenciál-algebrai egyenletek megoldásánál.

További PDE modellezés: Szilárdtestek és szerkezeti mechanika

A PDE-ket nehéz megoldani, és nehéz beállítani bizonyos helyzetekre. Az évek során a legkorszerűbb végeselemes megoldási lehetőségeket építettük ki a PDE-k számára. Felépítettük az úttörő szimbolikus számítási geometriai rendszerünket is, amely lehetővé teszi a PDE-k régióinak rugalmas leírását. De a 12.2-es verziótól kezdődően mást is csináltunk: elkezdtünk explicit szimbolikus modellezési keretrendszereket létrehozni bizonyos típusú fizikai rendszerek számára, amelyek PDE-kkel modellezhetők. Már megvan a hőátadás, a tömegszállítás és az akusztika. Most a 13.0-s verzióban szilárd és szerkezeti mechanikát adunk hozzá.

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:

Ezután meg kell mondanunk, hogy mik a kanalunk anyagparaméterei. És itt felhasználhatjuk a teljes tudásbázisunkat, amely sokféle anyagról tartalmaz részletes információkat:

Most készen állunk a PDE probléma tényleges beállítására és megoldására:

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:

És most például megtalálhatjuk a deformációs tenzor maximum 3, 3 komponensét és azt a pozíciót, ahol ezt elértük:

Mit szólnál ahhoz, hogy megtaláljuk a törzs értékeinek eloszlását a kanál között? Ennek egyik egyszerű módja, ha véletlenszerűen mintát vesz a kanál pontjaiból

majd készítsünk egy simított hisztogramot a törzsekről ezeken a pontokon:

(A maximum, amit korábban láttunk, a jobb oldali farokban van.) A szilárd mechanika bonyolult terület, és ami a 13-as verzióban van, az jó, ipari minőségű technológia a kezeléséhez. Valójában van egy teljes monográfiánk „Szilárd mechanikai modellellenőrzés” címmel, amely leírja, hogyan validáltuk az eredményeinket. Ezenkívül egy általános monográfiát is biztosítunk a szilárd mechanikáról, amely leírja, hogyan kell bizonyos problémákat kezelni és megoldani technológiai csomagunkkal.

Videók készítése képekből és videókból

A 12.3-as verzióban olyan funkciókat adtunk ki, mint az AnimationVideo és a SlideShowVideo, amelyek megkönnyítik a videók előállítását generált tartalomból. A 13.0-s verzióban már van egy olyan funkciógyűjtemény is, amellyel videókat hozhatunk létre meglévő képekből és videókból. Mellesleg, mielőtt még a videók készítéséhez kezdenénk, egy másik fontos újdonság a 13.0-s verzióban, hogy mostantól közvetlenül a notebookban is lejátszhatók a videók:

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:

Egy ilyen kép „megtapasztalásának” jó módja lehet egy „túravideó”, amely felváltva felkeresi a kép különböző részeit. Íme egy példa, hogyan kell ezt megtenni:

Nagyíthat és pásztázhat is:

Kifinomultabb példaként vegyünk egy klasszikus „fizikai képet”:

Ez megkeresi az összes arc helyzetét, majd kiszámítja a legrövidebb körutat, amely mindegyiket meglátogatja:

Most létrehozhatunk egy „arctúrát” a képről:

Amellett, hogy a képekről a videókra, a videókról a videókra is eljuthatunk. A GridVideo több videót is rögzít, rácsba rendezi őket, és egy kombinált új videót hoz létre

Készíthetünk egyetlen videót is, és „összefoglalhatjuk” videó és hangrészletek sorozataként, amelyeket például a videóban egyenlő távolságra választunk ki. Tekintsd úgy, mint a VideoFrameList videoverzióját. Íme egy példa egy 75 perces videó „összefoglalására”:

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:

Számos képműveletet készítettünk közvetlenül a videókra is. Tehát például egy videó kivágásához csak az ImageCrop-ot kell használnia:

Képfűzés

Tegyük fel, hogy egy csomó képet készített különböző szögekből – és most össze szeretné fűzni őket. A 13.0-s verzióban ezt nagyon leegyszerűsítettük – az ImageStitch funkcióval:

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

A 12.3-as verzióban alapkonstrukcióként vezettük be a Tree-t. A 13.0-ban kibővítjük a Tree-t, és néhány fejlesztést adunk hozzá. Először is, most már vannak lehetőségek a fa elrendezésére és megjelenítésére. Például ez egy fát sugárirányban helyez el (megjegyzendő, hogy ha tudjuk, hogy ez egy fa, nem pedig egy általános gráf, sokkal szisztematikusabb beágyazásokat tesz lehetővé):

Ez további lehetőségeket ad a stíluselemekhez, és a fa helyzete alapján meghatározott elemet kék színnel különítjük el:

Az egyik kifinomultabb új „fakoncepció” a TreeTraversalOrder. Képzelje el, hogy „áttérképez” egy fát. Milyen sorrendben érdemes felkeresni a csomópontokat? Itt van az alapértelmezett viselkedés. Állíts fel egy fát:

Most mutassa meg, hogy a TreeScan milyen sorrendben keresi fel a csomópontokat:

Ez kifejezetten felcímkézi a csomópontokat a látogatásuk sorrendjében:

Ez a sorrend alapértelmezés szerint a mélység az első. De most a TreeTraversalOrder lehetővé teszi, hogy más rendeléseket is kérjen. Íme a szélességi sorrend:

Íme egy kicsit díszesebb sorrend:

Miért számít ez? A „bejárási sorrendről” kiderül, hogy az értékelési folyamatokkal kapcsolatos mély kérdésekhez kapcsolódik, és amit ma többszámításnak nevezek. Bizonyos értelemben a bejárási sorrend határozza meg azt a „referenciakeretet”, amelyen keresztül a fa „megfigyelője” mintát vesz belőle. És igen, ez a nyelv úgy hangzik, mint a fizika, és ennek jó oka van:
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 Wolfram Language gráfelméleti képességei hosszú ideje nagyon lenyűgözőek (és kritikus fontosságúak voltak például a Fizikai Projektünk lehetővé tételében). A 13.0-s verzióban azonban még többet adunk hozzá.

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:

És most ezekkel a színekkel „kiemelhetjük ki” a grafikont:

A klasszikus „grafikonszínezés” probléma magában foglalja a földrajzi térképek színezését. Tehát itt van például az Egyesült Államok államainak határos viszonyait ábrázoló grafikon:

Most már könnyű megtalálni az Egyesült Államok államainak négy színét:

Valójában egy figyelemre méltó problémakör létezik, amelyek a grafikonok színezésére redukálhatók. Egy másik példa egy olyan „torna” ütemezésére vonatkozik, amelyben minden emberpár „játszik” egymással, de mindenki
egyszerre csak egy mérkőzést játszik. A szükséges egyezések gyűjteménye csak a teljes grafikon:

Minden egyezés egy élnek felel meg a grafikonon:

És most, ha megtaláltuk az „élszínezést”, megvan a lehetséges „idősávok” listája, amelyekben minden meccs lejátszható:

Az EdgeChromaticNumber megmondja a szükséges egyezések teljes számát:

A térképszínezés felveti a síkgrafikonok témáját. A 13.0-s verzió új funkciókat vezet be a síkgrafikonokkal való munkavégzéshez. A PlanarFaceList egy sík gráfot vesz fel, és elmondja nekünk, hogyan bontható fel a gráf „arcokra”:

A FindPlanarColoring közvetlenül kiszámítja ezeknek a síklapoknak a színét. Eközben a DualPlanarGraph olyan grafikont készít, amelyben minden lap egy csúcs:

Részgráf izomorfizmus és egyebek

Mindenhol előkerül. (Valójában a mi Fizikai Projektünkben még az univerzum is hatékonyan csinálja a teret a hálózatban.) Hol tartalmaz egy adott gráf egy bizonyos részgráfot? A 13.0-s verzióban van egy funkció ennek meghatározására (az All azt mondja, hogy minden példányt megad):

Egy tipikus terület, ahol ez a fajta részgráf izomorfizmus megjelenik, a kémia. Íme egy molekula gráfszerkezete:

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:

Ez most minden csúcsra megmondja, hogy mi a „dominátora”, azaz mi a legközelebbi kritikus csúcs

Ha a grafikon egy „esemény” ok-okozati vagy más függőségét ábrázolja a többitől, akkor a dominánsok gyakorlatilag szinkronpontok, ahol mindennek egy „történelemszálon” kell haladnia.

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:

Most készítsünk „térbeli becslést” az adatokra

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

Ennek a becslésnek az elkészítéséhez elkerülhetetlenül modellt használtunk. A modellt megváltoztathatjuk a térbeli becslés létrehozásakor:

Most más lesz az eredmény:

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:

De annak ellenére, hogy mindkettő ugyanahhoz az „óraleíráshoz” kapcsolódik, különböző aktuális pillanatoknak felelnek meg. És ezeket kivonva nullától eltérő értéket kapunk:

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:

(És igen, ez azt mutatja, hogy – a mérések 1950-es évek végén történt megkezdése óta először – a Föld forgása kissé felgyorsul.)Láthatjuk-e a szökőmásodperceket, amelyek a
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:

De itt van elcsúszott UTC-ben:

És igen, ezt a számot levezetheti egy „szökőmásodperces nap”
másodperceinek számából:

Mellesleg azon töprenghet, hogy miért kell törődni ezzel a bonyolultsággal. A mindennapi életben a szökőmásodpercek egy részlet. De ha csillagászattal foglalkozik, azok valóban számíthatnak. Végül is egy (ugró) másodperc alatt a fény körülbelül 186 000 mérföldet tesz meg…

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

A térképek sok adatot tartalmaznak, és ezek hatékony szállítása és megjelenítése (megfelelő vetületekben stb.) nehéz feladat. A 13.0-s verzióban nagymértékben „megtisztítjuk” a térképeket, vektoros betűtípusokat használunk minden címkézéshez:

Legalábbis jelenleg alapértelmezés szerint a háttér továbbra is bittérkép. A háttérben is használhatunk „roppantott” vektorgrafikát, de tovább tart a renderelés

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):

A 13-as verzió másik kiegészítése a több háttérréteg keverésének lehetősége. Íme egy példa, amely egy utcatérképet tartalmaz egy áttetsző domborművel a tetején (és címkékkel a tetején):

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

Ha adott egy csomó pont egy körön, melyik körön vannak? Íme egy kör körül véletlenszerűen kiválasztott pontok:

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

Íme egy pontgyűjtemény 3D-ben:

Ez egy hengert a következő pontokhoz illeszt:

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:

A domború hajótest „zsugorfólia” lesz minden körül:

De a homorú hajótest a felületet „bemegy a homorúba”

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:

Ne feledje, hogy ez egy „pontos” régió – nincs benne numerikus közelítés. Tehát ha a mennyiségét kérdezzük, pontos eredményt kapunk:

Hierarchikusan bonyolultabb struktúrákat is fel lehet építeni:

Bár az integrálok bonyolultak, gyakran még mindig pontos eredményeket lehet kapni olyan dolgokra, mint például a térfogat:

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

A gépgyártás során nagyon gyakori, hogy különféle műveletek fizikai végrehajtásával készítenek alkatrészeket, amelyek könnyen ábrázolhatók CSG formában. Tehát itt van például egy kicsit bonyolultabb CSG fa

amely „összeszerelhető” egy tényleges CSG régióba egy tipikus mérnöki részhez:

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 képletből önmagában kiszámítható néhány tulajdonság, például a molekulatömeg:

A kémiai képlet alapján kérhetünk konkrét „ismert” molekulákat, amelyek rendelkeznek ezzel a képlettel:

Gyakran sok ilyen molekula lesz, és például láthatjuk, hogyan helyezkednek el a „kémiai jellemzők terében”:

Most, hogy mind a molekulákat, mind a kémiai képleteket kezelni tudjuk, a következő nagy lépés a kémiai reakciók. A 13.0-s verzióban pedig ennek kezdete a kémiai reakció szimbolikus ábrázolásának képessége.
A reakciót karakterláncként is megadhatja:

Íme a reakció kifejezett szabályok szerint:

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 vizualizáción túl azonban a 13.0-s verzió az RNS, a fehérjék és az egyszálú DNS másodlagos struktúrájának megjelenítését is lehetővé teszi. Itt van például egy darab RNS további hidrogénkötésekkel:

A másodlagos szerkezetet a „pont-zárójel” jelöléssel is megadhatja:

A BioSequence a hibrid szálakat is támogatja, például a DNS és az RNS közöttikapcsolódást:

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

Mindezt összeadva, itt van egy példa két peptid közötti térhálósításra (most már diszulfidkötésekkel), jelen esetben az inzulin esetében:

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:

Most nézzük meg az egyik járatot. Szimbolikus entitásként ábrázolják, mindenféle tulajdonsággal:

Ez ábrázolja a sík magasságát az idő függvényében:

É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:

Ez pedig egy hisztogramot mutat arról, hogy mikor indultak járatok tegnap Bostonból:

Eközben a Bostonba érkező járatok az alábbi útvonalakon haladtak a repülőtér közelében:

És igen, most elkezdhetjük nézni a kifutópálya irányait, a tegnapi szélirányokat stb. – mindezekre vonatkozó adatokat a tudásbázisunkban.

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:

És íme, mi történik, ha egyes görbék osztoznak a tengelyükön:

A több tengely lehetővé teszi, hogy több görbét csomagoljon egyetlen „rajzi panelre”. A többpaneles diagramok segítségével görbéket különálló, összekapcsolt panelekbe helyezhet, megosztott tengelyekkel. A többpanelesdiagramok első eseteit már a 12.0-s verzióban bemutatták. De most a 13.0-s verzióban a többpaneles diagramokat más típusú vizualizációkra is kiterjesztjük:

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

A 13.0-s verzióban a telkekben a „koordinátáknak” nem csak számoknak kell lenniük; randevúk is lehetnek. Ez például azt jelenti, hogy az összes szokásos ábrázolási függvény „csak működik” olyan dolgokon, mint például az idősorok:

És semmi sem akadályozza meg, hogy több tengelyen randevúzzon. Íme egy példa a napszak (TimeObject) ábrázolására a dátum függvényében, ebben az esetben a Databin-ben tárolt e-mail időbélyegek esetében:

Egy másik dolog, ami újdonság a tengelyekkel – vagy inkább a léptékekkel – a 13.0-s verzióban, az a lehetőség, hogy végtelen diagramtartományokat lehet használni:

Ez úgy működik, hogy van egy skálázó függvény, amely a végtelen intervallumot végesre képezi le. Ezt kifejezetten a ScalingFunctions funkcióval használhatja

Íme egy kicsit kidolgozottabb példa, amely kétszeresen végtelen intervallumot tartalmaz:
:

Új vizualizációs típusok

Folyamatosan új típusú beépített vizualizációkat adunk hozzá – nem utolsósorban az új típusú funkciók támogatása érdekében. Így például a 13.0-s verzióban vektoros eltolási diagramokat adunk hozzá, hogy támogassuk a szilárd mechanika új képességeit:

Or in 3D:

A diagram megmutatja, hogy egy adott régiót hogyan deformálódik egy bizonyos eltolási mező. A VectorPoints lehetővé teszi az eltolási vektorok felvételét is:

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:

Az új lehetőség azonban az, hogy egy jelenetben különböző tárgyakat „külön megvilágítunk”, különböző szimbolikus „világítási stílusokat” adva meg nekik:

Egyébként a 13.0-s verzió másik újdonsága a beépített Torus primitív

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:

Most már használhatjuk a tartalomérzékelőt meghatározott bemeneteken:

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:

Miután elvégeztük ezt a képzést (ami, igen, kb. 5 percet vett igénybe egy GPUképes gépen), alkalmazhatjuk az imént létrehozott detektort:

Amikor alkalmazza az érzékelőt, különféle információkat kérhet tőle. Itt határolókereteket ad, amelyekkel megjegyzéseket fűzhet az eredeti képhez:

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 gépi tanulásra alkalmas funkció, amelyet például mindig használok, a FeatureSpacePlot. A 13.0-s verzióban pedig egy új alapértelmezett módszert adunk hozzá, amely gyorsabbá és robusztusabbá teszi a FeatureSpacePlot-ot, és gyakran lenyűgözőbb eredményeket produkál. Íme egy példa arra, hogy 10000 képen fut:

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):

Íme az egyetlen adatrészlet kinyert jellemzői

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):

Most az a célunk, hogy beállítsuk a robot bemeneti változóinak (a kocsit mozgató erőnek és a mutató nyomatékának) „meghajtásának” módját,

hogy a kimeneti változók (a végpont pozíciója) bizonyos viselkedését elérjük:

Íme egy görbe, amelyet szeretnénk, hogy a mutató vége idővel kövesse:

Most ténylegesen meg akarjuk építeni a vezérlőt – és itt kell tudni egy bizonyos mennyiséget a vezérléselméletről. Itt a póluselhelyezés módszerét fogjuk használni a vezérlőnk létrehozásához. És a 13.0-s verzió új képességét
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):

Most meg kell alkotnunk a zárt hurkú rendszert, amely magában foglalja a robotot és annak vezérlőjét:

Most pedig szimulálhatjuk ennek az egész rendszernek a viselkedését, bemenetként megadva a referenciapálya x és y koordinátáit:

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

Egy kezdeti tranziens után ez követi a kívánt utat. És igen, bár ez az egész egy kicsit bonyolult, hihetetlenül egyszerűbb, mintha közvetlenül valódi hardvert használnánk, nem pedig elméleti „modell alapú” tervezést.

Kevesebb zárójelet írjon be!

Amikor először indítja el a 13-as verziót, és beír valami olyasmit, mint az f[, a következőket fogja látni:

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…

Ön egy hosszú számítást futtat. mi történik vele? Hosszú távú kezdeményezésünk van, hogy interaktív folyamatfigyelést biztosítsunk a lehető legtöbb olyan funkcióhoz, amelyek a lehető leghosszabb számításokat végeznek.

Egy példa a 13.0-s verzióban az, hogy a ParallelMap, a ParallelTable stb. automatikusan felügyeli az előrehaladást:

A megjelenítés ideiglenes; csak akkor van ott, amíg a számítás fut, majd eltűnik.
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:

A 13.0-s verzióban elég sok minden került hozzáadásra a Wolfram|Alpha-Mode notebookokhoz. Először is vannak paletták a 2D matematikai jelölések közvetlen bevitelére:

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

Aztán amikor megnyomja a Generate gombot, azonnal megkapja a kvíz telepített verzióját, amely például közvetlenül elérhető az interneten. Kapsz egy eredményjegyzetfüzetet is, amely megmutatja, hogyan kérhet le
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 itt van egy vektorgrafikaként importált oldal:

És most, hogy bebizonyítsuk, hogy vektorgrafika, ténylegesen bemehetünk és módosíthatunk, egészen az egyes karakterjelekben használt körvonalakig:

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:

Így megkapjuk a táblázat 5. részét:

Visszaállíthatjuk:

Ez megkapja a teljes felhő kifejezést:

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:

Sokféleképpen elképzelhető a bonyolultabb esetek kezelése; ez a funkció egy adott választást tesz:

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:

Íme egy példa egy olyan funkcióra, amely talán egy napon az alapnyelven lesz.
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

Vannak olyan funkciók, amelyek határozottan „résnek” tűnnek – de rendkívül hasznosak, ha szüksége van rájuk:

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

Vannak „szórakoztató funkciók” is (ez mindenképpen hasznos lehet)

És vannak olyan funkciók, amelyek „bennfentes” humornak tekinthetők:

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:

Ez beállítja a paclet alapvető vázlatos szerkezetét, amelyhez ezután fájlokat adhat hozzá:

Alternatív megoldásként megadhat néhány összetevőt a pacletben közvetlenül a paclet első létrehozásakor:

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:

Mostantól a ComputerArithmetic szimbólumok használhatók anélkül, hogy bármit is mondanánk a környezetükről:

Ez betölti a csomagot, és meghatároz egy környezeti álnevet:

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:

And here’s the webpage it produces:

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

majd csak az eredmény megtekintéséhez használt ablak átméretezése:

É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.)