Lezione 01 — Il primo script GNU Octave in GX-TXT

Corso: GNU Octave e programmazione scientifica con le API pubbliche di GX-TXT.

Scheda di riferimento verificata

Campo	Riferimento
Repository ufficiale	giuxlab-hub/GX-TXT
Versione dichiarata dal repository	0.9.8.10-dev-103
Ramo consultato	main
Commit fissato per questa lezione	e07376e0a62e0eecf1737da33c87bbbb41273f4b
Verifica delle fonti	17 ottobre 2026
Linguaggio	GNU Octave (.m)
Framework	GX-TXT, Octave Script Bridge API v1
Provider scientifico	math.numeric, NUMERIC_API_v1
Licenza dello script	GNU GPL-3.0-or-later
Verifica di esecuzione	Eseguita con esito positivo nella Session GX-TXT 0.9.8.10-dev-103 (17/10/2026); codice di uscita 0, log e output verificati

Fonti primarie, fissate al commit:

• Contratto OCTAVE_SCRIPT_BRIDGE_API_v1.
• Contratto NUMERIC_API_v1 del provider math.numeric.
• Registrazione Script Bridge di NUMERIC_API_v1.
• Implementazione numerica pubblica Octave.
• Esempio pubblico di Script Bridge Octave.

Regola del corso. I sorgenti usati sono quelli GitHub al commit indicato. Una eventuale copia locale di sviluppo non fa parte del riferimento scientifico o tecnico. Il commit documenta ciò che è stato letto, non una garanzia di funzionamento su installazioni GX-TXT differenti.

1. Cosa impareremo

Questa prima lezione insegna a scrivere un file .m e a farlo eseguire in GX-TXT. Non serve conoscere ancora Dataset, fitting o grafici. Ci concentreremo su una catena ridotta ma reale: definizione dei dati → controllo delle API → calcolo nel provider → stampa dei risultati.

Obiettivi:

1. Capire cosa distingue il linguaggio Octave dal framework GX-TXT.
2. Scrivere assegnazioni, commenti, vettori, strutture, condizioni e cicli in Octave.
3. Comprendere perché gxtxt_api_call richiede l’identità dell’API e una lista di argomenti posizionali.
4. Calcolare attraverso NUMERIC_API_v1 anziché implementare separatamente il servizio numerico.
5. Sapere dove non scrivere file e perché questa prima lezione non pubblica alcun Dataset.

Octave e GX-TXT: una differenza fondamentale

In Octave si scrive x = [1; 2; 3];: è sintassi del linguaggio, indipendente dal framework. In uno script GX-TXT, invece, il calcolo scientifico coperto dal framework passa dalle sue API pubbliche; per esempio gxtxt_api_call('NUMERIC_API_v1', 'array_reduce', {'sum', operand}) delega la somma al provider numerico registrato.

Questo non significa rinunciare a if, for, struct, fprintf o ai normali tipi di Octave. Sono gli strumenti linguistici per costruire il programma; GX-TXT governa il servizio scientifico, i Dataset, la persistenza e la tracciabilità. Nella lezione 01 useremo solo output testuale: nessun CSV privato, nessun grafico salvato a mano, nessun accesso ai percorsi interni.

2. Il problema sperimentale

Abbiamo cinque temperature, in gradi Celsius:

\[ T_C = \begin{bmatrix} 18 & 20 & 22 & 21 & 19 \end{bmatrix}^{\mathsf T} \; ^\circ\mathrm{C} \]

Vogliamo trasformarle in kelvin e calcolarne la media. Si utilizza la relazione per temperature assolute:

\[ \frac{T}{\mathrm{K}} = \frac{t}{^\circ\mathrm{C}} + 273{,}15 \]

La media attesa è 293,15 K; il numero di misure è 5.

Nota sulle unità: le operazioni elementari array_binary/array_reduce di NUMERIC_API_v1 agiscono su valori numerici e non eseguono da sole conversioni di unità fisiche. Qui il cambiamento °C → K è esplicito e giustificato dalla relazione sopra. In una lezione sui Dataset assoceremo unità e identità fisiche allo schema delle variabili GX-TXT.

