string llFloat2Sci(float imput)

I've recently had the problem that i wanted to pass floats in scientific notation. So consequently i wrote a function to do that; upon compleation i relized it would have percion problem; tests showed that 1/6 random floats lost percion. So i rewrote the script and it now evaluates 1 float every 3 seconds which is SLOW. Now i know every good programing language has a way of typecasting your numbers into scientific notation; so can LSL be one of them?

string llFloat2Sci(float imput)

why? because it can be done better by the server then by my silly script.

Haha

Strife, would it be possible to post the two functions you used to try to accomplish this? Floating point manipulation like this.... I dunno if a totally new ll function is necessary.

What strategies are you using to do this now?
==Chris

Even better, let's have an sprintf-type function llFormat2String(), taking either a variable number of arguments or else a single list argument, or prefereably two functions to cater for both argument styles.

Then you'd get your scientific notation output pretty much for free alongside all the other standard printf-type formatting. Google for "printf" if you're not familiar with this normal C output facility.

Personally, I could make good use of the hex output that this would give us, and also the fieldwidth specifiers.

ehh it was 6 am and i hadn't gone to bed

here is the code i wrote. The FloatToSciBad has a 1/6 chance on a random float to not equal the number you put in (a!=(float)FloatToSciBad(a)) but the other version solves that problem (by using a float and an integer resuliting in 55 bits of accuracy) but is SLOW ranging from 1->5 seconds depending on the number.

string FloatToSciBad(float a)
{
    if(a==0) return "0";
    float tf=(float)a;
    integer ti=4;
    if (llFabs(tf)<1)
        ti+=llFloor(llLog10(llFabs(1/tf)));
    else
        ti+=-llFloor(llLog10(llFabs(tf)));
        a=llPow(4,ti);
    return (string)((tf*a*a)*               //this call has no percion loss
                llPow(.625,llFloor(ti)))    //this call does have percion loss.
            +"E"+
            llDeleteSubString("+ ",(ti<0),-1)+
            (string)(-ti);
}

string FloatToSci(float tf)
{
    if(tf==0.0) return "0.0";//without this zero hangs.
    
    //whats the bit shift?
    integer ti = -llFloor(llLog10(llFabs(tf)) / 0.301030009); 
    tf*=llPow(2,ti);
    
    //time to tweak the bit shift some...
    integer ttt=24;
    float tff=tf*llPow(2,ttt);
    while(tff+1.0==tff || 0==(1&(integer)tff))
        tff=tf*llPow(2,--ttt);

    integer tfi=(integer)tff;
    ti+=ttt;
    ttt=0;

    tff=0;
    //time to apply the bit shift |tf|<1
    while(ttt<ti)
    {
        if((5*tfi)/5==tfi)
        {
            tfi=tfi*5+(integer)(tff*=5.0);
            tff-=(float)((integer)tff);
            ++ttt;
        }
        else
        {
            tff=(tff + tfi%2)*0.5;
            tfi=tfi/2;
            --ti;
        }
    }

    //time to apply the bit shift |tf|>1
    while(ttt>ti)
    {
        if((1073741824&tfi)*2 == (tfi&-2147483648))
        {
            tfi=tfi*2+(integer)(tff*=2.0);
            tff-=(float)((integer)tff);
            ++ti;
        }
        else
        {
            tff=(tff + tfi%5)*0.2;
            tfi=tfi/5;
            --ttt;
        }
    }

    return (string)tfi+
//            llGetSubString((string)tff,-7,-4)+"E"+
            ".0E"+
            llDeleteSubString("+ ",(ti<=0),-1)+
            (string)(-ti);
}

I wrote a "printf()" a while back. It only implemented a small subset of the formatting specs, was dog-slow, and took up most of the 16k of scripting space.

Ouch. Yes, I can well imagine, Carnildo. My own noddy hex output routine is dreadfully slow too.

In contrast, it would cost LL virtually nothing to expose sprintf directly from the system library. All they'd need to do is put some protective filtering around parts that might be unsafe -- eg. ("%c", 0) conversion might mess up their garbage collection for strings, depending how they've implemented that, and they might not want non-printing characters to appear at all, to protect newbies. And they might want some arbitrary restrictions on runaway '*' fieldwidths too I guess.

It's really not much work to do that, yet it would terminate all feature requests relating to output conversion.

To go with all the nice fieldwidth handling though, I'd want a function to give me the width of a string in the proportional font that they use for chat. I was brought up on nicely lined up output. ))

converting to and from hex should be pretty fast.

string int2hex(integer a)
{
    string b="";
    integer c;
    for(c=8;c && a;c--)
    {
        b=llGetSubString("0123456789ABCDEF",15&a,15&a)+b;
        a=a>>4;
    }
    return "0x"+b;
}

integer string2int(string a)
{
    a=(string)llParseString2List(a,[" "],[]);
    integer b=llStringLength(a) - 8;
    if (b>=2 && llSubStringIndex(a,"0x")==0)
    {
        integer c=llSubStringIndex("89ABCDEF",llGetSubString(a,2,2));
        if(c+1)
            return -2147483648 + (integer)llInsertString(
                llDeleteSubString(a,b,b), b,
                llGetSubString("01234567",c,c));
    }
    return (integer)a;
}

string2int is a wrapper for converting strings to integers. It handles negative integers. Haven't tested for overflow consistency with converting hex to integers.