Arc Forumnew | comments | leaders | submitlogin
2 points by garply 4920 days ago | link | parent

Thanks! I pushed a little bit of progress to lib/statistics.arc. I'd also like my vectors to function like lists.

  (= a (vec 1 2 3))
  type.a => 'vector
  (a 0) => 1
The list index referencing w/o first calling rep seems like it would require hacking ac.scm, right?


2 points by rocketnia 4920 days ago | link

In Anarki, the hacking has already been done. ^_^

  (defcall vector (vec i)
    rep.vec.i)
The original 'defcall post is way back here: http://arclanguage.org/item?id=3743

Since then, it's been redefined in terms of [coerce _ 'fn] and an extensible implementation of 'coerce. http://arclanguage.org/item?id=9828 (Here you go, akkartik!)

Rainbow also supports 'defcall, but in the more direct way rather than through extensible coercion.

-----

1 point by garply 4920 days ago | link

This is great, thanks!

-----

1 point by alimoeeny 4919 days ago | link

Sorry guys, would somebody summarize this discussion on vectors and matrices? I mean after all is there any merit in defining a generic matrix type for everybody to use or people better define their own for their specific job. I am still trying to read the documentation, this is all new for me.

-----

2 points by rocketnia 4919 days ago | link

Well, what is there to summarize, hmm...

Looks like garply is putting together a library which deals with matrices and vectors and wants to be able to say (isa x 'vector). The 'annotate and 'rep functions make that happen. Anarki also defines 'defcall so that new types like these can be given special behavior when used as functions.

In one sense, garply's defining a matrix type for every Anarki user to use. In another sense, it's only a matrix type specific to the purposes of that library. But in any case, if this type doesn't look good to someone, they can just follow the same process to define their own type and forget this one exists at all. :-p

Realistically, I think efficiency is one of the things at the top of people's minds when they're trying to do computation with matrices, and with all due respect to garply, I doubt the project is going to get to the cutting edge of matrix efficiency anytime soon. >.> So I actually do expect someone to decide to define another matrix type later on. Nevertheless, garply's contributions could certainly help that person along. ^_^

-----

1 point by garply 4919 days ago | link

You're absolutely correct. I would go so far as to say that Arc itself is too slow to do any serious matrix computations (maybe if you made this just an interface to some Racket matrix libs you could work around it). I'm really not going to bother thinking about efficiency much at all. What I have done before in Arc is prototyped some algorithms on very small test sets. Once I got those working and figured out what I actually wanted, I rewrote everything in C++ or C, with a very close eye to efficiency.

I used to use this strategy all the time with an R / C combination, but I greatly prefer writing in Arc. Lush is kind of the best of both worlds, except the last time I pulled the bleeding edge version there appeared to be some crippling, hard-to-find bugs. Plus it's nice to just be able to build quick prototypes when you're already in Arc.

-----