Recent

Author Topic: DateUtils.Inc* with double instead on Int64  (Read 4084 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: DateUtils.Inc* with double instead on Int64
« Reply #15 on: June 07, 2022, 03:45:22 pm »
There is so much code around since more than 25 years that relies on the internal structure of TDateTime.
If you change this you break a lot of existing code.

Are you honestly trying to tell me Winni that people are doing internal bitwise manipulation of TDateTime?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: DateUtils.Inc* with double instead on Int64
« Reply #16 on: June 07, 2022, 03:46:54 pm »
Are you honestly trying to tell me Winni that people are doing internal bitwise manipulation of TDateTime?

No, but floating point math, like +1.0 or even 1/86400 etc is often done with it.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: DateUtils.Inc* with double instead on Int64
« Reply #17 on: June 07, 2022, 04:36:46 pm »
Are you honestly trying to tell me Winni that people are doing internal bitwise manipulation of TDateTime?

No, but floating point math, like +1.0 or even 1/86400 etc is often done with it.

Bravo Marcov!

Example:

s := "Please pay the bill until "+DateToStr(now+30);

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: DateUtils.Inc* with double instead on Int64
« Reply #18 on: June 07, 2022, 04:41:11 pm »
No, but floating point math, like +1.0 or even 1/86400 etc is often done with it.

Bravo Marcov!

Example:

s := "Please pay the bill until "+DateToStr(now+30);

That's straight floating point maths, absolutely nothing to do with the number of bits in the representation.

But having the number of fractional bits nibbled away the further the current data moves from the epoch is hardly a good idea.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: DateUtils.Inc* with double instead on Int64
« Reply #19 on: June 07, 2022, 04:55:04 pm »
Many devices now measure distances by the time it takes to bounce a signal off of it. So, if you want to make a better unit, you should at least take those time frames and that resolution into account. And what we have is already a big update over the 18.2 Hz timer tick of the original IBM PC, the default for a long time.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: DateUtils.Inc* with double instead on Int64
« Reply #20 on: June 07, 2022, 05:15:34 pm »
Many devices now measure distances by the time it takes to bounce a signal off of it. So, if you want to make a better unit, you should at least take those time frames and that resolution into account. And what we have is already a big update over the 18.2 Hz timer tick of the original IBM PC, the default for a long time.

If I wanted to "make a better unit" I'd use the longstanding IBM mainframe convention of an integer where the LSB represents some unreasonably small timescale (e.g. 1 nSec) with the lowest bit actually guaranteed to increment (e.g. every 1024 x 1024 nSec) being implementation-defined.

However I'm /not/ out to make a better unit, I'm just interested in why extended type isn't being used for what it supposedly an opaque floating point type. Surely nobody in their right mind bit-twiddles floating point numbers?

I note Marco's comment elsewhere yesterday that there's always twits who write in assembler expecting it to be portable. But even there floating point manipulation was done either by hardware or by predefined libraries.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: DateUtils.Inc* with double instead on Int64
« Reply #21 on: June 08, 2022, 09:53:59 am »
Because Delphi did so. And the accuracy of Double is probably sufficient for the intended purpose.

Hmm. But we're both  further from the epoch (1900?) than when Borland selected it (late 90s?) and expecting to be able to use smaller intervals for timeouts etc. as computers speed up (assuming, of course, that that trend continues).

I need to correct my statement a bit: it's not a Double, because Delphi did so, but because Microsoft did so for Visual Basic and Excel. TDateTime is fully interchangeable with the DATE type used in OLE which is described for the VARIANT struct here:

Quote
Type: DATE A date and time value. Dates are represented as double-precision numbers, where midnight, January 1, 1900 is 2.0, January 2, 1900 is 3.0, and so on.

Also Delphi's documentation mentions this:

Quote
The maximal correct date supported by TDateTime values is limited to 12/31/9999 23:59:59:999.

So that's plenty of time for normal use cases...

Since a TDateTime should be treated as opaque, is binary compatibility that important?

Yes, due to above point.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: DateUtils.Inc* with double instead on Int64
« Reply #22 on: June 08, 2022, 10:05:00 am »
I need to correct my statement a bit: it's not a Double, because Delphi did so, but because Microsoft did so for Visual Basic and Excel. TDateTime is fully interchangeable with the DATE type used in OLE which is described for the VARIANT struct here:

Quote
Type: DATE A date and time value. Dates are represented as double-precision numbers, where midnight, January 1, 1900 is 2.0, January 2, 1900 is 3.0, and so on.

OK, that's a fairly persuasive reason, at least for the default type and library routines.

Some people might argue that an alternative floating-point representation might be preferable, but in light of the limited portability of 80-bit extendeds that's probably not a viable solution.

I once thrashed out a workable 64-bit (?) representation which gave both high resolution and a limit several 10's of thousands of years in the future, only to be told by my boss that the coverage wasn't sufficient for his plans for World domination.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: DateUtils.Inc* with double instead on Int64
« Reply #23 on: June 08, 2022, 10:27:46 am »
That's straight floating point maths, absolutely nothing to do with the number of bits in the representation.

But having the number of fractional bits nibbled away the further the current data moves from the epoch is hardly a good idea.

Double is the highest shared floating point number. But maybe if you implement soft float for 128-bt float, that can be used. (extended is not portable enough to really be a solution)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: DateUtils.Inc* with double instead on Int64
« Reply #24 on: June 08, 2022, 10:34:41 am »
Double is the highest shared floating point number. But maybe if you implement soft float for 128-bt float, that can be used. (extended is not portable enough to really be a solution)

My previous point stands: nobody in their right mind gets involved with bit-twiddling floating points :-)

