Can someone please help me understand why it's like this?

[9thsky]

When I'm looking at 1 day chart...

it shows that the lowest btc got was $47,301.

But when I see the 7 day chart..

it shows that the lowest it got was $48,268. How??

Shouldn't it also be $47,301 since that was the lowest? I don't get it.

This is on The Crypto App. I've noticed it also on other apps and wallets. Any idea?

[1714820894]

1714820894

[1714820894]

1714820894

[1714820894]

1714820894

[Shymaa-Arafat]

I'm no expert in this, just guessing, maybe 47,301$ was the calculated price at that moment 2:33 I think but no actual exchange happened till the price got raised again by outside influencing parameters in this AMM equation

[pooya87]

This is how the UI elements representing charts work.
Usually what these chart elements do is that they take the minimum and maximum, decide what the closest value is without spilling out of designated space, split it into multiple steps (5 in this case: 48268, 51095, 53923,....) and use those on UI to represent the chart.
For example if data for Y axis is >=11 and <=15 it could use values on the axis from 10 to 16 but if data went from 11 to 999 then it can use values from 0 to 1000 for the Y axis. The data doesn't change though, just the representation.

In second case since the top value is changed, so it has to change the steps and the range to match that. Due to rounding it ends up using a different minimum.

[NotATether]

In second case since the top value is changed, so it has to change the steps and the range to match that. Due to rounding it ends up using a different minimum.

This is a very strange rounding method if that's the case. Usually rounding to a very different number like this means you're going to round to the nearest 10, or 100. My bets are on that particular price being registered outside of exchanges' training hours for BTC (post above yours says it was at 02:33) so they included the lowest price in the window. Bitstamp has such hours for example.

[Poker Player]

In second case since the top value is changed, so it has to change the steps and the range to match that. Due to rounding it ends up using a different minimum.

This is a very strange rounding method if that's the case. Usually rounding to a very different number like this means you're going to round to the nearest 10, or 100. My bets are on that particular price being registered outside of exchanges' training hours for BTC (post above yours says it was at 02:33) so they included the lowest price in the window. Bitstamp has such hours for example.

That's exactly what I was thinking. Pooya87 has made a detailed explanation that has left me a bit perplexed. Perhaps it is that the rounding of the Bitcoin price is different from the way it is done in classical arithmetic.

[DdmrDdmr]

I haven’t checked out their app, but performed a similar exercise on their website (under the Prices menu, select bitcoin). The information displayed is not exactly the same, but if we compare we’ll see that:

-   The 1 day view Y axis ranges from 47K to 51K
-   The 7 day view Y axis ranges from 47,5K to 57,5K

Those scales do not represent the max/min values though on the website, as the app seems to suggest it does. Nevertheless, if I chose a datapoint in the 7 day window, it coincides in value with the 1 day window reading (as expected), but, the granularity of the x axis data points is different on both views:

The x axis datapoints are 5 minute readings on the daily scales, whilst being 30 minute apart on the 7 day view. That means that the weekly view captures 1 in 6 of the data points shown in the daily view, losing out the representation of 5 out of 6 values. The coincidential reading has the same value (it does not average it out for the 6 data points).

I can only think that the charts on the app follow a similar logic, and that the daily chart, being more granular, catches more data points (and therefore dips in this case) than the weekly chart. That would mean that the max/min shown are relative to the datapoints, but are not absolute max/min readings necessarily.

[9thsky]

I haven’t checked out their app, but performed a similar exercise on their website (under the Prices menu, select bitcoin). The information displayed is not exactly the same, but if we compare we’ll see that:

-   The 1 day view Y axis ranges from 47K to 51K
-   The 7 day view Y axis ranges from 47,5K to 57,5K

Those scales do not represent the max/min values though on the website, as the app seems to suggest it does. Nevertheless, if I chose a datapoint in the 7 day window, it coincides in value with the 1 day window reading (as expected), but, the granularity of the x axis data points is different on both views:

The x axis datapoints are 5 minute readings on the daily scales, whilst being 30 minute apart on the 7 day view. That means that the weekly view captures 1 in 6 of the data points shown in the daily view, losing out the representation of 5 out of 6 values. The coincidential reading has the same value (it does not average it out for the 6 data points).

I can only think that the charts on the app follow a similar logic, and that the daily chart, being more granular, catches more data points (and therefore dips in this case) than the weekly chart. That would mean that the max/min shown are relative to the datapoints, but are not absolute max/min readings necessarily.

Pretty stupid, don't you think? If data is already being read every 5 mins, that reading could just be logged and applied to be displayed at whatever time intervals you choose. What am I missing?

[masulum]

As far as I know, every application uses an API with different levels of speed in retrieving data. If the API is running correctly, it means that the difference in data that is displayed is a bug in the application.

The source API is also influential. The reason is, if we look at the price of BTC at coingecko, we will not see the same price between prices on the market and also at coingecko. because, if I'm not mistaken, the value of valuation is based on average prices. That which could have caused different results in the application. (CMIIW)

[DdmrDdmr]

<…>

It looks like they’re using a widget that, technically, displays as max/min on the Y axis the max/min of the plotted data points, not the actual max/min of the underlying data granularity (which is at least minutes, somewhere in their database).

Since the max/min on the Y axis is being interpreted as the max/min during the window’s interval, and due to the effect we’re commenting here, it would seem wise to display the absolute max/min as independent fields within the window’s timeframe, based on reading the data with the maximum granularity (as opposed to the one shown in the widget for a given window).
That is, display two separate fields for the max/min, and not relying on the ones shown on the widget’s Y axis.