How to resolve a function of X.

[John Drew]

G'day all, well that was an interesting set of experiments. By splitting into multiple lines it saved 30 bytes of program space for David's equation but no saving in variable numbers.

For the hundreds of floating point equations in my moon tracking program which include trig and arithmetic the memory savings become significant - in my case I was able to save a couple of kBytes. Perhaps a small difference in speed too.

The results for David's equation were the same irrespective of the method  (You're right Tumbleweed)

On another topic the exercise has shown an anomaly with scientific notation. The compiler does recognise scientific notation but with errors.
e.g.
-9.42477E-6 recognised but returns rubbish
-9.42477E+6 recognised but returns rubbish
-9.42477E6 returns the correct value (-9424770.3, I know this "accuracy" is not meaningful)
-0.00000942477 returns the correct value and computes correctly for the full equation.

It would appear that the + and - are failing but recognised by the compiler. I'll put a note in the anomalies sections.

A very useful thread, especially the use of float conversions to fractions. Thanks all.
Cheers
John

David: I've sent you a message with a run in Delphi to give you some cross checking references for the calcs. I used original formula from the graph and double floats for 64 bit variables.

[david]

Oh dear - I only checked to see that it compiled with the scientific format and hadn't yet tried to run it.  it's certainly not a show stopper and perhaps even of less importance now that I can convert the decimals to fractions. As mentioned - I just hadn't come across the use of scientific format before so your earlier comments were of great interest.
Many thanks for the high precision Delphi listing.  I shall use this as reference.  I bet your moon bounce calculations are impressive and I hope they're well commented. 
Do you think this sort of stuff is a good hedge against getting Alzheimer's? Lawn bowls just never appealed to me.....

Thanks and cheers,
David

[John Drew]

Well I've spent some fun time looking at all the possibilities and checking results.
I've attached a PDF showing the code and variable use. My numbers are different but consistent with Tumbleweed's as I printed results to LCD.
The key thing to take away from this is:
1) although Positron accepts scientific notation there is currently an anomaly in 4.0.3.3 with calculations. So my tests have all used -0.00000942477 to replace -9.942477E-6.
2) all but the version using the conversion of a float to a fraction, gave consistent results across the range and these checked to 5 significant figures as measured against a Delphi program using 64 bit variables. The fraction conversion method provided results that were 4.5% out at x=2000 and 14.5% out at x=6000 making this method in need of more work.

The tests have revealed there is a significant saving in code by splitting to multiple lines and using temporary variables. The single line equation worked well but was expensive in terms of memory.

The exercise showed that Les's coding of floats provides excellent results.
I've attached a PDF summary. See Tumbleweed's post 15 for details of the code used after substituting for scientific notation. I used a PIC18F452 as I had an ISIS schematic.
Spreadsheet calculations.pdf

John
PS if I use JohnW's reduction for the first and last terms to -0.0000094 * x^2 + 0.441x its <  0.1% error
and then use the integer method (method 5) the results are quite good but memory use is not (2022 bytes + 58 var). The trick is to identify a best float to division. All in all, best answer is to use floats throughout, most accurate and least memory.

[John Lawton]

Hi John,

fascinating results thank you. You haven't speed rated / timed the different models, that would be interesting to see if possible?

John L

[david]

Hello John Drew,
This is getting quite academic now but just for the record what values did you use in the 5th (integer) evaluation?  Trastikata indicated he had mis-read the decimal value and gave the integer values as -9.42477E-06 = -58903 / 6250000000 which is slightly off.
I would also be interested to see what you got if you changed that fraction to -1/106112

Cheers,
David

[John Drew]

G'day David,
The bottom line is that the accuracy for this polynomial is especially sensitive to the size of the integers e.g. JohnW's suggestion gave good results and seems to be the sweet spot. Using -0.9 gives a fraction of 9/1000000 and this doesn't meet your criteria at an input of 6780 (the maximum I printed out for you from Delphi) being 0.2% or > your criteria of 0.1%. Similarly at an input of 2000.

When I use your suggestion of -1/106112 things start to work pretty well and easily meet your criteria. Memory use drops down a couple of bytes too (2018 and 58Var).

However messing around with the constants until things work is not good use of time, and takes more code and variable memory and is not as accurate as using floats. Memory size may be better if no floats are used in the program (float library not loaded) and in this circumstance the code and variable size may come down providing you hit the sweet spot with the integer approach.

Interesting experiments. You and other users have pointed out how the terms can be manipulated/disregarded with an intelligent look at the polynomial such as omitting the last constant on your graph and other shortcuts. I've learned in the process.

And yes David, I'm sure keeping the brain active helps staves off Alzheimer's disease although it doesn't seem to be helping my memory. I had to look up the spelling of Alzheimer
Best wishes
John

[david]

Hello John,
All interesting stuff.  How to get lost in the process and forget about the result.
The last term in that function printed on the graph was not supposed to be there but I couldn't find a way to edit it out.  It is vanishingly small and plays no part in the main function.  As JonW pointed out the x^2 term is not a major contributor until x gets larger in value and he showed that the precision is not too critical.
As for the messing around with finding a good set of integers for making a proper fraction - that's where the converter website comes in.  In the past I used the previous website converter I had for changing things like knots to km/h and it always surprised me how close some simple fractions were and how they avoided the need to go in to floats.
Keep well.

Cheers,
David

[John Drew]

All good David, kept me out of mischief for a while.
Cheers
John