Perché le lingue con un supporto di numeri interi grandi hanno versioni non firmate?

4

Una rapida occhiata a C #, Java e altre lingue indica che questa non è una funzione richiesta. Ho provato a cercare una giustificazione per questo forse da un team di progettazione linguistica o da un blog, ma non ho trovato nulla che spieghi perché un tale tipo venga ignorato.

La mia attuale ipotesi migliore è che le applicazioni che utilizzano i numeri interi grandi non salveranno o vedranno evidenti benefici in termini di prestazioni, quindi non saranno disponibili.

Esistono lingue che supportano sia i grandi numeri interi che quelli senza segno e firmati? C'è qualche giustificazione scritta o post di una mailing list che descrivono perché o perché non è stata aggiunta o non inclusa tale funzionalità?

    
posta Sirisian 16.04.2016 - 01:19
fonte

3 risposte

3

Se hai un caso d'uso in cui non hai mai a che fare con numeri negativi all'interno di qualsiasi grande calcolo intero, allora potresti usare anche l'implementazione di interi interi firmati, e la tua ipotesi di rendimento è quello che mi aspetterei anch'io le differenze di prestazioni sarebbero probabilmente trascurabili.

Se si dispone di un caso d'uso in cui possono verificarsi risultati intermedi negativi, ma si desidera che eseguano il "wraparound" su un valore positivo, in un contesto intero di grandi dimensioni non è intrinsecamente chiaro quale dovrebbe essere il risultato. Ad esempio, il risultato di "4 -5" in un contesto intero senza segno a 32 bit è in genere "2 ^ 32-1" (purché il proprio ambiente non elimini un errore di underflow). Cosa dovrebbe essere in un contesto in cui non esiste un tale limite superiore di 32 per il numero di bit?

Questo rende difficile la creazione di una specifica utile su come dovrebbe funzionare il grande intero non firmato di carattere generale, supponendo che si voglia renderlo anche un utile universalmente.

Ovviamente, questo problema potrebbe essere risolto introducendo un "massimo bitsize" artificiale configurabile nell'implementazione di interi interi senza segno e sarei stupito se qualcuno in passato non avesse implementato una cosa del genere. Tuttavia, ritengo che autori di librerie o linguaggi di uso generico ampiamente utilizzati ci pensino due volte se l'implementazione di un requisito così specifico vale la pena e se ci saranno abbastanza applicazioni per giustificare lo sforzo aggiuntivo di sviluppo e test.

    
risposta data 16.04.2016 - 11:00
fonte
8

Il motivo originale per cui gli interi senza segno in una lingua in primo luogo è di estendere l'intervallo numerico di un tipo di dimensione fissa verso l'alto al costo di limitarlo verso il basso. Effetti benefici come la semantica sana delle operazioni bit a bit (in C) o l'imposizione implicita di un vincolo non negativo non sono la ragione principale.

I grandi numeri interi non hanno il problema di un intervallo insufficiente, perché crescono secondo le necessità e il salvataggio di quel bit non vale la pena.

    
risposta data 16.04.2016 - 01:30
fonte
2

Uno dei vantaggi chiave con un (per esempio) intero senza segno a 32 bit rispetto a un intero con segno a 32 bit è overflow. Gli interi senza segno fissi di precisione operano tramite l'aritmetica 2 n , una forma specializzata dell'aritmetica dell'orologio. Anche se questo può essere controintuitivo, non può traboccare. Risolti gli interi con segno di precisione, dall'altra quelli che pretendevano di operare secondo le regole standard dell'aritmetica che imparavamo da bambini. A volte questa finzione fallisce.

Questo vantaggio scompare con l'aritmetica di precisione estesa. Implementazioni di precisione estese usano con successo le regole elementari che abbiamo imparato da bambini, entro i limiti della memoria del computer. D'altra parte, l'aritmetica dell'orologio usata in interi di lunghezza fissa senza segno non ha senso nell'aritmetica di precisione estesa. La somma di due bignum ben implementati è un bignum più grande. L'unico rischio sta esaurendo la memoria. Anche la differenza tra una coppia di bignum non è un problema. L'aritmetica dell'orologio non ha senso nel dominio dell'aritmetica di precisione estesa.

    
risposta data 16.04.2016 - 20:08
fonte

Leggi altre domande sui tag