Velocity Reviews > Perl > Mathematical Abstraction corresponding to References

# Mathematical Abstraction corresponding to References

poopdeville@gmail.com
Guest
Posts: n/a

 10-11-2005
Hi everybody,

I'm a mathematician who's trying to learn Perl. My knowledge has been
steadily growing, even though I don't have a computer science
background. I rely on my familiarity with the mathematical
abstractions of computation (such as Turing machines and recursive
functions) to figure out the "essential" semantics of code.

I want to understand references, but I've gone through the relevant
chapter in "Programming Perl" and have just gone cross-eyed. Can
someone point (heh) me to a good resource? Preferably one that relates
the pointer/references paradigm to a mathematical abstraction of
computation.

It seems almost as if you comp.sci guys are making distinctions about
variables we math guys don't. Something along the lines of "x" is the
name of the variable x, whose value is (currently) a fixed constant.
If this is the right idea, how is this useful in a computational
context?

Thanks!
'cid 'ooh

Paul Lalli
Guest
Posts: n/a

 10-11-2005
(E-Mail Removed) wrote:
> I'm a mathematician who's trying to learn Perl. My knowledge has been
> steadily growing, even though I don't have a computer science
> background. I rely on my familiarity with the mathematical
> abstractions of computation (such as Turing machines and recursive
> functions) to figure out the "essential" semantics of code.
>
> I want to understand references, but I've gone through the relevant
> chapter in "Programming Perl" and have just gone cross-eyed. Can
> someone point (heh) me to a good resource?

perldoc perlreftut
perldoc perlref
perldoc perlrefref

> Preferably one that relates
> the pointer/references paradigm to a mathematical abstraction of
> computation.

Pointers are not a concept that have much meaning in Perl. Perhaps you
are thinking of C?

I have no idea what this statement actually means, not being a
mathematician.

> It seems almost as if you comp.sci guys are making distinctions about
> variables we math guys don't. Something along the lines of "x" is the
> name of the variable x, whose value is (currently) a fixed constant.

x can be the name of the variable \$x, which can have a current value,
of say, 42. You can then have another variable \$ref which can have a
current value of a reference to \$x. \$ref and \$x are therefore
inextricably linked. Any change you make to the value of \$x would be
reflected in the de-referencing of \$ref.

my \$x = 42;
my \$ref = \\$x;
\$x = 35;
print "Dereferenced ref: \$\$ref\n";
#The above prints 35;

> If this is the right idea, how is this useful in a computational
> context?

Again, I don't know what this means.

Paul Lalli

A. Sinan Unur
Guest
Posts: n/a

 10-11-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote in
news:(E-Mail Removed) oups.com:

> I'm a mathematician who's trying to learn Perl. My knowledge has been
> steadily growing, even though I don't have a computer science
> background. I rely on my familiarity with the mathematical
> abstractions of computation (such as Turing machines and recursive
> functions) to figure out the "essential" semantics of code.
>
> I want to understand references, but I've gone through the relevant
> chapter in "Programming Perl" and have just gone cross-eyed. Can
> someone point (heh) me to a good resource? Preferably one that
> relates the pointer/references paradigm to a mathematical abstraction
> of computation.

I am not sure what you are talking about. I regard the use of
'paradigm' and 'mathematical abstraction of computation' as huge red
flags [1] that indicate that somehow, you are not focusing on the
problem at hand.

I lived with a couple of math Ph.D.'s for a while and occasionally
helped them with their C programs. Neither ever started talking about
Turing machines or paradigms when they did not understand something, and
neither had any problems with the concept of a pointer. When they had
specific issues, we debugged programs by actually looking at the code,
and working with it, rather than philosophizing.

It is important to realize that you cannot become a good programmer just
by thinking in the abstract. You need to practice it.

perldoc perlreftut

especially the section "The Solution".

Do some exercises, ask some practical questions when you don't
understand something.

I am not saying this because I cannot discuss Turing machines with you,
but rather because this is the only way you'll learn to program.

Sinan

