Is it possible to pass a Double not a Float in the last version of the library because i couldn't do so before. if not can you consider adding it ?

[abderhim]

[Gowsky]

Hello @abderhim, you can use entryOf to create ChartEntry with a Double value. You can also create your own subclass of the ChartEntry. However the Double will be converted to Float, as this type is used internally by charts.

[abderhim]

then we can't pass Timestamps with ms as X values, because we can't get the exact values when we convert it to Float :(

[Gowsky]

A very similar use case is already described in the wiki here.

[abderhim]

that will not cover Timestamps with ms , when converting to Float , data will be lost

[patrickmichalik]

Hello! Millisecond-based timestamps are typically whole numbers, and no rounding errors should occur for such values. The first six decimal digits should be accurate too. Unless you require picosecond-level precision, there shouldn’t be an issue.

[github-actions[bot]]

There hasn’t been any activity here for four weeks. If no activity occurs over the next week, this issue will be closed as stale.

[OskarPersson]

@patrickmichalik How would you represent a millisecond (or second) -based timestamp as a whole number that can be safely converted to a float? See for example this playground where we create two LocalDateTime objects ~1 second apart and still end up with the same float.

import java.time.Instant
import kotlin.test.*
import java.time.LocalDateTime
import java.time.ZoneId

fun main(args: Array<String>) {
    val localDateTime = LocalDateTime.now()
    Thread.sleep(1_000)
    val localDateTime2 = LocalDateTime.now()
    val instant = localDateTime.atZone(ZoneId.systemDefault()).toInstant()
    val instant2 = localDateTime2.atZone(ZoneId.systemDefault()).toInstant()
    val milliseconds = instant.toEpochMilli()
    val milliseconds2 = instant2.toEpochMilli()
    val floatRepresentation = milliseconds.toFloat()
    val floatRepresentation2 = milliseconds2.toFloat()
    val floatToDate = LocalDateTime.ofInstant(Instant.ofEpochMilli(floatRepresentation.toLong()), ZoneId.systemDefault())
    val floatToDate2 = LocalDateTime.ofInstant(Instant.ofEpochMilli(floatRepresentation2.toLong()), ZoneId.systemDefault())

    println("LocalDateTime: $localDateTime")
    println("LocalDateTime2: $localDateTime2")
    println("Float Representation: $floatRepresentation")
    println("Float Representation2: $floatRepresentation2")
    println("Float as LocalDateTime: $floatToDate")
    println("Float as LocalDateTime 2: $floatToDate2")
}

Output:

LocalDateTime: 2024-02-18T13:09:25.668965898
LocalDateTime2: 2024-02-18T13:09:26.669259623
Float Representation: 1.70826177E12
Float Representation2: 1.70826177E12
Float as LocalDateTime: 2024-02-18T13:09:29.216
Float as LocalDateTime 2: 2024-02-18T13:09:29.216

[patrickmichalik]

It looks like I made a mistake in my previous comment. I apologize. While Float.MAX_VALUE is much greater than a normal timestamp, precision problems are, in fact, possible. Not all whole numbers smaller than Float.MAX_VALUE can be represented.

We will be switching from Float to Double in Vico 2. In the meantime, for most use cases, you can transform your x values to avoid precision loss. Could you let me know a bit more about your use case, @OskarPersson? Do you need precision down to the second or down to the millisecond? What is the range of your x values (e.g., several hours, several days, a year)?

[OskarPersson]

@patrickmichalik Personally I need precision down to the second with a range over a year. But if Vico 2 switches to using Double I think that would solve it 🙂

[patrickmichalik]

Got it, @OskarPersson. Float can accurately represent around 16.8 million consecutive whole numbers. You can relatively easily transform a set such that it starts at zero, undoing the transformation at the formatting stage, and so you always have around 16.8 million units at your disposal. With Vico, some room needs to be left for the chart to perform its calculations accurately, so the limit is lower. A year has around 31.5 million seconds, so if you need to be able to represent any second in a range spanning over a year, Float is, unfortunately, insufficient, even with the aforementioned transformation applied.

That said, I’d suggest double-checking if such a level of precision is required. Even if we assume that two points are discernable when they’re just a pixel apart, this gives us over 31.5 million pixels—more than two kilometers on the average screen. Scrolling through such an amount of chart content would take a significant amount of time. Additionally, Compose’s ScrollableState would likely start misbehaving along the way, as it’s Float-based too. At a lower zoom factor, on the other hand, you’d end up with multiple points per pixel, which is unnecessary and best avoided.

[Gowsky]

Vico 2.0.0-alpha.24 uses Double for the data. Cheers!