gmane.comp.multimedia.packet-forth

Latest darcs URL?

Thomas Sivertsen — 2008-01-20T20:23:35

Hello Giving it another go. :-) So, what is the current darcs URL for PF? Many thanks in advance. -thomas

Re: [brood] trac down?

marloes — 2007-12-07T15:41:41

oops wrong list :) marloes wrote:

Re: [brood] trac down?

marloes — 2007-12-07T15:39:18

pic18f1320 perhaps you need to reload a couple of times, the site looks fine from here! grtz marloes krgn wrote:

Re: 2d matrices, bitgrids, images?

Mathieu Bouchard — 2007-11-12T16:20:52

If I use bit operations only, I can also use 8 or 16 or 32 of them in the same word, and I get that same speedup. Jumping around seemed like a killer slowdown, which is why I asked. I don't quite believe that bit-serial is very appropriate here. It could be if you didn't allocate 4 buffers (you do, right?) but there are also other ways to get there. If you have your bits interleaved, you can use GridFlow's progressively-parallel adder, which adds 64 variables of 1 bit into one variable of 64 bits (in which 57 bits are always zero, of course): static inline uint64 weight(uint64 x) {uint64 k; k=0x5555555555555555ULL; x = (x&k) + ((x>> 1)&k); k=0x3333333333333333ULL; x = (x&k) + ((x>> 2)&k); k=0x0f0f0f0f0f0f0f0fULL; x = (x&k) + ((x>> 4)&k); k=0x00ff00ff00ff00ffULL; x = (x&k) + ((x>> 8)&k); k=0x0000ffff0000ffffULL; x = (x&k) + ((x>>16)&k); k=0x00000000ffffffffULL; x = (x&k) + ((x>>32)&k); return x; } ... which can be readily adapted to 8 or 16 or 32 or 128 bits. And btw GridFlow

Re: 2d matrices, bitgrids, images?

Tom Schouten — 2007-11-04T23:33:21

> > the VM computes 32 cells in bit-parallel. read is the only thing > > that's complicated by this, the rest is a straightforward minimal > > forth VM with only logic ops, and an 'optimized' 4 bit counter. > > How fast is this? We should really benchmark SCAF vs GridFlow... it's pretty fast. a factor 32 is hard to ignore :) but the previous version (in PDP) was much faster. it used 64 bit (mmx) words and had native code. the SCAF in PF looses a lot by constantly jumping around, i think it's about an order of magnitude even. so i do wonder if the use of bit ops in 'read' really makes any difference in the current implementation. > but actually, I'd only interested if SCAF wasn't just about logic > ops. it's really just about 2D binary celluar automata, for which logic is quite appropriate. i don't see a point taking this approach for general operations. extending it for >2 state CA's might be interesting though. > Besides, I don't know how you expect to implement > game-of-life with that.

Re: 2d matrices, bitgrids, images?

Mathieu Bouchard — 2007-11-04T17:38:49

Wouldn't "Line-by-line" count as a "no"? I'd think of it as very ordinary... Ok. GridFlow does this too, but only when the sizes are actually powers of two, and it uses multiplication in other cases. I haven't checked whether I could use the classic shortcuts for some other common sizes, such as 320 like this: lea ebx,[ebx+ebx*4] shl ebx,6 But I'm not sure whether it's any faster nowadays. I should probably spend more time working on multiplication/addition combos to reduce memory access (I don't use a VM, I use precompiled loops for every operation, which would be better when cache<->register transfer times are neglectible, but they are not) How fast is this? We should really benchmark SCAF vs GridFlow... but actually, I'd only interested if SCAF wasn't just about logic ops. Besides, I don't know how you expect to implement game-of-life with that... a lookup-table? (eek) So, actually, I'm interested in comparing a-version-of-SCAF-that-does-a-wide-range-of-ops and GridFlow's NumOps sy

Re: 2d matrices, bitgrids, images?

Tom Schouten — 2007-11-01T22:37:26

> > > note that CA grid dimensions can only be a power of 2, and to convert > > an image into a grid do this: > > Do you have a very special reason for this limitation, such as a recursive > quadrants memory layout (perhaps using the Hilbert curve) ? yes, but it's a bit more modest than that. the way it works now doesn't need any special encoding to keep the cache happy: everything goes line-by-line: access patterns are predictable, except on the corner cases. > Else that > requirement could easily be removed, yes? the reason is the way the VM for scaf is implemented. i'm using simple bit ops to compute the pointers. so if you give up one of 'simple and efficient', the constraint could be removed. the only thing to change would be "read:" in http://zwizwa.goto10.org/darcs/packetforth/plugins/scaf/scaf.c the VM computes 32 cells in bit-parallel. read is the only thing that's complicated by this, the rest is a straightforward minimal forth VM with only logic ops, and an 'optimized' 4 bit coun

Re: 2d matrices, bitgrids, images?

Mathieu Bouchard — 2007-11-01T20:45:01

this is also the same as [#] in GridFlow. The mapping, I mean. To use neighbours you have to use [#convolve] instead (but if you use *lots* of neighbours at once you are better off with [#fft]). In GridFlow you can compute one pass of game-of-life using only two objects, [#convolve] then [#]. However, GridFlow has no uint1 type, only uint8, int16, int32, float32, and optionally some more, but the byte is the base unit. Do you have a very special reason for this limitation, such as a recursive quadrants memory layout (perhaps using the Hilbert curve) ? Else that requirement could easily be removed, yes? _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PF-list mailing list PF-list-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org http://lists.goto10.org/cgi-bin/mailman/listinfo/pf-list

no pixel access..

Tom Schouten — 2007-11-01T19:02:05

> > The only other graphics language I know is Processing, which is very heavily > steeped in x,y pixel coords for everything, so I am sure my question reeks > of this kind of thinking :) > indeed... and i take this as an opportunity to rant a bit. one of the ideas behind PF (actually PDP) has been to do everything with high level 'mapped' or 'folded' operators. http://www.cse.unsw.edu.au/~en1000/haskell/hof.html ( there are probably better articles.. anyone ? ) on a pragmatic level, higher order functions (hofs, or iterators/visitors in OO speak) allow you abstract the process of looping over a data structure. in some cases, hofs can be really inefficient if the thing you're doing inside the loops is a simple operation, and the data structure is big. for most programs this inefficiency is really not a problem: writing clean code (getting a program to work at all, not taking too long to write it) is usually more important than to make it do the wrong thing.. but fast. except for DSP... ther

