On Sep 12 2006, Robert Leif wrote:
> Hi, Firstly, as a retired Professor of Biomedical Engineering, the most 
> important factor is that human life could be involved in a subsequent 
> version of your program and that you may be creating a medical device, 
> which is regulated by the FDA and whose malfunction could be the source 
> of significant legal liability. 

This seems to me a canard. You could say that about any program ever 
written. From what I can tell, Glenn is simply working on modeling how a 
biological system may work.

> Have you performed a requirements and 
> hazards analyses? I hope that as part of your training that you have read 
> some of Prof. Nancy Leveson (http://sunnyday.mit.edu/) work. Her book, 
> Safeware: System Safety and Computers, is a classic. She has a new book 
> that is available for download on her web site 

I believe Glenn has a plan to simply type away at a keyboard. I don't think 
he has to worry about injuring himself or anyone around him with the 
simulation source code.

> http://sunnyday.mit.edu/book2.pdf. Ada is a wonderful management tool for 
> life critical systems. The cowboys quit; you do not have to fire them. 
> Since you are working at different physical scale levels, you can subtype 
> these and create simple conversion subprograms. You can also do nucleic 
> acids by using representation specs. Unfortunately, no one has created a 
> bounded array type, which would be generic predecessor of a bounded 
> string and an elegant way to represent nucleic acid sequences. 

A bit too cryptic for my taste.

> It is also 
> possible to achieve close to a one to one correspondence between Ada and 
> XML schema datatypes. This will greatly facilitate report generation and 
> data entry. I have published extensively on the use of Ada for medical 
> devices. Many of the papers can be downloaded from 
> http://www.newportinstruments.com/ada_med/ada_med.htm Lastly, in the one 
> commercial case where I have knowledge, the use of Ada permitted the 
> software to be finished prior to the hardware. Yours, Bob Leif
>
>-----Original Message-----
>From: Team Ada: Ada Programming Language Advocacy (83 & 95)
>[mailto:[log in to unmask]] On Behalf Of G. Booker
>Sent: Tuesday, September 12, 2006 10:12 AM
>To: [log in to unmask]
>Subject: Ada for system biology modeling
>
> Hi, I need help proving (or disproving) why Ada is or isn't well suited 
> for a particular application. I've been an Ada fan for over a decade, and 
> I'm faced with a possible application I haven't seen before. I'm a PhD 
> student in biomedical engineering. A major part of my dissertation will 
> involve getting various mathematical models, of how parts of the body 
> work, to interact with each other. The challenge is that the models are 
> working on different physical scale levels (from sub-cellular to the 
> whole body), and on many different time scales (millisecond-duration 
> processes to ones that take months or years). So my question is: Is Ada's 
> concurrency capability well suited to this type of problem? Why or why 
> not? Has it been done before in Ada? TIA for any thoughts, advice, 
> directions to look, etc. Glenn Booker Drexel University

Glenn, This problem requires a discrete event engine which sequences time 
in strict order but can skip over large time gaps. A colleague of mine and 
I have created such an engine that replaces the GNAT run-time. One can 
write regular Ada multi-tasking programs that use conventional constructs 
such as the delay statement and protected types, but when run in discrete 
event mode behaves just like a time-queued scheduler. This means that 
delays that are expressed in days, months, or years can expire next to 
instantaneously. Of course, if many small delays get mixed in with the 
longer delays, those will naturally cause a bottleneck in execution. That 
particular issue crops up in many mixed-time simulations, including EDA 
logic simulators. The usual workaround is to run the high rate parts for 
shorter periods, and the slowly varying parts separately. A related issue 
occurs in solving ODE's where you run into so-called "stiff problems". 
Overall, it is a challenging problem, so good luck and if you want to try 
out the DEGAS discrete event run-time, feel free.

A paper on our work will be presented at SigAda Albuquerque in November. 
Download source code and the paper here:

http://degas.sourceforge.net