Help with smooth scrolling

@dave1707 - the reason that “a = function()” is the same as “function a()” is that when you create a function you call “a”, the lines of code are stored in memory, and Codea returns a memory address where the function can be found. This address is stored in a. So a doesn’t contain the function itself, just its address (just like we keep phone numbers for our contacts).

So in fact it is accurate to say “a=function()”, because a is getting the address of the new function. When you then run the function with a(), the brackets tell Codea you want to run a function, and it looks at the memory address in “a” to see where the function can be found.

This also explains why you can say “a=print” and then use a instead of the print function, because you aren’t copying the actual function, but its address, which is just a number. So after you do this, both print and a contain the same number, and running either of them will run the same function.

If you didn’t know already, it may surprise you to know that only numbers and strings can actually be stored in variables. Anything more complex, such as tables and vectors, gives you an address where it can be found, and that address (a number) is stored in the variable. This means that when you write a=b, if b is a string or number, then a will be a separate copy of b, but if b is anything else, then a and b will both contain the same memory address, ie they point to the same thing, and any change to a or b will affect the other.

(And if you ever wondered what “pointers” meant in programming jargon, they are just these memory addresses I’ve been talking about).

@Ignatz Thanks for your explanation. I’m familiar with pointers and their addresses. I wish Codea allowed pointers so I could dump memory. I also know that if you do something like print(tab) where tab is a table, you get it’s address. It’s just that I didn’t recognize what Sky was doing. I thought maybe his function mult=function(i) was doing something special and I was just curious.

@Andrew_Stacey You posted the second comment as I was posting the first.

I meant to do >= for the mult function, but forgot and did > instead. And I chose mult as short for multiplier. Sort of as a number version of checking if the value is positive. I used -1 and 1 so I could multiply another number by that, to change positive or negative.

@Igntaz Strings are also pointers. If b is a string then doing a=b creates a new pointer to the same string as b. The point is that in an assignment, lua dereferences the right-hand side before doing the assignment.

@dave1707 Yeah, you could be right. The characterising quality of the sign function is that it satisfies sign(x) x = |x| which doesn’t specify what happens at 0.

@Andrew_Stacey - Codea doesn’t seem to agree that strings are treated as pointers

a="abc"
b=a
b="def"
print(a,b) --prints abc def NOT def def
a="ghi"
print(a,b) --prints ghi def NOT ghi ghi

@ignatz i am not sure to understand what you mean. Strings are definitely managed by their adress, and doing b = a copies the a value (adress of string) in b. Looks like what is called a ‘pointer’ to me?

@Jmv38 - Andrew said that a=b leaves both variables pointing to the same string, which means that a change to one of them will also change the other (since there is only one string).

I just showed that in fact a and b are completely separate strings. It doesn’t matter whether a and b actually store addresses or strings, they are different and that is the point I was making - that strings and numbers actually make new copies, whereas everything else just copies the pointer.

@Ignatz Let’s analyse your code:

a="abc"

This creates a string in memory with value abc (assuming that it doesn’t already exist) and makes the variable a a pointer to it. So we have:

a -> abc

Next:

b=a

In an assignment, the right-hand side is dereferenced so this makes b also a point to the memory location where abc is stored. So we have:

a -> abc
b -> abc

Next:

b="def"

This creates a string in memory with value def and makes the variable b a pointer to it. This overwrites the previous value of b. So we have:

a -> abc
b -> def

Next:

print(a,b) --prints abc def NOT def def

We look up a and find abc. We look up b and find def. So abc def is the correct behaviour here.

a="ghi"

Now we have:

a -> ghi
b -> def

whence:

print(a,b) --prints ghi def NOT ghi ghi

is completely correct.

The point is that once a string is in memory it is never altered. It might be garbage collected, but it can never be changed. All you can do is create a new string and update the pointers. Lua doesn’t do soft references easily. There’s no immediate way to make b a reference to a so that b acts like a pointer specifically to a. That is, b says “Whatever as value is now, use it.” (this is possible in languages like Perl). You could write a little function that made this work, or you could do some metatable magic so that looking up b automatically returned a, but it’s not there by default.

@dave1707 Wikipedia agrees with you that the correct definition of the sign function is to be 0 at 0.

(My functions are either smooth or are considered equivalent if they only disagree on a set of measure 0. Since the sign function is not smooth, it comes in under the second heading and so I don’t care what its value at 0 is since I can declare it to be whatever number[1] I like without changing the equivalence class of the function.)

[1] I can’t declare it to be an elephant, much to my disappointment.

@Andrew_Stacey - the important thing is that you can copy strings via the equal sign. I don’t really care what handstands the compiler is doing behind the scenes. As far as a Codea programmer is concerned, Codea is effectively storing the string in the variable.

And as I understand it, Codea’s behaviour is different to C, where a=b copies the string pointer, so a and b point to a single string, and you have to use strcopy to make a completely separate copy.

Thanks @SkyTheCoder it’s working well now!!

@Ignatz The key difference between lua and C++ is that the bare objects in lua are immutable. So when I construct a string abc then there is nothing that I can do to change it. Every time I attempt to change it then I actually create a whole new string. The same happens with numbers. In fact, numbers make this a bit clearer. In C++, I could do the following (ignore the syntax, I don’t know C++): make a a pointer to 1, assign b = a so that b is also a pointer to the same 1. Then do a++ which replaces the 1 in memory by 2, whence also b points to 2. But in lua, the ++ operator does not exist. I have to do a = a + 1 which is a fresh assignment and breaks the connection between a and b. So a now points to 2 but b is left still pointing to 1.

So a=b really does copy the string/number pointer. But there is absolutely nothing that I can do to change what is located at the memory address that the pointer points to.

You’re right that this generally isn’t necessary to know. It becomes important when dealing with optimisation and memory usage. It can also catch you out if you think that a = a + 1 ought to update the slot that a points to rather than creating a whole new variable, but the syntax ought to protect you against that.

However, if you want to talk about these things in a not-very-precise way then you should make sure that you use not-very-precise language! You invoked the mathematician by making the precise statement: “If you didn’t know already, it may surprise you to know that only numbers and strings can actually be stored in variables.”. And it’s very hard to put the mathematician back in the bottle. (The other way around is easier …)

Lol, I know, Andrew. I’m an actuary, and you may know we are very happy with approximate results. We do use some math, mainly to get our forecasts wrong to more decimals than anyone else…

I understand your explanation, and thanks for taking the time to do it. I will qualify my explanations to say something like “Codea appears to…”.