OK, I've tried piggy backing other threads and I've noted the comments.

Is this thread the only one where those of us that have bought this package have listed our enhancement requests?

Is there any kind of voice for paid, global users whom are not associated with a Fidelity retail trading account?

My requests:

1) Market mechanics definition
This should be where round lots and tick sizes and shortable "y/n" are defined.
Round lot and tick sizes are mostly rule driven, however, these items must be accessed by the backtesting engine to apply slippage and sizing.
Shortable "y/n" is exchange driven and again, if a portfolio contains tickers that are both shortable and "not allowed" the backtesting engine
must have this info.
Of course these rules are then used by strategy monitor for alerts and new order sizing.

2) Portfolio syncing (for tomorrows generated alerts on stops for actual market activity as executed today)
Once the order messages have been generated by the staged strategy, we need to be able to tell the alert monitor the price at which executions
really happened. This drives T+n alerts on positions entered on T.

3) Currency normalization (run strategy vs. shekel account while postition sizing and executing trades in K. Won, V. Dong, J. Yen, etc.

These few enhancements would really push Wealth-Lab forward (ie. additional sales revenue) as there aren't many systems available with these features for trading global markets.

Most users of the forums are customers, either through Fidelity or with MS123.

1 and 3 - These are global, architectural changes and as such will not be considered for the foreseeable future.
2 - Since removing portfolio sync was a design decision for Version 5, it's again an architectural challenge and therefore can't be reverted.

Sorry.

Thanks for the response Eugene - I did specify paid in and not associated with Fidelity.

So, in short, Wealth-lab for oustide of US use is always going to remain an interesting, if somewhat irrelavent due to lack of market mechanic intelligence, strategy development and test platform?

Not quite. The product has a plan for development which includes short-term (6.5) and medium-term goals (6.6?), partially based on the feedback provided by both WLP/D customers. It's just not possible to please every customer without sacrificing business needs and other customers' wishes.

The effort of lobbying a change at Fidelity should not be underestimated. Fidelity is a software factory, it's a business process that is unable to react in the manner of MS123 where e.g. a data provider library can be delivered to the requesting customer in a matter of days (sometimes). If converting from shekels to wons may interest just a couple of paid customers, the request will be deferred or inversely prioritized.

We're willing to help our customers by extending Wealth-Lab using the standard APIs but all architectural changes are in the hands of Fidelity where they are measured through the "bang for the buck" glass. And they're dead right: sometimes, a seemingly innocuous and correct change like wiping out the stale alerts in SM (6.4) adversely affects customers' workflows. Even a drop-in replacement of the built-in Editor DLL (3rd party work) may take months of lobbying. Needless to say, chances of introducing architectural changes at this state of product's maturity are pretty low these days when there are numerous active customers using it.

Eugene,
You must realize that currency x to currency u, v, w, z, etc is part of offering a global sollution and market mechanics are not just "nice to haves"?

For those of us not in the US, the platform is interesting, but irrelevant. If the product is slated to be single currency and single markets, it is fine to express that(current state).

The changes should not wipe out anyone's slate but should allow development, testing and implementation on markets other than 1 share at a tick of 0.01 and in USD. Most software factories understand the buying community; however, here it appear that the understanding is missing.

These are not community component type fixes, they are "will-it-work-elsewhere" fixes. The paid in community is elsewhere.

If Fidelity is only concerned with a single market, currency, tick rules/round lot rules, then so be it.

Architecture be damned, when someone buys software that is specifically "for users outside of the United States", you bet that they expect it to work rationally outside of the United States.

Wealth-Lab can work with any single currency, making it work with multiple currencies sounds like a serious effort and currently is not on the radar.

Do not forget that you can have multi-currency quotes on a same exchange (i.e. swiss stock exchange). It's really regrettable to do not integrate this feature for the "international version" of WLD

Even working with a single currency is a challenge in markets where standard tick sizes are not 0.01 and lot sizes are not 1.

Tencent/0700.HK trades in lot sizes of 100 and ticks of 1.00 making rounding and position sizing easy. However, slippage of 3 spreads here is 1.1% of last price (HKD268 at the time of this e-mail).

COSCO/1199.HK trades in lot size of 2000 shares and minimum tick of 0.05. Round lots here trade in HKD increments of 22,400; 44,800; 67,200 (3 lots of Tencent are 80,400). Using last of HKD11.40, a three spread slippage equals 1.3%

You can see that there isn't a rational percent to use as a standard slippage as a few dozen trades split between these two stocks in a portfolio would give wildly different results for backtested P&L and trade sizes, driven by lot rounding, that would be impossible in the market for COSCO.

Singapore stocks are listed and traded in either SGD or USD and Hong Kong has just introduced equity listings in RMB.

Agree with you also for ticks and lot management. I have the same problem in Europe (i.e. Spanish stock exchange).

A software can't please everyone. These examples represent a very minor subset of stocks yet would mean a serious change that might affect lots of unsuspecting users, should something go not as planned. My opinion is that it might be far easier to handle such special cases with the help of Symbol Info Manager, in your Strategy code and/or commission library or PosSizer.

On a global scale, the requirements for lot size and tick size support are much closer to the majority of markets.

If one is being diligent in their testing by using multiple data providers, then the universe of shortable stocks in Hong Kong would mean 1,500 entries to support 3 data providers IF one used a symbol manager.

I can see the potential of a Market Manager where rules for tick size calculation and lot sizes could be entered.

Having an option for slippage in an appropriate manner would also be needed once these definitions were entered: slippage happens in tick value, not percent of stock price. This is just as true in the US as in the global markets.

QUOTE:
then the universe of shortable stocks in Hong Kong would mean 1,500 entries to support 3 data providers IF one used a symbol manager.

Absolutely not. The Symbol Info Manager supports Regex since version 6.2, so for instance, all stocks ending with .HK could be covered with a single rule.

Tickers from Bloomberg Static end in :HK while and ascii provider uses _HK

I think a single rule for stocks tick and lot value based on last trade would make sense, it would not make sense creating the 500 entries for the shortable universe, even if for one provider.

Of course, an upload function, essentially to a security master, would make the excel creation of all rules a snap. At that time one could also give traded currency for later enhancements!

QUOTE:
Tickers from Bloomberg Static end in :HK while and ascii provider uses _HK

Not a problem with Regex (still a single rule).

QUOTE:
it would not make sense creating the 500 entries for the shortable universe, even if for one provider.

This is a task that can be implemented using a custom method to call from your Strategies.

Eugene,

Can you show me an example of:
If symbol = "%HK" then
Case
last price < 0.25
tick = 0.001
decimals = 3
last price < 0.50
tick = 0.005
decimals = 3
last price < 10.01
tick = 0.01
decimals = 2
last price < 20.01
tick = 0.02
decimals = 2
last price < 100.01
tick = 0.05
decimals = 2
[..]
last price > 5000 then tick - 5 & decimals = 0
End Case
If symbol = "%AU" then
last price < 0.10 then tick = 0.001 & decimals = 3
last price <= 0.50 then tick = 0.005 & decimals = 3
last price > 0.50 then tick = 0.01 & decimals = 2
If symbol = "%SG" then
If symbol = "%JP" then

On lot size, lot are assigned by exchange in many markets and are not calculated on price. For instance, HKEX posts the lot sizes here: http://www.hkex.com.hk/eng/market/sec_tradinfo/stockcode/eisdeqty.htm

That list also tells if shortable.

On currency normalization, what do you think about having a dataset per currency pair needed, reading in the portfolio from x provider and writing out a new portfolio of DATE, O[rateadjusted], H[rateadjusted], L[rateadjusted], C[rateadjusted] and letting the strategy work vs. this daily rebuilt portfolio?

Thanks,

Hank

QUOTE:
Can you show me an example of:
If symbol = "%HK" then

You can modify the SymbolInfo object's properties in a Strategy, overriding the Symbol Info Manager:

CODE:
Please log in to see this code.

Same with decimals.

QUOTE:
On lot size

That's a PosSizer task.

QUOTE:
That list also tells if shortable.

As mentioned above, a custom function can be planted in your Strategies (or better, in a compiled library similar to our Community Components, and referenced in Strategy code).

QUOTE:
On currency normalization, what do you think

Sorry, I don't have experience in this field.

Thanks for that.

I don't get you on PosSizer understanding the exchange's value of tradable lot sizes though..from 100 shares to 20,000 shares as defined on exchange.

For currency, I have been trying to write something that will access external symbol for currency (already updated for each pair that I will need going back several years) and taking the 2 right-most characters of any symbol (creating the "mkt" variable) and 1) writing out the values if the ticker is in HKD; 2) converting currency to HKD for others.

