About david.harding

The good news is that this will be available in Polaris. The bad news is that it is not possible to add to the Classic engine. ... View more

The good news is that this capability will be present in Polaris. The bad news is that it is not really possible in the Classic engine. ... View more

To add slightly to what Rob said: the 2^64 (roughly 18 quintillion) cell limit in Polaris is *per line item*. There is nothing to stop you having multiple 2^64-1 cell line items, and if they each only have one populated cell - that is still only ~24 bytes (plus some overhead) each. ... View more

嗨@dkangrga,我是北极星的产品经理. Caveating with the usual roadmap statements that we haven't yet made Polaris generally available, so things are subject to change - I can explain the following between Polaris and Hypermodels. Polaris uses a completely new underlying engine which is a natively sparse engine. That means that the amount of memory/workspace used by a line item does not depend on the dimensionality, rather it depends on the number of populated (non-zero for numeric) cells. So if I create a 10 billion cell line item in Polaris that is all zeros, it will require zero bytes of workspace. Note though that every populated (non-zero for numeric) cell in Polaris requires more memory/workspace (about 24 bytes) than every cell in the Classic engine.(about 8 bytes). So there is a trade off. Workspace size for a Polaris model is driven by the number of populated cells (including primary, aggregate, and calculated cells) and not the dimensionality. Currently Hypermodels means the current Classic engine with greater than 130GB workspace size. That can be necessary when the amount of data being modelled is large enough - whether or not that business problem is highly sparse. We do plan to support Polaris Hypermodels - so Polaris Workspaces with >130GB size, as well as standard Polaris workspaces (up to 130GB), but as we are still early in an EA phase with Polaris we will need to see more data to understand best practice for those scenarios. ... View more

I would like to post an update on, this as I am aware we have not communicated any news on this for a while. We are still planning on implementing a TODAY() type function that will allow the current days date to be returned (with a parameter to specify the timezone). This won't be delivered into production until next year (2022) though. There is a significant amount of complication with this function as it would be the first function whose returned value would change without any other user action. We have chosen to prioritise releasing the Enhanced Calculation Engine (with native support for sparse data sets) before we release the TODAY function next year. ... View more

Please note that YEARFRAC is now available natively in Anaplan. This was released in May 2019. Please see: https://help.anaplan.com/anapedia/Content/Calculation_Functions/All/YEARFRAC.htm ... View more