It does, but scaling it up like that is going to blow over the 32 bit number limit relatively easily.
At this point, I really have no idea how much precision I really need, so I just threw 10000 out there However, when using doubles to achieve those ratios, the fractional part is actually sometimes quite large, but I think I could round it off to around 3 digits, and that might be more than enough. Even two digits might be good enough.
If you do your scaling in powers of two, the resulting code will run an order of magnitude faster - Prop doesn't do multiply or divide natively, so if you have something that needs to be scaled in an inner loop, use a scale of 64 or 128 instead of 100. It's a marginal change in precision, but a massive change in performance, because now it can be done with a shift instead of calling a divide function.
Years ago, when I started working on several G-Code efforts, I came to the conclusion that it would be so much easier to just use floating point,...
I'm sure I have said this here and on other forums many times but it's worth saying again. Back in 1982 when I was working on a phased array 3-D radar project that could deliver position and altitude of aircraft 250 miles away my project manager said:
"If you think you need floating point to solve the problem then you don't understand the problem. If you really need floating point to solve the problem then you have a new problem that you don't understand"
We did everything in fixed point arithmetic. Worked fine. I can't imagine any 3D printer or CNC machine has a worse problem than our old radar.
It took me some years before I understood the second part of what my old boss told me though.
The second part is where the fun is. Most people don't get that float is just "fixed precision" instead of "fixed range". If you take the number 2^23, as a float, and add 0.5, you don't get 2^23 + 0.5. Hell, 1.0 - 0.1 isn't 0.9 either.
If you're careful with your ranges, you can generally do what you need to with fixed math significantly faster than with float. There are cases, like working with normalized vectors, where the fixed precision is actually useful, particularly when doing things like squaring a small number to compute the length.
If you do your scaling in powers of two, the resulting code will run an order of magnitude faster - Prop doesn't do multiply or divide natively, so if you have something that needs to be scaled in an inner loop, use a scale of 64 or 128 instead of 100. It's a marginal change in precision, but a massive change in performance, because now it can be done with a shift instead of calling a divide function.
I really have no idea whether I will succeed or not, with this endeavor, but I think I can, with a little support, from those with more experience in programming the Propeller and more experience programming in the C language. To me, the issue of success seems to all be a matter of timing and mathematics, and I believe the Propeller is more than equipped to do the job. I will just have to work around obstacles that get in my way. Before my best friend passed away, whenever I would encounter a problem, he would always tell me to adapt and overcome, which I believe is sound advice. Any scaling performed, will be my attempt at adapting
That being said, I have two thoughts pertaining to your comment above. First off, my time is currently very limited and scaling is a new concept for me, because I never have done any scaling, except in drawings or modeling, so for me to start learning and adapting to the process of scaling, will definitely require time, which is currently unavailable to me. It is my hope, that if I can get this all to work, that perhaps someone more knowledgeable, might be willing to go back over it, to optimize it and expand it. So most likely, at this point, I will only use scaling when it is absolutely necessary for me to go forward, as in this instance. Secondly, as to the point of what type of scaling procedure should be used, I believe that both should be used. There will be instances where people and processes will demand the ultimate in precision, and then there will be people and processes where speed will be of the utmost importance. I believe this should become a case of conditional programming. If "precision" is defined, then scale by 100, and if "speed" is defined, then scale by 64 or 128. However, since I haven't learned bit shifting yet, I will currently have to stick with scaling by 10.
Well, if you are going to scale by 10 that means there is some "x * 10" and "x / 10" going on some place. That means multiply and divide operations. That means time wasted.
If you scale by 16 instead that means there is "x * 16" and "x / 16" going on instead. Not much of a difference right?
But in the later case the multiply can be replaced by a shift left by 4 bits. Which is a single instruction. Much time saved. Similarly the divide can be replaced by a shift right by 4 bits. A single instruction. More time saved.
I think you will find that a C compiler will figure this out by itself and use shifts for the * and /.
I guess in Spin you have to write the shift operators yourself instead of the multiply and divide operators.
All in all good speed and precision gains to be had for no conceptual overhead or code complexity. Just use a power of 2 for the scale factor rather than a power of 10.
Comments
At this point, I really have no idea how much precision I really need, so I just threw 10000 out there
Thanks for looking that over and responding.
"If you think you need floating point to solve the problem then you don't understand the problem. If you really need floating point to solve the problem then you have a new problem that you don't understand"
We did everything in fixed point arithmetic. Worked fine. I can't imagine any 3D printer or CNC machine has a worse problem than our old radar.
It took me some years before I understood the second part of what my old boss told me though.
If you're careful with your ranges, you can generally do what you need to with fixed math significantly faster than with float. There are cases, like working with normalized vectors, where the fixed precision is actually useful, particularly when doing things like squaring a small number to compute the length.
I really have no idea whether I will succeed or not, with this endeavor, but I think I can, with a little support, from those with more experience in programming the Propeller and more experience programming in the C language. To me, the issue of success seems to all be a matter of timing and mathematics, and I believe the Propeller is more than equipped to do the job. I will just have to work around obstacles that get in my way. Before my best friend passed away, whenever I would encounter a problem, he would always tell me to adapt and overcome, which I believe is sound advice. Any scaling performed, will be my attempt at adapting
That being said, I have two thoughts pertaining to your comment above. First off, my time is currently very limited and scaling is a new concept for me, because I never have done any scaling, except in drawings or modeling, so for me to start learning and adapting to the process of scaling, will definitely require time, which is currently unavailable to me. It is my hope, that if I can get this all to work, that perhaps someone more knowledgeable, might be willing to go back over it, to optimize it and expand it. So most likely, at this point, I will only use scaling when it is absolutely necessary for me to go forward, as in this instance. Secondly, as to the point of what type of scaling procedure should be used, I believe that both should be used. There will be instances where people and processes will demand the ultimate in precision, and then there will be people and processes where speed will be of the utmost importance. I believe this should become a case of conditional programming. If "precision" is defined, then scale by 100, and if "speed" is defined, then scale by 64 or 128. However, since I haven't learned bit shifting yet, I will currently have to stick with scaling by 10.
As mentioned above, scaling is new to me, so I really need floating point to solve the problem.
Well yeah, I knew that, which is why we are having the "Mothra" discussion in the first place.
If you scale by 16 instead that means there is "x * 16" and "x / 16" going on instead. Not much of a difference right?
But in the later case the multiply can be replaced by a shift left by 4 bits. Which is a single instruction. Much time saved. Similarly the divide can be replaced by a shift right by 4 bits. A single instruction. More time saved.
I think you will find that a C compiler will figure this out by itself and use shifts for the * and /.
I guess in Spin you have to write the shift operators yourself instead of the multiply and divide operators.
All in all good speed and precision gains to be had for no conceptual overhead or code complexity. Just use a power of 2 for the scale factor rather than a power of 10.