2d matrices, bitgrids, images?

Tom Schouten — 2007-11-01T18:41:36

hi kevin, > I am interested in doing some 2d matrix manipulation to generate images > based on incoming data. In ca.pf I can see that something like this has to > be going on, but I don't have any understanding of the scaf stuff so I am > missing the part where it sets the points of the bitgrid according to the > rules. scaf is a bit of an odd duck. but the basic idea is that you write a program for how a single pixel behaves, and the system takes care of 'mapping' (iterating) this over the data structure, which is a 2d matrix of cells. so with scaf, you can only set LOCAL behaviour, which is what a Cellular Automaton (CA) is all about. important to note: the code you write inbetween 'scaf-begin' and 'scaf-end' is not PF! it is an entirely different language, which only shares Forth syntax with PF. it is machine code for a 1-bit stack machine that can see the state of its neighbour cells using the word 'read', and can move from one neighbour to another using 'left', 'right', 'up' and 'down'. it ca

2d matrices, bitgrids, images?

Kevin McCoy — 2007-11-01T04:24:36

_______________________________________________ PF-list mailing list PF-list-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org http://lists.goto10.org/cgi-bin/mailman/listinfo/pf-list

new darcs url

2007-08-20T12:56:56

hello, the read-only PF darcs archive has moved to http://darcs.goto10.org/packetforth groet, tom

Re: which libpf?

Charles Turner — 2007-07-19T10:55:51

marloes-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org wrote on 7/19/07 at 5:18 AM Hi Marloes- Many thanks. JK pushed me on the PacketForth rename, and I realized I had not seen the "PacketForth" directory under "PacketForth-Montevideo". Are you still working on/with d_u_w? I was reading a paper by Alvy Ray Smith on graph grammars and thought of your Piksel video from last year... groeten en cheers! Charles public.gmane.org>

Re: which libpf?

2007-07-19T09:18:14

Hey! http://zwizwa.goto10.org/darcs/packetforth/ that is the one! the others are forked because of projects relying on no more changes ;) Greetings! marloes

which libpf?

Charles Turner — 2007-07-17T21:23:59

Hey all- Went to pull libpf and found I had three choices: metabiosis pre-thread-removal fork point montevideo Which one do I want? groeten, Charles public.gmane.org>

mouse.

Mathieu Bouchard — 2007-07-06T03:55:11

after much experiments on cat-themed stack-oriented programming languages, there ought to be mention of this language: http://en.wikipedia.org/wiki/Mouse_%28programming_language%29 (Note that, back in 1980, the computer mouse input device was still virtually unknown, despite having been invented as early as 1963.) _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PF-list mailing list PF-list-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org http://lists.goto10.org/cgi-bin/mailman/listinfo/pf-list

test

Mathieu Bouchard — 2007-06-30T00:08:08

test! _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PF-list mailing list PF-list-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org http://lists.goto10.org/cgi-bin/mailman/listinfo/pf-list

Re: [OT] Re: concat

Mathieu Bouchard — 2007-05-30T05:10:39

Agreed. I think that the spirit of (a+b)-b=a is respected by floats, even if not exactly. I have been developing of unexact algebraic structures for PureUnity. I have defined the invertor of operator f with anti-operator g as being g(f(a,b),b), so that if f=+ and g=- then the invertor is (a+b)-b. Then, in the context of an operator on elements of a set, there is a certain expectation of performance... loosely speaking, we want the result of the invertor to be small relative to a certain norm. This is how we can judge of the quality of a certain g in the role of opposing f, and how we can judge the invertibility of f. I've written more about it in PureUnity, but some questions are not resolved yet, so I haven't implemented everything. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PF-list mailing list PF-list-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org http://lists.goto1

64 bit

Tom Schouten — 2007-05-16T09:05:28

yesterday i've changed some int/void* casts that could give problems on 64bit systems. i don't have a machine here to test, but this could solve the ppc64 problem.

Re: concat

Mathieu Bouchard — 2007-05-10T03:21:29

inversibility requires that each element has an inverse. it is necessary that backspace and delete become elements in some way for that to be true, so that "a"+backspace+"b"="b" can be as valid as "a"+(backspace+"b") than as ("a"+backspace)+"b" (associativity). Then from the moment that backspace is an element, it has to have an inverse, so that if you have x+backspace+thatinverse=x, thatinverse doesn't depend on the value of x. (that might actually be already implied by associativity and simpler invertibility of the form backspace+antibackspace="") I don't understand why string:+ would become xor and not addition. Addition and xor are only the same if you consider each word as a vector of independent bits that work as mod 2 arithmetic. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PF-list mailing list PF-list-hk8Gx6dT9hkdnm+yROfE0A< at >public.gmane.org http://lists.go

Re: concat

Tom Schouten — 2007-05-09T22:55:37

what about backspace and delete? yes. since lists of numbers are used to build matrices (them being a sort of 'compiled' version of lists of numbers), it makes sense to have '+' do addition. indeed, then string's + for concat has to go for general consistency. probably string:+ will just become xor.