As an example, our core business collects Actuals across 6 segments. However, our partner organisations can only supply values for 3 segments. Our budgeting and forecasting is also only across 3 segments. When loading data into those 3 minor segments (dimensions) we have to load to an element. We could have loaded to a default code, but that would not make it clear that the split was not available for those dimensions. We therefore instead created a zz_Not Applicable element in the minor dimensions and we load into that. This is then semantically clear, but there is no need for UNDEFVALS. The case is different but it is addressing the same issue.
I would agree that because UNDEFVALS is cube based that using a system where one cube has UNDEFVALS in its rules, while another cube does not, is going to cause unpredictable results, especially if one cube references the other in a rule. However, that is one of the reasons that I have never come across anyone actually using UNDEFVALS.
I would therefore tend to agree that if UNDEFVALS is going to be used, then it should be a setting that is either on or off for the whole system, rather than individual cubes with developers having to create a rule file for every cube with UNDEFVALS at the top, which is easily going to be forgotten, particularly for cubes that don't otherwise need rules.
However, I would still prefer the option to have UNDEFVALS on or off.
If UNDEFVALS is turned off, then as there is some degree of programming between any input and a value getting in to a cube, then it should be possible for that programming to change a 0 into a null, or in reality clear out what is currently stored and store nothing, which as I understand it is what currently happens without the UNDEFVALS statement. Only at query time is that 'nothing' shown as a 0.
If a customer decides to turn UNDEFVALS on then the assumption would be that someone storing a 0 actually wants a 0 to be stored in the cube, and will take steps to deal with any increase in size that results from that.
I have been working with TM1 for over 20 years. I am aware that calculated cells are not stored in the cube. However, the amount of memory used by TM1 does grow as cached results are stored. If TM1 is going to start storing zeroes in the cache because of the change to Undefvals, then this would seem to be an issue. On base level cells, zeroes are going to be stored in the cube. Again, this would seem to be an issue.
I think you may have misunderstood, what I was saying. If we must have UNDEFVALS then I would prefer to see a blank as per the Exploration view, as opposed to the #N/A shown in the PAX cube viewer, but overall I would prefer to leave things as they are ie to have the option whether we want to use UNDEFVALS or not, and my option would be to not have them, and it would therefore show a 0.