| 03-29-2007, 08:20 PM | #1 |
Sometimes you get things done without actually making them... JASS:interface superarray method size takes nothing returns integer method operator[] takes integer index returns integer method operator[]= takes integer index, integer val returns nothing endinterface //! textmacro subarray takes index struct subarray$index$ extends superarray integer array v[1000] method size takes nothing returns integer return this.v.size endmethod method operator[] takes integer i returns integer return this.v[i] endmethod method operator[]= takes integer i, integer val returns nothing set this.v[i] = val endmethod endstruct //! endtextmacro //! runtextmacro subarray("1") //! runtextmacro subarray("2") //! runtextmacro subarray("3") //! runtextmacro subarray("4") //! runtextmacro subarray("5") //! runtextmacro subarray("6") //! runtextmacro subarray("7") //! runtextmacro subarray("8") //! runtextmacro subarray("9") //! runtextmacro subarray("10") function NewSuperArray takes nothing returns integer local integer r=subarray1.create() if (r!=0) then return r endif set r=subarray2.create() if (r!=0) then return r endif set r=subarray3.create() if (r!=0) then return r endif set r=subarray4.create() if (r!=0) then return r endif set r=subarray5.create() if (r!=0) then return r endif set r=subarray6.create() if (r!=0) then return r endif set r=subarray7.create() if (r!=0) then return r endif set r=subarray8.create() if (r!=0) then return r endif set r=subarray9.create() if (r!=0) then return r endif return subarray10.create() endfunction function Trig_Untitled_Trigger_001_Actions takes nothing returns nothing local superarray s=NewSuperArray() local integer i=0 loop exitwhen i==s.size() set s[i]=i set s[i]=s[i]+1 set i=i+1 endloop call BJDebugMsg(": "+I2S(integer(s))) endfunction SuperArray is a dynamic array object, with 1000 of size and max 80 instances!, yes 80000 indexes in very few code, once you get this code using superarray is exactly the same as using normal dynamic arrays. In fact, you could extend it to increase max instances alot. Problem currently is that .create and .destroy have linear complexity O(n) if n is the number of subarray types. In theory, we could exploit this to allow 8190 instances of 1000 indexes each, or 8190000 indexes in total, but create/destroy would need like 1000 iterations to get things done, and if it was in debug mode the screen would fill with messages when instanciating the last one. But right now this can be exploited to get a single, global array with 655200 indexes or even more very easily in exchange of initialization time and little overhead when accessing indexes. |
| 03-29-2007, 09:07 PM | #2 | |
Quote:
PS who will need this ? =) i think allmost no one... |
| 03-29-2007, 10:03 PM | #3 |
well I WOULD use it if it didn't involve extra overhead reading from an array. |
| 03-29-2007, 10:31 PM | #4 | |
Quote:
... The only thing left would be comparing its performance with gamecache, I have my doubts, 2 extra functions call + TriggerEvaluate, who knows? the advantage still over gamecache is no string leaks. |
| 03-29-2007, 10:31 PM | #5 | |||
Quote:
Quote:
Quote:
|
| 03-29-2007, 10:36 PM | #6 |
The real question would be whether it is possible to make this better. Actually, with some theorical compiler able to optimize it all right, all the extra overhead would be a call to TriggerEvaluate() I think that it wouldn't be too slower in comparisson to a normal array. |
| 03-29-2007, 10:54 PM | #7 | |
Quote:
conculsion =) this stuff is not really useful ! btw gamecache may be much better... but if you code correct you almost don't need it... some people want a theoretical max multi instances but they don't need this ! 100 - 200 incstances are some times more than needed ! so the coders must know what they do... PS this text is not really for you ;) (i know what you know this) |
| 03-29-2007, 11:01 PM | #8 |
if TriggerEvaluate is so slow, we could always just use binary search like if then elses and reduce the complexity of accessing indexes to logarithmic, it should be able to beat this speed-wise. Although I can't think of a good application for this yet... |
| 03-29-2007, 11:08 PM | #9 | |
Quote:
|
| 03-29-2007, 11:34 PM | #10 |
well that's 'simple' we only need a program that writes it for us. This is really compiler area cause after I tried I could figure out it is not sane at all to do it manually too much times: JASS:if(t>16) then if(t>24) then if(t>28) then if(t>30) then if(t==32) then set a32=i else set a31=i endif else if(t==30) then set a30=i else set a29=i endif else if(t>26) then if(t==28) then set a28=i else set a27=i endif else if(t==26) then set a26=i else set a25=i endif endif else if(t>20) then if(t>22) then if(t==24) then set a24=i else set a23=i endif else if(t==22) then set a22=i else set a21=i endif else if(t>18) then if(t==20) then set a20=i else set a19=i endif else if(t==18) then set a18=i else set a17=i endif endif endif else if(t>8) then if(t>12) then if(t>14) then if(t==16) then set a16=i else set a15=i endif else if(t==14) then set a14=i else set a13=i endif else if(t>10) then if(t==12) then set a12=i else set a11=i endif else if(t==10) then set a10=i else set a8=i endif endif else if(t>4) then if(t>6) then if(t==8) then set a8=i else set a7=i endif else if(t==6) then set a6=i else set a5=i endif else if(t>2) then if(t==4) then set a4=i else set a3=i endif else if(t==2) then set a2=i else set a1=i endif endif endif endif That one is for 32 variations. with a compiler we could even get to 1024 variations, and since complexity is logarithmic it would require max 10 comparissons, unless there is some if nesting limit... Edit: 117 lines are required for 32 values, if we wanted 1024 then we would really need like 3700 lines counting contents it would be like 21 KB just for one array. but we could have a giant global array of 8387584 indexes, the "only" overhead added would be a function call plus log(n) comparissons. Edit: and go figure how much memory 1024 Jass arrays use. |
| 03-30-2007, 02:36 AM | #11 |
I wonder, has anyone EVER done anything that could use this? only thing I would need it for is tracking objects in collision range of each object and then I wound up only needing 1 array per object with a backup array if that one runs out. and I think that if someone were dealing with such huge arrays speed would probably be extremely important, so the triggerevaluate would be bad. but how fast is triggerevaluate compared to a function call? |
| 03-30-2007, 03:06 AM | #12 |
It does a function call internally so take a guess. TriggerEvaluate was dismissed for this a long ago anyways |
| 03-30-2007, 09:24 AM | #13 |
O.o im so outdated, i have never seen these syntaxes before, struct and interface. what do they do? One thing is interesthing tho, is the array size, but again we need good performance, if performance is not good, then gamecache is better, cus its easyer to read ^^ |
| 03-30-2007, 09:42 AM | #14 | ||
Vexorian wow nice... i will check this ;) (using this we can ignore using cache for dynamic attaching...) so gj ! Quote:
Quote:
|
| 03-30-2007, 10:11 AM | #15 | |
Quote:
This is not standard syntax, it's vex's grimore syntax. It's quite good though, it beats normal jass for alot of things, and they're no cons to it as far as I know. I don't see a use for this array, 8190 is pritty much the most I could ever see myself using. Also, this array consumes like 200MB of pagefile ;P. I don't see anything using more than 8190*2 but it is an interesting idea. |