Although I suppose it will have to be done at some point...

I did have to decode floating point stuff from an HP instrument a few months ago. Great company, but they also had the big-company "not-invented-here" syndrome with massive internal incompatibility between equipment. Still better than Tektronix, where if you wanted to capture output you had to OCR an Epson-format bitmap.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: DateUtils.Inc* with double instead on Int64
« Reply #25 on: June 08, 2022, 10:41:09 am »
I did have to decode floating point stuff from an HP instrument a few months ago. Great company, but they also had the big-company "not-invented-here" syndrome with massive internal incompatibility between equipment. Still better than Tektronix, where if you wanted to capture output you had to OCR an Epson-format bitmap.

128-bit is not not invented here. To my knowledge hardware sits in this room that has hardware 128-bit FP.

Tektronix I know mostly from large, card based multi channel scopes.

Extended only works on 32-bit x86 and x86_64 *nix systems (status on win64 is murky)
« Last Edit: June 08, 2022, 10:43:48 am by marcov »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: DateUtils.Inc* with double instead on Int64
« Reply #26 on: June 08, 2022, 10:42:12 am »
Many devices now measure distances by the time it takes to bounce a signal off of it. So, if you want to make a better unit, you should at least take those time frames and that resolution into account. And what we have is already a big update over the 18.2 Hz timer tick of the original IBM PC, the default for a long time.

If I wanted to "make a better unit" I'd use the longstanding IBM mainframe convention of an integer where the LSB represents some unreasonably small timescale (e.g. 1 nSec) with the lowest bit actually guaranteed to increment (e.g. every 1024 x 1024 nSec) being implementation-defined.

However I'm /not/ out to make a better unit, I'm just interested in why extended type isn't being used for what it supposedly an opaque floating point type. Surely nobody in their right mind bit-twiddles floating point numbers?

I note Marco's comment elsewhere yesterday that there's always twits who write in assembler expecting it to be portable. But even there floating point manipulation was done either by hardware or by predefined libraries.

MarkMLl

Ah, well, I don't know about that...

Although you can argue that it was using the floating-point hardware in unusual ways.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: DateUtils.Inc* with double instead on Int64
« Reply #27 on: June 08, 2022, 10:59:59 am »
I did have to decode floating point stuff from an HP instrument a few months ago. Great company, but they also had the big-company "not-invented-here" syndrome with massive internal incompatibility between equipment. Still better than Tektronix, where if you wanted to capture output you had to OCR an Epson-format bitmap.

128-bit is not not invented here. To my knowledge hardware sits in this room that has hardware 128-bit FP.

Tektronix I know mostly from large, card based multi channel scopes.

Extended only works on 32-bit x86 and x86_64 *nix systems (status on win64 is murky)

128 bit FP is a quite common format for vector units. Many game computers, like the XBox 360 and PS/3 have those. AMD64, not so much. Although you could use fixed-point calculations with the SIMD units.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6646
Re: DateUtils.Inc* with double instead on Int64
« Reply #28 on: June 08, 2022, 11:00:45 am »
Ah, well, I don't know about that...

Yes, I've come across that inside Crays. But I'd suggest that that's still the sort of thing you're more likely to use for high-performance integer work (which, when push comes to shove, is what graphics and signal processing are) and that the number of situations in which one should get involved in bit-twiddling things like the long-standardised IEEE format are minimal.

But I have unbounded respect for people who could build a calculator implementing CORDIC with a magnetostrictive delay-line and a few diodes.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: DateUtils.Inc* with double instead on Int64
« Reply #29 on: June 08, 2022, 11:06:56 am »
128 bit FP is a quite common format for vector units. Many game computers, like the XBox 360 and PS/3 have those.

Afaik the machine I was talking about, is an older uncle of those, a IMac with a G5.

Quote
AMD64, not so much. Although you could use fixed-point calculations with the SIMD units.

Maybe. 64-bit,64-bit pairs or so.

 

TinyPortal © 2005-2018