On 6/2/06, Dan Rie <drie@portfoliointelligence.com> wrote:
>
>  John,
> A quick google exploration turned up nothing in the way of a source for
> the python Crusher software, but I did find some comments by Dirk from 2004
> on the python/R issue.  Is there an "open" source analogy to "If a tree
> falls in the forest and no one hears it . . ."?  Anyhow, I would really like
> to see the open part of the package if it is available.
>

I'll have a look for a copy--maybe Dirk still has one, but Crusher was not
ready for prime time. At version 0.0.4 it had not been seriously debugged
and I am sure that there were calc errors that had not been fixed yet. I had
planned for basic usability at 0.1.0, but we didn't get that far. If I can't
find it, I'll post some Python TA indicator code.

There are a couple of SourceForge projects you might want to look at as
well. For example: http://sourceforge.net/projects/ta-lib

I've been using S-Plus and now R for about fifteen years.  In that time I've
> learned how to do almost anything in S/R, but I still believe that some
> things are better done outside the R environment, so I'm kind of curious as
> to why you would even ask if David Kane was volunteering.  If you are really
> anxious to do some conversion from python to R, I'd be quite willing to take
> a run at it, at least in a limited way.
>

1) Because for a long time now I have thought that a TA package for R would
be a really good thing. (Most TA indicators are filters, some of which have
unique and interesting characteristics.)

2) Because I was genuinely curious as to whether he was.

3) Because, upon rare occasion, I have been accused for having a sense of
humor.

By way of background I am currently migrating and extending a production
> system (modeling mutual fund risk) that has been a combination of S-Plus,
> C++, and FoxPro (MS database software) to a python-R mode.  I am still
> puzzling out where the appropriate boundaries should be between the
> two.  For various reasons, including website interactions and some fairly
> intensive iterative procedures,  I do not expect that R will capture the
> full set of tasks even though it probably could.  I don't see much of a
> problem working in a hybrid environment if it works well (and that's already
> implicit in the notion of writing extensions to R in C++).
>

For me it goes like this. I use R as a calculation engine rather than a
programming environment. So any time I have a calc that R seems like a
natural resource for, I use R. That include regressions, t tests, Chi
Square, etc... I've found no need to go to C or C++ as with a decent
computer and a modicum of memory R and Python are fast enough for my needs.

     jab
-- 
John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.

	[[alternative HTML version deleted]]

