Staredit Network

I wanted to inform you @ SEN of my map as well. You can find it in this thread on Blizzforums:
FastCalc

It's a concept map that features several mathematical operations:

Addition: simple, just for completeness' sake
Subtraction: No negative results, also just to have it

Multiplication: What you would expect from the name. Uses a new algorithm that reduces the trigger amount A LOT.

Division: Now this is the REAL thing I made the map for. It uses a new algorithm, too. Rounds up/down correctly.

What makes it so special? NO HYPERS, yet still instantaneous (as fast as SC updates the leaderboard, wich displays the result).


I commented all the triggers for those that want to understand the algorithms.
A brief summary of the multiplication/division algorithms:

multiplication:
The great improvement is that one factor is split up in its bits (if you think of it as an integer as used in computing). This makes the annoying "refresh value from buffer" unneeded, which saves us almost 50% of the usual trigger amount.

division:
Utilizes a split-up value, too. Does not change much in trigger amount in this case; would only benefit significantly when the numbers get larger, but it does not hurt as well, because it was already included for multiplication.
The algorithm:
a is checked against 512 * b, and if a is larger, 512 * b is subtracted and 512 is added to the result. Next, the algorithm checks if a is NOW (!) larger than 256 * b and continues as before.
This effectively results in trying out "how many b's fit into a.
It relies on using a value that is highest-checkable such as score. This is also where the trigger number can be reduced, by setting several multiples of b for several players' score of the same type.

Thats pretty sweet but I dont see the point of negative of positive and you should put negative numbers in it if possible

interesting, i'll dl this later when i register. it sounds like it'd be very useful for my fractional reducer... which suffers from enormous calculation time.

I don't get what you want to say

Anyways, this merely is a concept map. I could do a lot more stuff, actually (anything you can do with floating point numbers), but it would require a completely different approach (beginning with the interface and hull) and different algorithms. It's not really hard to do, but that's not the point of this map.

These algorithms are optimized for use in UMS maps that are NOT only a calculator - meaning: Result within a single trigger run and "low" number of triggers, while being limited to maximum input (in this case the maximum input value is 1027, but the map is limited to 999 for simplicity) and other restrictions (positive values only).

If you don't believe anyone would really use this: I AM going to use it in my current project, and I need not only one of these calculating algorithms, I need several copies of it to allow for several calculations per trigger run. That's why the trigger amount has to be low.

This doesn't seem all that interesting. Multiplication and division for calculations are very common in my line of work. I find using 'stacks' for input and output values much easier to use in commonplace real-time situations. This just seems like they are putting too much time into what is a very simple system.

And by the way, negetive numbers can be calculated very easily... This 'FastCalc' doesn't seem very complete without negetive numbers...

Where are square roots and exponents?

Again, this is just a concept map. I once was working on a map that was emulating a real calculator, with 8 digits, floating point, negative numbers, addition, multiplication, subtraction, division, hell I even had concepts for roots, logarithmi and whatsoever. I had all the triggers on paper, but after addition and subtraction were done, I lost interest in it.

But that's not the point now.

Another time: This is just a concept map. This is easily portable to be used with stacks. I will be using it with binary stacks in my map, anyways.
The only real improvement compared to usual methods is the new algorithm for division, and - in case you want to multiply counters - the conversion into split-up binary values.

I don't claim this to be exceptional, but I would be surprised if your algorithms for division would require the same amount or even less triggers than mine while still being instant.
In fact I'd even be surprised if your algorithm for division was something else than "subtract b from a until a is 0; add 1 to c for every b you subtract". And this one will only be instant when you copy the triggers all over, which takes up many more triggers than my method (and is not very pretty).

But I'd really like to hear how you are dividing.

.......
since you pointed out negative numbers: I know that I just have to subtract b from a until one of them is 0 and use the one that is not 0 into the result, in the case that b was bigger as a negative number.
But as I said, that's not what I made this map for.

...I knew I had an account on here...

Anyway you seem awfully condescending for somebody without their own work to back them up. This is a pretty neat example of some work on a more useful sort of calculations in sc triggers. Next time your degrade somebody I'd love to see your own, better, work attached .

Oh, and it's hard to believe you're a professional anything with a geocities site.

that hurt my feelings ima definitely use this when i have time to look at and learn the trigs.

How did I hurt your feelings?

Please tell me; I'm curious to learn new ways of hurting other's feelings

...its the algorithm i use .

It's the only one I ever heard of until I introduced mine

