# Mighty Maths Programs

So this is what I did.

Download the package here:

**http://www.rickdangerous.co.uk/hammer/ms/zx/hexfrac.zip**

In short, I thought it was possible to make a program to convert fractional decimals into their hex equivalents - and include some test examples - pi, e, and the usual suspects. After one

*very*false start after which I almost abandoned the whole idea, I went through with the process of "multiply by 16, take the value before the point as the next hex bit, replace that with a zero and continue". For the most part it works, and the input will take a string of 30 digits after the decimal point. Decimal expressions that terminate within those 30 digits will come out exact; irrational numbers and recurring decimals, because they are 30-digit approximations of the actual value, will not be so accurate. I found pi would calculate to 13 hex digits after the point; e, the golden ratio and the square root of 2 were all accurate to 24 digits. The final result will be printed in just under four minutes, so even on real hardware you can give your input, start the process, make a mug of tea and come back to find it's nearly done.

Not bad for a day's programming, that - and I now further wonder if it could be down-converted for a ZX81. Even once the colour information and the UDGs are removed (which requires the maximum number of digits to be cut to 29 at most), would 16K be enough memory to handle the same process? I suppose there's only one way to find out...

## Comments

I just loaded your experience into a 16k Fuse emulator and the example PI and T work very wel, although i have to admid i set the emu to 10000 percent ;-)

I can only compare it with my failed big-small endian project were some one asked after 5 years , "shouldn't that 1024 be 65536 ???", which was correct since thats the math for the 3rd byte. why did i set it on 1024?

well, it does not do any thing either.

With 'golden ratio' i had the letter Phi in mind or in dutch just 'fi' 1.6 as short calculation number, so thats the same as 'gulden snede' which means 'golden cut'

if i cut out you REMS and CLEAR then in 16k there is 3262 bytes free.

if you change 6x "000000000000000" to z$ you save some more. and then set a 'mx' as max and DIM all m$ etc. to (mx) and z$ to of course. a$=a$+a$ needs twice the space of a$ as you probably know better then i do.

maybe if you cut deep, it all will fit in a original zx81, how small is that?

well , its your routine, i leave it like it is since i dont go re-poke the lot

there are typins waiting for me,

cheers

ps:

suggestion against poking

x$=chr$19+chr$1

y$=chr$19+chr$0

You know what, I'll give the ZX81 version a go, just for a laugh. Now hang on while I LPRINT the Spectrum listing...

I would be very interested to see this as Maths/encryption is my thing for the 81 rather than games playing.

Download the updated package:

http://www.rickdangerous.co.uk/hammer/ms/zx/hexfrac.zipThe graphical compromise that was the loss of colour has been compensated for by (a) using the ZX81's "shades of grey" graphics around the input and output values, and using inverse video to show the build-up of the hex bits instead of BRIGHT. The number of accessible digits after the decimal point is reduced to 29, and you'll know if your input is too long as the "L" cursor, with quotes intact, will spill onto a second line (and the BEEP-less error routine compensates for this). This is so that there's two character spaces for input integers from 10 to 15.

Otherwise, the program works as I'd expect, and the accuracy hasn't been reduced by much for the loss of that one decimal place - the golden ratio loses two digits of accuracy but pi, e and root 2 are unaffected (although the digits after this point are different).

The major difference is in the speed the program works. I've just tested the Spectrum version on a real +2B, and it reaches a result for a 30-digit input in three and a half minutes. The ZX81, handling 29 digits, will get there... in

17minutes, at least on the EightyOne emulator running at normal speed. I don't have a real ZX81 to test it with, but if anyone does, feel free to convert the .P to .WAV and give it a shot.It's lunchtime, so I've earned myself a corned beef sandwich - at least I would have if all my tins of corned beef weren't stashed away in a Corona-chan Doomsday Box, which I refuse to open unless absolutely necessary. So yesterday's freshly-baked bread - yes, I've been trying that myself - will have to be filled with something else. But I'll find something, that's for sure.

Also, anyone who wants to translate these two programs into machine code to see how they run that way, fire away. I'd be expecting the Spectrum to zip through the routine in no time at all.

I further wonder now, if it's possible to do anything similar on a (16K and probably emulated) ZX80 - losing the PRINT AT commands will be tough, losing floating-point arithmetic will be even worse, and the long multiplication routine as I've written it needs that facility.

Approx 4 minutes 47 seconds using standard ROM in fast mode.

Perhaps the spectrums relatively poorer performance is down to having to constantly refresh the display which the 81 doesn't need to do in fast mode?

(No need for to convert to wav as most of us are using some kind of SD interface for the zeddy these days.)

This time, I've taken the hexadecimal fraction converter and adapted it for dozenal, to satisfy all those who

demandthat we should have evolved to have six fingers on each hand and thus count in base 12, or who want to go back to the good old days of pounds, shillings and pence.Both the Spectrum and ZX81 versions of the hex fraction converter program have been adapted.

Spectrum version:

ZX81 version:

There are many representations for the extra digits ("dek" and "el") required for the values of 10 and 11 - A and B, X and E, T and E, chi and epsilon, or the upside-down 2 and 3 that look like a very mangled T and curly E (or epsilon). On the ZX81 it was far easier to keep them as A and B rather than try to fanny about with X and E(which was the original plan), seeing as A and B follow on directly from 9 in the ZX81 character set. As they don't on the Spectrum there had to be separate lines to represent any digits beyond 9 (which was also the case in the hex program), so I defined upside-down 2 and 3 UDGs to make them look like the Dozenal Society of Great Britain would want them to.

Also, the semicolon isn't a mistake, it's how the radix point is denoted in dozenal.

Download the package here:

http://www.rickdangerous.co.uk/public_html/hammer/ms/zx/dozfrac.zipyour link is to long

http://www.rickdangerous.co.uk/hammer/ms/zx/dozfrac.zip

Hi only had a quick look . Is this stuff on the Speccy as well as the ZX81?