|
|
|
|
 |
pongkai
 |
|
|
I don't understand the graphs, what is the vertical axis? eg http://asia.vtec.net/Reviews/CityPerf/sixty.jpg
|
Wong KN
|
|
The vertical axis is just arbitrary. It's not supposed to mean anything. What you want to see is the x-axis which is the time needed to do 0-60mph. I actually experimented with putting all the data-points in 1 straight line. But I discovered when I do that, we can't see separate data points when we have more than 1 run with similar times. E.g. if I have two runs of 10.9 seconds, then such a chart will only 1 point because the two points are on top of each other. So what I did was to stagger their vertical locations slightly so that in this way, two data points of the same timing will now be plotted with 1 slightly above the other and we can clearly see we have 2 runs with the same timing.
Hopefully this explanation is clear. So the main thing is we want to see how the 10 data points are distributed in the chart. For the case of this City, we can clearly see the 0-60mph times are quite evenly distributed from ~10.8 to 11.0 seconds but the 2 runs above 11.0seconds are somehow 'isolated' from the 'main pack. This clearly shows the fact that I had slightly bad launches when I did this 2 runs. Also that I was generally able to get quite consistently good launches because all the other data points are below 11 seconds. So if I were to commit on a single value for a representative 0-60mph time for the City, I would probably saying ~10.8 seconds which by coincidence is also what the averaged value from all the 10 run is.
But take the case of the 60-0 mph braking distance. Now for this chart, if I were to 'eye-ball' the results, I would say that the 3 datapoints for around 148 and 150feet are for slightly 'blotched runs' and if I were to commit on a single value for this test, I would say probably slightly below 145feet, maybe 144 feet. But note that the averaged value for all 10 runs is 146feet. Looking again at the chart in total, I would also say it will show accurately that while I was able to generally get the braking done well, better tyres are probably going to give me more consistent and better results, i.e. it's quite possible to 'over-brake' the City with the result that the ABS cuts in more than absolutely necessary and thus increasing the braking distance.
Of course how much we can interpret from the charts depends on the additional notes that I provide and as well as our experience and skills for such things. I would think someone with more training in statistical analysis might probably be able to infer a lot more than I can. The main thing is presenting the results in such a way allows the readers to analyze it themselves, instead of me forcing a single average value 'down their throats' (so to speak).
|
Culicine
|
|
Hi Wong, if you have enough runs it may be better to present the data as a histogram - the x axis would be the grouping of your times 10.1-10.2, 10.2-10.3, etc. and the y-axis is the frequency (how many runs were in each group. That gets rid of the problem of the arbitrary y axis. Also you could just present the raw data, with the mean and standard dev. or st. error. But I think most people would understand your graphs anyway:)
Paul
|
Wong KN
|
|
I have considered a histogram or a distribution graph too but the problem is a histogram forces me to 'compartmentalize' the data into neat groups of a fixed interval, e.g. 10.5-10.6, 10.6-10.7, etc. This artificially reduces the accuracy of the runs so three runs of slightly different times, say 10.62, 10.65, and 10.69 will all be reduced into a single time of 10.6. In the graph I use, these three will be clearly different.
I have also considered presenting the data using normal statistical methods, mean, median, standard deviation, even 90th, 80th precentile and thing. But the problem with this is firstly that not everyone will have enough training in statistics to understand or appreciate what the values mean & imply. I'll be honest that I myself won't be able to see a good picture between 10.5s mean with 0.2 std deviation and 10.5s mean with 0.5s std deviation. But the biggest problem is trying to use pure statistics to dissect the run data will quickly become cumbersome, and presenting it even becomes very wordy.
In the end the saying 'a picture paints a thousand words' really is a wise one after all. Don't forget people have access to the whole raw data and they can make their own inference from it. Different people often have different standards and to some the 2 'blotched runs' of >11s in the 0-60mph runs are important facts while to others, they are happy to just ignore them. Just different personalities !
|
|
|
| |
|
| Thread Page - [1] |
| |
|
![[home]](http://sohc.vtec.net/elem04/home.gif){kind=small}
![[rumors and news]](http://sohc.vtec.net/elem04/rumors.gif){kind=small}
![[model release matrix]](http://sohc.vtec.net/elem04/newmodelreleasematrix.gif){kind=small}
![[dealer network]](http://sohc.vtec.net/elem04/dealernet.gif){kind=small}
![[desktop calendar]](http://sohc.vtec.net/elem04/calendar.gif){kind=small}
![[exhaust notes]](http://sohc.vtec.net/elem04/exhaust.gif){kind=small}
![[tov forums]](http://sohc.vtec.net/elem04/forums.gif){kind=small}
![[links]](http://sohc.vtec.net/elem04/links.gif){kind=small}
![[search]](http://sohc.vtec.net/elem04/search.gif){kind=small}
![[sponsors]](http://sohc.vtec.net/elem04/sponsors.gif){kind=small}
![[garage]](http://sohc.vtec.net/elem04/garage.gif){kind=small}
![[login]](http://sohc.vtec.net/elem04/login.gif){kind=small}
