- Adding new SerializedOrderEvent and SerializedOrder with new
JsonConverters
- Specifying OrderEvent json converter when storing, streaming data
- Adding unit tests
Adds static methods of the form Parse.<TypeName>(string str) that use
CultureInfo.InvariantCulture. These are to be used when parsing strings.
It's still safe (from the CA1304/CA1305 perspective) to use the ToDecimal
extension method for decimals.
Adds string extension methods for common operations that will now require
CultureInfo.InvariantCulture. These are to be used when converting values
to strings, such as ToStringInvariant()/ToStringInvariant(format), but also
useful for searching within strings, StartsWithInvariant, EndsWithInvariant
and IndexOfInvariant.
FxCop has various rulesets for enforcing things within our codebase.
For this particular issue, we'll be enforcing CA1304 and CA1305 to
ensure we're always using an IFormatProvider or a CultureInfo where
applicable.
Linked Issue: #3045
Can now simply flip a flag in the code at the top of Messaging.cs or
specify via configuration 'regression-update-statistics' and it will
automatically update the code statistics using the statistics from
the current run. Useful when updating factor files and need to update
all statistics :P
Launcher project is packed as `QuantConnect.Lean`but as a mean ot having all Lean features just calling one package.
In the same sense, `QuantConnect.Algorithm.CSharp` is included as package and added as dependecy in the `QuantConnect.Lean` package just to have a working example aailable out-of-the-box.
The term 'alpha' is used to describe the entire algorithm. Therefore, 'alpha'
produces insights. From this we have things like IAlphaModel, which is the model
defining how insights are produced. We have IAlphaHandler, which defines how the
insights from a single 'alpha' (the algorithm) are managed, analyzed, and stored.
Types closer to the individual prediction level, such as InsightDirection, or
InsightScore relate directly to exactly 1 insight. The distinction between the
two became more clear as we developed the insights API, and from that effort it
was decided to harmonize alpha/insight terminology across the various QC systems.
The IAlphaManagerExtension defines a type that needs to react to events produced
by the AlphaManager. The actual events were removed in favor of a interface to
handle the events. This removes the need to wire events and instead just pass the
extensions to the alph manager and it will handle invoking the extensions at the
appropriate time.
This change removes all charting and statistics aggregation logic from the alpha
handler and moves it into dedicated types, AlphaChartingManagerExtension and
AlphaStatisticsManagerExtension. The resulting types are highly decoupled from the
LEAN ecosystem allowing them to be easily unit tested, whereas before the logic
was embedded in a handler with many many dependencies which would be very hard to
properly unit test.
As part of this change (and in preparation for moving scoring to the alpha thread)
the resolution of SecurityValues was removed from the alpha manager. In this new
pattern, the alpha manager is pushed generated alphas and security values at each
time step.
When the algorithm finishes, the alpha statistics are merged with the backtest
result statistics. This keeps the regression testing pattern of alpha statistics
the same as the existing regular statistics.
In the advanced build settings, Language version was also upgraded from C# 5.0 to C# 6.0. The minimum Visual Studio version required will now be VS2015.
In order to avoid switching on types in StreamingMessageHandler, the NetMQ tcp Push Socket will now only send the serialized packet to the desktop client, instead of the serialized packet and the packet type.
The DesktopClient now only accepts single part messages in order to accomadate the changes in StreamingMessageHandler. The type of the packet is distinguished in the DesktopClient because StreamingMessageHandler does not disnguish the types of the packets.
The StreamingMessageHandler tests and DesktopClientTests have been altered to reflect these changes.
This message handler uses NetMQ Push socket to push messages over tcp to a client. It makes no garantees about the client. It will always send two part messages. The first part of the message is the resource and the second part of the message is the serialized packet.
When algorithm run ends before the message system is loaded (it depends on the UX loading), enqueued packets used on charting are never sent to the UX.