[1] I am glad you did not mention "thinking outside of the box".
--
A. Sinan Unur <(E-Mail Removed)>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:

poopdeville@gmail.com
Guest
Posts: n/a

 10-11-2005

Paul Lalli wrote:
> (E-Mail Removed) wrote:
> > I'm a mathematician who's trying to learn Perl. My knowledge has been
> > steadily growing, even though I don't have a computer science
> > background. I rely on my familiarity with the mathematical
> > abstractions of computation (such as Turing machines and recursive
> > functions) to figure out the "essential" semantics of code.
> >
> > I want to understand references, but I've gone through the relevant
> > chapter in "Programming Perl" and have just gone cross-eyed. Can
> > someone point (heh) me to a good resource?

>
> perldoc perlreftut
> perldoc perlref
> perldoc perlrefref

Thanks, I'll check them out.

>
>
> > Preferably one that relates
> > the pointer/references paradigm to a mathematical abstraction of
> > computation.

>
> Pointers are not a concept that have much meaning in Perl. Perhaps you
> are thinking of C?
>
> I have no idea what this statement actually means, not being a
> mathematician.
>

Regarding pointers and references, I've seen books/websites/etc (I'm
really tring to avoid using the word "references" here) that say that
references and pointers are just different implementations of the same
underlying idea. I'm looking to understand the underlying idea -- not
just an implementation. For instance, once you understand "procedural
programming," learning how to do procedural programming in Perl and C
is just a matter of figuring out how the languages go about doing it.

> > It seems almost as if you comp.sci guys are making distinctions about
> > variables we math guys don't. Something along the lines of "x" is the
> > name of the variable x, whose value is (currently) a fixed constant.

>
> x can be the name of the variable \$x, which can have a current value,
> of say, 42. You can then have another variable \$ref which can have a
> current value of a reference to \$x. \$ref and \$x are therefore
> inextricably linked. Any change you make to the value of \$x would be
> reflected in the de-referencing of \$ref.
>
> my \$x = 42;
> my \$ref = \\$x;
> \$x = 35;
> print "Dereferenced ref: \$\$ref\n";
> #The above prints 35;

If I understand your example, \$\$ref is a scalar variable whose value is
defined as the value of \$x for all time after \$\$ref is defined. That
is, if \$x changes, \$\$ref changes accordingly. So why introduce \$ref
when

my \$x = 42;
\$x = 35;
print "Dereferenced ref: \$x\n";

outputs the same thing? I realize the example you gave was just to
illustrate what a reference does. I'm just not seeing how a reference
can be useful.

'cid 'ooh

poopdeville@gmail.com
Guest
Posts: n/a

 10-11-2005

A. Sinan Unur wrote:
> (E-Mail Removed) wrote in
> news:(E-Mail Removed) oups.com:
>
> > I'm a mathematician who's trying to learn Perl. My knowledge has been
> > steadily growing, even though I don't have a computer science
> > background. I rely on my familiarity with the mathematical
> > abstractions of computation (such as Turing machines and recursive
> > functions) to figure out the "essential" semantics of code.
> >
> > I want to understand references, but I've gone through the relevant
> > chapter in "Programming Perl" and have just gone cross-eyed. Can
> > someone point (heh) me to a good resource? Preferably one that
> > relates the pointer/references paradigm to a mathematical abstraction
> > of computation.

>
> I am not sure what you are talking about. I regard the use of
> 'paradigm' and 'mathematical abstraction of computation' as huge red
> flags [1] that indicate that somehow, you are not focusing on the
> problem at hand.
>
> I lived with a couple of math Ph.D.'s for a while and occasionally
> helped them with their C programs. Neither ever started talking about
> Turing machines or paradigms when they did not understand something, and
> neither had any problems with the concept of a pointer. When they had
> specific issues, we debugged programs by actually looking at the code,
> and working with it, rather than philosophizing.

This isn't my intention.{1} I've looked at a bunch of code in the CPAN
and see lots of ->'s. I don't understand their semantics, so I'm
trying to relate what they do with what I already know. Since I don't
have a grounding in comp.sci, reading the Camel book is difficult here
since I don't know a lot of the comp.sci jargon (though I know plenty
of related mathematical jargon).