3. Dall’editor all’esecuzione: percorso guidato nel viewer Octave Scripts

Le cinque schermate si riferiscono al test originale in italiano; il codice scaricabile in questa revisione è in inglese e mantiene gli stessi calcoli. Il test descritto in questa lezione è stato effettuato realmente nel viewer Octave Scripts di GX-TXT 0.9.8.10-dev-103. Sono necessarie una Session aperta, il runner analysis.octave_script, GNU Octave disponibile e il provider math.numeric registrato nello Script Bridge. Il percorso funziona sia con un file .m già preparato sia scrivendo il codice da zero nell’editor.

3.1 Aprire il viewer Octave Scripts

Aprire la scheda Viewers nella finestra principale di GX-TXT. Nella sezione Scientific Scripting selezionare Octave Scripts. Si apre Octave Script Workspace: qui si gestiscono gli script registrati nella Session.

3.2 Scegliere come introdurre il codice

Metodo A — Importare uno script .m: utilizzare il menu File dello Workspace e selezionare l’azione di importazione di uno script GNU Octave. Nella finestra Import GNU Octave script individuare GXTXT_Octave_L01_EN.m, selezionarlo e premere Apri. Il codice viene caricato nell’editor. La descrizione visualizzata dopo l’importazione conferma che lo script registrato sarà indipendente dal file originale: la copia originale non viene utilizzata come sorgente mutevole a ogni esecuzione.

Metodo B — Scrivere direttamente nell’editor: creare uno script dallo Workspace e digitare o incollare il codice nel riquadro centrale. Non è necessario possedere un file .m esterno: l’editor supporta la scrittura e la modifica manuale dello script.

3.3 Identificare e salvare lo script

Nella parte superiore dello Workspace impostare i campi di registrazione:

Campo	Utilità	Valore usato nella lezione
Scope	Determina il contesto in cui lo script viene registrato	session
Name	Nome leggibile visualizzato nell’elenco degli script	GXTXT_Octave_L01
Script ID	Identificatore dello script nel proprio scope; utile per richiamarlo senza ambiguità	GXTXT_Octave_L01
Description	Descrizione facoltativa dell’obiettivo scientifico	Conversione °C → K e media con NUMERIC_API_v1

Lo Script ID non è il Job ID: il primo identifica lo script registrato, il secondo una specifica esecuzione. Nel test, il riferimento effettivamente registrato è session:GXTXT_Octave_L01 (lo scope compare nel prefisso). Impostare o verificare l’ID prima del salvataggio, così da mantenere una denominazione coerente. La descrizione è facoltativa e non incide sul calcolo.

Salvare lo script nello Workspace prima di avviarlo, in modo che sia registrato nella Session. Lo stato iniziale unsaved / modified mostrato nella figura indica invece codice importato o modificato ma non ancora salvato.

3.4 Eseguire direttamente dall’editor

Usare il comando Run dello Workspace. Si apre la finestra di conferma dell’esecuzione dello script registrato; la finestra mostra anche la revisione e l’impronta SHA-256 della sorgente. Per questa lezione Dataset bindings è opzionale perché lo script impiega valori definiti nel codice, non Dataset della Session. Premere Run per inviare il Job al runner GX-TXT.

3.5 Ritrovare l’esecuzione nei Session files

Tornare nella finestra principale di GX-TXT, aprire la vista Session files ed espandere la directory logica analysis/scripts. Qui compaiono le esecuzioni registrate. Facendo doppio click sul nome dello script o sull’esecuzione corrispondente si apre la finestra dei risultati con il log tecnico e l’output dello script.

Nel riquadro del log si trovano stato, orari, codice di uscita, revisioni, risorse e identificatori del Job. Nel riquadro dell’output si legge ciò che lo script stampa con fprintf, incluse le cinque conversioni e la media. Non occorre navigare manualmente nei percorsi privati mostrati nel log: è GX-TXT a gestirli.

