Submitted by Armando on 2010/04/12 15:48
 
[EDIT 2010 08 05:

The problem affects any field that has both a column and a row equation.
 
Fix :
1- Column equations should always have priority over row equations
2- Column equations shouldn't consider a "null" result as valid and supersede row equations results (hence emptying the field...). In these cases, Row equations should have priority and supersede the "null" result of the Column equations. (i.e. :  if there are children with null values under a parent, the "null" result shouldn't supercede the row equation and erase it.)
]

This problem affect any item that has : a column equation AND a row equation

The main problem is that whenever a parameter directly affecting an equation is touched, the direct corresponding equation is recalculated (i.e. : I modify the DueDate of a parent-item, and it's urgency is recalculated), but the current item's AND/OR parent's transversal equation isn't (i.e. : the column equation of that same item isn't updated).
 
Example :
 
1- if I modify a parameter affecting the row equation (equivalent to "touch" a field affecting the equation) of an item-parent, the row equation is performed, but not the column equation (i.e. : even if it's a parent, the column equation Sum(parents) isn't recalculated).

 
2- If I modify an item-child affecting a column equation (or "touch" a field affecting the column equation), the column equation is performed so that the parent's result is modified accordingly, but the parent's row equation won't be calculated. This is usually NOT a problem, except when the column equation is conditional and the sub-items don't meet the condition. The conditional equation is still taken into account (it shouldn't) and gives a NULL result which is reported up to the parent.
 

All these problems are approximately fixed if I go to the cell where the calculation is erroneous and press shift-F9.
Then both equations are performed and the priority between column/row is ok. However, we shouldn't have to correct calculations manually.
 

(Also like I said at the beginning of this post, it seems to me that a conditional column equation shouldn't calculate anything when the subs don't meet the condition, hence a null result shouldn't appear in the parent. The parent's value, especially if entered by the user or calculated with a row equation, should remain untouched. I will create another issue for that.)
 
 
=============
 
[Older bebugging]
 
==============
 
Steps :
 
0- Create a new number field : [numericfield3]
 
 
in this field :
 
1- Insert a  row equation , e.g. : [numericfield1]+[numericfield2] (both fields should also be number fields ; it's possible to create them or use already existing ones)
2 a- Insert a simple conditional hierarchical equation (ideally a Y/N field), e.g. mySum(adrsbook
   b- The equation should be set to automatic recalc.
 
 
Now, in a grid
 
3- show [numericfield1], [numericfield2], [numericfield3], [adrsbook]  as columns (for simplicity...) :
 
 
4- create a simple hierarchy with one TLI and 2-3 subs.
 
5- all subs and the TLI have the [adrsbook] field checked
 
6- insert values in [numericfield1] and [numericfield2] for all subs, but not for the TLI. (The Row equation will calculate the sum : [numericfield1]+[numericfield2] and show it in [numericfield3] )
 
7- The TLI's [numericfield3] should now indicate the total sum of all sub's [numericfield3] (i.e. : The hierarchical calculation is performed)
 
 
Until now, everything is working as expected...
but now :
 
 
8- uncheck the TLI's YN field [adrsbook].
The Row equation seems to be re-performed and now the TLI's [field3] = 0 (instead of the sum of all subs).
 
Shift F9 will correct the problem and show the right hierarchical total.
 
 
IMO, this shouldn't be since :
 
a- Hierarchical/column equations have priority over row equations
b- all subs still meet the conditions hence, the column (hierarchical) equation should be performed normally.
c- automatic recalc. has been set in the field options.
 
The [numericfield3] value of the  TLI shouldn't change...
 
 
Thanks for looking at it.

 

Comments

Bumpy bump bump.
Anybody looked at this ? Pierre ?
Mantis ?

This annoying one needed a Mantis issue.
 
 Update Issue0953 Column/Row Equation problems  Bugmajornew  2010-06-21 09:19Armando
 
   

Pierre, I'm not sure of what is the problem here, but it's very time consuming. It just doesn't work properly.
 
My previous diagnosis was partly wrong as I'm now having the reverse problem : column equation is performed but not the row equation.
(This is ok, but it shouldn't happen when the column equation is conditional and the result of the column equation necessarily null.)
 
In fact, the main problem is that whenever a parameter directly affecting an equation is touched, the direct corresponding equation is recalculated (i.e. : I modify the DueDate of a parent-item, and it's urgency is recalculated), but the current item's AND/OR parent's transversal one isn't (i.e. : the column equation of that same item isn't updated).

 

Example :

 

1- if I modify a parameter affecting the row equation (equivalent to "touch" a field affecting the equation) of an item-parent, the row equation is performed, but not the column equation (i.e. : even if it's a parent, the column equation Sum(parents) isn't recalculated).

 
2- If I modify an item-child affecting a column equation (or "touch" a field affecting the column equation), the column equation is performed so that the parent's result is modified accordingly, but the parent's row equation won't be calculated. This is usually NOT a problem, except when the column equation is conditional and the sub-items don't meet the condition. The conditional equation is still taken into account (it shouldn't) and gives a NULL result which is reported up to the parent.
 

All these problems are approximately fixed if I go to the cell where the calculation is erroneous and press shift-F9.

Then both equations are performed and the priority between column/row is ok. However, we shouldn't have to correct calculations manually.
 
(Also like I said at the beginning of this post, it seems to me that a conditional column equation shouldn't calculate anything when the subs don't meet the condition, hence a null result shouldn't appear in the parent. The parent's value, especially if entered by the user or calculated with a row equation, should remain untouched. I will create another issue for that.)

Armando

2010/06/19 15:16

In reply to by Armando

Please see first post where I reported the important info.

I apologize for adding a note to this thread again today... But this is a major problem for me as I realize that I'll lose data that I've entered myself everyday as a result of faulty conditional equations mechanism
 
e.g. :
1- I'll enter a duration in a task, item-parent,
2- and if the tasks sub items don't have any duration, the item parents duration (sum(children)) will become NULL as soon as something is touched in these subs, even if the column equation is conditional and shouldn't be performed )
 
The work around is to put fake items all over the place, which duration will condition what the parent's duration should be. But this hard to manage, and not elegant at all.

Hi Pierre, this is a special request as this bug has been going on and on for ages.
  Update Issue 0953   Column/Row Equation problems     Bug major new     2010-06-21 09:19 Armando
And it completely disrupts any calculation in fields where there's a row equation + a column equation.
 
 
The fix is mentioned in the first post. But here it is again, just in case :
 

The problem affects any field that has both a column and a row equation.
 
Fix :
1- Column equations should always have priority over row equations
2- Column equations shouldn't consider a "null" result as valid and supersede row equations results (hence emptying the field...). In these cases, Row equations should have priority and supersede the "null" result of the Column equations. (i.e. :  if there are children with null values under a parent, the "null" result shouldn't supercede the row equation and erase it.)
 
 
 
It would be great if this could make it into the next version. That + the most major inheritance problems which have been going on for ages too. They're all in Mantis. Many thanks!!

I've made changes following your recommendations.
 
Your example (numericfield3 ...) now works fine
 
Available in 0.9.25pre-rel29
 

Armando

2010/08/16 14:27

In reply to by Pierre_Admin

Thanks a lot for looking at this.
Yes the problem in the first example now works fine.
 
There are 2 other situations where it could work better though, following my "recommendations"
 
The 2 main rules were :
 
1- Column equations should always have priority over row equations
2- Column equations shouldn't consider a "null" result as valid and supersede row equations results (hence emptying the field...). In these cases, Row equations should have priority and supersede the "null" result of the Column equations. (i.e. :  if there are children with null values under a parent, the "null" result shouldn't supercede the row equation and erase it.)
 
First situation : using touch
 
These 2nd rule don't work when I  "touch" a Sub item field which = null,  involved in a column equation. The column equation supersedes the row equation, even if the result is null. IMO, that shouldn't be. But I'd be happy to hear other points of view.
 
 
Second situation (related to the first one)
 
erasing all SLIs values  (column equation =  null)  result in an unchanged parent value even if its row equation should show some result.
(i.e. : the row equation isn't recalculated and it should since there are no values for the column equation)
 
When all SLIs values from a field involved in a column equation are erased : the result of the column equation is null and the good thing is that the Parent's value isn't just changed to a null value. However, the row equation for that parent isn't recalculated following rule #2, even if it should.
 
 
Third situation (related to the previous one, probably)
 
Erasing all sub items (column equation =  null)  will delete (=null) the previous parent value, even if its row equation should show some result.
(i.e. : column equation = null and the row equation isn't recalculated... And it probably should )
 
 
Is that clear ?
 
[Edited 2010 08 26]

Armando

2010/08/24 15:47

In reply to by Armando

Hi Pierre. Just a small bump so that  this older post of mine -- where I mention these 2 things still not working optimally in column equations -- doesn't get lost.

Armando

2010/08/26 22:57

In reply to by Armando

I added a third situation. Similar to the 2nd one.
 
HTH (you can always phone me if you don't understand the explanations...)

gregory

2010/08/26 23:21

In reply to by Armando

Armando is not the only user looking for transparent and reliable behaviour with equations! This issue matters to me as well. One of the strong plusses I emphasised about IQ at a recent academic conference was row and column equations - where IQ is well ahead of Excel, for instance.
 
Mark Gregory, Rennes, France - GMT +1/+2; EST +6

Pierre_Admin

2010/08/31 14:05

In reply to by Armando

Item 1 and other related issues are now fixed in v0.9.25
 
Items 2 and 3 will be adressed in v0.9.27
 

(entered an issue for the other unresolved problem mentioned in this thread)
 
[Edit : Working on finance stuff tonight and realised again that column equations are capricious and slightly unreliable.

- The problem where deleting one (or even all ) SLI(s) values doesn't change the results at all in the parent(s) is quite troubling. I constantly need to remember to touch emptied Sub level items so that the column equation reflects these changes. This is not "automated" enough, and it's very easy to make mistakes.

I don't know if there are other problems, but this one is quite evident. However... note that other aspects work well and should hopefully stay as is.
 
I know you said this would wait till 0.9.27... But it feels like a long time for such a bug.]
 
MANTIS

1061
Problem with column/row equation when SLIs values are simply deleted (directly or through some other equation)
  Bugaverage