Post B6tUonvXrOvUDGYaPI by azonenberg@ioc.exchange
 (DIR) More posts by azonenberg@ioc.exchange
 (DIR) Post #B6tSGq2JJQul04OhCi by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       AI people: uses bfloat16 down to fp4, it's fineMe: runs into float32/float64/int64 dynamic range issues on a daily basis
       
 (DIR) Post #B6tSgxgLVZv8F4a1se by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       (float64 is woefully inadequate for trying to measure sub picosecond time resolution over even a few hundred μs)
       
 (DIR) Post #B6tSr3NXBQpao0aqTA by jmax@mastodon.social
       0 likes, 0 repeats
       
       @azonenberg At least you know. Too many people run into them without even noticing.
       
 (DIR) Post #B6tTBij7A6F0ptXfSC by funkylab@mastodon.social
       0 likes, 0 repeats
       
       @azonenberg yeah, never keep time in floating point; it's typically not a thing where that makes a lot of sense (this was learned by SDR software *several* times). Your timestamps should just be int64 multiples of some pre-defined time quantum, and you'll be fine. You don't need sub-attosecond accuracy, and neither do you need to be able to measure in millions of years; the fixed 64 bit range suffices.
       
 (DIR) Post #B6tUM9oNPpvLgjXmfA by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @funkylab that's what I'm doing, but in this case I was interpolating sub sample level crossings for measuring rise time of a signal and using float temporaries since the interpolation code worked in floating point domain
       
 (DIR) Post #B6tUXRDj1wXArlmOie by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @funkylab the normal native time format is int64 multiples of a base quantum which is itself described by an int64 number of femtoseconds.This caps you to about +/- 4 hour record length though which is a problem for trending data over a long period so i plan to move eventually to block floating point with a shared exponent per waveform and then a 64 bit mantissa per sample
       
 (DIR) Post #B6tUY5LDrUIZIbawxU by funkylab@mastodon.social
       0 likes, 0 repeats
       
       @azonenberg yep, need to shift the time values to a "local environment" if you will (extreme example: the interpolator doesn't care about absolute time, you can always shift all times by an integer value so they're zero-centered, locally)
       
 (DIR) Post #B6tUcSOS62uBx6Br7I by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @funkylab that is in fact the fix, split into int64 integer part plus float32 fractional for start and end of each edge then only work about deltas
       
 (DIR) Post #B6tUonvXrOvUDGYaPI by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @funkylab and then at the end add the int delta to the float delta and the deltas fit comfortably in float32 dynamic range
       
 (DIR) Post #B6tVzUKVACH8ZWt8tc by funkylab@mastodon.social
       0 likes, 0 repeats
       
       @azonenberg exactly! (and that's, surprisingly, something that the vernerable and deservedly-so universally disliked libc `struct timespec` gets right, in principle.
       
 (DIR) Post #B6tX9KozTB9VvtPNmy by taral@mastodon.social
       0 likes, 0 repeats
       
       @azonenberg That's only 2^30 scale factor. Where are the rest of your bits going?