# Mighty Maths Programs

In a break from typing in listings from 37-year-old magazines, I had a sudden urge to write a maths-related program, as I do, occasionally. Some, such as a cubic equation solver, remain unfinished as I still don't quite understand the methods behind it (but I'll probably have another go at some stage). And others, such as the RPN Calculators I made three years ago, I've made public because I thought they were good enough to show off and the listing would probably have been snapped up by Sinclair Programs, had I been in my 30s or 40s in 1983 (I wasn't... I was a tenth of that) and had a huge stack of tapes, and a printer, and an enormous amount of that shiny paper to print out the listing until I could work out how and why it was going wrong, when at least these days I have an emulator with savestates to make the programming process a whole lot easier.

So this is what I did.

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...

• Mighty Fingers you mean.
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'
my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
• edited March 29
.
Post edited by Crisis on
my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
• edited March 29
Well,i though lets try 300 instead of 30
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
Post edited by Crisis on
my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
• I would think "cutting deep" to fit the program on a 1K ZX81 would be beyond even the author of 1K Chess!

You know what, I'll give the ZX81 version a go, just for a laugh. Now hang on while I LPRINT the Spectrum listing...
• edited March 29
Seeing as the 81 can resolve pi to 400 decimal places in BASIC and using FORTH can work out !4000 (12670 digits) it should be doable.
I would be very interested to see this as Maths/encryption is my thing for the 81 rather than games playing.
Post edited by moggy on
• It is doable, and I've done it, in the space of a morning:

The 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 17 minutes, 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.
• I will try this on a ZX81 with double speed ROM which has faster calculator routines over the standard ones and see if there is any speed difference.
• edited March 29
2 Minutes 40 seconds in fast mode, (which is said to be roughly on par with the spectrums compute and display mode even though the spectrum has a faster clock) , using double speed ROM to work out pi and similar timings for the golden ratio number.

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.)
Post edited by moggy on
• I've done it again... maths programs which are of no use to anyone but me! But I do it because I can.

This time, I've taken the hexadecimal fraction converter and adapted it for dozenal, to satisfy all those who demand that 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.