Calculator help please

I'm working on calculator as my first script in sl, but I can't quite figure out how to set the users speech as a float variable. Is there any way to do this? Thanks.

You can change a variable's type by putting (<desired type> in front of it. For example, if the variable foo is the string "2.5" make it (float)foo. You can do the opposite too like llOwnerSay((string)answer).

You will probably want some error checking code in there to make sure your user doesn't give garbage input of course.

Might I recommend that you don't have a calculator as your first script in lsl? Unless, of course, it's just a basic RPN calculator...

Trust me, calculator scripts are hard work.

This is a nit, but maybe also a point of clarification, in case some people are confused. I wish people would stop talking about a variable's type when there is not necessarily any variable involved. You can cast the type of a value, not a variable.

The type of a variable stays the same once you declare it E.g. string myString; The type of myString is always string after that. Note that casting applies to any expression, not just expressions containing variables. E.g. (float)(myString + ".123" casts the result of contatenating two string values into a float.

Ideally, see the wiki page:

Typecast

EDIT: Added the wiki page to my post

Typecasting
Typecasting allows us to convert a variable of one type to another.

We can do this in one of two ways:
Explicit Typecasting | Implicit Typecasting


--------------------------------------------------------------------------------


Explicit Typecasting
Explicit typecasting is the process of converting between variable types by casting them in the form: (newtype)variable.

For example, to say an integer:

integer x = 5;
llSay(0, (string)x);

A key is really just a specialized string. Any string can be stored into a key variable, though don't expect it to work in any function that needs a UUID if the key variable contains "Hello". Note that keys can only be explicitly typecast to and from strings. If casting data is needed from any other type to a key, first cast it to a string.

Many functions will not compile if (string)my_key isn't explicitly typecast, while others will accept my_key on its own.
Obviously, a script will not function correctly if it's expecting a key in the form "66864f3c-e095-d9c8-058d-d6575e6ed1b8" and instead gets "hello".

It is important to note that some string values can be interpreted in odd ways when typecasting. One thing that catches a lot of people is an empty string ("" or a blank space (" " both cast to the value 0 when converting from a string to an integer. Many other programming languagues have a NULL value that would be used instead, but LSL does not.


--------------------------------------------------------------------------------


Implicit Typecasting
Implicit typecasts are like explicit typecasts except that the (type) notation is not actually seen; the compiler makes the implicit typecast explicit for you. Implicit typecasting also happens when a value is copied from a list. However, implicit typecasting can lead to unexpected behavior with mathematical operators.

Explicit typecasting is preferred over implicit typecasting, since it is often easier to see what is actually happening during the type conversion. Plus, explicit typecasting is prone to less compiler buggy-ness.

LSL supports two implicit typecasts:

integer to float
string to key

Examples:
float myFloat = 1; // 1 is an integer. 
integer myInt = 3;
myFloat = myInt; // No typecasting needed.

string myString = "foobar";
key myKey = myString; 
// ^^^ No typecasting needed, but bad coding practice (key variables should always contain UUID values).

// Without implicit typecasting, this is necessary:
float myFloat = (float)1; // or float myFloat = 1.0;
integer myInt = 4;
myFloat = (float)myInt;

// With integer -> float conversion, explicit typecasting is unnecessesary since precision is never lost.

Implicit typecasting does not work with lists because lists can hold any type of variable (except lists). If a specific type of variable is desired in a list, it must be explicitly cast or already be of that type. LSL functions (llParticleSystem, llSetPrimitiveParams) that read lists and expect specific types will not implicitly cast the list entries. This is why functions that use lists will fail to compile when passed an integer instead of a float.

Sorry, Zeno, I'm not a programmer. Thanks for clarifying.

Don't feel bad. Even programmers make this frequent mistake. In fact, the LSL wiki has several instances of confusion about variables vs values that I have endeavored to clean up. One is in the page on typecast that Keknehv Psaltery quoted.

This confusion seems related to the confusion between names and the things they name, and between objects and the class of the object. In many cases, people know what you mean anyway. But it always bugs me, sometimes enough for me to speak up about it.

We (developers) often get a bad rap for being nit-picky, a***-retentive, argumentative bastards because we feel the need to clarify things like that.
I just wish people would realise how stupid computers are - my compiler never "knows what I mean anyway".
Maybe they would cut us more slack if they realised how little chance there was of their machines even booting if we weren't

Here is a good group exercise for teaching about how particular computers are (also good for goup building) :

1. Ask group to write down instructions on how to make a peanut butter and jelly sandwich.
2. Have a third party preform the instructions like they were born yesterday.
3. If instructions are not adequate to complete the task have the group revise the instructions.

Your not done the activity till there are atleast 20 instuctions on the paper; humans come with extensive libraries on how things work and can guess at how things should work.

Yes, I also find that peanut butter and jelly slathered all over things is rather goopy

Really, this excercise proves the need for a language in which no ambiguity exists, because everything is governed by rules.