[SciPy-user] SciPy Data Analysis Workbench
robert.vergnes at yahoo.fr
Wed Jan 17 07:52:32 CST 2007
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.
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.
SciPy-user mailing list
SciPy-user at scipy.org
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...
More information about the SciPy-user