1 Zinc Delta of Tranquility = 999,999,998.
Yeah... not sure what's going on there. Definitely weird though. I'll take a look.> ash historical_price($item[zinc delta])
Returned: 0
> ash mall_price($item[zinc delta])
Returned: 0
Well, whatever, but the reason to use ints rather than floats when you are dealing exclusively with integers and doing nothing but addition and multiplication is because that is "good coding" as opposed to "bad coding".because it makes Veracity happier, networth/networthi is merged back to a single networth which uses ints.
buffer pnum( buffer b, int n )
{
buffer pnum_helper( buffer b, int n, int level )
{
if ( n >= 10 )
{
pnum_helper( b, n / 10, level + 1 );
}
b.append( to_string( n % 10 ) );
if ( level > 0 && level % 3 == 0 )
{
b.append( "," );
}
return b;
}
if ( n < 0 )
{
b.append( "-" );
n = -n;
}
return pnum_helper( b, n, 0 );
}
string pnum( int n )
{
buffer b;
return pnum( b, n ).to_string();
}
Using that, it said it averaged the same period of time to run with floats v. ints, though ints had more variance... both faster and slower. You're right though (as you know ), since we're just dealing with positive integers and don't have any decimals, and we shouldn't have anything bigger than a long int, it is better coding practice to stay there. When I changed, I initially briefly forgot that change had been made, and as such (and for people still using the 'stable build' or stuff even older) was thinking that floats would actually allow for full-number accuracy.tracktime ashq int currenttime = gametime_to_int(); try{cli_execute("%%");}finally{ int posttime = gametime_to_int(); print_html("Time: " + (posttime - currenttime));}
tracktime ashq for x from 1 to 10 CLI_EXECUTE(\"call networth.ash\");
<lots of text>
Time: 3158
First result tossed, due to more thinking going on and lookups and the like. Interestingly, as before, floats gave a much more 'standard' result, with all 5 executions staying within 100 of 3400. The 5 executions of the int version varied from 2900-4000. Weird.tracktime ashq for x from 1 to 10 CLI_EXECUTE(\"call networthf.ash\");
<lots of text>
Time: 3418
3 different timings for the same function, which gets called in both scripts, but can make things appear less accurate. That's why I prefer larger, fully-timed comparisons. When possible. My original plan was to run it a thousand times, but I didn't feel like bloating my session log that much, but... fine. Let's do it. A thousand executions of each...10 .000001973 0.000001973 my_meat()
10 .000003552 0.000003552 my_meat()
10 .000001579 0.000001579 my_meat()
tracktime ashq for x from 1 to 1000 CLI_EXECUTE(\"call networth.ash\");
<way more text>
Time: 253869
So yeah... ints faster, taking on average 253.869ms per execution compared to 289.467ms for floats. On my system, at least.tracktime ashq for x from 1 to 1000 CLI_EXECUTE(\"call networthf.ash\");
<way more text>
Time: 289467
have you ever looked at zlib's rnum(int) vs. rnum(float)? I really can't say I like either of them, particularly, from either a readability or an efficiency viewpoint, but considering that the latter calls the former and does a bunch of additional cruft, it's hard to understand why you think floats vs. ints is "a wash".
string rnum(int n) {
return to_string(n,"%,d");
}
string rnum(float n, int place) {
if (place < 1 || to_float(round(n)) == to_float(to_string(n,"%,."+place+"f"))) return rnum(round(n));
return replace_all(create_matcher("0+$", to_string(n,"%,."+place+"f")),"");
}
As far as efficiency goes, if Veracity (or anyone) has suggestions for improving the efficiency of this function while retaining the functionality I'd be very happy to hear them.
string trim_zeros(string myString) {
if(myString.index_of(".") == -1) {
return myString;
}
return replace_first(create_matcher("\\.?0*$", myString), "");
}
string rnum(float n, int place) {
return n.to_string("%,."+place+"f").trim_zeros();
}
to_float(round(n)) == to_float(to_string(n,"%,."+place+"f"))
string rnum(float n, int place) {
if (place < 1) return n.round().to_string("%,d");
return replace_first(create_matcher("\\.?0*$", n.to_string("%,."+place+"f")), "");
}
1 Cheshire Bitten = 999,999,998
1 hippopotamus skirt = 999,999,998
1 flaming juggler's balls = 999,999,998
... Umm... no.
My knowledge of scripting sucks so I can't help out by saying what's gone wrong, but there's no way those are right. Bug or feature?
Still correcting that manually... it's good to know I'm worth 962,501,896.
Fixed in the version attached to 183.1. If you're out of ronin, it double-counted everything in hagnk's. I fixed this with an if statement. (I know I don't have 2 boris's helms.)
Already included in the version attached to 183.A feature I'd like: Something to count the cost of buying all the familiars you have, if you didn't have them yet. That'd put me over 200M net worth, easily (I'm at 130M but have a mimic)
Fixed in the version attached to 183.Already included in the version attached to 183.
I know it's a feature of the original pricegun, but it never made any sense to me. In any case, if you want to track your familiar "worth", you might want to do the same for skills.A feature I'd like: Something to count the cost of buying all the familiars you have, if you didn't have them yet.
I know it's a feature of the original pricegun, but it never made any sense to me. In any case, if you want to track your familiar "worth", you might want to do the same for skills.
tostorage_meat = excise(visit_url("storage.php"),"have "," meat").to_int();
and that fixed it. I haven't uploaded the file since I know a lot of people comment out the familiar stuff and I haven't done that.storage_meat = excise(visit_url("storage.php?which=5"),"You have "," meat").to_int();