FundamentalsRatio in WLD using YCharts data
Author: superticker
Creation Date: 9/9/2020 2:47 AM
profile picture

superticker

#1
Let me start by asking, can I assume the WealthLab.Rules.FundamentalsRatio classes work okay with Wealth-Lab Developer? I'm assuming they do since they are documented in the programming guide for WLD (although there's this little disclaimer at the top suggesting the FundamentalsRatio classes only apply to WLP. They're just kidding, right?).

So why does the following line return a run-time error saying "Object reference not set to an instance of an object." What's the correct way to compute priceCashFlow with YCharts data under WLD?

CODE:
Please log in to see this code.

I also have this line below to compute annual earnings from Fidelity data. What's the best way to convert this to work with YCharts data employing WLD? I do have "[yc] eps" available to use.

CODE:
Please log in to see this code.
profile picture

Eugene

#2
Forget about the FundamentalsRatio for now. It has hardcoded fundamental items by Fidelity all over the place. Despite that it may accept a custom fundamental item like PriceToRatioSeries, internally many supporting functions are bound to their now non-existent Fidelity counterparts.

Fixing this will be a moderate effort with no ETA. I put this on our product backlog. At the moment we don't know when we'll be able to accomplish this.

If you need it right now, your best bet is to come up with a DIY script-based solution.
profile picture

superticker

#3
Can you provide me with a reference on how to compute these above items. I had a document concerning this (I "think" it was a WLP document.), but it has been deleted. I need a new reference to recreate this.

I'm also confused on how we arrive at a time series out of these calculations when they look like scaler calculations to me. A sigma formula integrating over time should clear this up. Without the sigma formula (series) over time, I just don't see it.
profile picture

superticker

#4
I found a marginal reference for the calculations. The percent annual growth calculation is easy; see below.
CODE:
Please log in to see this code.

The cash flow calculation is messed up. I "think" the units are wrong by 1000? Can you help me?
CODE:
Please log in to see this code.

profile picture

Eugene

#5
What number is wrong, specifically - the value coming from YCharts provider (what exactly) or some part of your formula (what step)? Could you explain in more detail.
profile picture

superticker

#6
QUOTE:
some part of your formula (what step)?
I "think" the numbers from YCharts are okay, but one needs to be careful. For example, YCharts gives shares_outstanding in Millions(?) rather than single shares as one would expect. I honestly don't know what the units are for free_cash_flow. Is it in dollars or thousands of dollars? Is this documented somewhere?

I "think" the formula is correct. Does it look right to you? Does a cash flow of 607K seem high to you or is it a few decimal points off?

I would have used "[yc] free_cash_flow_per_share" for the calculation, but it isn't available with the free YCharts subscription.
profile picture

Eugene

#7
QUOTE:
I honestly don't know what the units are for free_cash_flow. Is it in dollars or thousands of dollars? Is this documented somewhere?

It's documented on their website:

https://ycharts.com/companies/BRKR/free_cash_flow
https://ycharts.com/glossary/terms/free_cash_flow
profile picture

superticker

#8
Okay, so both free_cash_flow and shares_outstanding are in units of Millions, so the millions cancel out in the numerator and denominator. And shares_outstanding is not to be summed over the year. In the corrected calculation below, I'm just going to use the most recent month of shares_outstanding for my calculation to keep it simple and approximate. Here's the new calculation.
CODE:
Please log in to see this code.

Let me know if you don't agree with this calculation. But the numbers now look believable to me. Thanks for all the help.
profile picture

Eugene

#9
Good point re: shares_outstanding not to be summed up.

I'm not very familiar with what you're trying to achieve but "Close[Bars.Count-1]" in a DataSeries hits the eye. Shouldn't this be a DataSeries adjusted for splits rather than a fixed value of the last bar? See below for what I mean:

Split and Dividend Adjusted Prices? (Custom cumulative dividend series)

If it's not for backtesting but to create an Alert for live trading then I guess it's okay to do.
profile picture

superticker

#10
QUOTE:
Shouldn't this be a DataSeries adjusted for splits rather than a fixed value of the last bar?
"Close[Bars.Count-1]" is okay because the Price/CashFlow ratio is based on the "current bar price". One is trying to decide if the "current price" is too high to buy (overbought). Technically, you would want to create a scatter plot of "price vs. cash flow per share" and check to see where the candidate-to-buy stock falls in this scatter over other stocks to determine if it's overbought, but I don't know anyone routinely doing this.

Moreover, ideally you would want to be dividing the free_cash_flow DataSeries by the shares_outstanding DataSeries that was corrected for splits. But I'm only interested in the "final number," so there's no point in spending the extra CPU cycles doing that.

I employ WL for trading, not investing. So none of the fundamentals are employed in the trading model itself. I just employ the most recent fundamentals to see if they are really bad (e.g. the PEG ratio >> 2.0). If one fundamental is really bad, I may not trade the stock.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).