> It is important to realize that you cannot become a good programmer just
> by thinking in the abstract. You need to practice it.
>
>
> perldoc perlreftut
>
> especially the section "The Solution".
>
> Do some exercises, ask some practical questions when you don't
> understand something.

Thank you, I wasn't aware of this resource. From my limited vantage
point, it looks like references are a big jump in abstraction from what
beginner books deal with. I hadn't found a basic introduction to just
what they do.

'cid 'ooh

>
> I am not saying this because I cannot discuss Turing machines with you,
> but rather because this is the only way you'll learn to program.
>
> Sinan
>
>
> [1] I am glad you did not mention "thinking outside of the box".

{1} It's not my fault marketspeak co-opted "paradigm" and
"abstraction." They're actually useful words when you're talking about
ideas and their implementations. My thinking is strictly in-the-box.

Paul Lalli
Guest
Posts: n/a

 10-11-2005
(E-Mail Removed) wrote:
> Regarding pointers and references, I've seen books/websites/etc (I'm
> really tring to avoid using the word "references" here) that say that
> references and pointers are just different implementations of the same
> underlying idea.

I rather disagree with that, but here we're treading on the border of
my knowledge. A pointer is basically an integer memory address. You
can add or subtract values from that value and end up with adjacent (or
nearby) memory location addresses. References, on the other hand refer
to a very specific memory location. You can't get at any other piece
of memory just by manipulating the reference variable.

> > > It seems almost as if you comp.sci guys are making distinctions about
> > > variables we math guys don't. Something along the lines of "x" is the
> > > name of the variable x, whose value is (currently) a fixed constant.

> >

> Paul Lalli wrote:
> > x can be the name of the variable \$x, which can have a current value,
> > of say, 42. You can then have another variable \$ref which can have a
> > current value of a reference to \$x. \$ref and \$x are therefore
> > inextricably linked. Any change you make to the value of \$x would be
> > reflected in the de-referencing of \$ref.
> >
> > my \$x = 42;
> > my \$ref = \\$x;
> > \$x = 35;
> > print "Dereferenced ref: \$\$ref\n";
> > #The above prints 35;

>
> If I understand your example, \$\$ref is a scalar variable

.... no. \$\$ref is not a variable at all. \$ref is a scalar variable,
which holds a reference to \$x. \$\$ref is simply the syntactic means by
which we "dereference" this variable, to get at the the value contained
in the variable that \$ref references.

> whose value is
> defined as the value of \$x for all time after \$\$ref is defined. That
> is, if \$x changes, \$\$ref changes accordingly. So why introduce \$ref
> when
>
> my \$x = 42;
> \$x = 35;
> print "Dereferenced ref: \$x\n";
>
> outputs the same thing? I realize the example you gave was just to
> illustrate what a reference does. I'm just not seeing how a reference
> can be useful.

You're correct - in that simple example, there was no point whatsoever
for \$ref. There are two main areas in which references are useful (or
even vital):

1) multi-dimensional data structures.
Perl has no concept of a "2d array", or "array of arrays". Arrays and
hashes can only hold scalar variables. Therefore, if you want to
simulate a two-dimensional array, you actually create an array which
holds references to more arrays:
my @two_d;
for my \$i (0..5){
my @inner_array = (0..5);
push @two_d, \@inner_array;
}
(The above can be written much more succinctly, but I'm trying to
sacrifice brevity for clarity). This creates a single array - @two_d -
and then loops 6 times. In each iteration of the loop, we create a new
array - @inner_array - and then we store a reference to this new array
in the "outer" array. So now, for example: \$two_d[0], the first
element of @two_d, is a reference to an array of six integers. I can
therefore access, say, the 3rd element of this inner array using:
\$two_d[0][4].

For more on multi-dimensional structures:
perldoc perllol
perldoc perldsc

