## Problem
Multiple partial_close actions on the same position were being counted as separate trades, inflating TotalTrades count and distorting win rate/profit factor statistics.
**Example of bug:**
- Open 1 BTC @ $100,000
- Partial close 30% @ $101,000 → Counted as trade #1❌
- Partial close 50% @ $102,000 → Counted as trade #2❌
- Close remaining 20% @ $103,000 → Counted as trade #3❌
- **Result:** 3 trades instead of 1 ❌
## Solution
### 1. Added tracking fields to openPositions map
- `remainingQuantity`: Tracks remaining position size
- `accumulatedPnL`: Accumulates PnL from all partial closes
- `partialCloseCount`: Counts number of partial close operations
- `partialCloseVolume`: Total volume closed partially
### 2. Modified partial_close handling logic
- Each partial_close:
- Accumulates PnL into `accumulatedPnL`
- Reduces `remainingQuantity`
- **Does NOT increment TotalTrades++**
- Keeps position in openPositions map
- Only when `remainingQuantity <= 0.0001`:
- Records ONE TradeOutcome with aggregated PnL
- Increments TotalTrades++ once
- Removes from openPositions map
### 3. Updated full close handling
- If position had prior partial closes:
- Adds `accumulatedPnL` to final close PnL
- Reports total PnL in TradeOutcome
### 4. Fixed GetStatistics()
- Removed `partial_close` from TotalClosePositions count
- Only `close_long/close_short/auto_close` count as close operations
## Impact
- ✅ Statistics now accurate: multiple partial closes = 1 trade
- ✅ Win rate calculated correctly
- ✅ Profit factor reflects true performance
- ✅ Backward compatible: handles positions without tracking fields
## Testing
- ✅ Compiles successfully
- ⚠️ Requires validation with live partial_close scenarios
## Code Changes
```
logger/decision_logger.go:
- Lines 420-430: Add tracking fields to openPositions
- Lines 441-534: Implement partial_close aggregation logic
- Lines 536-593: Update full close to include accumulated PnL
- Lines 246-250: Fix GetStatistics() to exclude partial_close
```
Add missing fields to TradeOutcome:
- Quantity: Position size
- Leverage: Leverage multiplier
- PositionValue: Total position value (quantity × openPrice)
- MarginUsed: Margin required (positionValue / leverage)
This provides complete trade information for analysis and display.
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
Major fixes:
1. Trade History data loss issue
- Root cause: Open records outside analysis window caused close matching failures
- Solution: Pre-populate position state by reading 3x window of historical records
- Ensures long-term positions (>5 hours) generate correct trade records
2. P&L calculation errors
- Remove incorrect leverage multiplication from absolute P&L
- Correct calculation: Futures P&L = quantity × price difference
- Leverage only affects P&L percentage (relative to margin)
3. Other fixes
- Break-even trades (pnl=0) no longer misclassified as losses
- Perfect strategy shows Profit Factor as 999.0 instead of 0.0
- Expand analysis window from 20 to 100 cycles (5 hours)
Files changed:
- logger/decision_logger.go: Core matching and calculation logic
- api/server.go: API analysis window
- trader/auto_trader.go: AI decision analysis window
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
Critical bug fix in Sharpe Ratio calculation logic:
Problem:
- Previously calculated equity as TotalBalance + TotalUnrealizedProfit
- This was incorrect because TotalBalance already stores TotalEquity
- TotalUnrealizedProfit actually stores TotalPnL (not unrealized profit)
- This caused: equity = 2 * TotalEquity - InitialBalance (wrong!)
Root cause:
- Field naming mismatch between AccountSnapshot and actual stored values
- TotalBalance field actually contains TotalEquity (wallet + unrealized)
- TotalUnrealizedProfit field actually contains TotalPnL (equity - initial)
Solution:
- Use TotalBalance directly as it already represents complete account equity
- Added clear comments explaining the field name vs content mismatch
- Sharpe Ratio now correctly calculates risk-adjusted returns
Impact:
- Sharpe Ratio values are now mathematically accurate
- AI performance assessment is now reliable
- No changes needed to data storage or API layer
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
Backend changes (logger/decision_logger.go):
- Fixed Profit Factor to use standard formula (total profit / total loss)
- Previously used average values which was incorrect when win/loss counts differ
- Now saves total amounts before calculating averages for accurate ratio
Frontend changes (web/src/components/AILearning.tsx):
- Fixed display units: changed USDT amounts from "%" to "USDT"
- Updated avg_win and avg_loss to show "USDT Average" instead of "%"
- Updated best/worst performer displays to show "USDT" instead of "%"
- Added "(USDT)" labels to table headers for clarity
- Removed "%" from all table data cells showing monetary amounts
This ensures accurate performance metrics and eliminates user confusion
between percentage values and absolute USDT amounts.
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
Fixed critical issues in historical trade record and performance analysis:
1. PnL Calculation: Changed from percentage-only to actual USDT amount
- Now correctly calculates: positionValue × priceChange% × leverage
- Previously: 100U@5% and 1000U@5% both showed 5.0
- Now: Properly reflects different position sizes and leverage
2. Position Tracking: Added quantity and leverage to open position records
- Store complete trade data for accurate PnL calculation
- Previously only stored: side, openPrice, openTime
- Now includes: quantity, leverage for proper accounting
3. Position Key: Fixed to distinguish long/short positions
- Changed from symbol to symbol_side (e.g., BTCUSDT_long)
- Prevents conflicts when holding both long and short positions
4. Sharpe Ratio: Replaced custom Newton's method with math.Sqrt
- Simplified standard deviation calculation
- More reliable and maintainable
Impact: Win rate, profit factor, and Sharpe ratio now based on accurate USDT amounts
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
Major improvements:
- Use period-level Sharpe ratio (range -2 to +2) instead of annualized
- Save full user prompt in decision logs for debugging
- Format complete market data (3m + 4h candles) for AI analysis
- Prevent position stacking with duplicate position checks
- Update Sharpe ratio interpretation thresholds
Market data enhancements:
- Display full technical indicators in user prompt
- Include 3-minute and 4-hour timeframe data
- Add OI (Open Interest) change and funding rate signals
Risk control:
- Block opening duplicate positions (same symbol + direction)
- Suggest close action first before opening new position
- Prevent margin usage from exceeding limits
UI improvements:
- Update multi-language translations
- Refine AI learning dashboard display
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
- Implement Sharpe ratio calculation in decision logger
- Add adaptive behavior recommendations based on Sharpe ratio
- Display Sharpe ratio in AI learning dashboard with visual indicators
- Enable AI to adjust trading strategy based on risk-adjusted returns
- Color-coded performance levels (red/yellow/green) for easy monitoring
Co-Authored-By: tinkle-community <tinklefund@gmail.com>
- Frontend trading records and UI enhancements
- Optimized AI prompts and decision engine
- Performance analysis and comparison features
- Binance-style UI improvements
- Multi-AI competition mode (Qwen vs DeepSeek)
- Binance Futures integration
- AI self-learning mechanism
- Professional web dashboard
- Complete risk management system
Linden
Icyoung
tangmengqiu
ZhouYongyou
SkywalkerJi
tinkle-community