>>>It would be interesting to try with a classic N(n,d) format as well - these would be automatically converted into doubles as soon as they're used in any calculation. My take these would be slower, as they are stored as an ASCII representation, not binary, but the slowness would be only in the field reading or writing, not the actual in-memory operation.
>>>
>>>Also, another interesting thing to test would be just memory operation, i.e. no cursors, no fields, just variables.
>>>
>>>Sounds like I'm giving you homework, uh? :) The reason is that I don't have the time, really - got to try some other things tonight before hitting the road tomorrow.
>>
>>Dragan, N(n,d) is as slow as F(n,d), so it is at the 6th place.
>
>OK, that's good to know.
>
>>I cannot run my test with variables, as it is very difficult to match the number of operations, as my test invloved a mix o several SUM and CALCULATE commands over a 50.000 record table. Besides, you have to test with the m. and without, both affecting the results.
>
>Actually, I think only a m. type of test would be required, because we want other overhead excluded, to measure only the speed of different numeric types under the same conditions. And if the test wouldn't include any tables, there should be no difference with m. and without it.
>
>Still don't have the time... (actually expecting Fabio to do this :).

Dragan, it is quite difficult to test variables versus fields performance, as loops and assignments are different in most cases. You could build tests which do not use SUM, CALCULATE, REPLACE and all those commands with scopes, but in the real life you use them. The kind of operation and uses for variables and fields are not the same, unless you want to compare ADO recordSets (which I guess are similar to arrays) and VFP tables, but I don't have the time now to build a simple test for them.