2) Passing large amounts of data
Say you have a huge hash:
my %big_hash = map ( \$_ => \$_ * 2 } (1..100_000);
(if you're not familiar with the syntax, this simply creates a hash
whose keys are the integers from 1 to 100,000 and whose values are the
even integers from 2 to 200,000).
Now, you want to write a subroutine which accesses and modifies this
data. An initial approach might be:

sub change_something {
my %hash = @_;
\$hash{42} = 'forty-two';
return %hash;
}

%big_hash = change_something(%big_hash);

The problem here is that you've just made three copies of your large
data structure. Three separate instances of all that data had to be
copied, taking up time and space resources in your computer. A better
approach is to store the data once, and have your subroutine just be
given a reference to this data, and modify it:

sub change_something {
my (\$hash_ref) = @_;
\$hash_ref->{42} = 'forty-two';
}

change_something(\%big_hash);

Now we have only ever created one instance of this large data. When we
call change_something, instead of copying all that data, we simply pass
a reference (a single scalar value) to the data. The subroutine gets
that reference, and then directly modifies the data that the reference
references. When the subroutine has completed, the data has been
altered, without making any needless copies.

2b) Passing multiple structures
It directly follows from the above that it is not possible to pass more
than one structure (such as arrays or hashes) into your subroutine and
let your subroutine be able to access the individual elements:

my @foo = (1..10);
my @bar = (11..20);
sums (@foo, @bar);
sub sums {
my @stuff = @_;
#now what? @stuff contains (1..20). No way to know where
#@foo ended and @bar began
}

Instead of passing the actual arrays, we can pass references to those
arrays, so that the sums() subroutine can access the array locations
individually:

my @foo = (1..10);
my @bar = (11..20);
my \$new_array_ref = sums (\@foo, \@bar);
#we can get directly at our new array by dereferencing the above:
my @new_array = @\$new_array_ref;
sub sums {
my (\$arr1, \$arr2) = @_;
my @new_array;
for my \$i (0 .. \$#{\$arr1}){
push @new_array, (\$arr1->[\$i] + \$arr2->[\$i]);
}
return \@new_array;
}

Here, rather than lumping all the elements of both arrays together into
the single @_ array, we were able to obtain the two references, and
then used the two references to access the individual data elements.
When we conclue, we return a reference to the new data, just to avoid
copying the new data structure as well (preferring to allow the calling
code decide if the data needs to be copied).

perldoc perlsub

I hope this rather lengthy post is helpful to you.

Paul Lalli

poopdeville@gmail.com
Guest
Posts: n/a

 10-11-2005

Paul Lalli wrote:
> (E-Mail Removed) wrote:
> > Regarding pointers and references, I've seen books/websites/etc (I'm
> > really tring to avoid using the word "references" here) that say that
> > references and pointers are just different implementations of the same
> > underlying idea.

>
> I rather disagree with that, but here we're treading on the border of
> my knowledge. A pointer is basically an integer memory address. You
> can add or subtract values from that value and end up with adjacent (or
> nearby) memory location addresses. References, on the other hand refer
> to a very specific memory location. You can't get at any other piece
> of memory just by manipulating the reference variable.

I have a little bit of knowledge of C, where I was first exposed to the
term "pointer." You're right in that C pointers are just integer
value stored in it. I was inspired to do some experimentation, so I
wrote up the quicky:

my \$x = 42;
my \$ref = \\$x;
my \$ref_2 = \$ref + 2;

print "\\$ref = \$ref\n";
print "\\$ref_2 = \$ref_2\n";
print "\\$\\$ref = \$\$ref\n";
print "\\$\\$ref_2 = \$\$ref_2\n";

whose output is

\$ref = SCALAR(0x10015644)
\$ref_2 = 268523078
\$\$ref = 42
Use of uninitialized value in concatenation (.) or string at
../experiment line 12.
\$\$ref_2 =

It seems that \$ref is just a memory address, though Perl has some built
in functionality to keep me from jumping around arbitrarily. Indeed,
the code won't compile at all if strict is used. I wonder, however, if
there is a way to write to arbitrary memory addresses. That way I
could define \$\$ref_2 without declaring that \$ref_2 is a reference to
another variable. This is all that is missing from their equivalence.

