definition/explanation of an unboxed array in c is ...?

[ben]

i was reading this page "Optimizing Machine Learning Programs"
http://hunch.net/?p=290 where in the comments at the bottom regarding
the third point "Avoid Pointer-Based Representations " there is talk of
unboxed arrays.

having done a bit of searching i have now have a rough idea of what
unboxed variables are. generally they seem to be primative variable
types like int and float where the value in question is right there,
not referrenced by a pointer which points to the value in the heap. so
is an unboxed variable one which is local and on the stack? also in c,
so far as arrays go, would an unboxed array be one that is only on the
stack? do unboxed arrays never exist on the heap?

thanks.

[ben]

or is "unboxed" and "unboxed arrays" not really applicable to c ?

[Richard Tobin]

In article <11************ **********@r29g 2000hsg.googleg roups.com>,
<be*@mailinator .comwrote:

>i was reading this page "Optimizing Machine Learning Programs"
http://hunch.net/?p=290 where in the comments at the bottom regarding
the third point "Avoid Pointer-Based Representations " there is talk of
unboxed arrays.

I think you may have misinterpreted this. As far as I can tell,
they're not contrasting "boxed arrays" and "unboxed arrays", but boxed
representations - typed objects, which point to each other - with
arrays.

I take the term "unboxed array-base implementations " to mean "unboxed
(i.e. array-based) implementations ".

I haven't read the article in detail.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Eric Sosman]

be*@mailinator. com wrote:

or is "unboxed" and "unboxed arrays" not really applicable to c ?

"Unboxed" and "boxed" aren't C terms. In some object-
oriented languages, they refer (usually informally) to
simple primitive variables and to full-fledged objects,
respectively. In Java, for example, a `float' variable is
a primitive and a `Float' is an object with a `float' hidden
("boxed") inside it. (Why bother? Because an object is an
instance of a "class," and the class provides "methods" that
code can use without necessarily being fully aware of exactly
what kind of object is at hand. This is said to promote code
reuse; IMHO "promote" is some distance short of "guarantee. ")

C has "objects," but not in the way O-O languages use the
term. C's objects are passive receptacles for values; an O-O
language would probably call them primitives or aggregates of
primitives. In other words, all C variables of all kinds are
"unboxed," and there is no way to "box" them.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[ben]

ok, thanks v. much for the replies.

[Malcolm McLean]

"Eric Sosman" <es*****@ieee-dot-org.invalidwrot e in message

be*@mailinator. com wrote:

>or is "unboxed" and "unboxed arrays" not really applicable to c ?

"Unboxed" and "boxed" aren't C terms. In some object-
oriented languages, they refer (usually informally) to
simple primitive variables and to full-fledged objects,
respectively. In Java, for example, a `float' variable is
a primitive and a `Float' is an object with a `float' hidden
("boxed") inside it. (Why bother? Because an object is an
instance of a "class," and the class provides "methods" that
code can use without necessarily being fully aware of exactly
what kind of object is at hand. This is said to promote code
reuse; IMHO "promote" is some distance short of "guarantee. ")

C has "objects," but not in the way O-O languages use the
term. C's objects are passive receptacles for values; an O-O
language would probably call them primitives or aggregates of
primitives. In other words, all C variables of all kinds are
"unboxed," and there is no way to "box" them.

Though the equivalent would be, for say a list of x, y, z co-ordinantes

float **coords;

as opposed to

float coords[100][3];

A more illuminating example might be a tree.

typedef struct node
{
struct node *left;
struct node *right;
double data;
}
is the obvious way to do it.

However

struct node
{
int right;
int left;
double data.
};

struct tree
{
struct node nodes[100];
/* left and right index into this array */
};

will tend to produce fewer pointer dereferences and execute faster.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Bacarisse]

"Malcolm McLean" <re*******@btin ternet.comwrite s:

"Eric Sosman" <es*****@ieee-dot-org.invalidwrot e in message

>be*@mailinator. com wrote:

>>or is "unboxed" and "unboxed arrays" not really applicable to c ?

"Unboxed" and "boxed" aren't C terms. In some object-
oriented languages, they refer (usually informally) to
simple primitive variables and to full-fledged objects,
respectively .

<snip succinct explanation of boxed and un-boxed types>

Though the equivalent would be, for say a list of x, y, z co-ordinantes

<snip>

A more illuminating example might be a tree.

typedef struct node
{
struct node *left;
struct node *right;
double data;
}
is the obvious way to do it.

However

struct node
{
int right;
int left;
double data.
};

struct tree
{
struct node nodes[100]; /* left and right index into this array */
};

will tend to produce fewer pointer dereferences and execute faster.

....but also represents a different structure. I suspect the OP will
stare at this and be baffled as to how these two represent boxed and
un-boxed versions of some type.

In a boxed type, it is usual to find the same data inside. You could
have illustrated it with a raw array:

float data[100];

vs. a "boxed" version with high-level access operations:

Array *make_array(siz e_t n);
void set(Array *a, size_t elem, float value);
float get(Array *a, size_t elem);
float sum(Array *a);

but even this is rather confusing because everything has to be "done
by hand" in C since there is no native language equivalence of boxing
a type.

--
Ben.