Figura 5 — Accesso da analysis/scripts: il Job è COMPLETED e l’output mostra Media: 293.15 K.

3.6 Distinguere lo script dai risultati e dai file temporanei

La registrazione conserva uno script identificato da nome, ID e revisione. Ogni esecuzione ha invece un Job ID proprio, un’istantanea immutabile della sorgente e un log associato. Il runtime può utilizzare directory e risorse temporanee gestite dal framework: non equivalgono a file scientifici pubblicati né a scritture dirette eseguite dal codice utente. Per il primo esperimento, infatti, non vengono creati Dataset né grafici.

3.7 Prerequisito dell’API numerica

Quando la UI permette di specificare le API richieste, dichiarare NUMERIC_API_v1@1:math.numeric. Lo script contiene in ogni caso gxtxt_api_require e i controlli delle operazioni necessarie. Questo permette di ottenere un errore esplicito qualora il provider non sia disponibile, anziché affidarsi a chiamate private o a sostituzioni non documentate.

Esecuzione: usare lo Script Workspace di GX-TXT e non una console Octave indipendente. Il framework gestisce avvio e arresto dello Script Bridge; lo script non deve farlo manualmente.

4. Le basi di Octave che incontriamo

Sintassi	Cosa significa	Esempio
%	Commento, non eseguito	% Initial temperature
=	Assegnazione a una variabile	x = 273.15;
; a fine istruzione	Sopprime la stampa automatica del valore	x = 5;
[...]	Costruisce un vettore o una matrice	[18;20;22] è una colonna
struct(...)	Struttura con campi denominati	struct('kind','scalar','value',4)
{...}	Cell array, contenitore di valori anche eterogenei	{'add', a, b}
oggetto.campo	Legge un campo della struttura	result.values
if ... endif	Esecuzione condizionata	if (manca) error('...'); endif
for ... endfor	Ripete istruzioni	for i=1:5 ... endfor
fprintf	Stampa formattata sullo standard output	fprintf('n = %d\n', 5);
numel	Numero di elementi di un array	numel([1;2;3]) vale 3

Attenzione ai separatori: [18; 20; 22] è un vettore colonna, mentre { 'sum', x } non è un vettore numerico ma una cell array con due elementi di tipi diversi. Le API Bridge richiedono proprio una cell array di argomenti posizionali.

5. Il programma completo

File allegato: GXTXT_Octave_L01_EN.m. Il codice e tutti i messaggi generati dallo script sono in inglese; la guida è in italiano. Tutti i calcoli scientifici di questo esercizio sono chiamate alla API numerica pubblica. Il linguaggio Octave viene usato per descrivere il flusso, rappresentare dati e stampare il risultato.

% GX-TXT / GNU Octave - Lesson 01
% First scientific script using the framework's public APIs.
%
% Official repository: https://github.com/giuxlab-hub/GX-TXT
% GX-TXT release: 0.9.8.10-dev-103
% Reference commit: e07376e0a62e0eecf1737da33c87bbbb41273f4b
% Source verification date: 2026-10-17
% SPDX-License-Identifier: GPL-3.0-or-later
%
% IMPORTANT:
% - Run this script in the GX-TXT Octave Script Workspace in a test Session.
% - Do not run it from a standalone Octave console. The analysis.octave_script
%   runner starts and stops the Script Bridge automatically.
% - This script creates no files, Datasets, or plots.
%
% 1. Read the public execution context without accessing private paths.
context = gxtxt_context();
fprintf('GX-TXT - Lesson 01\n');
fprintf('Script: %s\n', context.script_name);

% 2. Require the public numeric provider and its exact API version.
%    The script stops explicitly if the required provider is unavailable.
gxtxt_api_require('NUMERIC_API_v1@1:math.numeric');

% 3. Verify that the required public operations are registered.
if (!gxtxt_api_has_operation('NUMERIC_API_v1', 'array_binary'))
  error('L01: required array_binary operation is unavailable');
