Progress on the swimming waveform analysis front is grinding to a halt as communication between the various team members has become difficult. A combination of time zone differences (12 hours between the 'thought leader' and the 'development team'), recovery from jet lag and unfamiliarity with the code sharing site have all contributed to the situation.
How best to get a grip on things again?
The main issue has been the way development has had to be carried out using a 'rapid prototyping' approach. Essentially get something up and running and review what it looks like then tweak (sometimes TWEAK) then review then tweak again ..... continue ..... until right answer. Which all worked fine when all parties were together in one place. However, now the review and development cycle has become protracted the 'thought leader' is struggling seeing the code run and the 'development team' is wondering what happens next.
If you read the text on this software engineering practice everything works seamlessly and Bob's your aunt you end up with the perfect code (sorry 'app' - fully documented too!). We are attempting to use an approved approach that will keep us out of the hacking arena. However, what its not doing is helping much on progressing around the development cycles or on homing in of the final solution. You could end up going round and round and round and round ...... just another variation please.
What we need is a means of facilitating the capture of emerging requirements and or questions from the 'thought leader' that the 'development team' can then work on and reply to. Done in a simple and visible way so that all parties can immediately understand the level of progress, identify any issues, and know who is in the seat for resolving them. Progress around the cycle can then be maintained - hopefully.
Just need to get everyone using Trello properly now then ..... ;)
All things computing, software engineering and physics related! Now also including retirement stuff.
Friday, 31 August 2012
Saturday, 25 August 2012
Languages suck .... computer ones that is ;)
More a though for the day this one....
I have been both impressed and confused over the last few months by the sheer number of software languages that you appear to need to keep abreast of these days. I am easily into double figures on the count and I'm not even trying. What is going on?
In the good old days you would get by with BASIC, FORTRAN and possibly C but only if you were a real geek. Oh and then there was JCL (my god - I'd almost forgotten about that). These days the number has ballooned and careers have been made upon the back of the various mutations of operating systems and their associated languages.
In past blogs - as you can read - even the production of a simple package (sorry 'app') to analyse a waveform has required quite a bit of soul searching on which language to use. Surely what is needed is some overarching operating system of languages to act as a master controller - hey maybe nobody has thought of that one!
With the IoT (Internet of Things) emerging what is the best way forward - or are we doomed to even greater mushrooming of languages.
The balloon (or my mind) must pop at some point.....
I have been both impressed and confused over the last few months by the sheer number of software languages that you appear to need to keep abreast of these days. I am easily into double figures on the count and I'm not even trying. What is going on?
In the good old days you would get by with BASIC, FORTRAN and possibly C but only if you were a real geek. Oh and then there was JCL (my god - I'd almost forgotten about that). These days the number has ballooned and careers have been made upon the back of the various mutations of operating systems and their associated languages.
In past blogs - as you can read - even the production of a simple package (sorry 'app') to analyse a waveform has required quite a bit of soul searching on which language to use. Surely what is needed is some overarching operating system of languages to act as a master controller - hey maybe nobody has thought of that one!
With the IoT (Internet of Things) emerging what is the best way forward - or are we doomed to even greater mushrooming of languages.
The balloon (or my mind) must pop at some point.....
Saturday, 18 August 2012
Data presented!
Well not much progress last week as holiday return trip home has got in the way - was a long way back!
There was a little bit of movement though - the week was spent checking the code. I was please to note that even with all the new programming language bell's and whistles we still ended up de-bugging using the good old print statement. Which was actually very simple in Python - unlike my memory of Fortran 'WRITE' statements - though I'm sure all that has changed by now - at least I hope so.
Anyway - here is a print out of 5 right (top) and 5 left (bottom) hand pressure waveforms extracted from the first dataset.
The work going forward is to start to analyse the structure of these to try and come up with an optimum shape that will deliver maximum power for the swimmer. A swimmer can then use this information in real time to make adjustments to their technique.
I don't know much about swimming but this is interesting stuff - the appliance of science!
There was a little bit of movement though - the week was spent checking the code. I was please to note that even with all the new programming language bell's and whistles we still ended up de-bugging using the good old print statement. Which was actually very simple in Python - unlike my memory of Fortran 'WRITE' statements - though I'm sure all that has changed by now - at least I hope so.
Anyway - here is a print out of 5 right (top) and 5 left (bottom) hand pressure waveforms extracted from the first dataset.
The work going forward is to start to analyse the structure of these to try and come up with an optimum shape that will deliver maximum power for the swimmer. A swimmer can then use this information in real time to make adjustments to their technique.
I don't know much about swimming but this is interesting stuff - the appliance of science!
Friday, 10 August 2012
Data extracted!
Well much to my amazement Bambofy has managed to build a code to pull out the swimming pressure data from the hand sensors. Not that I doubted he could do it, just that I didn't think Python was appropriate for doing this extraction. Just goes to show - old dog's and new tricks can happen.
My view of Python - from looking over the shoulder - is it seems pretty flexible for string manipulation, good for object coding, simple to produce plots (we would still be loading the plotting library in Fortran - Python variant knocked up in 10mins no lie!) and can add up. Not sure what editor is being used to build the code but it puts out a great psychedelic screen for doing the edits!
Not sure how it will get on with the next phase which will involve a bit more complex mathematics - we will see......
Friday, 3 August 2012
Data extraction!
Not by me - Prof Jefferies has appointed Bambofy to help sort out the analysis of the swimming data.
First up is the data extraction so that we can pick out the waveforms associated with each hand. Given the way the data is stored even doing that is turning out to be a bit of a trauma. This is being done using Python code - so that's the end of me - PJ was going to do this in Fortran (same code era as me you see) but we have been overruled.
The monkey is now on Bambofy's back to split the waveforms into left and right hand sets - then the fun starts.....
First up is the data extraction so that we can pick out the waveforms associated with each hand. Given the way the data is stored even doing that is turning out to be a bit of a trauma. This is being done using Python code - so that's the end of me - PJ was going to do this in Fortran (same code era as me you see) but we have been overruled.
The monkey is now on Bambofy's back to split the waveforms into left and right hand sets - then the fun starts.....
Sunday, 29 July 2012
Holiday computing!
All a bit sporadic for the next few weeks while holidaying takes precedence.
Think may have a new application for Robfit fittery - nothing to do with gamma rays this time but swimming related!
The essence of the fitting is based around analysis of swimmer force profiles which have been measured using 'glove' worn by swimmers. Analysing the waveforms from these gloves is being used to improve swimming technique. A better explanation of the physics behind all this is provided in an article by friends Stuart and Colleen in the Journal of International Society of Swimming Coaching;
Full reference; http://isosc.org/index.php/journal/international-journal-of-swimming-coaching/261-journal-volume-2-issue-2
The Effect of Real-Time Feedback on Swimming Technique (page 41)
"We examine a new approach for accelerating the learning of efficient stroke mechanics: using a flume equipped to deliver multi-perspective live video footage and force analysis data simultaneously to the swimmer and the coach. A preliminary study of the effectiveness of this approach with a small group of age group swimmers shows gains in ability to generate force of around 20% and to improve swim velocity with only two hours of application."
where you can see the profiles produced by the gloves.
May take few few beers to come up with the optimal way of analysing the waveforms mind...;)
Think may have a new application for Robfit fittery - nothing to do with gamma rays this time but swimming related!
The essence of the fitting is based around analysis of swimmer force profiles which have been measured using 'glove' worn by swimmers. Analysing the waveforms from these gloves is being used to improve swimming technique. A better explanation of the physics behind all this is provided in an article by friends Stuart and Colleen in the Journal of International Society of Swimming Coaching;
Full reference; http://isosc.org/index.php/journal/international-journal-of-swimming-coaching/261-journal-volume-2-issue-2
The Effect of Real-Time Feedback on Swimming Technique (page 41)
"We examine a new approach for accelerating the learning of efficient stroke mechanics: using a flume equipped to deliver multi-perspective live video footage and force analysis data simultaneously to the swimmer and the coach. A preliminary study of the effectiveness of this approach with a small group of age group swimmers shows gains in ability to generate force of around 20% and to improve swim velocity with only two hours of application."
where you can see the profiles produced by the gloves.
May take few few beers to come up with the optimal way of analysing the waveforms mind...;)
Saturday, 21 July 2012
ROBFIT operation.....how it works!
So how does it work - just realised I launched into GitHub loading without setting out how the code operates.
ROBFIT - that's the Fortran code used to find peaks within a complex spectrum, such as a gamma ray spectrum where the code originated. The idea behind the code is that it is designed to find the very smallest peaks (signals) in a spectrum and it does that by employing a ROBust FITing technique.
There are many spectral analysis packages on the market, however, these tend to require the spectrum to be broken into small sections, each of which is then fitted separately. This creates a couple of major problems. One is that if you have a large spectrum then there is substantial user intervention required resulting in fitting taking increased time to complete. Secondly, and more importantly, splitting the background into sections may misrepresent the background continuum. Small details in the spectrum could therefore be missed.
What's the solution?
Use ROBFIT - sorry - but yes do - the code gets round these problems by seperating spectra into two functions: background and foreground. The background contains slowly varying features and the foreground contains high-frequency content (peaks). Accurate separation of these functions allows the code to detect small peaks and decompose multiple-peak structures. ROBFIT iterates on background and foreground fitting to move smaller peaks from the background to the foreground.
A critical feature is that the code fits the background over the entire spectrum as a set of cubic-splines with adjustable knots - a knot being a place where two cubic splines meet. More on this in later post. Fitting over the whole spectrum range allows the background features to be continually fitted with fewer constants, resulting in a more accurate representation than is possible when fitting in small sections.
Two algorithms make operation this possible. The first is a data compression algorithm which uses a robust averaging technique to reduce the contributions to the background from peaks and spurious high points. The second is a minimisation algorithm (SMSQ routine) that minimises chi-square with respect to the constants of the background and foreground. With the background represented as a smoothly varying function, peaks can be identified as regions of the spectra that lie above this background curve - simples!
So now you know.....
ROBFIT - that's the Fortran code used to find peaks within a complex spectrum, such as a gamma ray spectrum where the code originated. The idea behind the code is that it is designed to find the very smallest peaks (signals) in a spectrum and it does that by employing a ROBust FITing technique.
There are many spectral analysis packages on the market, however, these tend to require the spectrum to be broken into small sections, each of which is then fitted separately. This creates a couple of major problems. One is that if you have a large spectrum then there is substantial user intervention required resulting in fitting taking increased time to complete. Secondly, and more importantly, splitting the background into sections may misrepresent the background continuum. Small details in the spectrum could therefore be missed.
What's the solution?
Use ROBFIT - sorry - but yes do - the code gets round these problems by seperating spectra into two functions: background and foreground. The background contains slowly varying features and the foreground contains high-frequency content (peaks). Accurate separation of these functions allows the code to detect small peaks and decompose multiple-peak structures. ROBFIT iterates on background and foreground fitting to move smaller peaks from the background to the foreground.
A critical feature is that the code fits the background over the entire spectrum as a set of cubic-splines with adjustable knots - a knot being a place where two cubic splines meet. More on this in later post. Fitting over the whole spectrum range allows the background features to be continually fitted with fewer constants, resulting in a more accurate representation than is possible when fitting in small sections.
Two algorithms make operation this possible. The first is a data compression algorithm which uses a robust averaging technique to reduce the contributions to the background from peaks and spurious high points. The second is a minimisation algorithm (SMSQ routine) that minimises chi-square with respect to the constants of the background and foreground. With the background represented as a smoothly varying function, peaks can be identified as regions of the spectra that lie above this background curve - simples!
So now you know.....
Subscribe to:
Posts (Atom)