I saw this at blizzforums today while at school, and its nothing new to me, infact me and zeratul-101 are using it along with micro scanning to detect slope and distance between 2 units... Old news here.

actually, we're not. at least not at the moment.

That was a good one

Well, seriously: You probably don't use it. No doubt you use division; that's no big deal. My algorithm is no big deal either, actually, but still I'd be surprised if you use it already. At least I would have to scold you for not making it public
Anyways, feel free to use it if it brings you any advantages (of course it won't bring much for small numbers, might even be worse for very small numbers), and don't forget that I just laid out the system; for practical use you would probably have to change quite a bit; especially everything that deals with input.

okay, so i looked at it for a few minutes... and i don't quite get it.

it seems like you split 'A' into switches and you compare 'A' switches to 'B''s DC value(which is segregated into these 'bits' you describe)

the basis, as i currently see it, is to retrieve the pre-determined product of two numbers(one is 'A', the other is 'B', each which has already been segregated into many numbers) and then adds all the products together... how close am i?

Not so far, but I kept A as it is, as a death counter.
It is essential that A is NOT split up. Whether you use a virtual counter or a unit counter is up to you, but for a value of A up to 999 a unit counter would be consuming too many units. Also, this counter has to be comparable to other values, with conditions such as "most resources", "highest score", "command the most at".
(another reason why I can't split up A is that I will subtract several values from it later, and this is more complicated - in SC - with split up values than with normal counters)

Ok, so A is a comparable counter.

Next: B. In my map, B is split up. But it is not really necessary; I my case it would result in the same amount of triggers if it wasn't, and it would not need 10 switches but only one death counter (backup value). But since I already used it in multiplication (where it does make sense), I kept it.
Explanation: A is stored in P1's Kills Score. The values A is comparable to are P2's to P8's Kills score. What I do is put B * 512 into P2's kills score, B * 256 into P3's kills score and so on. Since I have 7 empty slots, I can do 512, 256, 128, 64, 32, 16, 8. All of these are calculated in a single set of triggers. In my case this would be by checking if switch 10 is set, adding 512 * 1 to P2's kills score, 256 * 1 to P3's kills score and so on, repeating this for 512 * 2 (to P2's score), 256 * 2 for swicth 11, then 512 * 4 and so on. If you chose not to split up B, you can use a simple copy-value binary countoff, so setting P2's to P8's kills scores and creating a backup of B in a different counter.

So now we set up all these multiples of B. I'll explain the maths behind it:
If A is larger than 512 * B, B fits at least 512 times into A. If B * 512 is larger than A, B fits at most 511 times into A.
If A is the larger value, I add 512 to the result, C, and subtract 512 * B from A. Note that A must now be smaller than 512 * B, or else it wouldn't work, so the input value for A has a maximum - which is quite large anyways.
If B * 512 is larger, I just dump this value and leave A untouched.

So now lets put this into triggers: P1's kills score is A, P2's to P8's kills scores are multiples of B.
When I check for the highest score now, I will either get A or P2's kills score (512 * B in this case), because 512 * B obviously is larger than 256 * B (on a sidenote: try division by 0 in my calc ). Since "highest score" is a CurrentPlayer trigger, it has to be run by P1. So if P1 has the highest score (A), B * 512 (P2's kills score) is subtracted with a simple binary countoff, and 512 added to C. If A is not the highest value, P2's kills score is reset to 0.
Same procedure is repeated, but now it can only be A or B * 256, since I reset B * 512 to 0.
This is repeated until I hit P8's kills score.

Now I have to set up a new kills score table. If I used the split up B earlier, I can repeat the same procedure for 4, 2, 1, 0.5 (explanation follows later). If I used another death counter as backup, I can just calculate the values from this one using a binary countoff.

Now I repeat the highest score thing for 4, 2, 1. We now know how many times B fits into A, and A is smaller than B now.

The 0.5 thing is only needed when you want to round your values. Setting up the 0.5 value has a little detail you should notice: B could be an odd value, but a score cannot be 14.5 or something like that. This has to be rounded up. So we have a binary countoff like this:
(k represents B, for example k could be the backup value; m is a kills score)

C: k > 511;
A: k - 512; m + 256;

C: k > 255;
A: k - 256; m + 128;

...

C: k > 1;
A: k - 2; m + 1;

C: k > 0;
A: k - 1; m + 1;

When I now check A against m, and A s larger or equal to m (fulfills the highest score condition), C is rounded up - C + 1.
I don't even check th opposite case because after this the division is completed, and unless someone gave me invalid input, nothing was able to go wrong

I hope this helps