[Gridflow-dev] ping (fwd)
matju at sympatico.ca
Thu Sep 9 03:36:09 EDT 2004
---------- Forwarded message ----------
Date: Thu, 9 Sep 2004 05:57:53 +0200
From: Tom Schouten <doelie at zzz.kotnet.org>
To: Mathieu Bouchard <matju at sympatico.ca>
Subject: Re: [Gridflow-dev] ping (fwd)
> > i ran into a problem modularizing some transpose (interleave) code and
> > this made me realize i need a generic grid interpretation of a raw
> > buffer. this would have the type description:
> > bitgrid/8/320/240/3
> > this describes a 8 bit, planar row encoded image: w=320 h=240 planes=3
> I'm not sure what you mean. Is it like char, or like another
> C array shape?
more like a bit grid, literaly. a grid of bits.
bitgrid/2/10/10 would represent a 2D 10x10 grid of 4-state (2 bit) entities, or
a 2x10x10 grid of bits, depending on the interpretation.
what i need this for, is to host permutation and other map operations that are
really only dependent on the structure, not on the interpretetion.
this is just a type alias. when casted, polymorphic words will change behaviour.
> > the alternative is something like:
> > bitgrid/int/100/100
> > i'd like to keep it a pure bitgrid, and leave the interpretation upstream.
> > this would simplify the code a lot. but it does mean that it might not be
> > enough to catch the full meaning of a gridflow grid.
> GridFlow 0.7 has two 32-bit types (i,f) and two 64-bit types (l,d). How
> would you differentiate between int and float in general? and signed vs
i don't. i don't need generic grids yet, only to implement permutations
and have at least some raw bit representation.
my matrices are floating point, images are fixed point.
> Besides, GridFlow does not use planes at all, ever, unlike, say, Jitter.
what do you mean? the planes are just your outer dimension wrt to memory
layout, no? if that happens to be colour, you have planar data.
> > a short note: i noticed you use loop unrolling macros in grid.h i
> > found out gcc does this very well automaticly,
> Which versions? I thought about moving definitely away from older versions
> of GCC that aren't as smart wrt loop-unrolling, but then, the tools I have
> for compiling on Zaurus/iPaq/NetWinder are still just 2.95. Certainly that
> when I wrote the original version of that code I was still using 2.95
> myself (probably when I was using debian-stable).
gcc 3, but use 3.3.1 or higher.
gcc 3 is really nice, but a lot of the optimization code seems buggy.
More information about the Gridflow-dev