Why won't this work?

[Heathbo]

Essentially I have a calculation field with the calculation below on it.

Def, Aver A1, and Aver A2 are all number fields with values in them.

What I want to happen is when ((Def - Aver A1) + (Def - Aver A2)) / 2 = 3

I want the number 100 to show up in the field.

Is there an easier way of doing this?

Am I going about this all wrong?

Case (((Def - Aver A1) + (Def - Aver A2)) / 2 = "3"; "100";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "4"; "99.54";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "5"; "98.15";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "6"; "95.37";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "7"; "90.74";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "8"; "83.80";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "9"; "74.08";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "10"; "62.51";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "11"; "50.0";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "12"; "37.51";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "13"; "25.94";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "14"; "16.22";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "15"; "9.28";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "16"; "4.65";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "17"; "1.87";

((Def - Aver A1) + (Def - Aver A2)) / 2 = "18"; ".48";"")

Any help you can give me is greatly appreciated

Heathbo

[MoonShadow]

I'm unsure of the result you are looking for. It appears that Aver might stand for average and you seem to be hard-coding percentages; but I won't try to guess. I'm no mathematician but I would think FM could do this for you?

I certainly see the patterns, however. I think you can (substantially) increase its efficiency. I wish I had your real numbers to plug in for testing but I'll leave that up to you. You should be able to copy/paste this calc as I matched your field names exactly:

Choose(Div((Def - Aver A1) + (Def - Aver A2) ; 2) - 3 ;

100; 99.54; 98.15; 95.37; 90.74; 83.8; 74.08; 62.51; 50; 37.51; 25.94; 16.22; 9.28; 4.65; 1.87; .48)

Bottom line - if all three numbers are the same (regardless of the number size) it will equal 100 if this is what you need. Are we moving you closer?

[Heathbo]

Never mind I figured it out. I forgot about the decimal. By adding a round command it fixes it.

[MoonShadow]

For anyone that is interested in efficiency, the comparisons between these two calculations is significant.

Case( x1, y1, x2, y2, x3, y3, x4, y4, ... )

1) Solve expression x1

a) It was true: solve and return y1

It was false: Solve: Case( x2, y2, x3, y3, ... )

- Solve expression x2

A) It was true: solve and return y2

It was false: Solve, Case( x3, y3, ... )

etc.

Choose( n, y0, y1, y2, y3, y4, y5, ... )

1) Solve n to a number

2) Solve and return y[n]

If I understand correctly, the first calculation might take 32 (or 48) evaluations (?) whereas the second will always take only 2. But with FM7, Case() will short-circuit so accurately counting the calls isn't possible, is it? Case() stops when it hits the first true, so we can only say it would require up to a certain number. But I still think a comparison is important.

Can any math wizards help me count the potential evaluations in that Case()? I want to further learn how to read this so I can structure my thinking accordingly. I have a sneaky suspicion that, depending upon whether one utilized branch prediction, the data will skew the counts. In prior versions, Case() had to evaluate the entire calculation every time so it was black and white. Input on this concept would be appreciated.