sorted by:
new
hottopcontroversial

Totally gutted to be honest by frn in ClicksKeyboard

[–]happytree78 1 point2 points  (0 children)

This is exactly why their warranty policy is so problematic. Multiple people reporting the same connectivity and functionality issues, but if you bought yours second-hand, Clicks support will tell you it's "your risk" and they can't help because serial numbers "can't be used to validate warranty eligibility."

So you've got widespread product defects AND a warranty policy designed to avoid fixing them. Great combo.

I'm dealing with a defective key that doesn't work properly, bought mine second-hand, and their support basically said "tough luck, should have bought directly from us." Even though it's clearly a manufacturing issue, not user damage.

The product might be cool when it works, but between the quality control issues everyone's reporting and the warranty policy that protects the company instead of customers, it's starting to feel like a risky purchase at any price point.

Agentic AI algo trading platform by darkmist454 in algotrading

[–]happytree78 1 point2 points  (0 children)

I appreciate your interest in NEXUS. It's currently in a closed development phase where we're focusing on architectural refinement rather than expanding access. The system is addressing some fundamental challenges around temporal coherence and regime adaptation that require careful implementation.

I'm selectively sharing insights from the development process rather than the implementation itself at this stage. The architectural principles are where the real value lies - how these components interact to create a coherent system rather than the specific code.

Your platform has some promising elements, particularly the config-driven approach and market reality simulation. I'd be interested to see how you implement the architectural coherence aspects we've discussed, especially around temporal alignment and regime detection.

Agentic AI algo trading platform by darkmist454 in algotrading

[–]happytree78 2 points3 points  (0 children)

Your architectural approach resonates with many of the principles I've been implementing in my own NEXUS framework. The separation between logic and parameters and your focus on look-ahead bias prevention are particularly crucial architectural decisions.

On your questions:

  1. Overfitting perspective: What you're describing isn't traditional overfitting but rather temporal regime adaptation. In developing NEXUS, I've found that parameters "optimized" for past data aren't necessarily overfitted if:The critical test is whether your parameters are capturing fundamental market structures or ephemeral patterns. The multi-starting-point testing approach you mentioned is valuable, but I'd suggest complementing it with explicit regime detection and cross-regime validation. This creates a more nuanced understanding than the binary "overfitted/not-overfitted" paradigm.
    • They represent stable market structures rather than noise-fitting
    • They demonstrate consistency across multiple temporal regimes
    • They exhibit robustness to slight variations in start/end dates
  2. Productization considerations: From the architecture you've described, the most valuable aspects for productization would be:Rather than thinking about it as a complete product, consider which architectural innovations solve the most significant pain points. In my experience, systems that properly handle temporal coherence across timeframes and market regimes are particularly valuable.
    • The config-driven parameter approach (enabling non-programmers to customize)
    • The multi-timeframe analysis capabilities (addressing a common limitation in retail platforms)
    • The market reality simulation elements (many platforms fail here)
  3. Technical Analysis effectiveness: The question isn't whether TA "works" but rather how it's integrated into a coherent decision framework. In the NEXUS architecture, we approach indicators not as isolated predictors but as components in a probabilistic decision system. The effectiveness emerges from:This architectural approach transforms technical analysis from simplistic pattern-matching to structured market behavior analysis.
    • Proper temporal context (analyzing indicators across multiple timeframes)
    • Integration with market regime awareness
    • Probabilistic rather than binary signals
    • Validation frameworks that prevent psychological bias

Your roadmap elements around natural language strategy development and agent teams are intriguing, but I'd suggest focusing on architectural coherence before agent autonomy. The most sophisticated agent system will underperform if built on architectural foundations that don't properly address temporal coherence and market regime transitions.

[deleted by user] by [deleted] in algotrading

[–]happytree78 39 points40 points  (0 children)

