>Ed,
>
>>>I agree this is probably the best way, but I think it could have a performance penalty because now you have to deal with more than 1 table.
>>>
>>
>>ROFL! Compared to an IIF() and an INLIST() per line (hey, might as well ridicule my own code for being dumb!)? I can make an index? Rushmore still does bitmap matching? I am gonna have a tiny list of values...I am going to laught for hours, because the .003 seconds that
might get saved on execution, comes back the first time I have to maintain this piece of code by 100,000 fold. In fact, more like 1*10^(pick a large number), I'm never going to have to touch this code, even if the multipliers change...
>>
>>Think for a billionth of a second about this. Apply neurochemical energy to the problem. You've gotta be kidding!!!!!!! Solve it once and never touch it again sounds right to me.
>
>As I said, I completely agree with you. But one of your arguments was performance. I don't think the differance in performance would be significant. Instead I said that the inlist could be actually be faster, depending on the situation.
>
>If the list is larger than a few item (we can't determine this by the data that is provided in this case) and isn't indexed the INLIST variant *could* be faster. Furthermore, the lookuptable could be wider than just one or two fields so the table size could be significant larger than you've suggested.
No, we determine this by the fact the INLIST() smokes on item 25...
>
>This said, I can imagine (though this would be very exceptional) that from a performance point of view the INLIST *could* be better.
>
Walter, you've completely missed the point here. The cost of maintaining the INLIST(), counting the number of args, fixing it when it breaks, changing the code again when the positive and negative numbers have to be the other way negate even an amazingly exceptional performance difference, simply because the performance gain would be completely negligible compared to NO TIME TO MAINTAIN THIS CODE!!!!! A whole minute gained in 3/1000 of a second intervals is completely insignificant compared to maintaining the code!!!!
Performance in this case is a totally fallacious argument. Look at the taks. Assume a 3 minute difference running this a few million times. The odds are if the list changed say, once every 50,000 iterations, and I had to visit the code, and screwed up typing in the change to the list 1% of the time (too much coffee, too little sleep, a cow flew by and jostled my elbow. There was an earthquake! A TERRIBLE FLOOD! IT WASN'T MY FAULT!!!!) probably the corrections and recompiles ate every bit of the time saved. And J Random Clerk updated the list, not yours truly, so it wasn't my fault after all!!!!!!
I've seen this in threads with you and JimB, who knows this concept absolutely dead cold to rights. None of this crap you're working on or I'm working on will be measurably improved by spending measurable time creebing code to gain 4 CPU cycles per run. It will be measurably improved, as will the sanity of the next guy picking up the code to MAKE THE CODE CLEAN, CLEAR, MAINTAINABLE AND COMPREHENSIBLE. This is why you and I will never agree on our approaches to how to code. You want to xBASE it up, be smarter than the tool, show off how much you know before it happens. I like SQL - it's concise, it's clear, it's maintainable, and in the event that the data is smarter than I am, letting the data engine find the best path to solving the problem based on its knowledge of the state of the data from experience and heuristics rather than my guessed behavior is going to beat the crap out of my programmatic solve based on faulty assumptions. And when it gets too big for VFP I don't have to rethink the whole problem.
I don't want to lovingly relive the ulcers caused by the code of my past if I can help it.