endif
if (!gxtxt_api_has_operation('NUMERIC_API_v1', 'array_reduce'))
  error('L01: required array_reduce operation is unavailable');
endif

% 4. Define five Celsius measurements as an Octave column vector.
temperatures_C = [18; 20; 22; 21; 19];

% 5. Build typed operands for NUMERIC_API_v1.
%    The offset explicitly converts Celsius readings to kelvin.
measurements = struct('kind', 'vector', 'value', temperatures_C);
offset = struct('kind', 'scalar', 'value', 273.15);

% 6. Perform the addition through the GX-TXT numeric provider.
kelvin_result = gxtxt_api_call('NUMERIC_API_v1', 'array_binary', ...
                              {'add', measurements, offset});
temperatures_K = kelvin_result.values;

% 7. Delegate summation and counting to the GX-TXT numeric provider.
kelvin_vector = struct('kind', 'vector', 'value', temperatures_K);
sum_result = gxtxt_api_call('NUMERIC_API_v1', 'array_reduce', ...
                            {'sum', kelvin_vector});
count_result = gxtxt_api_call('NUMERIC_API_v1', 'array_reduce', ...
                              {'count', kelvin_vector});

% 8. Compute the arithmetic mean using the provider, not Octave mean().
total_K = struct('kind', 'scalar', 'value', sum_result.values);
sample_count = struct('kind', 'scalar', 'value', count_result.values);
mean_result = gxtxt_api_call('NUMERIC_API_v1', 'array_binary', ...
                             {'divide', total_K, sample_count});
mean_K = mean_result.values;

% 9. Format textual output using the GNU Octave language.
%    fprintf writes to stdout captured by the GX-TXT runner, not to a file.
fprintf('\nTemperature conversion results:\n');
for i = 1:numel(temperatures_C)
  fprintf('  Measurement %d: %.2f °C = %.2f K\n', ...
          i, temperatures_C(i), temperatures_K(i));
endfor
fprintf('Number of measurements: %.0f\n', count_result.values);
fprintf('Mean: %.2f K\n', mean_K);
fprintf('Expected result for this example: 293.15 K\n');

% End: no direct disk writes or Dataset publications.

6. Le API pubbliche, spiegate una per una

6.1 gxtxt_context() — leggere il contesto di esecuzione

Scopo. Permette a uno script di conoscere la propria identità di esecuzione GX-TXT senza cercare file interni o variabili globali private.

Firma Octave:

context = gxtxt_context();

Parametri: nessuno. Valore restituito: una struct che comprende, secondo il contratto pubblico, informazioni quali bridge_api_id, bridge_api_version, module_id, run_id, operation, script_name, script_sha256, arguments_raw, output_dir e inputs. In questa lezione leggiamo solo context.script_name.

Comportamento e limiti: il percorso di lavoro interno della Session non viene divulgato come interfaccia di lettura dei Dataset; output_dir, quando usato in futuro, è il percorso controllato dal framework per la pubblicazione di file completati. Non autorizza scritture arbitrarie in cartelle di GX-TXT. La chiamata richiede un Bridge attivo.

Confronto con Octave: pwd mostra una directory del processo, ma non descrive la provenienza dello script, il run_id o i Dataset associati alla Session. Il contesto GX-TXT contiene invece identità logiche gestite dal framework.

6.2 gxtxt_api_require(requirements) — dichiarare un prerequisito

Scopo. Impedire che lo script parta con un’API o un provider assente/incompatibile.

Firma:

ok = gxtxt_api_require(requirements);

Parametro: requirements è una dichiarazione stringa, una cell array di dichiarazioni o strutture previste dal contratto. Nel nostro caso:

gxtxt_api_require('NUMERIC_API_v1@1:math.numeric');

Indica il public API ID NUMERIC_API_v1, la versione API 1 e il provider math.numeric. Risultato: conferma il requisito oppure solleva un errore esplicito se non è soddisfatto; possiamo ignorare il valore positivo quando vogliamo solo verificare il prerequisito.

