My personal stupid approach is to get rid from float completely, and use only integer/longinteger in any calculation needed.
That doesn't sound stupid, as opposed to write a floating point emulation code, which in the end will still be slow. I think what the .NET runtime does is exactly just that when it detects a processor without floating point support.
Absolutely. That was what I worry about: compiler's emulation (of unsupported floating point by processor) will drops the performance again.
My stupid is in detail: I will just multiply any used decimal number with a constant; eg. 3.14f = 314000i = 3.14 * 100000(constant).
Thats bad idea, isn't it?
Because my approach requires float either, and in turn will (again) require floating-point emulation in process.
----------------
@Nitorami, big thanks. After few minute I found that said:
ftp://ftp.freepascal.org/fpc/docs-pdf/prog.pdfIts very useful to know that compiler options, to get greater control of codes generated by compiler/fpc.
----------------
@Thaddy, I need about an hours to understand your suggestion. Now I know, after reading @avra's articles.
----------------
@avra, god bless you of your kind let us know that great pascal units ( plus quickly updating broken link).
So, @avra, by using AFP/Fix.pas, we only have one chance to decide the range of integer~fraction part per application, right?
I can accept that situation; because usually we are only working in one world at one time.
eg. in geographic (spatial) world, there is needed only few integer range and wider fraction part.
in accounting world, the requirements is wide integer range with few fraction portion.
In bio identification world, I am yet not sure which one is the most needed, due I have spent weeks in result accuration check (high level).
Now I am getting down on it.
Thanks you everybody