Hi Joe,
I noticed that types weren't propagating as well as they could be in
the SIMD matrix code. Turns out making 'scale-matrix4' inline fixed
it. This reduced the runtime of the 3d matrix benchmark from 350ms to
80ms on my Mac Pro.
Then I made (byte-array) open-coded for larger allocation
Well, I've taken a stab at writing some documentation comparing Factor to
Forth. Take a look at this (www.rosycrew.org/FactorVsForth.dvi) and let me
know if this is going in a direction that you think will be useful.
Despite the title, I'm not allowing the book to become a my language can
beat
On Tue, Oct 6, 2009 at 2:50 PM, Hugh Aguilar hugoagui...@rosycrew.com wrote:
Well, I've taken a stab at writing some documentation comparing Factor to
Forth. Take a look at this (www.rosycrew.org/FactorVsForth.dvi) and let me
know if this is going in a direction that you think will be useful.
Hi Hugh,
Here are cleaner versions of your resistors words.
First, the original version:
: par ( R1 R2 -- R ) [ * ] [ + ] 2bi / ; inline
: pars ( seq -- val ) [ ] [ par ] map-reduce ;
The second version that uses the generalized equation:
: pars ( seq -- val ) [ recip ] [ + ] map-reduce recip
Hi Hugh,
Your Factor examples looks too much like Forth. Ideally there would
be no stack shuffling at all:
: par ( r1 r2 -- r ) [ * ] [ + ] 2bi / ;
: pars ( seq -- val ) [ ] [ par ] map-reduce ;
Chris Double's version of pars is also nice.
Doug
On Oct 5, 2009, at 8:50 PM, Hugh Aguilar
I get the impression that Slava’s
knowledge of Forth is mostly theoretical — he has never actually worked as
a Forth programmer and written large programs in Forth — his background
primarily involves working in Lisp (most likely CLOS).
Actually to be honest my knowledge of both Lisp and Forth
