>I think my English is not good enough, sorry.

Mine is not better, but I understood your irony. Which, BTW, is not at all necessary. :(

>You are so right there is nothing better than Rushmore and other RAD tools. A programmer must not seek
>a faster way to do a job.

Show me the faster way and I will use it. The examples you gave me didn't convince me. I've run hundreds of tests on all kind of tables and in almost all situations Rushmore is the best way to go. In the same time, I know that it is not a panacea, so, I don't use it where it shouldn't be used. Only that your arguments didn't convince me. That's all and that's it.

And I've done and do tests all the time exactly because I look for faster ways.

>We must think as 1 ms is equal to 0.1 ms, why should I take care of that little
>0.9ms, let me assume that it will be done once. When one tries to make it for 1000 times than it's his/her problem.

I never said 1 ms = 0.1 ms. And don't generalize my conclusions. I commented only the case we were discussing.

Now, for the same particular case we were discussing: the Rushmore decisions and optimizations that are done before a SCAN FOR are extremly fast and you shouldn't worry about them. If the SCAN FOR is included in other loop command, it may matter. But, if the FOR expression is optimizable, the gain due to Rushmore will be much higher then the loss.

And, if it makes any difference to you: Each time I have to right a very heavy process, I do a lot of tests and write several code versions. Obviously, I choose the fastest one.

>We only need to write an application that does the job, speed is not important. Changing CPU is a better
>solution. You are right, so right and made me to see the light. Thanks.

Once again, your irony is not the best way to go. :( Sorry, but if your English is not so good, you can assume the same thing about mine. Maybe you missunderstood me, etc.

When I said that it would be a good idea to reread the docs on Rushmore, I said it because doing it you will see that you gave several arguments that are not good acording to those docs. In other words: if you want to use Rushmore at its real power, you have to respect the docs. If you don't respect them, you can't say Rushmore is not good, and, obviously, your tests will show your code faster than Rushmore optimizable code.

>Cetin
>PS: How a pity Peter Norton doesn't know that he should use division operator instead of shifting.

I have too much respect for Peter Norton to bring his name in this discussion. Nobody said the division is faster than shifting. I only said that a good C compiler should optimize this operation (ie generate the shifting for you whenever this is possible.)

I propose to end this thread here since it doesn't seem to very productive. Anyway, it ends here from my part.

Vlad