Home |
Search |
Today's Posts |
|
#1
|
|||
|
|||
Horse manure?
"Geir Harris Hedemark" wrote in message ... "Ted Byers" writes: interruptions are not tolerable (at least in most situations I have seen) and no-one interrupts because everyone there knows that any interruption in many procedures will result in the entire effort being scrapped and started over. You must be fond of souffles. Can't say that I've tried them. But there are a geat many things, both in the kitchen and in the wetlab, where an interruption can cause trouble. In the kitchen, one of the common consequences of interruptions is that the item burned. they are of no help with things like Grandma's favourite butter tart recipe, or with my efforts to modify it so that the revised version doesn't put my blood sugar ten times higher than it is supposed to be. And on checking, I I guess you have a problem with the apples themselves, then. Actually, I have to watch almost all fruits because of their sugar content, as well as starchy foods (almost all root crops) because of their starch. Beets are so high in sugar and starch that I can almost never have them, and I love them. Nothing is trictly forbidden, but quantities haveto be vry carefully controlled. diet). She would complain that she didn't know what or how to cook for him because it seemed that no matter what she prepared, someone told her that he couldn't eat it because it was bad for him. It seemed to me that if she had had a product like this, and obtained instructions from her physician regarding what the minimum and maximum daily intake for each nutrient should be given Dad's health, she could rather easily find recipes and construct meal plans that would have met Dad's dietary needs. But in adition to those You are now assuming that we know the full and final truth about nutritional needs. No I don't. I assume only that the measurements that have been taken of nutrient content for a given food are reasonably accurate. It is to be expected that there will be some error in them, though. So we're talking about estimates; not claims that a given number represents "the TRUTH" with respect to the nutrient content in a given food. If you look ten years back in time, it is easy to see how things have progressed. I can't see any reason why todays answers aren't wrong tomorrow. When it gets right down to it, todays answers are wrong today! The existence of error in empirical data is inevitable. But that doesn't mean we don't try to do the best we can with the data presently available. This is why I think most people should eat a varied diet. People who tell you to eat something or other usually have a book to sell. You are quite right. A varied diet is indispensible. This isn't an effort to tell anyone what to eat or not eat. Rather, it is only to provide the best available information about the nutrient content of given foods. It is up to the individual to get advice from his primary health care provider as to what the daily recommended intake ought to be for each nutrient; and I have no doubt that that advice will change through time, but that does not affect how my product would, or could, be used. In fact, I am planning a custom version for the health care industry in which the user can maintain a log of what is eaten, what medication is taken, what kinds of health issues have arisen and when and for how long, &c., so that primary health care providers can have sufficient data to examine how a given patient responds to given foods and medications and combinations thereof. Isn't everyone's? Almost all of the development I have done in recent years has been in C++ and very object oriented. I do do some structured and C++ went out of style around here in the early 1990s. Come to think of it, it never really took off. Awful language, by the way. It feels like C with a huge great big roof rack on top where are the objects are kept, making the whole thing waddle through corners. That is debatable. I don't mind C either. Like all languages, there are nasty synactic corners, but overall, it is the most useful language I have studied, with Perl being a close second. Java, I find the object model in VB seriously broken and the Java runtime a major performance problem (but Java is a very interesting language - it just doesn't have much utility in the kinds of programming I do). Performance problem? Strange. I can't see more than a 10 or 20% degradation over using vanilla C. CPUs are inexpensive. Out-of-control pointer bugs are not. That depends very much on what you're doing. The bulk of my work has involved intensive number crunching and simulation modelling. Between the overhead of the runtime and the programming idioms supported, I have personally observed improvement in performance, WRT a JAVA version of a product, of a factor of well over 100: simulations that took several hours in the Java version ran to completion in seconds when I reimplemented the program in C++. One of the big factors proved to be supported idioms; idioms that could be used trivially easily that would have been quite painful to adapt to Java. Yes, I know both Java and C++ are Turing complete, so anything that can be done in one can be done in the other in theory, but that sidesteps the important issue practicability. If I were developing a distributed database application, the runtime overhead would probably not be an issue for a network or website that doesn't see enormous amounts of traffic. If a given application has out of control pointer bugs, that speaks directly to the competence of the team that developed it; not the utility of being able to use pointers. I wouldn't use Java for low-level OS stuff. For a recipe database, I think it is a good match. That may be because I use Java every day. That is quite possible. Please note I am NOT saying that Java is a bad language; only that it isn't appropriate for most of the development I do. As a point of fact, I am looking at a new database development that will likely use Java applets for client side processing and PHP+SQL for server side processing, along with some server side development using either C++ or fortran (for the number crunching requirements). This project is, in fact, a database that will include a substantial amount of orchid data (along with comparable data for all other plants as well as animals). Are you familiar with SQL? If so, how would an XML database provide an advantage over combining SQL with C++ and perhaps COM/DCOM? I can see how The query bits of SQL is a relational query language. If something can't be expressed in terms of static relations, you are out of luck. The inverse problem also applies - XML is, IMNSHO, truly awful at efficient static relations. OK, so a little multiparadigm analysis will show that for one part of a given development, one would use SQL and XML for a different part of it; given their current strengths and weaknesses. I have no qualms about mixed language development. one can relatively easily find all objects satisfying your search criterion using SQL and C++ and a suitable class inheritance tree (and one of the things making it easy is the availability of the STL in C++ and the power of SQL). How do you propose to do this while at the same time allowing the user to define his own relations? You place some constraints on the top-level nodes ("I want a keywords node around here somewhere if it exists") the rest is left as a user-defined application space. This really isn't an onerous problem. It just takes careful design; something I have plenty of experience with. Some of my more successful applications not oly supported but required theuser to establish relationships for themselves. A careful analysis of what is required (along with the features of, and idioms supported by, C++ ;-) would show how simple this really is. In this case, the static relations would be maintained using SQL, and the dynamic ones by C++. I haven't done the analysis required to know if what is to be done here using C++ could in principle be supported by SQL with a suitable abstraction. I sincerely hope you are not telling me you want to create tables for every node the user may want to dream up on the fly. That would be maintenance hell. Nope! Not a chance! But tables are not the only tool in the toolbox. Many people split things. The topmost information is kept in relational tables, the rest is put into blobs or object databases as XML or something else that may be adapted by the user. The very act that some relational information might be stored in blobs or object databases suggests a possible approach to using a mixture of C++ and SQL to obtain the functionality you require. These issues are faced in the interaction between orchid growers and taxonomists all the time when the latter decide to cause us trouble by changing how species are classified. Relationships are changed, and so hard coding such information is problematic. I have an advantage in this because of the importance of numerical taxonomy in my background. But there are ways around dynamic relationships, even if one is using the mix of languages I intend to use in my next database project. Cheers, Ted |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Horse manure again | United Kingdom | |||
San Jose/Santa Clara County horse manure for composter. | Edible Gardening | |||
Aged Horse Manure Avail for the taking | Edible Gardening | |||
Horse or Cattle manure??? | Gardening | |||
Horse Manure When can it be used | United Kingdom |