Confronto con Octave: exist('funzione') cerca un simbolo nel path di Octave, ma non garantisce che un provider GX-TXT sia registrato con l’identità e il contratto richiesti. Per le API framework è preferibile gxtxt_api_require.

6.3 gxtxt_api_has_operation(api_id, operation) — controllare un’operazione

Scopo. Verificare che una specifica operazione sia esposta alla Session dallo specifico provider, non semplicemente che l’API esista.

Firma:

available = gxtxt_api_has_operation(api_id, operation);

Parametri: api_id è il nome pubblico esatto dell’API, operation il nome esatto dell’operazione. Risultato: valore logico di disponibilità.

if (!gxtxt_api_has_operation('NUMERIC_API_v1', 'array_reduce'))
  error('Required operation is unavailable');
endif

Confronto con Octave: controllare se esiste una funzione nativa con nome simile non prova nulla sulla possibilità di chiamare il servizio GX-TXT tramite il Bridge. La disponibilità effettiva è decisa dalla registrazione del provider.

6.4 gxtxt_api_call(api_id, operation, args) — invocare un servizio pubblico

Scopo. Chiamare un’operazione del provider registrato attraverso il trasporto pubblico del Bridge.

Firma:

result = gxtxt_api_call(api_id, operation, args);

Parametri: api_id identifica il contratto (NUMERIC_API_v1); operation identifica la funzione (array_binary o array_reduce); args è una cell array che contiene gli argomenti nello stesso ordine prescritto dalla documentazione del provider.

Risultato: una struttura Octave il cui contenuto è definito dalla specifica operazione. Nel nostro esempio si legge il campo .values. Un errore del provider produce un errore Octave riconoscibile, non un finto risultato vuoto.

Sicurezza dell’interfaccia: non può chiamare a piacere procedure Tcl interne o leggere direttamente file privati. Lo Script Bridge è un perimetro di API pubbliche, non un sandbox completo del processo Octave.

Confronto con Octave: l’espressione nativa a + b fa eseguire l’operazione a Octave; la chiamata gxtxt_api_call('NUMERIC_API_v1', 'array_binary', ...) richiede invece al provider pubblico GX-TXT di eseguire un’operazione catalogata, con i controlli e gli errori propri del provider.

6.5 NUMERIC_API_v1 / array_binary — addizione e divisione

Scopo. Applicare un’operazione binaria numerica a operandi tipizzati, anche combinando un vettore e uno scalare.

Firma attraverso il Bridge:

result = gxtxt_api_call('NUMERIC_API_v1', 'array_binary', ...
                         {operation_name, left_operand, right_operand});

Operandi: in questa lezione gli oggetti sono struct('kind','vector','value',v) e struct('kind','scalar','value',s). kind può indicare scalar, vector o matrix, secondo il contratto. Tra i nomi pubblici ci sono add, subtract, multiply, divide e power. Gli array devono essere reali e non contenere non-finiti nella modalità predefinita. Uno scalare si espande rispetto al vettore; due operandi non scalari devono avere forme compatibili secondo il contratto.

Risultato: result.values, uno scalare o un array numerico. Qui add converte le cinque temperature, mentre divide produce la media a partire da somma e conteggio. Non vengono associati automaticamente metadata o unità fisiche: è responsabilità del chiamante dichiarare la relazione scientifica.

Esempio minimo:

a = struct('kind', 'vector', 'value', [1; 2; 3]);
b = struct('kind', 'scalar', 'value', 4);
r = gxtxt_api_call('NUMERIC_API_v1', 'array_binary', {'multiply', a, b});
% r.values is [4; 8; 12]

6.6 NUMERIC_API_v1 / array_reduce — somma e conteggio

Scopo. Ricondurre una serie di valori a una quantità aggregata, usando il provider invece di implementare il calcolo nello script.

Firma:

result = gxtxt_api_call('NUMERIC_API_v1', 'array_reduce', ...
                         {reduction_name, operand});

