Interesting observation about temperature (Read 192 times)

I had once requested that the range check on temperature be removed.  I find it to be of greater value to store temperature + dew point for a better indication of the day's conditions than just temperature alone.  I see that that has been done, but in kind of an interesting way.  For example, I can key in 200 as a temperature and if I view it on the en masse workouts screen it does indeed show up as 200.

But if one displays the individual workout it shows as 127 (obviously an 8 bit field).  So, if one edits that workout, for example to add some comment, and then saves the workout, the original 200 will be lost to be replaced by the 127.  So, it seems that the field is held somewhere as a string (or at least more than 8 bits) in addition to being held as an 8 bit field.  One will need to view the workout on the en masse screen, make a note of the temperature and then re-key in that temperature if one wants to edit the workout without losing the original temperature value if it was greater than 127.

I was just using 200 as an example.  Namely, anything over 127 would overflow an 8 bit signed field.  80F and 50DP would not be unusual in Atlanta.  I'm running the marathon leg of a 140.6 relay on June 29th in Atlantic City.  So, i'll be doing a lot of after work running in the Atlanta area trying to get acclimatized before then.  I've never done well in heat, but am going to have to force myself to get used to it.

I don't quite care about logging that type of stuff or requesting Eric to make modifications to RA to collect this type of data, but I do factor in this math during the summer and complain about it when it whooped me on a workout or a run or when I'm looking at any upcoming run.

I believe that the closer things get to 150 the more noticeable Yuck is.

In the '70's' or '100's', it doesn't matter as much.

But a 90 degree day with 60 dew point is 'yuck'.

This thread or one like it got me to mentally track the 'yuckiness' or a run.

Cheers,

Brian

is time to complain about summer already?

No!

I am so ready for summer!  And I promise not to complain.

 

No!

 

I am so ready for summer!  And I promise not to complain.

I'll complain for both of us. It was too freakin' hot in Athens yesterday. I'm not ready for 80+ degrees.

Let's not loose sight that there is a technical problem here -- a field allows entry of a value which is not properly maintained in the workout information database.  It may be a...uhhh...unusual use case -- but it allows the entry of 200 and should either edit that as invalid entry or store the 200 properly.

Define "problem".  Has anyone ever legitimately needed to enter a temperature of over 127 degrees?  I highly highly doubt it, considering that the highest temperature ever recorded on earth was 134 degrees.  I don't see a technical problem when people try to use a system outside of any reasonable use parameters.

I don't see needing to re-write code to prevent someone from entering an unreasonable temperature, or re-writing code to properly deal with an unreasonable entry, to be real problems in need of spending time on a solution.  But then I am not The Great Smiley.

 

MT has a point here. From a purely programming and data integrity perspective it's a bug. Data should never be unintentionally altered. Whether the data is valid or not it should remain consistent.

 

Oh I get that and I'm borderline IT illiterate.  But the real-life fact remains that the field in question is "Temperature", and the user is trying to use it for an entirely different purpose.  With limited resources, I don't see why to even bother with trying to fix a "bug" that is not a real problem.

This vehicle has a "bug".  Its suspension cannot handle the load packed onto it.  Should the mechanical engineer re-design the vehicle, or should the end user have borrowed a pickup truck?

 

How does this make any sense?  You consider 50 degrees and 50 degree dew point to be similar running conditions to 100 degrees with zero humidity?

 

I'm not sure it makes any sense to request changes based on using a field in a way entirely different from what is intended.

I don't track dew point when the temperature is much below 65 - 70, in a similar fashion to the weather service not tracking wind chill when the temperature is above 50 F.  Yesterday evening the temperature here was 80 with a 56 dew point and I wasn't able to hold MP for the run.

I haven't been able to find the particular temperature + dew point table I was looking for, but  here is a quote from another post:

"Temp+dewpoint of 90-100 is probably ideal, but anything below 130 is pretty much OK to go for the fast time…maybe 120 for longer distances…say 1/2 marathon or above. Between 130-150 will see a gradual slowdown in pace, and if it’s above 150, forget pace altogether and just focus on finishing.

Here’s another poster’s way of looking at it (that the meteorologist agreed with):

Dewpoint <55*F: Go for it!
Dewpoint in the 60s…it’ll be tough for racing, training runs OK
Dewpoint in the low 70s…hard training will be tough
Dewpoint in the upper 70s….anything other than a recovery run will be a struggle
Dewpoint in the 80s…even a recovery run is tough"

This temp + dew point will be ok later in the year, but not so soon after having had to run in cold temperatures.

Also, I wasn't asking Eric to change anything, just noting that entry of a value is allowed which is seemingly retained in the database as entered, but then not displayed the same way when viewed on the individual workout screen.  If I remember correctly, there was a time that the field was edited upon entry so that value higher than 127 couldn't be entered.  If that edit was removed then presumably it was removed for some purpose, like perhaps allowing a larger number to be entered.