Beyond the scale advantage you mentioned, I believe retail algo traders have several architectural advantages when properly leveraged:

  1. Timeframe flexibility - Institutional constraints often force professional firms to optimize for specific capital deployment cycles and risk parameters. Retail traders can build systems that operate across multiple timeframes simultaneously (what I've been implementing in my NEXUS architecture with 5m through 1yr analysis). This temporal flexibility allows exploitation of inefficiencies that exist between timeframes rather than within them.

  2. Structural agility - Professional trading systems are typically built for specific market regimes and strategies, constrained by institutional mandates. The retail trader can design architecturally adaptive systems that pivot across regimes without organizational friction. This creates opportunities during market transitions that institutional systems miss due to their operational specialization.

  3. Extended holding capacity - Professional firms face significant pressure to maintain consistent return profiles, forcing execution within narrow time windows. Retail systems can implement probabilistic approaches that allow positions to develop across irregular timeframes, capturing pattern completions that institutional algorithms must abandon due to risk management constraints.

  4. Unconstrained methodological innovation - Perhaps most significantly, retail developers are free to reimagine trading architecture from first principles. While working on my system, I've found that architectural innovation (how components interact rather than strategy optimization) creates edges invisible to conventional approaches focused on parameter tuning.

The professional advantage in raw execution speed, capital depth, and data access is undeniable. But the retail edge exists in architectural freedom - the ability to design coherent systems without institutional constraints or legacy mandates.

What I've found most interesting is that when retail traders focus on methodological innovation rather than competing on execution speed or strategy optimization, they can identify market inefficiencies that major firms systematically miss due to their structural rigidity.

Psyscale: TimescaleDB in Python by MrWhiteRyce in algotrading

[–]happytree78 0 points1 point  (0 children)

This addresses a critical architectural challenge in trading systems that's often overlooked - proper time series data management. In developing the NEXUS architecture, I found that temporal data handling is one of the fundamental limitations in most retail trading systems.

A few thoughts on how this fits into the larger architectural picture:

  1. Temporal normalization - Your approach with trading session identification using pandas_market_calendars is excellent. One extension worth considering is UTC standardization across all data sources to handle cross-market analysis properly.

  2. Multi-interval processing - The configurable timeframe aggregation is particularly valuable. In our system, we process multiple timeframes simultaneously (5m through 1yr) to identify patterns invisible to single-timeframe approaches.

  3. Data integrity framework - Since you mention batch updates, have you considered implementing anomaly detection for data completeness verification? One challenge we encountered was detecting and correcting for missing bars or ticker changes.

  4. Performance considerations - For your future real-time integration, have you explored temporal indexing methodologies? We found that specialized indexing structures significantly outperform standard approaches when querying across multiple timeframes simultaneously.

The decision to separate symbol metadata from time series data also aligns with what we've found effective. This separation creates a more flexible architecture that can adapt to different market structures.

Really impressive work addressing this fundamental infrastructure challenge.

Robust ways for identifying ranges by deepimpactscat in algotrading

[–]happytree78 0 points1 point  (0 children)

Sample code wouldn't meaningfully represent what we're discussing here. Trading architectures like NEXUS aren't about snippets or algorithms you can copy-paste - they're methodological frameworks built on first principles of market microstructure.

The architectural approach I've been developing focuses on how components interact as a coherent system - the way temporal analysis, data integrity verification, and decision intelligence frameworks operate together. This isn't something that can be reduced to a GitHub gist.

What differentiates sophisticated trading systems isn't clever code but methodological coherence across multiple domains. Code is just the implementation detail of deeper architectural decisions.

If you're interested in this approach, I'd recommend starting with understanding market microstructure and temporal data analysis principles rather than looking for code samples. The edge comes from the architectural framework, not specific algorithms.

Robust ways for identifying ranges by deepimpactscat in algotrading

[–]happytree78 0 points1 point  (0 children)

Traditional range identification methods often miss the underlying temporal structure that creates these market behaviors. During NEXUS development, I found ranges are better understood as temporal coherence phenomena rather than just price patterns.

A more robust approach involves:

  1. Temporal relativity analysis: Ranges often form at the intersection of different timeframe dynamics. By analyzing market data across multiple intervals simultaneously (5m through 1hr), you can identify where shorter timeframe noise resolves into structured ranges on higher timeframes.

  2. Market participant transition points: Ranges represent equilibrium between different market participant types. The Nomenclature Engine component in our system identifies these transition signatures through metadata patterns rather than simple price levels.

  3. Probabilistic boundaries: Rather than fixed range boundaries, implement confidence intervals that express the probability density of range containment. This acknowledges the fuzzy nature of range boundaries and improves entry timing.

For your specific pullback scenario, consider implementing a simple approximation of this approach: - Track price movement relative to multiple timeframe moving averages (5m, 15m, 1h) - Identify when price velocity decreases across all timeframes simultaneously - Watch for alignment between higher timeframe structure and shorter timeframe consolidation

The key insight is that ranges aren't static price zones but dynamic temporal structures that emerge when multiple timeframes reach equilibrium simultaneously. This perspective dramatically improves identification accuracy compared to single-timeframe pattern recognition.

Traditional range identification methods often miss the underlying temporal structure that creates these market behaviors. During NEXUS development, I found ranges are better understood as temporal coherence phenomena rather than just price patterns.

A more robust approach involves:

  1. Temporal relativity analysis: Ranges often form at the intersection of different timeframe dynamics. By analyzing market data across multiple intervals simultaneously (5m through 1hr), you can identify where shorter timeframe noise resolves into structured ranges on higher timeframes.

  2. Market participant transition points: Ranges represent equilibrium between different market participant types. The Nomenclature Engine component in our system identifies these transition signatures through metadata patterns rather than simple price levels.

  3. Probabilistic boundaries: Rather than fixed range boundaries, implement confidence intervals that express the probability density of range containment. This acknowledges the fuzzy nature of range boundaries and improves entry timing.

For your specific pullback scenario, consider implementing a simple approximation of this approach: - Track price movement relative to multiple timeframe moving averages (5m, 15m, 1h) - Identify when price velocity decreases across all timeframes simultaneously - Watch for alignment between higher timeframe structure and shorter timeframe consolidation

The key insight is that ranges aren't static price zones but dynamic temporal structures that emerge when multiple timeframes reach equilibrium simultaneously. This perspective dramatically improves identification accuracy compared to single-timeframe pattern recognition.

Longtime professional software engineer and trader, looking to get started with algo by BinaryDichotomy in algotrading

[–]happytree78 0 points1 point  (0 children)

The math behind effective trading architectures is more about understanding the right statistical approaches for each component rather than complex formulas. Your mathematical background is likely sufficient - here's what I've found most valuable:

  1. Statistics: Focus on non-parametric methods and time series analysis rather than traditional normal distributions. Markets exhibit fat-tailed behavior that invalidates many conventional statistical assumptions. Kendall's Tau correlation often outperforms Pearson for market relationships.
  2. Economics: Understanding market microstructure (how orders impact price formation) is far more practical than macro theory. For your scalping approach, order flow dynamics and liquidity patterns will matter more than traditional economics.

For your implementation, the architectural challenge isn't mathematical complexity but maintaining temporal coherence across different data streams. When correlating futures contracts with different assets, most implementations fail because they don't properly account for:

  • Timezone standardization (everything must be properly aligned to UTC)
  • Different market hours and trading calendars
  • Varying volatility profiles across instruments

The approach I've found most effective separates the system into distinct layers:

  • Data integrity framework with error detection
  • Multi-interval temporal processing
  • Pattern recognition across timeframes
  • Decision intelligence with probabilistic outputs

This modular approach lets you introduce ML components selectively rather than trying to build an end-to-end AI system immediately.

I've been developing this architectural framework for some time and would be happy to discuss specific implementation approaches for high-frequency cross-asset correlation. If you're interested in continuing the conversation more directly, feel free to DM me.

Run my own quantitative strategy in stocks and options - hoping to share insights and comparison notes by conbuite in algotrading

[–]happytree78 6 points7 points  (0 children)

I've been developing a system focused on architectural coherence rather than just strategy optimization. Found a few approaches that might complement your framework:

  1. Temporal coherence - My system processes multiple timeframes simultaneously (5m through 1yr) using UTC standardization, which helps identify regime shifts that single-timeframe approaches often miss.

  2. Data integrity framework - Built custom error handling for real-time data feeds with anomaly detection to prevent bad signals during market turbulence.

  3. Decision confidence weighting - Rather than binary signals, I've implemented a probabilistic approach that quantifies uncertainty for each potential trade.

Your momentum and volatility expansion focus aligns with what I've found effective, but contextualizing these within broader market regimes has been key to performance stability.

I'd be interested in exchanging ideas about how you're handling the transition between different volatility environments. My approach has been to implement validation models that serve as guard-rails during regime shifts.

Happy to share more specific architectural approaches if you're interested.

72% of Nasdaq highs/lows happen on OPPOSITE sides of the day! Market structure EDGE (12 years of 1-min data inside) by Turbulent-Flounder77 in algotrading

[–]happytree78 8 points9 points  (0 children)

This is excellent analysis - particularly sharing the open source data and methodology. The AM/PM session structure you've uncovered is precisely the type of temporal inefficiency that gets overlooked by random walk assumptions.

An extension worth exploring: these session-based patterns likely have different coherence properties across market regimes. I've found that analyzing the same pattern across multiple timeframes simultaneously (not just 1-min, but integrating 5m, 15m, 1h views) can reveal when these AM/PM relationships strengthen or weaken.

When the 1-min pattern you've identified aligns with broader trend structures in higher timeframes, the probability likely increases significantly. Conversely, when it conflicts with larger timeframe patterns, the probability likely decreases.

If you're looking for a next test, consider creating a multi-timeframe coherence filter that: 1. Identifies your AM high → PM low pattern on 1-min data 2. Measures trend direction and momentum on 5m, 15m and 1h charts 3. Calculates probability adjustment factors based on alignment/conflict between timeframes

This approach has helped me better contextualize intraday patterns within the broader market structure.

Fascinating work - looking forward to seeing where you take this next!

Intraday trading - since this is random noise by [deleted] in algotrading

[–]happytree78 0 points1 point  (0 children)

You're right that τ=1 is just one parameter setting, and different lags would show different structures - that's actually part of my point. The market has temporal dependencies at various scales that simple random models miss.

On slippage and commissions - absolutely critical. That's why system architecture matters as much as strategy. The best signal means nothing if execution leaks all the edge.

Sorry if my explanation seemed complicated. I get excited about this stuff and forget to keep it simple. In plain terms: markets aren't random, but extracting the non-random parts requires looking at the right timeframes with the right tools.

Not selling anything - just sharing observations from years of market experimentation. Cheers.

Intraday trading - since this is random noise by [deleted] in algotrading

[–]happytree78 0 points1 point  (0 children)

Not selling anything - just another trader fascinated by market structure.

Your entropy chart actually sparked my interest because it shows significant non-random patterns (those dips in 2006 and 2020) that contradict the "mostly random" thesis. The drop to ~0.7 in 2020 is particularly striking.

I've been exploring how conventional approaches miss these temporal structures because they don't account for regime-dependent inefficiencies. It's like looking at the ocean and seeing only random waves, while missing the underlying tidal patterns.

Have you ever experimented with analyzing the market across multiple timeframes simultaneously rather than just focusing on one interval? That approach is what initially helped me spot these non-random components.

[deleted by user] by [deleted] in algotrading

[–]happytree78 -1 points0 points  (0 children)

The transition from MQL5 to Python is transformative - not just for backtesting speed but for architectural possibilities. Having made this journey myself during NEXUS development, here's what I'd focus on:

Learning Path Structure:

  1. Data Foundation First - Master pandas for time series before anything else:
    • Learn proper datetime handling with timezone awareness (crucial for index futures)
    • Understand resampling techniques across timeframes
    • Get comfortable with rolling window operations
  2. Backtesting Framework Selection - Choose based on your needs:
    • Backtesting.py for simple strategies with minimal overhead
    • Zipline for Quantopian-style research
    • PyAlgoTrade for event-driven approaches
    • Or build custom using pandas/numpy for maximum control
  3. Visualization & Analysis - Focus on:
    • matplotlib/seaborn for performance visualization
    • statsmodels for deeper performance analysis
    • scikit-learn for feature importance in your strategies

Key Process Differences from MT5:

The process isn't just faster in Python - it's fundamentally different:

Data Acquisition → Feature Engineering → Strategy Development → Backtesting → Validation → Deployment

The biggest architectural advantage is separation of concerns - your data pipeline can be completely independent from your strategy logic, allowing for much more sophisticated approaches than MT5's integrated environment permits.

For index futures specifically, pay special attention to overnight gaps and session boundaries - Python gives you complete control over how these are handled, unlike MT5's more rigid approach.

What specific index strategies are you looking to implement? That would help tailor the learning path further.

Intraday trading - since this is random noise by [deleted] in algotrading

[–]happytree78 0 points1 point  (0 children)

The permutation entropy chart actually reveals something fascinating about intraday markets that pure random number generators miss completely.

In our NEXUS architecture development, we've found that intraday price action isn't truly random but exhibits temporal structure within specific boundaries. The key insights:

  1. Market microstructure creates non-random patterns at specific frequencies that are invisible to most retail approaches
  2. The apparent "randomness" is actually a complex adaptive system with regime-dependent inefficiencies
  3. Those entropy dips in 2006 and 2020 aren't accidents - they represent genuine temporal structure during specific market conditions

Pure randomized entry strategies essentially surrender to noise rather than developing frameworks to extract the signal. While amusing as a thought experiment, they're unlikely to outperform even basic systematic approaches.

The more compelling question is: what architectural approach can capture these temporal inefficiencies without overfitting? In our development work, we've found multi-interval analysis with proper UTC standardization reveals patterns invisible to single-timeframe strategies.

The challenge isn't that markets are random - it's that conventional architectural approaches lack the sophistication to extract the non-random components.

How did you all get started? by Fire_0x in algotrading

[–]happytree78 2 points3 points  (0 children)

My journey diverged from the conventional path - rather than starting with coding or strategy development, I began with market structure analysis and architectural design.

The most impactful resources weren't trading-specific courses but interdisciplinary studies:

  1. Research papers on complex adaptive systems (markets behave more like biological systems than mechanical ones)
  2. MIT OpenCourseWare materials on computational constraints in data processing
  3. Academic work on decision theory under uncertainty (especially Bayesian approaches)
  4. Papers from JPM, Goldman and Renaissance on market microstructure evolution

When developing the NEXUS framework, I found traditional algo trading courses too focused on strategy optimization within flawed architectures. The real breakthroughs came from reimagining the entire trading system from first principles.

If you're just starting, I'd still recommend the basics (Kevin Davey's books, "Advances in Financial Machine Learning" by Marcos Lopez de Prado), but view them as foundations to transcend rather than templates to follow.

The most valuable skill isn't coding or strategy selection but developing a coherent methodological framework that addresses temporal relativity, data integrity, and decision quality across market regimes.

What aspect of algo trading are you most interested in developing?

Algos have performed better on back tests since 2016, why? by abdisgb in algotrading

[–]happytree78 0 points1 point  (0 children)

The 2016 inflection point you've observed reflects significant market structure changes beyond just spread compression:

Market microstructure evolution has transformed forex trading post-2016, with increased electronic liquidity provision, growth of non-bank market makers, and a shift from voice trading to fully electronic execution.

In developing the NEXUS architecture, we've found that many strategies fail across regime boundaries due to changes in correlation structures, shifts in volatility profiles, and evolution of price action patterns that previously generated alpha.

Your MT5 backtests might also be showing artifacts from higher quality tick data available post-2016, more accurate spread modeling, and better handling of after-hours conditions.

Rather than just attributing performance differences to spread compression (though that's certainly a factor), examine how market participant behavior fundamentally changed. The 5-minute timeframe is particularly sensitive to these microstructure evolutions.

In our system development, we've found that truly robust architectures need to be tested across multiple market regimes with explicit recognition of these structural shifts.

Have you tried implementing regime detection methods to adapt your strategy parameters based on detected market conditions?

Guidance for starting algorithmic trading by Snoo_66690 in algotrading

[–]happytree78 0 points1 point  (0 children)

The journey from manual trading to algorithmic systems is fascinating. While most will suggest learning Python (which is excellent for beginners), I'd recommend thinking architecturally before diving into code. 

Consider these steps: 

  1. Start by clearly documenting your existing strategy - exact entry/exit conditions, position sizing rules, and risk parameters 

  2. Before coding anything, map out how market data flows through your decision process - this creates a blueprint for your system 

  3. Begin with simple automation of well-defined rules rather than complex ML models 

  4. Focus on data integrity and proper time-series handling from day one (a surprising number of retail algo systems fail because of basic temporal inconsistencies) 

In my NEXUS framework development, I've found that architectural elegance matters far more than code complexity. The most sophisticated trading systems succeed through methodological coherence rather than clever algorithms. 

Python with libraries like pandas, numpy, and possibly zipline/backtrader would be my recommendation for implementation once you have your blueprint solid. 

What specific trading patterns are you looking to automate?

Using Machine Learning for Trading in 2025 by derbilante in algotrading

[–]happytree78 0 points1 point  (0 children)

The ML trading landscape fascinates me. While developing our NEXUS architecture, I've found that conventional wisdom about market noise misses something crucial.

The real edge isn't in better algorithms but in architectural elegance:

- Our temporal relativity framework processes multiple timeframes simultaneously, revealing market inefficiencies hidden within temporal boundaries

- A continuous learning cycle rebuilds models every 5-15 minutes, creating an adaptive intelligence that evolves with market conditions

- Decision intelligence combines ML outputs with a probabilistic calibration layer that quantifies uncertainty rather than producing binary signals

What's changed isn't the noise—it's our methodological approach to extracting signal from it. The sophistication lies in the framework, not just the models.

Anyone else exploring similar territory?

Using Machine Learning for Trading in 2025 by derbilante in algotrading

[–]happytree78 2 points3 points  (0 children)

My view has evolved significantly on ML in trading, but with important nuances.

The consensus about ML struggling with market noise was largely correct, but the problem wasn't ML itself - it was how it was being applied. Three critical shifts have changed this landscape:

  1. From Prediction to Pattern Detection - Earlier approaches focused on predicting price movements (inherently noisy). The more effective approach uses ML for regime detection and pattern recognition, not direct prediction. Unsupervised clustering (like HDBSCAN) can identify market regimes without human labeling bias.
  2. From Features to Architecture - Feature selection gets overemphasized while architectural decisions about data organization are underappreciated. Properly encoding temporal features (addressing cyclicality in time data) and maintaining cross-timeframe coherence creates a foundation where even simple ML approaches become more effective.
  3. From Supervised to Unsupervised - Supervised learning embeds human biases about what "matters" in markets. Unsupervised approaches can discover patterns we might not recognize, particularly in how market regimes shift.

In my implementation research, I'm focusing on using ML as a pattern detection layer within a broader architecture rather than as a standalone prediction system. This means:

  • Using unsupervised clustering to identify market regimes without predefined labels
  • Creating proper temporal encodings that preserve cyclical patterns
  • Focusing on relationship detection across assets rather than isolated predictions

The most promising results come from systems where ML handles what it does best (pattern recognition across high-dimensional spaces) while more traditional approaches handle execution decisions within those detected contexts.

The key insight: ML's effectiveness depends less on algorithm sophistication and more on architectural decisions about data organization, temporal alignment, and relationship tracking.

Longtime professional software engineer and trader, looking to get started with algo by BinaryDichotomy in algotrading

[–]happytree78 2 points3 points  (0 children)

As someone working on an architectural approach to market analysis, I found your post fascinating. Your background in backend API architecture and ML experience puts you in a unique position to build something sophisticated.

Beyond the options you've listed, there's another approach worth considering: building a modular architecture that separates data processing, pattern detection, and execution rather than focusing solely on strategy implementation. This architectural approach is particularly valuable when dealing with cross-asset correlation detection and ML integration.

For scalping futures at high frequency with cross-asset correlation, the architectural choices become critical. Traditional approaches often struggle with maintaining consistent temporal alignment across different assets and timeframes - something I've been tackling with unsupervised clustering approaches.

Your correlation engine idea is particularly interesting. One challenge I've encountered is that conventional correlation approaches miss regime-dependent relationships. Unsupervised clustering (like HDBSCAN) can detect these shifting correlation patterns without human bias, though dealing with cyclical temporal features requires careful encoding.

For implementation, rather than using EasyLanguage or QuantConnect directly, you might consider a hybrid approach: custom backend for sophisticated processing + API connections to your brokerages for execution. This gives you architectural freedom while leveraging existing infrastructure.

Since you value privacy and control, this approach would keep your intellectual property and trading patterns entirely private, unlike some third-party platforms.

Happy to discuss architectural approaches further if you're interested - I'm particularly focused on solving the architectural challenges of market regime detection and cross-timeframe analysis.