Il terzo argomento posizionale può essere una struct di opzioni; se omesso si usano i default del provider. In particolare, l’asse predefinito axis=0 aggrega tutti gli elementi del vettore o della matrice. Useremo sum e count.

Risultato: una struttura con .values; l’implementazione pubblica include anche dettagli quali n_input, n_valid, axis e requested_axis. count conta gli elementi in ingresso; su dati non finiti è importante distinguere il conteggio totale dai valori validi. Qui i dati sono tutti finiti.

Confronto con Octave: funzioni native come sum(v) e numel(v) possono produrre i medesimi numeri, ma bypassano il contratto dell’API scientifica che stiamo imparando a usare. Le useremo per spiegare il linguaggio, non per sostituire servizi pubblici GX-TXT già disponibili.

7. Lettura guidata dei passaggi

1. gxtxt_context() legge l’identità dello script. Non dipendiamo da directory correnti o convenzioni sul disco.
2. gxtxt_api_require() richiede un provider preciso. Senza math.numeric, l’esercizio non produce un risultato parziale ingannevole.
3. gxtxt_api_has_operation() controlla le due funzioni usate. Impariamo a diagnosticare una capacità mancante prima di calcolare.
4. temperatures_C = [18; 20; ...] costruisce un vettore colonna: l’ordine delle misure è conservato.
5. struct('kind',...,'value',...) prepara operandi tipizzati per il contratto pubblico.
6. array_binary/add applica +273.15 a ogni misura. Il provider restituisce una struttura, non direttamente un array privo di contesto.
7. array_reduce/sum e array_reduce/count ottengono totale e numero di campioni.
8. array_binary/divide calcola la media.
9. for ... endfor e fprintf costruiscono soltanto il report testuale del programma. Non avviene alcuna scrittura su file da parte dello script.

8. Risultati attesi e verifica

Misura	°C	K
1	18,00	291,15
2	20,00	293,15
3	22,00	295,15
4	21,00	294,15
5	19,00	292,15
Media	20,00	293,15

Nell’output reale del runner della versione originale italiana sono comparsi Numero di misure: 5 e Media: 293.15 K (con punto decimale secondo il formato di fprintf). Il risultato osservato coincide con quello atteso, ed è documentato dal log condiviso per la Session «Lezione 01 — Primo script Octave e Script Bridge».

Verbale del primo collaudo — versione originale italiana (17 ottobre 2026)

Campo del log	Riscontro
Framework nell’interfaccia	GX-TXT 0.9.8.10-dev-103
Script registrato	GXTXT_Octave_L01
Registered Script ID	session:GXTXT_Octave_L01
Versione dello script e revisione	1.0.0, revisione 1
SHA-256 della sorgente eseguita	9abceb6ae24a9c372d0608d4dfeba3ff62a7eb1f4544ef81c1cb5c6688fe85d6
Controllo dello snapshot	verified
Job ID	script-20261017T144038Z-2234348-1792248038026981
Stato finale	COMPLETED
Durata riportata	3.8 s
Codice di uscita	0
Errori	No error recorded
API richiesta	NUMERIC_API_v1@1:math.numeric
Dataset pubblicati	Nessuno, come previsto
Risultato misurato	293.15 K
Risultato atteso	293.15 K

L’indicazione publication_recovery: PASS riguarda il controllo finale del ciclo di esecuzione; non significa che siano stati pubblicati Dataset. Il log comprende percorsi di lavoro, snapshot e risorse gestiti dal runner; non è necessario inserirvi o modificare file manualmente. Il test conferma il funzionamento di questo specifico script, in questa Session e su questa installazione, non di tutte le API o di tutte le versioni del framework.

Output osservato nella prima esecuzione, prima della traduzione del codice:

GX-TXT - Lezione 01
Script: GXTXT_Octave_L01

Risultati della conversione:
  Misura 1: 18.00 °C = 291.15 K
  Misura 2: 20.00 °C = 293.15 K
  Misura 3: 22.00 °C = 295.15 K
  Misura 4: 21.00 °C = 294.15 K
  Misura 5: 19.00 °C = 292.15 K
