Mettendo i miei due centesimi nei linguaggi di programmazione dell'array , in particolare J e APL .
Anche K / Kona, Q e Nial rientrano in questa categoria, ma generalmente hanno gli stessi benefici e critiche. Usa discrezione. Userò J esempi di seguito, principalmente perché sono ASCII e quindi facili da digitare - ricorda che i caratteri APL contano come byte singoli, quindi non lasciare che questo sia il tuo problema con la lingua come scelta per il golf.
- Problemi di matematica
- Risolvere i puzzle numerici
- Esecuzione di metodi numerici
- Problemi di array 2D complessi
Questi due sono ottimi linguaggi matematici e di manipolazione dei dati, perché generano array intorno a un livello elevato e molti cicli vengono eseguiti implicitamente , dicendo, ad esempio, aggiungere dieci a ciascuno di 3, 4 e 5 ( 10 + 3 4 5
) o sommare ciascuno riga di un array ( +/"1 arr
- il looping è nel "1
).
- Problema con i numeri primi
Con problemi di numero primo in particolare, J ha primitive integrate veloci e brevi, così come alcuni dialetti di APL. (Modifica: sto pensando a Nars2000, che è in parte dialetto e in parte implementazione completamente diversa. APL non ha incorporato per i numeri primi.) N-esimo primo ( p:
), no. di numeri primi fino a ( _1&p:
), factoring ( q:
), GCD e LCM ( +.
e *.
), e così via, ce ne sono molti. Tuttavia, in pratica, la domanda spesso specifica che devi cucinare le tue prime implementazioni principali, quindi queste non vedono troppo uso. Ci sono ancora modi puliti e fantasiosi per ottenere le cose migliori di cui hai bisogno, diventa solo un po 'meno taglia e incolla.
- Elaborazione delle stringhe
- Elaborazione di array
L'elaborazione di array e stringhe è un po 'un miscuglio: se è qualcosa in cui APL / J è bravo o ha un linguaggio primitivo o comune, è quasi banale; se è qualcosa di molto sequenziale e non molto parallelizzabile, ti divertirai molto. Qualcosa nel mezzo è nell'aria, sebbene di solito rispondano favorevolmente.
- Problemi che richiedono una soluzione I / O, console o file
- Problemi che richiedono di scrivere la soluzione come definizione di funzione
IO è strano. APL ha un'espressione di ingresso singolo carattere, ma con J si deve spendere almeno l'8 per leggere in un numero: ".1!:1]1
. L'output è un po 'meno dettagliato, ma in pratica stai ancora guardando 6 o 7 caratteri sprecati. In particolare a J piace molto se si può accettare l'input come argomento di una funzione, invece di dover fare confusione con IO stesso.
In pratica, con J e APL, di solito la soluzione è scritta come una funzione invocata sulla console. Con APL, puoi semplicemente inserire nomi di variabili per i tuoi argomenti e racchiudere l'espressione con cui stavi lavorando in parentesi graffe e chiamarla un giorno.
Ma con J, c'è un po 'di sovraccarico per definire esplicitamente le funzioni-- 3 :'...'
e devi sfuggire a qualsiasi stringa all'interno - quindi ciò che viene solitamente fatto è qualcosa chiamato programmazione tacita: programmi a livello di funzione, combinando le primitive in un modo non diversamente da quello di Haskell. Questa può essere sia una benedizione che una maledizione, perché non devi spendere tanti personaggi facendo riferimento ai tuoi argomenti, ma è facile annegare tra parentesi e finire per perdere decine di personaggi cercando di hackerare la tua soluzione altrimenti breve e intelligente in qualcosa che funziona.
- Problemi che richiedono l'analisi
- Geometria computazionale
Non ho esperienza con il golf su questi particolari problemi, ma lo dirò: alla fine, i linguaggi di programmazione dell'array sono molto bravi a convogliare e trasformare molti dati allo stesso modo. Se riesci a trasformare il problema in un esercizio di mescolanza dei numeri, puoi renderlo un problema APL / J, senza sudare.
Detto questo, non tutto è un problema APL / J. A differenza di Golfscript, APL e J sono risultati buoni per giocare a golf, insieme ai loro altri vantaggi;)