skip to Main Content

XPLAN CODING

Floatify: whats it do and why we use it

May 20, 2015 | matthew-townsend

Floatify or rather how it’s been used in some templates, has prompted readers of the blog to question it – and thanks to those who have emailed asking, we’ve put this article together to explain 🙂

What is floatify

Floatify is a reasonably simple, built in xmerge function that takes a piece of data and will try force that data to be converted – and returned – as a floating point number instead.

Its base xmerge function is:

<:=floatify(x):>

How does floatify work

When floatify is called, it will go through each part of a nominated piece of data and filter out anything that is not a digit (0,1,2,3,5,6,7,8,9) and then return the result as a floating point number –  you know those guys with the decimal places.

The returned result will also maintain any decimal places in the original data as well.

Examples

Common use:
<:=currency(floatify($client.total_assets),0):>

Example with variables:

<:let myMoney = ‘$550.67 AUD’:>
<:=floatify(myMoney):>

# You should see: 550.67 as the returned result, noting the rest of the string has been stripped out.

History

The more technical function for how it’s achieved is actually something you’ve likely come across already in standard templates and something that often raises questions from people.  Before it was a standard function, here was the function you still sporadically see littered throughout templates:

<:let floatify=lambda val: float(filter(lambda x: x.isdigit() or x in ‘.-‘, str(val))):>

Why do we use floatify

Just because a piece of data appears as say, a currency on screen when in your xplan site, doesn’t mean the data is actually stored that way.

There are many examples throughout xplan where this is the case, with the most common being: portfolio data, risk researcher and wealthsolver, all storing data in ways which will require you to floatify so you can manipulate them into the format you want or even perform xmath and calculations with them.

It’s worth noting that some elements contain methods to get a floating point values naively:

  • ‘Unformatted’ and ‘Raw’ data from portfolio report sources and XTOOLS paths should be floating points natively.
  • Currency items can natively be converted by adding .value to them.  For example $client.total_assets.value would work in the currency function from earlier without needing to floatify it.

Follow up questions

Some further questions you might have and answers to them.

Isn’t this what float() is for?

Yes float is used and helpful in converting numbers to be floating points but you cannot ‘float’ datatypes that are not native numbers.

For example, you can’t float the mystring variable used above, you need floatify to correctly strip out the additional data and convert it to a floating point.

If Floatify is really built in as you “claim”…why is <:let floatify…:> defined in my templates?

Great observation and question.

In essence it’s not needed anymore. At best it’s depreciated coding that’s just taking up space. At worst, there’s always the possibility eventually it could interfere with elements of standard functioning.

Why is it still in the templates then?

As we mentioned earlier there was a time when it was needed because floatify was not part of the standard compiler – it wasn’t built in (unlike now).

It keeps appearing in templates because it’s a piece of legacy coding that likely has no impact and also since a lot of people don’t understand what it does, it just keeps being included – rather than removed.

Case in point is the IRESS Risk Researcher template via the template library. Floatify is unnecessarily defined multiple times in the remuneration section. There are other examples of depreciated coding that appear in standard templates, this is one of them and we will get to the others through subsequent articles.

About the author

Matthew Townsend on EmailMatthew Townsend on Linkedin
Matthew Townsend
Advice Technology Consultant | Digital Advice at Create Something
Matthew is an experienced and innovative Xplan consultant and developer, having worked on and developed some of the largest advice projects in the industry. Passionate about building great experiences in xplan that enable businesses and clients to get the most out of this powerful software.
Back To Top