CODE:
Please log in to see this code.

So far, having issues with the following:

"Object reference not set to an instance of an object.
Z74:SP"

This happens to be the last ticker in my portfolio (main dataset on which the "strategy" is executed.

QUOTE:
"Object reference not set to an instance of an object.
Z74:SP"

":" is a forbidden character in Windows file systems. One won't be able to save a file with the name like Z74:SP.WL without having to convert the char to a safe one first. Wealth-Lab does it internally when storing such symbols on disk, and translates the substitution char into ":" when reading them back.

QUOTE:
I don't get you on PosSizer understanding the exchange's value of tradable lot sizes though..from 100 shares to 20,000 shares as defined on exchange.

The idea behind building such a PosSizer is to round the size of each position (currentPos) based on an instrument (currentPos.Bars.Symbol) inside your SizePosition() implementation. For example, if the size determined by a position sizing formula is 22,436 shares and the lot size is 20,000 shares for the instrument, your formula rounds it down to 20,000. Examples of building PosSizers: Home - MS123.PosSizers > Attachments.

If it would have gotten that far in the code, writing the new file out, I would have seen an error like "The given path's format is not supported."

I resolved the ":" character by creating a string called "newsym" which contains the symbol + "_" + mkt

It feels as if I've missed the structure of the dataset object by having three Bars statements set using GetExternalSymbol for each of my three currency pairs.

I made this point "This happens to be the last ticker" as strategies all seem to run backward through the list of securities starting with the last one. Thus the error is happening on the first attempt through the code.

Can you see what I'm doing wrong?

CODE:
Please log in to see this code.

Also, I've looked over the PosSizer projects - there is no way to determin round lot size (that which can be executed in the market) as the values per security are defined by the exchange rather than being a function of tick size. Lot sizes must be table driven.

From my earlier post:

"On lot size, lot are assigned by exchange in many markets and are not calculated on price."

Without knowing sizes which are exchange tradable, backtest results are not going to be aligned with reality.

QUOTE:
Can you see what I'm doing wrong?

This:

CODE:
Please log in to see this code.

Should be:

CODE:
Please log in to see this code.

Also, instead of calling bars.SaveToFile( file ); on each bar, it's enough to do it once, after the bars loop has completed.

QUOTE:
Lot sizes must be table driven.

If you know the rules of determining the round lot size, you can program it in a PosSizer.

If the logic behind it is table-driven, you query the table from a PosSizer.

I changed the sym line as suggested and moved the bars.SaveToFile(file) outside of the loop.

I am still getting the error:
Error processing symbol Z74:SP Object reference not set to an instance of an object.

Things that I have checked:
* There is data in the dataset, I have pulled it up in a chart.
* I have limited the run of the "strategy" to be in a date range which included data from the dataset for the portfolio and all three currency symbols.

New code:

CODE:
Please log in to see this code.

What have I missed?

Thanks for your help Eugene.

To help you start your own debugging of your custom script, Z74:SP is not handled by your code.

I've taken it out. I get an error on the next symbol...

Error processing symbol WOW:AU Object reference not set to an instance of an object.

I've also run it against other datasets...last ticker in the dataset (first to be processed) always comes up with that error.

If I click directly on a symbol I get the following in the bottom pane of the code window:

Runtime error: Object reference not set to an instance of an object.
at WealthLab.Strategies.NormalizeToHKD.Execute()
at WealthLab.WealthScript.GetExternalSymbol(String symbol, Boolean synchronize)
at WealthLab.WealthScript.SetContext(String symbol, Boolean synchronize)
at WealthLab.Bars..ctor(Bars b)

It's not finding the External Symbol, i.e., a Bars object is not being created.

I'd say your error is here:

CODE:
Please log in to see this code.

Cone, you hit the nail on the head. That indeed is a typo and should be HKDJPY:CUR

I have resolved that and am waiting for my morning dataset updates to finish so that I can run a test.

Once this has been resolved, this "strategy" will run each morning just before my actual strategy to create a HKD normalized dataset across Asian markets. The newly created tickers will be the target of the trading strategy and thus all order alerts will be created on the same risk parameters, but on the correct number of local shares.

Thanks Eugene and Cone for getting me this far.

The conversion runs without error, all files are created in the temp directory and I have built a dataset using both type WL Pro and WL Developer for the files. However, trying to pull up any in a chart says no data.

Is there a way to open the files outside of Wealth Lab?

Each is close to the same size (within a few KB - which makes sense as I have limited the date range for execution) and looks like this:
https://dl.dropbox.com/u/58843243/Z74_SP.WL

Any ideas? Thank you.

If I execute a bars.LoadFromnFile and chart the data I can see it.

What am I doing wrong which is preventing me from creating a dataset of the files in that directory?

For now I've written them all out as ASCII files and done the same thing - created a dataset using the currency converted files on which my strategies run.

QUOTE:
I have built a dataset using both type WL Pro and WL Developer for the files.

This must be the WL4 Files provider for reading legacy .WL files (Version 3/4). What you have exported with Bars.SaveToFile is the new .WL format (Version 5/6). They are not backward compatible.

Exporting in legacy format is exemplified here: Exporting as WLD 3/4 native binaries (*.WL)

QUOTE:
What am I doing wrong which is preventing me from creating a dataset of the files in that directory?

Version 5/6 .WL files can not be used from a directory outside the WL's AppData\Data folder. I provided a detailed procedure a while ago, here's it:

How to create a DataSet from SaveToFile() *.WL data

P.S. As you can see, working with ASCII files is more convenient, less complex and less error-prone. Plus the benefit of ASCII cache makes efficiency on par with binary files.

Thanks Eugene - as the WL file types have been designed to be "more detailed" in subdirectory structure, I will abort the use of Bars.SaveToFile and use ASCII.

It took me a bit of thinking on getting around the single currency account/multiple market execution issue. My work around now performs beautifully.

I still need to address tick size and lot size however.

If anyone has written an exchange rule handler for dealing with tick size and lot size that gets enforced in backtesting and alerts through the strategy monitor, I'll trade for the Streamwriter solution to working multiple markets from a single currency.

Good for you. Please re-read my suggestions above on solving your other two problems.