[SciPy-user] SciPy Data Analysis Workbench

[Robert VERGNES]

Hello,

I started to write my own Data Anlysis Workbench based on Scipy and wxpython. (I haven't seen one around?)

Is there anybody interested in it and/or to help writing it ? 

Originally I was using the french software 'regressi' for experimental data analysis but I need some equations which are not included in it and I cannot check how exactly regressi is working - it is shareware but not open - so I started my own, based on python (Scipy, Numpy, labpy and wxpython)
 
It is on the verge to be functional ( near a 0.9 version)

The aim is to be able to acquire data from experiments ( text or other) and display it (grid), graph it and apply some ready function such as curve fitting. It has also the possibility to compare several set of data from the same or different experiment and find some parameters and or variations in parameters due to change in initial parameters.

Also with possibility to transfer acquired / calculated data from/to python-shell to play with the data and send the data back right away to the plotting and/or to curve fitting. - just with one click.

It can be applied to signal processing, chemistry or mechanics. It is for people who wants to focus on their data more than on programming...

Let me know if some of you are interested,

I used this mailing list because i did not where to send this information. Sorry if I bothered you.


Best Regards

Robert


Gary Ruben <gruben at bigpond.net.au> a écrit : Edward Loper wrote:


> If you really think that's too line-noise-like, then you could set  
> the default role to be math, so `x=12` would render as math.  But  
> then you'd need to explicitly mark crossreferences, so I doubt that  
> would be a win overall.

I want to highlight the distinction between the class/method-level 
docstrings and modules which are simply a large docstring used to 
implement an example. If we are to follow this model, as FiPy does, then 
I don't think there will be much (any?) LaTeX math in the 
class/method-level docstrings. In fact, I'd argue against LaTeX in these 
docstrings and probably against using matplotlib in the examples in 
these docstrings. It will mostly (only?) be in the module-level 
docstrings, which won't be seen in such environments as ipython. I 
expect they'll only ever appear to users as full html pages or LaTeX 
pages. Ed suggests using docutils directly for these. In FiPy, graphical 
output such as graphs and bitmaps are generated by a plotting package 
and embedded back into the resulting LaTeX. We would like to be able to 
do this for both html and LaTeX. I don't know if docutils supports this.

> [Gary Ruben]
> 
>> Currently epydoc generates far too much
>> information (2371 pages worth when I ran it on the numpy source a few
>> days ago) and seems unable to be easily modified to reduce its output.
> 
> If you can explicitly specify what you'd like included in the output,  
> and how you'd like it formatted, then I can give you an idea of how  
> hard that would be to produce.  You are right that, at the moment,  
> epydoc's output generators are not terribly customizable.  And the  
> latex output isn't as pretty as I'd like.  :)

I think "see also" cross references to other methods are also important.

I think we want a way to just generate the docstrings as html and LaTeX, 
with cross-references as navigational aids. No inheritance information. 
This is because SciPy is currently more of a library of functions 
grouped into modules and the inheritance information is not usually 
important. A user just wants to know what methods and variables/fields 
are available. The endo-generated API docs here:


demonstrate this approach, where the class hierarchy has been separated out.

Gary R.
_______________________________________________
SciPy-user mailing list
SciPy-user at scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-user


 		
---------------------------------
 Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20070117/b89bfb23/attachment.html>