That may be part of the problem. I worked in Real Estate for 20+ years, but I don't relate to the OP's problem.
For example, say your client wants a time-share in Hawaii, 2 bedroom, 2 bath., nothing less than 900 sq. ft. In the search for suitable vacation properties, I locate all the time-shares available during the requested period in Hawaii. AND have 2 bedrooms, AND have 2 baths, AND have >= 900 sq. ft. All this, within the alloted budgetary constraints, of course. :-) Now some of the properties will have MORE than 900 sq. ft., but that doesn't eliminate them! Far from it, that's even better, depending on all other factors (condition of the property, location, etc.) Do you think the Realtor's software has to work through a student's knapsack problem to find these properties?? Please, don't make me laugh. I agree that it WOULD BE a knapsack problem, if the data weren't in a database, and thoroughly indexed --- BUT IT IS, and that's where your argument comes a cropper. I code for my own projects - not for yours. Here's an idea of how it could be organized (and this is WAY less than a full database would have, mind you). You have 10,000 properties in your database. You have indicies for: number of bedrooms, baths, sq. ft., rental cost, and since it's Hawaii, the Island it's on, and distance to the nearest public beach. So you have your request for 2 bdrms + 2 baths. you open an index and there's your record id's for all properties with 2 bedrm, + 2 bath. and the sub-table is generated using those record id's (2, 11, 73, 101, say, etc.) A more extensive database, might also be indexed for sq. feet., but let's say our's isn't. Seeing the request for properties with >= 900 sq. feet, the sub-table is automatically sorted by sq. feet, and those with less, are eliminated from the new sub-table. This process is repeated automatically for all other constraints of the query, and shown on-screen for scanning, printing, emailing, etc. I don't see anything closely resembling the classical 0/1 Knapsack problem in this, except, of course, that the property is either IN the list, or OUT of the list - (0/1), never partly in/partly out. <grin> Have you ever worked with Real Estate software?? Any good database software?? When what you know are classical software problems, everything looks like a classical software problem! Wait a bit, and you'll understand the power of indicies and many other database programming tricks, if you go into that field of study or work. Although I'm not a professional database programmer, I can assure you, the good database programmer's are SLY foxes, indeed. They know more little tricks to speed things up than you can shake a stick at. Adak --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to algogeeks@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/algogeeks -~----------~----~----~----~------~----~------~--~---
