Сandles go outside the area. #430
Comments
|
Fixed in 3.6.4 |
rocso
added a commit
to rocso/apexcharts.js
that referenced
this issue
Jan 13, 2024
This change also fixes the root cause of issue apexcharts#430, allowing the removal of the previous fix.
rocso
added a commit
to rocso/apexcharts.js
that referenced
this issue
Jan 17, 2024
This change also fixes the root cause of issue apexcharts#430, allowing the removal of the previous fix.
rosco54
pushed a commit
to rosco54/apexcharts.js
that referenced
this issue
Feb 10, 2024
early due to cumulative precision errors in JS float representations. This is also the root cause of issue apexcharts#430, allowing the removal of the previous fix. Add NetBeans IDE config and ignore private resources. Exclude line and area chart from +/-5% range expansion that is applied to accommodate box and candlestick elements. Remove the unnecessary range expansion because the cited issue apexcharts#426 looks fine without it. Remove code from previous fixes for the following issues, as the examples provided with those issues display correctly with recent commits: Previous fix for issue apexcharts#492 is obsolete, possibly following commit #4562468 that fixed cases where the Y axis missed including the uppermost tick due to JS precision errors. NetBeans config, including to allow node.js builds from within NB. If the user defines options that are consistent amongst themselves, don't adjust them, apply them as-is. In computing the provisional nice step size, set magMsd to integer subdivisions of 10, i.e. magPow*[1,2,5,10], eliminating ugly values that are magPow*[3,4,6,7,8,9]. This can be overridden by setting stepSize and setting forceNiceScale: true. If the given stepSize is bigger than the range, or impractically small and resulting in excessive ticks, apply it after normalizing it the chart order of magnitude and checking again for consistency. E.g. if the range = 0.4 and user sets stepSize: 8 (or 8000 or 0.0008), then stepSize is obviously disproportionate and impractical. Normalize it to 0.08 or 0.008 depending on tickAmount etc. Root Cause Fix: getminYmaxY() not determining chart min and max according to series type, thus returning incorrect values. For example, e2e test "candlestick/candlestick-line.html" has chart.type "line" while the two series' have types "line" and "candlestick" respectively. The candlestick data min/max was being determined as for a "line" series. Modified unit tests: Brought into line with changes introduced in the current branch to prevent trivial failure reports. New sample to verify duplicate label removal by formatter. All working except for brush-charts, which are experimental and don't call niceScale yet. Add utility functions: getGCD() - return GCD of two numbers (not used in this version) getPrimeFactors() - return all prime factors of an integer mod() - a mod b: to overcome precision errors Reduce ticks nicely as chart size is reduced, if options allow. Multi series/multi yaxis charts: attempt to use consistent tickAmounts so they line up. Per series options override may override this. Adjust some tickAmount values in e2e samples now that users should expect to see that many ticks. Set default ticks back to 10. A default of 5 has the following undesirable effects: Most charts work with base 10 numbers, and 10/5=2, which tends to produce tick spacings of 0.2, 2, 20, etc. This tends to visually bunch graphs toward the centre of the axis range, leaving more of the chart area unused. Having 10 as the default reverses this tendency, bringing data points closer to the extremities of the range. defaults.js: remove the default tickAmount = 6 for polarArea charts. Let niceScale determine it if not user defined. radar-with-polygom-fill.xml: remove user defined tickAmount = 7. Let niceScale() determine it, otherwise 7 ticks are what will be drawn, which will produce a sub-optimal chart for the sample data.
rosco54
pushed a commit
to rosco54/apexcharts.js
that referenced
this issue
Feb 10, 2024
early due to cumulative precision errors in JS float representations. This is also the root cause of issue apexcharts#430, allowing the removal of the previous fix. Root Cause Fix: getMinYMaxY(): 1) not determining chart min and max according to series type, thus returning incorrect values. For example, e2e test "candlestick/candlestick-line.html" has chart.type "line" while the two series' have types "line" and "candlestick" respectively. The candlestick data min/max was being determined as for a "line" series. 2) Erroneous if conditional logic allowing entry to all chart types rather than just the targeted types. Exclude line and area charts from +/-5% range expansion that is applied to accommodate box and candlestick elements. See below: root cause fix. Remove the unnecessary range expansion. Root cause fixed. Several locations: remove code from previous fixes for the following issues, as the examples provided in those issue reports display correctly now: Previous fix for issue apexcharts#492 is obsolete, possibly following commit #4562468 that fixed cases where the Y axis missed including the uppermost tick due to JS precision errors. If the user defines options that are consistent amongst themselves, apply them without adjustment. In computing the provisional nice step size, set magMsd only to integer subdivisions of 10, i.e. magPow*[1,2,5,10], eliminating unhelpful values like magPow*[3,4,6,7,8,9]. This can be overridden by setting stepSize and setting forceNiceScale: true. Then, if the given stepSize is bigger than the range, or impractically small and resulting in excessive ticks, apply it after normalizing it the chart order of magnitude and checking again for consistency. E.g. if the range = 0.4 and user sets stepSize: 8 (or 8000 or 0.0008), then stepSize is obviously disproportionate and impractical. Normalize it to 0.08 or 0.008 depending on tickAmount etc. Rename the class in Scales.js from "Range" to "Scales" to avoid being confused with the "Range" class defined in Range.js. Modified unit tests: Brought into line with changes introduced in the current branch to prevent trivial failure reports. New unit tests to verify priority of user defined options. New e2e sample to verify duplicate label removal by formatter. AFAICS, the only way to hide labels that don't correspond to tick values is via the formatters. This is the cause of duplicate values on axes. All working except for brush-charts, which don't call niceScale. Add utility functions: getGCD() - return GCD of two numbers (not used in this version) getPrimeFactors() - return all prime factors of an integer mod() - a mod b: to overcome precision errors Reduce ticks nicely as chart svg size gets smaller, if options allow. Multi series/multi yaxis charts: attempt force consistent tickAmounts so they line up with the grid. Per series user tickAmount override this. Adjust some tickAmount values in e2e samples now that user defined tickAmount is honoured unless it conflicts with other user defined options. Set default ticks back to 10. With the proposed changes, the default value only influences the computed nice step size and is reduced to best fit the data after that. The previous default of 5 has the following visual effect: Most charts work with base 10 numbers, and 10/5=2, which tends to produce tick spacings of 0.2, 2, 20, etc. This tends to visually squeeze graphs toward the centre of the chart, leaving more of the peripheral chart area unused, lowering resolution. Having 10 as the default reverses this tendency, bringing data points closer to the extremities of the range. defaults.js: remove the default tickAmount = 6 for polarArea charts. Let niceScale determine it if not user defined. radar-with-polygon-fill.xml: remove user defined tickAmount = 7. Let niceScale() determine it, otherwise 7 ticks are what will be drawn, which will produce a sub-optimal chart for the sample data. multiple-yaxes.xml: associate y axes with their correct series'. The visual change in the chart is that the Income yaxis is scaled correctly. Further highlights the other changes in this commit, showing the alignment of all y scale labels with the grid. Add NetBeans IDE config and ignore private resources.
rosco54
added a commit
to rosco54/apexcharts.js
that referenced
this issue
Feb 10, 2024
…early due to cumulative precision errors in JS float representations. This is also the root cause of issue apexcharts#430, allowing the removal of the previous fix. Root Cause Fix: getMinYMaxY(): 1) not determining chart min and max according to series type, thus returning incorrect values. For example, e2e test "candlestick/candlestick-line.html" has chart.type "line" while the two series' have types "line" and "candlestick" respectively. The candlestick data min/max was being determined as for a "line" series. 2) Erroneous if conditional logic allowing entry to all chart types rather than just the targeted types. Exclude line and area charts from +/-5% range expansion that is applied to accommodate box and candlestick elements. See below: root cause fix. Remove the unnecessary range expansion. Root cause fixed. Several locations: remove code from previous fixes for the following issues, as the examples provided in those issue reports display correctly now: Previous fix for issue apexcharts#492 is obsolete, possibly following commit #4562468 that fixed cases where the Y axis missed including the uppermost tick due to JS precision errors. If the user defines options that are consistent amongst themselves, apply them without adjustment. In computing the provisional nice step size, set magMsd only to integer subdivisions of 10, i.e. magPow*[1,2,5,10], eliminating unhelpful values like magPow*[3,4,6,7,8,9]. This can be overridden by setting stepSize and setting forceNiceScale: true. Then, if the given stepSize is bigger than the range, or impractically small and resulting in excessive ticks, apply it after normalizing it the chart order of magnitude and checking again for consistency. E.g. if the range = 0.4 and user sets stepSize: 8 (or 8000 or 0.0008), then stepSize is obviously disproportionate and impractical. Normalize it to 0.08 or 0.008 depending on tickAmount etc. Rename the class in Scales.js from "Range" to "Scales" to avoid being confused with the "Range" class defined in Range.js. Modified unit tests: Brought into line with changes introduced in the current branch to prevent trivial failure reports. New unit tests to verify priority of user defined options. New e2e sample to verify duplicate label removal by formatter. AFAICS, the only way to hide labels that don't correspond to tick values is via the formatters. This is the cause of duplicate values on axes. All working except for brush-charts, which don't call niceScale. Add utility functions: getGCD() - return GCD of two numbers (not used in this version) getPrimeFactors() - return all prime factors of an integer mod() - a mod b: to overcome precision errors Reduce ticks nicely as chart svg size gets smaller, if options allow. Multi series/multi yaxis charts: attempt force consistent tickAmounts so they line up with the grid. Per series user tickAmount override this. Adjust some tickAmount values in e2e samples now that user defined tickAmount is honoured unless it conflicts with other user defined options. Set default ticks back to 10. With the proposed changes, the default value only influences the computed nice step size and is reduced to best fit the data after that. The previous default of 5 has the following visual effect: Most charts work with base 10 numbers, and 10/5=2, which tends to produce tick spacings of 0.2, 2, 20, etc. This tends to visually squeeze graphs toward the centre of the chart, leaving more of the peripheral chart area unused, lowering resolution. Having 10 as the default reverses this tendency, bringing data points closer to the extremities of the range. defaults.js: remove the default tickAmount = 6 for polarArea charts. Let niceScale determine it if not user defined. radar-with-polygon-fill.xml: remove user defined tickAmount = 7. Let niceScale() determine it, otherwise 7 ticks are what will be drawn, which will produce a sub-optimal chart for the sample data. multiple-yaxes.xml: associate y axes with their correct series'. The visual change in the chart is that the Income yaxis is scaled correctly. Further highlights the other changes in this commit, showing the alignment of all y scale labels with the grid. Add NetBeans IDE config and ignore private resources. Core.setupBrushHandler(): Bug fix: needed to clone targetChart.w.config.yaxis, not w.config.yaxis. Removed call to Scales.autoScaleY() and the assignment of results to the target chart yaxis. We no longer clobber the yaxis min and max elements, leaving them for the user if they want to define them. Only needs to record the event xaxis min and max for the target chart. Scales.autoScaleY(): Removed. Not required. Range.setYRange() and Range.getMinYMaxY() are now aware of xaxis min max range from the brush selection event. These functions are called as part of the target chart redrawing following the triggering of the selection event loop in Core.setupBrushHandler(). Range.getMinYMaxY(): Work with brush X ranges. Range.setYRange(): Allow mulitple Y axes to be scaled with Y ranges corresponding to their independent data series'. Brush now works with all appropriate chart arrangements, including multiple series, multiple axes, collapsible series', combos, etc. line/brush-charts.xml: Modified to demonstrate brush charts with multiple collapsible series and multiple Y axes, with dynamic "nice" scaling of axes. Unit test: yaxis-min-max-spec.js Specific Test: "min and max functions in multiple yaxis should return correct values in params". Charts with multiple Y axes can have different min values. Other changes in this patchset ensure "nice" scaling plus alignment of ticks with grid lines. Users can set minimums and maximums as per axis options to override the default auto-ranging.
rosco54
added a commit
to rosco54/apexcharts.js
that referenced
this issue
Feb 11, 2024
…early due to cumulative precision errors in JS float representations. This is also the root cause of issue apexcharts#430, allowing the removal of the previous fix. Root Cause Fix: getMinYMaxY(): 1) not determining chart min and max according to series type, thus returning incorrect values. For example, e2e test "candlestick/candlestick-line.html" has chart.type "line" while the two series' have types "line" and "candlestick" respectively. The candlestick data min/max was being determined as for a "line" series. 2) Erroneous if conditional logic allowing entry to all chart types rather than just the targeted types. Exclude line and area charts from +/-5% range expansion that is applied to accommodate box and candlestick elements. See below: root cause fix. Remove the unnecessary range expansion. Root cause fixed. Several locations: remove code from previous fixes for the following issues, as the examples provided in those issue reports display correctly now: Previous fix for issue apexcharts#492 is obsolete, possibly following commit #4562468 that fixed cases where the Y axis missed including the uppermost tick due to JS precision errors. If the user defines options that are consistent amongst themselves, apply them without adjustment. In computing the provisional nice step size, set magMsd only to integer subdivisions of 10, i.e. magPow*[1,2,5,10], eliminating unhelpful values like magPow*[3,4,6,7,8,9]. This can be overridden by setting stepSize and setting forceNiceScale: true. Then, if the given stepSize is bigger than the range, or impractically small and resulting in excessive ticks, apply it after normalizing it the chart order of magnitude and checking again for consistency. E.g. if the range = 0.4 and user sets stepSize: 8 (or 8000 or 0.0008), then stepSize is obviously disproportionate and impractical. Normalize it to 0.08 or 0.008 depending on tickAmount etc. Rename the class in Scales.js from "Range" to "Scales" to avoid being confused with the "Range" class defined in Range.js. Modified unit tests: Brought into line with changes introduced in the current branch to prevent trivial failure reports. New unit tests to verify priority of user defined options. New e2e sample to verify duplicate label removal by formatter. AFAICS, the only way to hide labels that don't correspond to tick values is via the formatters. This is the cause of duplicate values on axes. All working except for brush-charts, which don't call niceScale. Add utility functions: getGCD() - return GCD of two numbers (not used in this version) getPrimeFactors() - return all prime factors of an integer mod() - a mod b: to overcome precision errors Reduce ticks nicely as chart svg size gets smaller, if options allow. Multi series/multi yaxis charts: attempt force consistent tickAmounts so they line up with the grid. Per series user tickAmount override this. Adjust some tickAmount values in e2e samples now that user defined tickAmount is honoured unless it conflicts with other user defined options. Set default ticks back to 10. With the proposed changes, the default value only influences the computed nice step size and is reduced to best fit the data after that. The previous default of 5 has the following visual effect: Most charts work with base 10 numbers, and 10/5=2, which tends to produce tick spacings of 0.2, 2, 20, etc. This tends to visually squeeze graphs toward the centre of the chart, leaving more of the peripheral chart area unused, lowering resolution. Having 10 as the default reverses this tendency, bringing data points closer to the extremities of the range. defaults.js: remove the default tickAmount = 6 for polarArea charts. Let niceScale determine it if not user defined. radar-with-polygon-fill.xml: remove user defined tickAmount = 7. Let niceScale() determine it, otherwise 7 ticks are what will be drawn, which will produce a sub-optimal chart for the sample data. multiple-yaxes.xml: associate y axes with their correct series'. The visual change in the chart is that the Income yaxis is scaled correctly. Further highlights the other changes in this commit, showing the alignment of all y scale labels with the grid. Add NetBeans IDE config and ignore private resources. Core.setupBrushHandler(): Bug fix: needed to clone targetChart.w.config.yaxis, not w.config.yaxis. Removed call to Scales.autoScaleY() and the assignment of results to the target chart yaxis. We no longer clobber the yaxis min and max elements, leaving them for the user if they want to define them. Only needs to record the event xaxis min and max for the target chart. Scales.autoScaleY(): Removed. Not required. Range.setYRange() and Range.getMinYMaxY() are now aware of xaxis min max range from the brush selection event. These functions are called as part of the target chart redrawing following the triggering of the selection event loop in Core.setupBrushHandler(). Range.getMinYMaxY(): Work with brush X ranges. Range.setYRange(): Allow mulitple Y axes to be scaled with Y ranges corresponding to their independent data series'. Brush now works with all appropriate chart arrangements, including multiple series, multiple axes, collapsible series', combos, etc. line/brush-charts.xml: Modified to demonstrate brush charts with multiple collapsible series and multiple Y axes, with dynamic "nice" scaling of axes. Unit test: yaxis-min-max-spec.js Specific Test: "min and max functions in multiple yaxis should return correct values in params". Charts with multiple Y axes can have different min values. Other changes in this patchset ensure "nice" scaling plus alignment of ticks with grid lines. Users can set minimums and maximums as per axis options to override the default auto-ranging.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks a lot for this #426 .
But in the new version I've found a new problem.
Sometimes a candle goes outside the area.
Try this data
[[1553250600000,[0.20419999999999999,0.2051,0.20399999999999999,0.2041]],[1553252400000,[0.2041,0.20419999999999999,0.20349999999999999,0.2039]],[1553254200000,[0.2039,0.20419999999999999,0.20330000000000001,0.20399999999999999]],[1553256000000,[0.2041,0.20549999999999999,0.20349999999999999,0.20480000000000001]],[1553257800000,[0.20469999999999999,0.20519999999999999,0.2031,0.20430000000000001]],[1553259600000,[0.20430000000000001,0.20569999999999999,0.2039,0.20469999999999999]],[1553261400000,[0.2046,0.20530000000000001,0.20369999999999999,0.20369999999999999]],[1553263200000,[0.20369999999999999,0.2049,0.20230000000000001,0.2044]],[1553265000000,[0.2044,0.20549999999999999,0.2039,0.2051]],[1553266800000,[0.20499999999999999,0.20699999999999999,0.20469999999999999,0.20680000000000001]],[1553268600000,[0.20680000000000001,0.20730000000000001,0.2059,0.20710000000000001]],[1553270400000,[0.20710000000000001,0.20860000000000001,0.2056,0.20699999999999999]],[1553272200000,[0.20699999999999999,0.2072,0.20630000000000001,0.20699999999999999]],[1553274000000,[0.2069,0.20830000000000001,0.20660000000000001,0.20780000000000001]],[1553275800000,[0.20780000000000001,0.20830000000000001,0.2069,0.2072]],[1553277600000,[0.2072,0.2074,0.20660000000000001,0.2069]],[1553279400000,[0.20699999999999999,0.20710000000000001,0.20619999999999999,0.20619999999999999]],[1553281200000,[0.20630000000000001,0.2072,0.20580000000000001,0.20649999999999999]],[1553283000000,[0.20660000000000001,0.20699999999999999,0.20549999999999999,0.20630000000000001]],[1553284800000,[0.20619999999999999,0.20669999999999999,0.20569999999999999,0.20660000000000001]],[1553286600000,[0.2064,0.2074,0.20599999999999999,0.20699999999999999]],[1553288400000,[0.20699999999999999,0.20799999999999999,0.20649999999999999,0.2072]],[1553290200000,[0.20699999999999999,0.20730000000000001,0.20599999999999999,0.20630000000000001]],[1553292000000,[0.20630000000000001,0.2069,0.2054,0.2059]],[1553293800000,[0.2059,0.20619999999999999,0.20519999999999999,0.20599999999999999]],[1553295600000,[0.20610000000000001,0.20630000000000001,0.20530000000000001,0.20549999999999999]],[1553297400000,[0.2054,0.2064,0.2054,0.2054]],[1553299200000,[0.2054,0.2059,0.2026,0.20280000000000001]],[1553301000000,[0.20280000000000001,0.2039,0.20250000000000001,0.20349999999999999]],[1553302800000,[0.2036,0.20399999999999999,0.20300000000000001,0.20349999999999999]],[1553304600000,[0.20369999999999999,0.20530000000000001,0.20349999999999999,0.20469999999999999]],[1553306400000,[0.20480000000000001,0.20519999999999999,0.20399999999999999,0.20499999999999999]],[1553308200000,[0.20519999999999999,0.20530000000000001,0.2031,0.2034]],[1553310000000,[0.2034,0.20369999999999999,0.19589999999999999,0.19989999999999999]],[1553311800000,[0.1996,0.20119999999999999,0.19839999999999999,0.20080000000000001]],[1553313600000,[0.20080000000000001,0.20200000000000001,0.19980000000000001,0.20080000000000001]],[1553315400000,[0.20100000000000001,0.20150000000000001,0.19939999999999999,0.2001]],[1553317200000,[0.20019999999999999,0.20130000000000001,0.19989999999999999,0.20119999999999999]],[1553319000000,[0.20119999999999999,0.20280000000000001,0.2011,0.20230000000000001]],[1553320800000,[0.20219999999999999,0.2024,0.19969999999999999,0.2011]],[1553322600000,[0.2011,0.20300000000000001,0.20080000000000001,0.2024]],[1553324400000,[0.2024,0.2026,0.2011,0.2016]],[1553326200000,[0.2019,0.20280000000000001,0.2016,0.2026]],[1553328000000,[0.2026,0.20300000000000001,0.20219999999999999,0.2024]],[1553329800000,[0.2024,0.2026,0.2019,0.20250000000000001]],[1553331600000,[0.20250000000000001,0.2026,0.2016,0.2016]],[1553333400000,[0.2016,0.20200000000000001,0.2014,0.2019]],[1553335200000,[0.2019,0.20200000000000001,0.19850000000000001,0.20069999999999999]],[1553337000000,[0.2006,0.2014,0.20000000000000001,0.20130000000000001]],[1553338800000,[0.20130000000000001,0.20130000000000001,0.2011,0.20130000000000001]]]
The text was updated successfully, but these errors were encountered: