[Coco] Precisão numérica nos BASICs da vida (Era: Alguém se arrisca ?)

[Juan Castro]

O Apple II não é o único BASIC com essa limitação. No BASIC do TRS-80
Color, também, todo e qualquer número é ponto flutuante. Detalhe: de
precisão simples. Quer números melhores, programe em Assembler. Não, não
tinha DEFDBL ou DEFINT que nem nos Model I e III.

Detalhe do detalhe: No Dragon (clone inglẽs do CoCo) a precisão dos números
era melhor. Não era simples cópia do DECB.

Como sei disso? Rodei o seguinte programinha num micro e noutro:

10 A=100
20 B=A+1
30 C=B-A
40 IF C<>1 THEN END
50 PRINT B
60 A=INT(1.2*A)
70 GOTO 20

(Na verdade, eu rodo esse programa em todo micro clássico que pego pra
brincar. É o meu equivalente do '10 PRINT "BESTEIRA QUALQUER":GOTO 10'.)

O último número impresso é (com erro de 20%) o maior inteiro que pode ser
representado com exatidão. Daí dá pra ter uma idéia de quantos bits os
inteiros (ou a mantissa dos ponto-flutuante) tem nessa arquitetura. Se não
me falha a memória, o MSX é precisão dupla por padrão, mas não estou perto
de um agora pra testar.

Juan


2012/6/29 Lisias Toledo <lisias.toledo at gmail.com>

> **
>
>
> O Applesoft tinha que caber em 10KBytes, e dane-se o resto. Também TINHA
> que oferecer comandos para o HGR (era o carro chefe do Apple II!
> Gráficos de alta resolução!), pra não falar que a razão de ser desta
> nova versão era trabalhar com ponto flutuante - uma exigência já antiga
> dos usuários do Apple II.
>
> Daí que a MS teve que sair capando fora tudo o que não era estritamente
> imprescindível até caber nos benditos 10Kb, enquanto outros computadores
> ofereciam 16Kbytes (ou até mais) só para o interpretador.
>
> A coisa foi tão apertada que eles caparam fora todas as rotinas de
> matemática inteira. Toda e qualquer operação (inclusive a soma,
> implícita no FOR NEXT) é convertida em FP, executada pelas rotinas da
> ROM, e então (se for o caso) convertida de volta para INTEGER para ser
> armazenada na variável.
>
> É por isto que o Applesoft é lento de dar dó.
>