|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
for, this is a complex problem....is sloppy, unwieldy, and out of control. i'm not the most mathematically logical person (i suck at mathematical logic, actually), and my methods tend to be very inefficient. basically what i've got is three columns (more actually, but these three are the important ones) of data with 721 rows laid out as such Date Single1 Single2 the date column ranges from two-days previous from the present time at the first entry to about 1 day later than present at the last entry. single1 and single2 range from -1.0 to +3.0 (if your curious about what the data is, look at http://tidesonline.nos.noaa.gov/data_read.shtml?station_info=8747766+Waveland,+MS ). Date represents a date of observation (in the case of the date being past) or date of prediction (in the case of the date representing the future). Single1 (is present in all 721 entries) represents the value that was predicted for that corresponding date, and Single2 (present only in dates ranging from the first entry to the current time) represents the actual observed value for the corresponding date. what i'm trying to do is use this table of data to make a refined prediction based on how much the predicted value differs from the observed value at the same time. for example, if the predicted value for 10:00 AM this morning was 1.0 and the actual observed value at 10:00 AM is 1.2, and the values in both columns have a rising trend, then i look ahead in the predicted values column (Single1) until i find a value of 1.2 (or greater, and before the trend starts falling), get that time it was predicted to be at 1.2 and calculate the difference in time. for example, suppose it wasn't actually predicted to reach 1.2 until 10:24 AM. in this case, we're 24 minutes ahead of time. of course, it not always that simple, because sometimes the predicted value is ahead of the observed value, sometimes once value is rising while the other is falling, sometimes the data is updated for several hours (usually about every 60-90 minutes, though). now, throw in this: suppose a threshold is set to a value of 1.25. say i'm restricted to commence field operations in a particular area unless the observed value is at least 1.25. (i can set this threshold lower, depending on some factors, so that's adjustable really). ultimately what i'm trying to do is refine the prediction so that i can more accurately see when it will reach the threshold. start to operate at 1.25 and higher, stop operations when it falls back below. i've currently got a UDT with the Date and two Single values that i compare against each, as well as the threshold level. i'm completely willing to trash my logic and take suggestions from you guys. you always seem to have pretty efficient solutions to things like this. lance "Lance" <nu***@business.com> wrote in I'm guessing Single1 is generated by an underlying function. Do you news:#FxuLUTYFHA.3540@TK2MSFTNGP15.phx.gbl: > Single1 (is present in all > 721 entries) represents the value that was predicted for that > corresponding date, have access to it? If so, it might not be a bad idea to reverse engineer the function and solve for time. You can then automatically generate time values for Single2 > for example, suppose it wasn't actually predicted to reach 1.2 until What happens when the observed value is not predicted?> 10:24 AM. in this case, we're 24 minutes ahead of time. Are you after the nearest future occurrence? Or, are you after the nearest occurrence? > UDT with the Date and two Single values that i compare against each, I suggest you do this in a database with queries. You can restrict your > as well as the threshold level. i'm completely willing to trash my > logic and take suggestions from you guys. thresholds and elapsed time values with a WHERE clause. The query can also support BETWEEN, DateDiff, etc. It's probably the cleanest and fastest solution. > I'm guessing Single1 is generated by an underlying function. Do you Single1 is on public record, generated by the NOAA and put in the table shown at the link > have access to it? If so, it might not be a bad idea to reverse > engineer the function and solve for time. You can then automatically > generate time values for Single2 in my previous post. it's based on the average observed water level over the past 10 years at a particular time of day. Single2 is the "real time" observation. in actuality, the table on the site is updated every 60-90 minutes, but each update includes observations taken every 6 minutes since the last update. > What happens when the observed value is not predicted? there has never been an occurrence of that in our many months of tracking this data.> Are you after the nearest future occurrence? Or, are you after the > nearest occurrence? > I suggest you do this in a database with queries. You can restrict your if another solution isn't recommended, then i may reluctantly do that. i've always had > thresholds and elapsed time values with a WHERE clause. > > The query can also support BETWEEN, DateDiff, etc. It's probably the > cleanest and fastest solution. trouble with distributing, installing, registering, etc. files a DB program depends on. granted, this is my general lack of knowledge in DB dependencies, but it still causes me frustration. lance Show quoteHide quote "Tim Baur" <trbo20DIS***@ARDyahoo.com> wrote in message news:Xns9661771FC367Etrbo20DISREGARDyahoo@207.46.248.16... > "Lance" <nu***@business.com> wrote in > news:#FxuLUTYFHA.3540@TK2MSFTNGP15.phx.gbl: > >> Single1 (is present in all >> 721 entries) represents the value that was predicted for that >> corresponding date, > > I'm guessing Single1 is generated by an underlying function. Do you > have access to it? If so, it might not be a bad idea to reverse > engineer the function and solve for time. You can then automatically > generate time values for Single2 > >> for example, suppose it wasn't actually predicted to reach 1.2 until >> 10:24 AM. in this case, we're 24 minutes ahead of time. > > What happens when the observed value is not predicted? > Are you after the nearest future occurrence? Or, are you after the > nearest occurrence? > >> UDT with the Date and two Single values that i compare against each, >> as well as the threshold level. i'm completely willing to trash my >> logic and take suggestions from you guys. > > I suggest you do this in a database with queries. You can restrict your > thresholds and elapsed time values with a WHERE clause. > > The query can also support BETWEEN, DateDiff, etc. It's probably the > cleanest and fastest solution. > What you could do (just and idea) is obtain a polinominal regretion from
your data, and once you obtained the formula (based on the time) you could just put the value of the time and calculate. Let me check if I still have that code, but the bad new is if I found I, its writteng in C++. Show quoteHide quote "Lance" <nu***@business.com> escribió en el mensaje news:uJxIrLUYFHA.2348@TK2MSFTNGP14.phx.gbl... >> I'm guessing Single1 is generated by an underlying function. Do you >> have access to it? If so, it might not be a bad idea to reverse >> engineer the function and solve for time. You can then automatically >> generate time values for Single2 > > Single1 is on public record, generated by the NOAA and put in the table > shown at the link in my previous post. it's based on the average observed > water level over the past 10 years at a particular time of day. Single2 > is the "real time" observation. in actuality, the table on the site is > updated every 60-90 minutes, but each update includes observations taken > every 6 minutes since the last update. > >> What happens when the observed value is not predicted? >> Are you after the nearest future occurrence? Or, are you after the >> nearest occurrence? > > there has never been an occurrence of that in our many months of tracking > this data. > >> I suggest you do this in a database with queries. You can restrict your >> thresholds and elapsed time values with a WHERE clause. >> >> The query can also support BETWEEN, DateDiff, etc. It's probably the >> cleanest and fastest solution. > > if another solution isn't recommended, then i may reluctantly do that. > i've always had trouble with distributing, installing, registering, etc. > files a DB program depends on. granted, this is my general lack of > knowledge in DB dependencies, but it still causes me frustration. > > lance > > > "Tim Baur" <trbo20DIS***@ARDyahoo.com> wrote in message > news:Xns9661771FC367Etrbo20DISREGARDyahoo@207.46.248.16... >> "Lance" <nu***@business.com> wrote in >> news:#FxuLUTYFHA.3540@TK2MSFTNGP15.phx.gbl: >> >>> Single1 (is present in all >>> 721 entries) represents the value that was predicted for that >>> corresponding date, >> >> I'm guessing Single1 is generated by an underlying function. Do you >> have access to it? If so, it might not be a bad idea to reverse >> engineer the function and solve for time. You can then automatically >> generate time values for Single2 >> >>> for example, suppose it wasn't actually predicted to reach 1.2 until >>> 10:24 AM. in this case, we're 24 minutes ahead of time. >> >> What happens when the observed value is not predicted? >> Are you after the nearest future occurrence? Or, are you after the >> nearest occurrence? >> >>> UDT with the Date and two Single values that i compare against each, >>> as well as the threshold level. i'm completely willing to trash my >>> logic and take suggestions from you guys. >> >> I suggest you do this in a database with queries. You can restrict your >> thresholds and elapsed time values with a WHERE clause. >> >> The query can also support BETWEEN, DateDiff, etc. It's probably the >> cleanest and fastest solution. >> > > forgive me, i'm not all that up on regression, but isn't it a best-fit theoretical curve
between points? Show quoteHide quote "JLuis Estrada" <freshnk***@hotmail.com> wrote in message news:%237ll7gUYFHA.2756@tk2msftngp13.phx.gbl... > What you could do (just and idea) is obtain a polinominal regretion from your data, > and once you obtained the formula (based on the time) you could just put the value of > the time and calculate. > Let me check if I still have that code, but the bad new is if I found I, its writteng > in C++. > > > "Lance" <nu***@business.com> escribió en el mensaje > news:uJxIrLUYFHA.2348@TK2MSFTNGP14.phx.gbl... >>> I'm guessing Single1 is generated by an underlying function. Do you >>> have access to it? If so, it might not be a bad idea to reverse >>> engineer the function and solve for time. You can then automatically >>> generate time values for Single2 >> >> Single1 is on public record, generated by the NOAA and put in the table shown at the >> link in my previous post. it's based on the average observed water level over the past >> 10 years at a particular time of day. Single2 is the "real time" observation. in >> actuality, the table on the site is updated every 60-90 minutes, but each update >> includes observations taken every 6 minutes since the last update. >> >>> What happens when the observed value is not predicted? >>> Are you after the nearest future occurrence? Or, are you after the >>> nearest occurrence? >> >> there has never been an occurrence of that in our many months of tracking this data. >> >>> I suggest you do this in a database with queries. You can restrict your >>> thresholds and elapsed time values with a WHERE clause. >>> >>> The query can also support BETWEEN, DateDiff, etc. It's probably the >>> cleanest and fastest solution. >> >> if another solution isn't recommended, then i may reluctantly do that. i've always had >> trouble with distributing, installing, registering, etc. files a DB program depends on. >> granted, this is my general lack of knowledge in DB dependencies, but it still causes >> me frustration. >> >> lance >> >> >> "Tim Baur" <trbo20DIS***@ARDyahoo.com> wrote in message >> news:Xns9661771FC367Etrbo20DISREGARDyahoo@207.46.248.16... >>> "Lance" <nu***@business.com> wrote in >>> news:#FxuLUTYFHA.3540@TK2MSFTNGP15.phx.gbl: >>> >>>> Single1 (is present in all >>>> 721 entries) represents the value that was predicted for that >>>> corresponding date, >>> >>> I'm guessing Single1 is generated by an underlying function. Do you >>> have access to it? If so, it might not be a bad idea to reverse >>> engineer the function and solve for time. You can then automatically >>> generate time values for Single2 >>> >>>> for example, suppose it wasn't actually predicted to reach 1.2 until >>>> 10:24 AM. in this case, we're 24 minutes ahead of time. >>> >>> What happens when the observed value is not predicted? >>> Are you after the nearest future occurrence? Or, are you after the >>> nearest occurrence? >>> >>>> UDT with the Date and two Single values that i compare against each, >>>> as well as the threshold level. i'm completely willing to trash my >>>> logic and take suggestions from you guys. >>> >>> I suggest you do this in a database with queries. You can restrict your >>> thresholds and elapsed time values with a WHERE clause. >>> >>> The query can also support BETWEEN, DateDiff, etc. It's probably the >>> cleanest and fastest solution. >>> >> >> > > This might not be extremely helpful to you, but it sounds like you're
working on a Fuzzy Logic algorithm. I once worked at a research institute that owned a membrane press. This press used head to fuse laminates onto particle board. The temperature on it had to be within a very tight range, so they used a Fuzzy Logic thermostat. Most thermostats are nothing more than a simple on/off switch and turn on when the measured temperature is lower than the set temperature. They then turn off when the opposite condition is true. The problem with this typical system is that the heating element needs time to come up to temperature when it's turned on and it needs time to cool when turned off. The thermostat doesn't take this into account. A temperature wave function over time is the result. The FL thermostat "learns" the element's behavior and turns the element on or off *before* the temperature boundary is crossed. This significantly increases the accuracy and sharply cuts the fluctuation. Find the algorithm that does this -- learns from historical data, and I think you'll have your function. Here's a primer: http://www.omega.com/techref/fuzzylogic.html and i thought a LUT would be sufficient....
lance Show quoteHide quote "Tim Baur" <trbo20DIS***@ARDyahoo.com> wrote in message news:Xns966189C9A43Dtrbo20DISREGARDyahoo@207.46.248.16... > This might not be extremely helpful to you, but it sounds like you're > working on a Fuzzy Logic algorithm. I once worked at a research > institute that owned a membrane press. This press used head to fuse > laminates onto particle board. The temperature on it had to be within a > very tight range, so they used a Fuzzy Logic thermostat. > > Most thermostats are nothing more than a simple on/off switch and turn > on when the measured temperature is lower than the set temperature. > They then turn off when the opposite condition is true. > > The problem with this typical system is that the heating element needs > time to come up to temperature when it's turned on and it needs time to > cool when turned off. The thermostat doesn't take this into account. A > temperature wave function over time is the result. > > The FL thermostat "learns" the element's behavior and turns the element > on or off *before* the temperature boundary is crossed. This > significantly increases the accuracy and sharply cuts the fluctuation. > > Find the algorithm that does this -- learns from historical data, and I > think you'll have your function. > > Here's a primer: > http://www.omega.com/techref/fuzzylogic.html > but i'd be willing to bet that the heat up and cool down times was relatively consistent,
though. in the case of the water levels we're observing, there are weather conditions and other factors (i.e, prediction algorithm "errors" by NOAA....i think they reforecast and refine the predictions) that can cause the observed value to differ greatly from the predicted value at that same time. after each update to the table, the program will recalculate a new time at which it's expected to reach the threshold, based on the difference between predicted values and the most recent observed value at that same time. lance Show quoteHide quote "Tim Baur" <trbo20DIS***@ARDyahoo.com> wrote in message news:Xns966189C9A43Dtrbo20DISREGARDyahoo@207.46.248.16... > This might not be extremely helpful to you, but it sounds like you're > working on a Fuzzy Logic algorithm. I once worked at a research > institute that owned a membrane press. This press used head to fuse > laminates onto particle board. The temperature on it had to be within a > very tight range, so they used a Fuzzy Logic thermostat. > > Most thermostats are nothing more than a simple on/off switch and turn > on when the measured temperature is lower than the set temperature. > They then turn off when the opposite condition is true. > > The problem with this typical system is that the heating element needs > time to come up to temperature when it's turned on and it needs time to > cool when turned off. The thermostat doesn't take this into account. A > temperature wave function over time is the result. > > The FL thermostat "learns" the element's behavior and turns the element > on or off *before* the temperature boundary is crossed. This > significantly increases the accuracy and sharply cuts the fluctuation. > > Find the algorithm that does this -- learns from historical data, and I > think you'll have your function. > > Here's a primer: > http://www.omega.com/techref/fuzzylogic.html >
Show quote
Hide quote
"Lance" <nu***@business.com> wrote in I think the point to a Fuzzy Logic thermostat is that it's always learning. news:ew2jiaVYFHA.2948@TK2MSFTNGP10.phx.gbl: > Subject: Re: for, this is a complex problem.... > From: "Lance" <nu***@business.com> > Newsgroups: microsoft.public.vb.general.discussion > > but i'd be willing to bet that the heat up and cool down times was > relatively consistent, though. in the case of the water levels we're > observing, there are weather conditions and other factors (i.e, > prediction algorithm "errors" by NOAA....i think they reforecast and > refine the predictions) that can cause the observed value to differ > greatly from the predicted value at that same time. after each update > to the table, the program will recalculate a new time at which it's > expected to reach the threshold, based on the difference between > predicted values and the most recent observed value at that same time. > > lance Although the building was climate controlled, there are still bound to be more drafts in winter than in summer. Cooler ambient temperatures mean that the element can shut off later and needs to turn on sooner. The thermostat never stops examining the temperature history to calculate the best way to undercut the resulting wave pattern. true. thanks for the link, by the way. gives me something else to think about.
lance Show quoteHide quote "Tim Baur" <trbo20DIS***@ARDyahoo.com> wrote in message news:Xns966194A157FC7trbo20DISREGARDyahoo@207.46.248.16... > "Lance" <nu***@business.com> wrote in > news:ew2jiaVYFHA.2948@TK2MSFTNGP10.phx.gbl: > >> Subject: Re: for, this is a complex problem.... >> From: "Lance" <nu***@business.com> >> Newsgroups: microsoft.public.vb.general.discussion >> >> but i'd be willing to bet that the heat up and cool down times was >> relatively consistent, though. in the case of the water levels we're >> observing, there are weather conditions and other factors (i.e, >> prediction algorithm "errors" by NOAA....i think they reforecast and >> refine the predictions) that can cause the observed value to differ >> greatly from the predicted value at that same time. after each update >> to the table, the program will recalculate a new time at which it's >> expected to reach the threshold, based on the difference between >> predicted values and the most recent observed value at that same time. >> >> lance > > I think the point to a Fuzzy Logic thermostat is that it's always learning. > Although the building was climate controlled, there are still bound to be > more drafts in winter than in summer. Cooler ambient temperatures mean > that the element can shut off later and needs to turn on sooner. The > thermostat never stops examining the temperature history to calculate the > best way to undercut the resulting wave pattern. |
|||||||||||||||||||||||
Other interesting topics