NaN

Hi There

OK I have done a quick scan of the forums and WIKI and could not find what I needed, but appologies if I have over looked something.

What I need as a method to detect if something is a number. I have figures being passed through a LinkMessage and cast to an integer, but if the item being cast is a string for example, the integer ends up as 0.

Is there a way of determining if it is actually a number?

Thank yous!

From the Wiki:



So, the answer is no...

If the message is just a number, in case of getting 0 for the typecasted value, you could doublecheck with «if(message == "0"» to make sure, the value is really zero...

just send them tru with the number variable in link message

Haven't found a need to do this before and don't know if it works accurately but what about putting the message into a list and then using:

http://lslwiki.net/lslwiki/wakka.php?wakka=llGetListEntryType

Duh, hadn't even though of that! I'll give that a go. The llGetListEntryType looks interesting as well.

Thank you guys for the help!

Just played with it and it does work:

list entry = [3942.0];
list type_list = ["Invalid", "Integer", "Float", "String", "Key", "Vector"
, "Rotation"];

default
{
	touch_start(integer total_number)
	{
		integer type = llGetListEntryType(entry, 0);
		llOwnerSay(llList2String(type_list, type));
	}
}

That will say "Float" and if you take out the decimal point it will say "Integer".

So you could make it conditional so that if it returned either 1 or 2 (integer or string) then it would do something or an else, if any other number.

hmmm - I highly doubt that this would work as a message received through llMessageLinked is always a string. Putting this value into a list and then use llGetListEntryType would result in «string».

It is easy to convert any string containing a number into a float or integer. But when it's not a number to conversion will return a «0» value (and not NULL or NaN like in other programming languages). Passing the value through the number value would also require the message converted to a number first which causes the same problem.
So it's as I stated before: when the conversion results in «0» you have to double check if it is really the number «0» that is being passed.

If it's only one value, then it would be something like

if((integer)message == 0 && message == "0")
{
 llSay(0, "we've got a zero");
}
elseif((integer)message == 0 && message != "0")
{
llSay(0, "non numeric value");
}

if «message»*could be an entire string you would use

if((integer)message == 0 && llGetSubStringIndex(message, "0") != -1)
{
 llSay(0, "we've got a zero");
}
elseif(if((integer)message == 0 && llGetSubStringIndex(message, "0") == -1))
{
llSay(0, "non numeric value");
}

In the latter example, the message could be something like

«I have a 0 in my message»

and would still return a valid «0»

Right. I am using that method you suggested there Haruki. Although I didnt know about the llGetListEntryType and will certainly come in handy for something else I am doing.

Thank you

/me dumb as [fill in whatever you feel like]...

of course what Jesse suggested _will_ work. You just have to do this in the prim that actually _sends_ the message, rather than doing it in the prim that _receives_ the message...
(unless, the sending prim receives the value via chat - then it won't work)...

Sorry Jesse

hehe. This part of the script is actually via chat

Yep, you are right Haruki and I can't think of a simple way to strip the " when loading the string to the list.

O well!!! At least it got a few of my brain cells firing on this lazy Sunday afternoon

Well - if you'd strip the doublequotes on loading them into the list, wouldn't this cause an error when loading a string into the list? Are there any doublequotes at all, when you read out a chat-message?

Whatever... lots of good ideas, another happy scripter and brain-cells activated (but - «afternoon»? - I wish it was!!! - if it's still «afternoon» for ya, I guess you must be somewhere on the west-coast...

/me going for a late-night-beer now

(edited for overuse of smileys)