Re: Good math/stats libraries for Ruby?

[Note: parts of this message were removed to make it a legal post.]



My problem with this solution and
also with SciPy / PDL is their monolithic structure which have
complicated dependencies and/or maintenance woes. Coming up with a
lighter-weight alternative isn't a small task. So it's not worth
doing unless it's done right, and doing it right will take a good deal
of time.

I'm not sure of the best overall scheme for structuring dependencies
between the libraries. I think gems could help. Few of the
current ruby math libraries are gems. There should not be any
external dependencies and the licensing should be simple and flexible.

Also, for these kind of libraries source control ought to be chosen
to encourage outside contribution. I don't think I'd personally want
to belong to every math project in the world, but I might
occasionally contribute a feature or bug fix. It's much better if
changes can be submitted via distributed version control rather than
manually merged uncontrolled text via email.


On 25 nov. 08, at 19:39, Cameron McBride wrote:
I certainly do *not* think Python is "today's FORTRAN" (sidenote:
there are a lot of fun comparisons in there beyond the scope of Joe's
suggestion), Python is better than that. ;) I've found my solutions
in ruby to be quite sufficient, although I'll concede they are not as
comprehensive with repect to SciPy and/or PDL (perl!). There appears
to be more focus on the latter two from the US science community (at
least in astrophysics, which is what I'm most familiar with).

I agree with that. I don't mean to say that Python is crummy like
FORTRAN or that either of the two are crummy*. Python is a very
good language as well as one of the more interesting ones. But there
are lots of reasons to choose between different languages and
language implementations and with increasing frequency I find Ruby
and its various implementations to be really good choices for many
things. It doesn't seem like basic scientific and math libraries
should be one of the reasons not to choose Ruby. Yet sometimes I
feel pressured to use Python instead because of the libraries rather
than because it makes the most sense for a particular project. So it
feels to me very much like back in the day when there was pressure to
write in FORTRAN whenever science or math was involved.


*As soon as somebody makes a web framework for FORTRAN I'm sure it
will make a huge comeback. Just look at the success that COBOL ON
COGS has had.

joe
.

Relevant Pages

  • Re: how to build a MacOS universal python package including external dependencies
    ... I have developed a set python libraries that provide several scientific ... I am sure that all the dependencies (qt4, pyqt4, ... download, compile and install everything. ...
    (comp.lang.python)
  • Re: ANN: PyGUI 2.0.5
    ... means less bloat and less dependencies. ... Chances are you ... already have the necessary libraries installed. ... in some other language and translate into Python. ...
    (comp.lang.python)
  • Re: Pythons garbage collection was Re: Python reliability
    ... >>> Has anyone looked into using a real GC for python? ... A strategy based on PURE reference counting just ... > extensions, and with correct implementations, both refcounting and GC are ... > Lucky those existing C libraries were written to use python's refcounting! ...
    (comp.lang.python)
  • Re: Python component model
    ... other libraries. ... application domains like Scientific Python. ... dearth of Web frameworks as a benefit, I think you'd see less activity ... near-blessing of Django: it's almost nonsensical. ...
    (comp.lang.python)
  • Re: Why Lisp is not popular with average programmers
    ... are multiple implementations of Common Lisp, the "fragmentation" of which you speak can simply not exist in in Common Lisp ... ... the implementations differ on these. ... But, there are compatibility libraries that you can use rather than your implementation's primitives, and have your code portable across implementations. ... Python seems horribly "fragmented" as well. ...
    (comp.lang.lisp)