On 31/03/2012, at 2:33 PM, Michael Maul wrote:

> Octave, is a an ugly language. But for wrangling matrices wow, it is awesome. 
> It is like Perl for matrices.(don't rag on me about Perl either for  
> wrangling text there is nothing that comes close. Perl's problem is it was 
> taken way out of it's domain).

What can Perl do Felix can't?

BTW: serious question. Felix should be better than Perl
at text handling.We have much better data structures and
user defined grammar.

One thing Felix can't do quite as well at the moment:

        var a = "hello";
        println$ q"xxx$(a)xxx";

This works, Perl calls it interpolation. But only variables are allowed,
not expressions. This is a technical difficulty with the parser.
Basically the $(...) expression is an .. well its an expression but the
problem is .. expression isn't defined yet, so there's no way to parse
the expression.

It can probably be done NOW, since I have factored the literals
out of the hard coded grammar, by opening the expression
grammar first, THEN defining interpolation. Tricky,
since it may need recursive parsing (and Dypgen just isn't
set up to allow that). Strange .. Ocaml SUCKS at recursion.
Which is weird for a functional programming language.

Also Felix can't do back-references in regular expressions,
but these were always broken. In fact PCRE is badly broken.
Nice idea, but implemented by someone with no theory.
We have the theory now, both TRE and Google RE do
substring extraction properly (Perl never did).
And they do it fast .. much faster than PCRE.

Sure, we don't have all the convenient syntax of Perl,
but that's simply because we didn't put it in :)

I've been looking at:

        x =~ y

which is trivial to implement, though it doesn't seem that
useful. Regular expressions in matches seem more
important.

Of course, Felix has vastly superior hashes to Perl:
Judy arrays are thousands of times faster than anything
Perl ever had: again, we just don't have nice syntax yet.

There is one other thing Perl had. CPAN. A massive library.

>  You can write some seriously mind bending stuff in octave (especially where 
> vectorization is concerned).
> That is also part of the problem with it too, I would absolutely hate to have 
> to maintain a complex app in octave. But for prototyping and exploratory 
> prograining within it's problem domain there is no second. (Well actually 
> Matlab might be a first, but octave is a matlab clone)

Yeah, there is. There's something two orders of magnitude superior though 
without
any visualisation: Barry Jays FISh. I worked on it. It's array polyadic which 
means
you can write code independent of matrix rank.

Oh yeah, did I mention *statically typed* and *faster than Fortran*?

Of course Jay's Pattern Calculus subsumes that (and just about
everything else).

> 
> Anyways regarding OSX octave here are some links that the class provided for 
> an OSX dmg and X which might : X11-2.6.3.dmg (Leopard) or XQuartz-2.6.3.dmg 
> (Snow Leopard).: octave-3.4.0-i386.dmg

I tried the ones on the GNU site, and there were patches to get
gnuplot running but it never worked. There's a point where you just have
to give up.

>  If you get octave working I'll have to send you some of the image 
> recognition assignments we did in the Machine Learning class based on  Yann 
> LeCun's work. It gives a very good accounting of what can be done with 
> octave. Speaking of Yann LeCun I wish we could meld Lush's matrix/vector 
> library to felix. Actually I think lush was meant to be a lispy octave.

I would love to do a binding to LaPack, with Atlas as the kernel it should fly.

As above, matrices .. or more generally tensors .. can be modelled much better
than most of the dynamically typed libraries around: we just need a stronger
type system. But dynamic typing is better than no code :)

Actually there's some pretty good C++ matrix libraries,
using expression templates. Also C++ numeric class supports
parallelism already (with gcc, probably not clang though).

The problem with libraries (like LaPack, which I already have a binding
for somewhere) is that they're gross because they're for C so there's
no polymorphism. Quite some work to add that back in.

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to