mul vs div

[MichaelBenjamin]

.

[wlangfor@uoguelph.ca]

excellent thanks I needed something like this

[MichaelBenjamin]

.

[HughBanton]

In FS 3.06, if you substitute a double precision subtract in the final position the error goes away.

Curiously in FS64 you have to substitute all 3 elements (mult, div, sub) to get the same result.

Just an observation .. I'm not much of yer maths guy . But all is clearly not quite as it seems.

H

[wlangfor@uoguelph.ca]

Indeed, when working with co-efficents it becomes very clear that only using a divisible float value is realistic, but like you said; anything beyond a bipolar .5 is erratic. I was trying to get a negative pi to round more effectively and was sobered by only being able to find a suitable balance. But the balance will never be good, and especially after seeing the results in the highest sample rates; lesser sample rates suffer for the compensation.

Actually I'd come up with something interesting and if I remember in the correct way I'll let you know. I think I was rounding larger numbers into 100'ths and then using mere floats with three decimals, maybe. It's been so long since I gave it any thought; but at the time I mused that perhaps it was practical. Because only in the float's spectrum is it viable.

[wlangfor@uoguelph.ca]

I gave it more thought, convert all floats to one thousand million so as to increase amounts of decimals and then when done divide to the right number. Double precision without double precision!

Whoa woot!

[MichaelBenjamin]

.

[trogluddite]

I gave it more thought, convert all floats to one thousand million so as to increase amounts of decimals and then when done divide to the right number. Double precision without double precision!

If that worked, there would be no need for double precision! The precision of floats is best thought of as a number of "significant digits", not as a number of "decimal places". Single-precision float have about 6-7 significant decimal digits; so if you multiply a single-precision float by one thousand million, the final three integer digits and everything after the decimal point will always be zeros.

[wlangfor@uoguelph.ca]

I gave it more thought, convert all floats to one thousand million so as to increase amounts of decimals and then when done divide to the right number. Double precision without double precision!

If that worked, there would be no need for double precision! The precision of floats is best thought of as a number of "significant digits", not as a number of "decimal places". Single-precision float have about 6-7 significant decimal digits; so if you multiply a single-precision float by one thousand million, the final three integer digits and everything after the decimal point will always be zeros.

If you make sure every number is that way then there's more decimal points when divided by the same number afrter the fact. it's the same as double, because there is less decimals involved.

[trogluddite]

You can't change the precision of multiplication or division by "moving the decimal point" (unless the infinity or denormal zones are involved). That's the entire point of floating point numbers - the error is always approximately relative to the magnitude (an epsilon, not a delta). Your proposed scaling would do nothing more than insert two more operations where rounding errors could occur.

Michael has already shown you an ideal way to test this - you can experiment with different scaling methods on one path of his schematic to see the results very plainly.