mul vs div

[wlangfor@uoguelph.ca]

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.

They aren't decimals when you multiply by that much. And by using divide, it only takes the decimals into play. You'd still have more precision, arguably.

EDIT: Ran out of time, I wanted to add that this solution by multiplying by horrendous amounts can add precision mostly while using asm or maybe blue. And the rationale is that decimal points will in fact be part of the base number, and like double precision, only after it has been "divided, and only divided" will it's points likely be more accurate.

This is not something that will be all that useful with greens; but it's an idea, an innovation which might be useful if your polar or bipolar numbers are not accurate enough with mere float values. The question is, do you want to use one zero and 16 decimals or do you want to use 28 decimals? As far as I know, there's no other way of getting a value that's similar to double precision within ASM, or code like synths employ.

And that ultimately comes down to a more finite comparison of either multiplication and division if inside ASM and if inside code; it's just a real pita.

One other strange issue with multiplication or division that makes no sense is when you wish to calculate a horizontal bitmap into a strip animation. It's strange that division causes a hopping more often than not, and multiplication less so, so the question is (if using 80+ frames) is due to less or more accuracy, and is it indicative of the program making the strip or the math dividing the strip after the fact.

Hopefully someone has more time than Me and can come up with something useful from that. For Me, a post like this isn't so much about debate, but finite realizations of limitation aren't always constructive and I'm often looking around for workarounds rather than falling back on a happy medium which in the case of receded bipolar values would obviously be less accurate, especially in the case of forming a sine wave or another wave - if, arguably that wave is being used an LFO for instance that needs to be measurable.

[deraudrl]

They aren't decimals when you multiply by that much. And by using divide, it only takes the decimals into play. You'd still have more precision, arguably.

Or not:

Far Side Math.png (612.86 KiB) Viewed 16319 times

[tulamide]

I'm often looking around for workarounds rather than falling back on a happy medium which in the case of receded bipolar values would obviously be less accurate

There is no workaround. The nature of floats is as it is.

[trogluddite]

They aren't decimals when you multiply by that much. And by using divide, it only takes the decimals into play. You'd still have more precision, arguably.

Or not:

Far Side Math.png

I thought about looking for an XKCD cartoon in a similar vein - but The Far Side is even funnier!

I'm usually not fond of "reputation" systems, "upvoting", "downvoting", and all that (anti-)social-media malarky. But every once in a while, a thread comes along which makes me wish I had the moderator power to move posts to Stack Overflow!

...arguably...

There is nothing "arguable" about this - everything that myself and the other posters on the thread have said can be proven beyond all doubt mathematically, and the floating-point rules to which CPUs must conform are very tightly defined by the IEEE754 international standard. The Wikipedia page for IEEE754 even includes a handy graph of precision versus number magnitude, where you will see that numbers in the billions are only precise to the nearest 100 at best

[wlangfor@uoguelph.ca]

Yeah, proven popularity contests and facebook meme's instead of math and hobbies; I understand. So, I failed in My educated guess about decimal points, but did some testing about decimals.

multiply and division accuracy tester.fsm

(3.24 KiB) Downloaded 1050 times

and then I'd tested an older method for PI*2 to compare techniques which was interesting, here's an RBJ coeff at 192000

over precision test using rbj filter at 192000.fsm

(50.5 KiB) Downloaded 1023 times

Hehe "inserts meme here, *says something tendy

It's not cliche at all, popup video is so recent, lol.

But what the first test shows is multiplication is only accurate until 2, after that it loses congruity, even 2.1 loses its stability. So, what I will do to try and collectively solve this dilemma is to make a multiplication to division module. A module that converts multiplication into division. I guess that's constructive; so I'll make another test that compares just division and just multiplication.

[trogluddite]

what the first test shows is multiplication is only accurate until 2

You gave up too soon! There are two larger numbers on your selector which scale accurately, and all of the "errorless" values have something in common (hint: we shouldn't really be talking about "decimals")

[wlangfor@uoguelph.ca]

Hmm, I get an error from it (2.01 and on). I guess I could make a program that automates the test in ruby and then can collate multiple instances of the test and then provides a test average with a readout.

I could then post the source and the results I got.

But don't worry, I'll try multiplication into division; it might work.

[ChrisHooker]

Keep it simple, no neeed for programming some complicated automated test.

mul_vs_div (2).osm

(108.72 KiB) Downloaded 1101 times

Rounding errors are virtually nullified at a factor of 1,2,4,8,16,32,64...
(And the same applies to the reverse below 1: 0.5,0.25,0.125...)


I really want to make sure that people just getting into this are not mislead. In this thread first it's "discovered" and agreed upon by multiple people that factors UNDER 0.5 are the "most" error-free... then it is ALSO "discovered" that if you multiply by huuuge numbers first, then THAT yields the most error-free results? [Psst! It's all nonsense.]

Aside from that, the graph in this schematic that plots the difference-errors is great, but when you don't normalize it, how big are the errors really? When running this test with any signal, has anyone thought to check how much louder you need to amplify the difference-noise to even make it heard? Therefore do the rounding error differences between multiplication and division even make a difference?

[wlangfor@uoguelph.ca]

I was able to make something at about 3/4's of double precision. I'll post it on the site and Link it up. The only thing is though, it is articulated with a switch and is not as favorable as something without a switch, especially in the application of a co-efficient which is used for most things.

I'll be setting up a section of My site for that sort of thing, with likes and options of donating etc.

I used the same method I tried with the 192000 RBJ schematic, so you can replicate it by using the same method. After some testing, apply that only to the divisor using division. With the tester I made you can set it to any number btw and it has a random seed number so there's no way that the argument of certain numbers and patterns is so substantial, really.

[trogluddite]

I was able to make something at about 3/4's of double precision

The only way to increase precision is to increase the number of bits stored - that is the most basic axiom of information theory. There is simply no such thing as "precision-and-a-half".