Numero di misure: 5
Media: 293.15 K
Valore atteso per l'esempio: 293.15 K

Output atteso dal nuovo script inglese:

GX-TXT - Lesson 01
Script: GXTXT_Octave_L01

Temperature conversion results:
  Measurement 1: 18.00 °C = 291.15 K
  Measurement 2: 20.00 °C = 293.15 K
  Measurement 3: 22.00 °C = 295.15 K
  Measurement 4: 21.00 °C = 294.15 K
  Measurement 5: 19.00 °C = 292.15 K
Number of measurements: 5
Mean: 293.15 K
Expected result for this example: 293.15 K

Questa seconda stampa è prevista, non ancora attestata dal log storico. Le schermate si riferiscono al collaudo originale; i risultati numerici rimangono invariati.

Verifiche pratiche

• Caso corretto: cinque temperature; attendersi media pari a 293.15 K.
• Provider assente: disabilitando math.numeric in una Session di prova, il controllo del prerequisito deve interrompere l’esecuzione senza risultato fittizio.
• Nome API errato: un nome di operazione non presente nel registry deve essere rifiutato; non è previsto alcun richiamo automatico di funzioni Tcl private.
• Forma dei dati: [] è un array numerico vuoto e {} è una cell array vuota; confonderli produce argomenti differenti per il Bridge.

Errori tipici

Errore GXTXT:ScriptBridge:NotActive. Lo script è stato lanciato al di fuori del runner GX-TXT o dopo la chiusura del Bridge. Non tentare di chiamare manualmente funzioni private di avvio: eseguire il file nel corretto Script Workspace.

API o operazione sconosciuta. Verificare l’ID, il provider e la versione. Non sostituire automaticamente la chiamata con una funzione Octave autonoma: il problema di disponibilità deve restare esplicito.

Argomenti invalidi. Controllare kind, forma dell’array, ordine nella cell array e presenza di valori non finiti. Il Bridge non inferisce automaticamente il significato fisico dei numeri.

9. Esercizi

1. Sostituire i cinque valori con [10; 12; 14; 16]. Prima di eseguire il programma, prevedere la media in kelvin: 286,15 K.
2. Cambiare la stampa da due a tre cifre dopo il punto (%.3f) e osservare la differenza; non si modifica il dato, ma solo la sua rappresentazione testuale.
3. Aggiungere un controllo gxtxt_api_has_operation per array_unary, senza ancora chiamarlo. Capire perché API disponibile e operazione disponibile sono condizioni distinte.
4. Esercizio di lettura della documentazione: consultare sul commit fissato gxtxt_api_list() e gxtxt_api_describe(api_id) e individuare quali metadati delle operazioni vengono messi a disposizione del Bridge. Non introdurre chiamate ad API private.

10. Perché questa lezione non salva un Dataset?

Perché lo scopo è isolare il funzionamento dello Script Bridge e le prime strutture di Octave. Una pubblicazione scientifica corretta richiede concetti ulteriori: Dataset ID, Variable ID, unità, metadata, contratto di schema, identità della Session e provenance. Verranno studiati nel modulo sui Dataset.

Una regola da conservare: uno script GX-TXT non deve inserire manualmente file in cartelle del framework, né creare CSV/PNG “fuori banda” quando esistono API pubbliche di pubblicazione e plotting. Questo esercizio non scrive alcun file: soltanto output testuale del runner.

11. Sintesi e passo successivo

Abbiamo introdotto le istruzioni minime di Octave e quattro funzioni del Bridge: gxtxt_context, gxtxt_api_require, gxtxt_api_has_operation, gxtxt_api_call. Le operazioni scientifiche effettivamente usate sono NUMERIC_API_v1/array_binary e NUMERIC_API_v1/array_reduce.

Nella Lezione 02 — Variabili, tipi e operatori approfondiremo i tipi Octave, gli operatori e il modo in cui si rappresentano correttamente gli input delle API GX-TXT.

---