> The operation is finished when the progress float reaches 1.0 and isDone is called. If you set allowSceneActivation to false, progress is halted at 0.9 until it is set to true.
So, I needed to have my UI do other stuff until both this and something else was ready. Obvious thing to do would be to check this for "AsyncOperation.progress >= 0.9" and also check the other thing. Right?
Except AsyncOperation.progress is a float, 0.9 is a double and 0.9f < 0.9. Progress is not halted at 0.9. It never reaches 0.9. It's halted at 0.9f! Just a few million ulps short!
Interesting. When I first got started with Unity I found really buggy behavior if you do any kind of physics calculations near world origin (0, 0, 0). It has a weird gravity well effect if you get too near it. I never found a satisfactory explanation for it but maybe this is it.
If you mean built-in Unity physics, then unlikely. All built-in physics stuff (either 3D physics which is PhysX, or 2D physics which is Box2D) are done entirely in C++ code and are unaffected by Mono float<->double shenanigans.
Do you mean fixed point using integers, or actually decimal (base-10)? My gut would be to use fixed-point integers with a power of two in the denominator.
On the other hand, I’m not sure if modern compilers even bother converting division/multiplications by powers of two to shifts these days, so maybe it isn’t worth it…
Fair that relying on decimal is an interesting choice. My gut is that it would help with a lot of reasoning for folks.
This comes up all of the time with stuff like lat/lng values. People are convinced you have to use doubles because of the inaccuracy of floats. Completely skipping over the fact that you could have fixed point accuracy to 6 decimal digits with the same number of bits as a float. You just reduce your max/min value that you can represent. Which, for lat/lng, you are already heavily bounded.
I think it is fair to argue that basic libraries don't support trig on common fixed point sizes. But that is ultimately my lament. Floats are amazing for what they need to do. For what many people need, though, it feels overkill because it is overkill.
This depends entirely on the sizes needed. For a surprising number of things people would use fixed point for, I would be surprised if you couldn't get good speed with surprisingly little effort.
If you don't have to do trig, I'd be surprised if you aren't faster by default, oddly. Indeed, if you are just adding and subtracting, it is just a number. If you are doing multiplication, it is a multiply and shift. So long as you don't try and support massive numbers of different fixed sizes, that shift is almost certainly still cheaper than float hardware. (Indeed, a lot of multiplications wouldn't even need the shift...)
Again, I do not mean this as a criticism of floats. For simulations and for numbers where you do have to support completely arbitrary values, there is a reason floats are a thing.
Only tangentially related. But, I still have not forgiven Unity for the floating point footgun in https://docs.unity3d.com/6000.4/Documentation/ScriptReferenc...
> The operation is finished when the progress float reaches 1.0 and isDone is called. If you set allowSceneActivation to false, progress is halted at 0.9 until it is set to true.
So, I needed to have my UI do other stuff until both this and something else was ready. Obvious thing to do would be to check this for "AsyncOperation.progress >= 0.9" and also check the other thing. Right?
Except AsyncOperation.progress is a float, 0.9 is a double and 0.9f < 0.9. Progress is not halted at 0.9. It never reaches 0.9. It's halted at 0.9f! Just a few million ulps short!
trigger warning, lol
Interesting. When I first got started with Unity I found really buggy behavior if you do any kind of physics calculations near world origin (0, 0, 0). It has a weird gravity well effect if you get too near it. I never found a satisfactory explanation for it but maybe this is it.
If you mean built-in Unity physics, then unlikely. All built-in physics stuff (either 3D physics which is PhysX, or 2D physics which is Box2D) are done entirely in C++ code and are unaffected by Mono float<->double shenanigans.
I wish JavaScript or any open-source Array Language could do Single-precision Floats. It's awesome they were able to show the assembly breakdown.
I wish there was more explicit support for fixed point decimal out there.
Do you mean fixed point using integers, or actually decimal (base-10)? My gut would be to use fixed-point integers with a power of two in the denominator.
On the other hand, I’m not sure if modern compilers even bother converting division/multiplications by powers of two to shifts these days, so maybe it isn’t worth it…
Fair that relying on decimal is an interesting choice. My gut is that it would help with a lot of reasoning for folks.
This comes up all of the time with stuff like lat/lng values. People are convinced you have to use doubles because of the inaccuracy of floats. Completely skipping over the fact that you could have fixed point accuracy to 6 decimal digits with the same number of bits as a float. You just reduce your max/min value that you can represent. Which, for lat/lng, you are already heavily bounded.
I think it is fair to argue that basic libraries don't support trig on common fixed point sizes. But that is ultimately my lament. Floats are amazing for what they need to do. For what many people need, though, it feels overkill because it is overkill.
Speed wise no hardware can do it though.
This depends entirely on the sizes needed. For a surprising number of things people would use fixed point for, I would be surprised if you couldn't get good speed with surprisingly little effort.
I would be surprised if you could get even one third of performance of floats. So why bother?
If you don't have to do trig, I'd be surprised if you aren't faster by default, oddly. Indeed, if you are just adding and subtracting, it is just a number. If you are doing multiplication, it is a multiply and shift. So long as you don't try and support massive numbers of different fixed sizes, that shift is almost certainly still cheaper than float hardware. (Indeed, a lot of multiplications wouldn't even need the shift...)
Again, I do not mean this as a criticism of floats. For simulations and for numbers where you do have to support completely arbitrary values, there is a reason floats are a thing.
What do you mean by Array Language? Would Julia qualify here?
I was thinking like APL, all the open ones are float64 based.