All in all, it seems to me that C pointers are slightly more general
than Perl references -- or equivalently, that Perl references are more
structured.

>
> I hope this rather lengthy post is helpful to you.
>

Yes, it is definitely helpful. Thank you for taking the time to write
it. Now that I understand what they're for, learning the syntax will
be a peice of motivated cake.

'cid 'ooh

Babacio
Guest
Posts: n/a

 10-11-2005
(E-Mail Removed) writes:

> I want to understand references, but I've gone through the relevant
> chapter in "Programming Perl" and have just gone cross-eyed. Can
> someone point (heh) me to a good resource? Preferably one that relates
> the pointer/references paradigm to a mathematical abstraction of
> computation.

Being a mathematician (well, at least for a few monthes from now,
after that I may be an unemployed ex-mathematician or a math teacher
or whatever), I have sometimes the same kind of preoccupations.

When you'll arive to closures and static variables, it will be even
more funny to try that... in fact, the underlying mathematics of
modern computing languages seems to involves relatively new
concepts. Type theory may be usefull, but it's not enough. Object
oriented programming has something to do with category theory, well,
or at least I have this feeling.

References seem indeed very exotic from a mathematical point of
view... a first idea: one introduces sometimes some redondant notation
in a math text ; references allow to do that, in some sense ; but
that's not exactly true, because you have the original variable, and
its reference, and you need to derefence it before using it as you
would use the original. They are definitvely not of the same
nature. This mathematical habit seems more related to the operator :=
defined by Perl6::Binding.

Moreover, a reference to an anonymous object is something very useful,
but definitively different from the above idea.

In Perl, a reference to a scalar is scalar, that doesn't ease the
problem. In a strongerly typed language, a reference would have a type
like « reference to an integer », which is something you can't write
(as far as I know) in mathematical type theory ! it's linked to the
way a computer works, having a pointer in C is something very natural
when you think of it in a concrete point of view -- and references
seem to me to be very near to pointers, with a greater level of
abstraction.

My conclusion is that there is no widely spread math concept
corresponding to references.

They tell that Lafont's linear logic should ease the understanding of
variable managing, and so one. I have no idea of that, if you have
time to learn linear logic, that may interest you.

--
Bé erre hue ixe eu elle, Bruxelles.

Babacio
Guest
Posts: n/a

 10-11-2005
"Paul Lalli"

> I rather disagree with that, but here we're treading on the border of
> my knowledge. A pointer is basically an integer memory address. You
> can add or subtract values from that value and end up with adjacent (or
> nearby) memory location addresses. References, on the other hand refer
> to a very specific memory location. You can't get at any other piece
> of memory just by manipulating the reference variable.

....that's what I called « a greater abstraction level ». I think you
cannot have pointers in Perl because of the Garbage Collector -- I may
be saying total bullshit here, feel free to curse.

But I think references are the descendants of pointers. They sure have
a better look from the mathematical point of view, that pointers do,
they seem abstract enough to be integrated in an extension of type
theory.

--
Bé erre hue ixe eu elle, Bruxelles.

Babacio
Guest
Posts: n/a

 10-11-2005
poopdeville.

> my \$x = 42;
> my \$ref = \\$x;
> my \$ref_2 = \$ref + 2;
> (...)

> It seems that \$ref is just a memory address, though Perl has some built
> in functionality to keep me from jumping around arbitrarily.

Ay, it's a kind of blaspheme!

You're touching to the way references are *implemented* in perl, not
to what they *are* in Perl. If you speak spanish, that's the
difference between 'estar' and 'ser'!

And here is a quote from the faq, to help understant why I wrote perl
vs Perl above:

Larry now uses "Perl" to signify the language proper and "perl" the
implementation of it, i.e. the current interpreter.

Yes, references are implemented like pointers in perl, but they are
not pointers in Perl.

> All in all, it seems to me that C pointers are slightly more general
> than Perl references -- or equivalently, that Perl references are more
> structured.

Yes, indeed.

--
Bé erre hue ixe eu elle, Bruxelles.