DateUtils.Inc* with double instead on Int64 lazarus / 64-FPC development ---------------------------------------------------------------------- Чебурашка · 2022-05-25 11:44 Hi, I was using the DateUtils.IncSeconds(time, seconds) function, but my seconds parameter ended up being a floating point value. I remembered that these function want a Int64 number, so I had to use milliseconds with a little rounding. Would it be senseful to extend them to floating point inputs instead of interger? All in all the inner calculation does Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Function IncSecond(const AValue: TDateTime; const ANumberOfSeconds: Int64): TDateTime;begin  if AValue>=0 then    Result:=AValue+ANumberOfSeconds/SecsPerDay  else    Result:=IncNegativeTime(Avalue,ANumberOfSeconds/SecsPerDay);  MaybeSkipTimeWarp(AValue,Result);end;  and this would work also with ANumberOfSeconds being a floating point. Of course the same argument applies to all other DateUtils.Inc* functions. ---------------------------------------------------------------------- AlexTP · 2022-05-25 11:52 This must be Delphi compatible, https://docwiki.embarcadero.com/Libraries/Sydney/en/System.DateUtils.I ncSecond but if overload will appear, maybe its OK. ---------------------------------------------------------------------- Чебурашка · 2022-05-25 12:00 I correct myself: QuoteThe same argument might apply to DateUtils.IncDay, DateUtils.IncHour, DateUtils.IncSecond, DateUtils.IncMilliSecond functions. Others make less sense to be floating point. ---------------------------------------------------------------------- winni · 2022-05-25 15:49 Hi! If you know the basics of TDateTime thren you don't need IncSeconds and friends. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Type TDateTime = Double;  The Integer part contains the days since 30. December 1899 The fractional part contains the time and is organized this way: 1 hour = 1.0 / 24 1 minute = 1.0 / (24*60) 1 second = 1.0/ (24*60*60) To increment your DateTime with one second you can do Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i MyDateTime := MyDateTime + 1/ (24*60*60); To increment your DateTime with 45 days you can do: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i MyDateTime := MyDateTime +  45;  Winni ---------------------------------------------------------------------- Remy Lebeau · 2022-05-25 16:08 Quote from: tt on May 25, 2022, 01:44:40 pmAll in all the inner calculation does Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Function IncSecond(const AValue: TDateTime; const ANumberOfSeconds: Int64): TDateTime;begin  if AValue>=0 then    Result:=AValue+ANumberOfSeconds/SecsPerDay  else    Result:=IncNegativeTime(Avalue,ANumberOfSeconds/SecsPerDay);  MaybeSkipTimeWarp(AValue,Result);end;  Delphi stopped relying on floating-point math in the DateUtils unit over a decade ago, it was causing too many problems (rounding issues, etc).  Now, most of the date/time calculations are performed by first converting TDateTime to TTimeStamp, manipulating the TTimeStamp as needed using integer math, and then converting the result back to TDateTime.  Much more accurate, albeit maybe slightly less efficient. ---------------------------------------------------------------------- wp · 2022-05-25 16:17 Quote from: winni on May 25, 2022, 05:49:22 pmIf you know the basics of TDateTime thren you don't need IncSeconds and friends.[...] Your summary is correct. However, this simple calculation results in an "inverted" time when the date is negative. This case is covered correctly by the IncXXX functions: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; uses  SysUtils, DateUtils;  var  t, t0: TDateTime;begin  t0 := EncodeTime(9, 0, 0, 0);   // 9:00 (AM). But note that the date part is 0  WriteLn(FormatDateTime('hh:nn', t0));    // 1 day earlier   // We're expecting the time to be 9:00 again. But the simple subtraction makes it 15:00 (3:00 PM)  // This is because the date part is negative now.  t := t0-1.0;  WriteLn(FormatDateTime('hh:nn', t));    // Now the same calculation but using the IncDay function -> the result is correct.  t := IncDay(t0, -1);  WriteLn(FormatDateTime('hh:nn', t));  ReadLn;end. ---------------------------------------------------------------------- winni · 2022-05-25 16:49 Hi! But that is not a special problem of TDateTime: You  allways run in trouble with negative time and/or date. The greatest disadvantage of TDateTime is the offset date  30. December 1899. This means you can use TDateTime for office use but it is impossible to do some historical  research before 1900 with TDateTime. They should have taken an offset date 1.1.0001  or - even better -  use the scientific Julian Days starting at 1.1. -4712  (4713 BC). Winni ---------------------------------------------------------------------- Чебурашка · 2022-05-27 07:09 Quote from: winni on May 25, 2022, 05:49:22 pmHi! If you know the basics of TDateTime thren you don't need IncSeconds and friends. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Type TDateTime = Double;  The Integer part contains the days since 30. December 1899 The fractional part contains the time and is organized this way: 1 hour = 1.0 / 24 1 minute = 1.0 / (24*60) 1 second = 1.0/ (24*60*60) To increment your DateTime with one second you can do Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i MyDateTime := MyDateTime + 1/ (24*60*60); To increment your DateTime with 45 days you can do: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i MyDateTime := MyDateTime +  45;  Winni You are right with the direct calculations, I also did so several times. But lately I migrated to IncXXX because I perceived them comfortable, reader friendly, and able to manage transparently the oddities of the TDateTime calculations. I was just wondering if was senseful to extend them allowing fractional quantities increment/decrement, like add 2.58 seconds or 7.652 hours. ---------------------------------------------------------------------- SymbolicFrank · 2022-06-07 09:58 There's about 2^62 seconds in the lifespan of the universe. Fits a single Int64. So set 0000-01-01T00:00 to be 0. Universal time. The main frustration: leap seconds. Although time zones will be as usual. ---------------------------------------------------------------------- MarkMLl · 2022-06-07 12:01 Pardon me for jumping in, but can anybody comment on why TDateTime isn't an (80-bit) extended on platforms that support it? MarkMLl ---------------------------------------------------------------------- PascalDragon · 2022-06-07 12:10 Quote from: MarkMLl on June 07, 2022, 02:01:15 pmPardon me for jumping in, but can anybody comment on why TDateTime isn't an (80-bit) extended on platforms that support it? Because Delphi did so. And the accuracy of Double is probably sufficient for the intended purpose. ---------------------------------------------------------------------- winni · 2022-06-07 12:40 Hi! TDateTime is a Double since Delphi 1.0 So ask Borland .... Winni ---------------------------------------------------------------------- MarkMLl · 2022-06-07 12:43 Quote from: PascalDragon on June 07, 2022, 02:10:08 pmBecause 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). Since a TDateTime should be treated as opaque, is binary compatibility that important? MarkMLl ---------------------------------------------------------------------- SymbolicFrank · 2022-06-07 13:15 Exact time is a bit more challenging, as you need 144 bits to store the amount of Planck time units for each second. So, if we take 192 bits for that and add the 64 bits for the seconds, we end up with 256 bits and a universe-shattering precision that is never going to be outdated Edit: if you count seconds in Planck time, the value won't be exact, but extremely close. And as you convert from a large integer of Planck time to days and seconds, it doesn't matter. ---------------------------------------------------------------------- winni · 2022-06-07 13:17 Quote from: MarkMLl on June 07, 2022, 02:43:44 pmSince a TDateTime should be treated as opaque, is binary compatibility that important? MarkMLl Hi! 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. TDateTime is sufficient for Office Apps. If you got other needs then use another Type of DateTime. If you make historical  research the use the Julian Days. If you need milliseconds then use QWords like getTickCount64. Winni ---------------------------------------------------------------------- MarkMLl · 2022-06-07 13:45 Quote from: winni on June 07, 2022, 03:17:41 pmThere 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 ---------------------------------------------------------------------- marcov · 2022-06-07 13:46 Quote from: MarkMLl on June 07, 2022, 03:45:22 pmAre 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 · 2022-06-07 14:36 Quote from: marcov on June 07, 2022, 03:46:54 pmQuote from: MarkMLl on June 07, 2022, 03:45:22 pmAre 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 · 2022-06-07 14:41 Quote from: winni on June 07, 2022, 04:36:46 pmQuote from: marcov on June 07, 2022, 03:46:54 pmNo, 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 ---------------------------------------------------------------------- SymbolicFrank · 2022-06-07 14:55 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 · 2022-06-07 15:15 Quote from: SymbolicFrank on June 07, 2022, 04:55:04 pmMany 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 ---------------------------------------------------------------------- PascalDragon · 2022-06-08 07:53 Quote from: MarkMLl on June 07, 2022, 02:43:44 pmQuote from: PascalDragon on June 07, 2022, 02:10:08 pmBecause 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: QuoteType: 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: QuoteThe 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... Quote from: MarkMLl on June 07, 2022, 02:43:44 pmSince a TDateTime should be treated as opaque, is binary compatibility that important? Yes, due to above point. ---------------------------------------------------------------------- MarkMLl · 2022-06-08 08:05 Quote from: PascalDragon on June 08, 2022, 09:53:59 amI 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: QuoteType: 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 ---------------------------------------------------------------------- marcov · 2022-06-08 08:27 Quote from: MarkMLl on June 07, 2022, 04:41:11 pmThat'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 · 2022-06-08 08:34 Quote from: marcov on June 08, 2022, 10:27:46 amDouble 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 ---------------------------------------------------------------------- marcov · 2022-06-08 08:41 Quote from: MarkMLl on June 08, 2022, 10:34:41 amI 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) ---------------------------------------------------------------------- SymbolicFrank · 2022-06-08 08:42 Quote from: MarkMLl on June 07, 2022, 05:15:34 pmQuote from: SymbolicFrank on June 07, 2022, 04:55:04 pmMany 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 · 2022-06-08 08:59 Quote from: marcov on June 08, 2022, 10:41:09 amQuote from: MarkMLl on June 08, 2022, 10:34:41 amI 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 · 2022-06-08 09:00 Quote from: SymbolicFrank on June 08, 2022, 10:42:12 amAh, 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 ---------------------------------------------------------------------- marcov · 2022-06-08 09:06 Quote from: SymbolicFrank on June 08, 2022, 10:59:59 am128 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. QuoteAMD64, not so much. Although you could use fixed-point calculations with the SIMD units. Maybe. 64-bit,64-bit pairs or so. ---------------------------------------------------------------------- SymbolicFrank · 2022-06-08 09:51 Quote from: marcov on June 08, 2022, 11:06:56 amMaybe. 64-bit,64-bit pairs or so. That would fit the TDateTime format. Although it would make calculations that simply add or substract hours or seconds slower. ---------------------------------------------------------------------- marcov · 2022-06-08 11:03 btw, I send records with tdatetime in it over TCP between FPC and Delphi apps...... ---------------------------------------------------------------------- PascalDragon · 2022-06-08 12:24 Quote from: MarkMLl on June 08, 2022, 10:34:41 amQuote from: marcov on June 08, 2022, 10:27:46 amDouble 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 :-) Well, we could definitely use such people, because for FPC we need software 128-bit FP support so that we can fully support cross compilation from platforms that don't support Extended (including x86_64-win64) to those that do. And while basic routines are already available functions like exp and ln as well as the trigonometry ones are missing... ---------------------------------------------------------------------- MarkMLl · 2022-06-08 12:40 Quote from: PascalDragon on June 08, 2022, 02:24:24 pmWell, we could definitely use such people, because for FPC we need software 128-bit FP support so that we can fully support cross compilation from platforms that don't support Extended (including x86_64-win64) to those that do. And while basic routines are already available functions like exp and ln as well as the trigonometry ones are missing... I'm currently twiddling factors and primitive roots: my brain hurts enough already :-) I don't know who they are, but there's some useful stuff at https://www.geeksforgeeks.org/ If https://en.wikipedia.org/wiki/Quadruple-precision_floating- point_format#Hardware_support is to be believed, there's very little that actually has hardware support for 128-bit IEEE maths. Which could be interpreted either as indicating that nobody's really bothered about that level of precision (notwithstanding my original question), or that software support is urgently needed. In the latter case, surely it's a "Summer of Code" job for some bright undergrads? MarkMLl ---------------------------------------------------------------------- SymbolicFrank · 2022-06-09 11:42 Quote from: PascalDragon on June 08, 2022, 02:24:24 pmQuote from: MarkMLl on June 08, 2022, 10:34:41 amQuote from: marcov on June 08, 2022, 10:27:46 amDouble 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 :-) Well, we could definitely use such people, because for FPC we need software 128-bit FP support so that we can fully support cross compilation from platforms that don't support Extended (including x86_64-win64) to those that do. And while basic routines are already available functions like exp and ln as well as the trigonometry ones are missing... There still isn't native support for BigInt either, so a general library for arbitrary precision fixed and floating-point would be awesome. I started both a few times and translated one halfway from Delphi, but it was too much work for what I needed it for. The last time I wrote a working floating-point library was before floating-pont hardware was common. So, long ago ---------------------------------------------------------------------- PascalDragon · 2022-06-10 07:19 Quote from: SymbolicFrank on June 09, 2022, 01:42:13 pmThere still isn't native support for BigInt either, so a general library for arbitrary precision fixed and floating-point would be awesome. I started both a few times and translated one halfway from Delphi, but it was too much work for what I needed it for. The last time I wrote a working floating-point library was before floating-pont hardware was common. So, long ago Neither a BigInt library nor support for arbitrary precision fixed and floating point arithmetic is important for cross compilation. Support for 128-bit floating point however is. ---------------------------------------------------------------------- MarkMLl · 2022-06-10 07:30 Quote from: PascalDragon on June 10, 2022, 09:19:44 amNeither a BigInt library nor support for arbitrary precision fixed and floating point arithmetic is important for cross compilation. Support for 128-bit floating point however is. I'd not presume to argue with that bit as a reality check: am I correct in believing that only the POWER architecture support this in hardware (possibly with RISCV in the future)? And however much I've favoured alternative architectures in the past, is that one really likely to remain viable? MarkMLl ---------------------------------------------------------------------- marcov · 2022-06-10 08:10 Quote from: MarkMLl on June 10, 2022, 09:30:08 amI'd not presume to argue with that bit as a reality check: am I correct in believing that only the POWER architecture support this in hardware (possibly with RISCV in the future)? And however much I've favoured alternative architectures in the past, is that one really likely to remain viable? The compiler now uses extended that is not crossplatform to do calculate to create double constants. A generic 128-bit soft fpu would fix that crossplatform issue, regardless of hardware support. ---------------------------------------------------------------------- PascalDragon · 2022-06-10 11:16 Quote from: MarkMLl on June 10, 2022, 09:30:08 amQuote from: PascalDragon on June 10, 2022, 09:19:44 amNeither a BigInt library nor support for arbitrary precision fixed and floating point arithmetic is important for cross compilation. Support for 128-bit floating point however is. I'd not presume to argue with that bit as a reality check: am I correct in believing that only the POWER architecture support this in hardware (possibly with RISCV in the future)? And however much I've favoured alternative architectures in the past, is that one really likely to remain viable? It's not about hardware support! It's about compiling from a system that does not support 80-bit floating point to a system that does. And instead of using 80-bit it's a logical step to simply use the next bigger size, namely 128-bit. ---------------------------------------------------------------------- MathMan · 2022-06-11 10:16 Quote from: PascalDragon on June 08, 2022, 02:24:24 pmQuote from: MarkMLl on June 08, 2022, 10:34:41 amQuote from: marcov on June 08, 2022, 10:27:46 amDouble is the highest shared floating point number. But maybe if you implement soft float for 128-bit 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 :-) Well, we could definitely use such people, because for FPC we need software 128-bit FP support so that we can fully support cross compilation from platforms that don't support Extended (including x86_64-win64) to those that do. And while basic routines are already available functions like exp and ln as well as the trigonometry ones are missing... "software 128-bit FP support" is a very generic term. Are the exact requirements noted down somewhere? Depending on these the task can vary from several man days to man years ... * full implementation in FPC, or wrapper for an existing FP128 library? * 32/64 bit and little-/big-endian architecture support? * based on IEEE754? * exposure of an internal, more efficient format too? * designed to allow replacement of some kernel functions by asm routines? * how much trade is allowed between exactness and speed? * ... Don't get me wrong - I'm not committing to anything here (yet)! I'm just a hobby programmer who's solely developing things for his own amusement. But I recently started explorations into FP128 based on IEEE754-2008 and this may coincide with my own ambitions. Beside that, mmartin has recently announced an FP128 library, following the IEEE754 - however also his version is only covering basic functionality and does not include the desired elementary functions like ln, exp, etc. Cheers, MathMan ---------------------------------------------------------------------- PascalDragon · 2022-06-13 13:36 Quote from: MathMan on June 11, 2022, 12:16:34 pm"software 128-bit FP support" is a very generic term. Are the exact requirements noted down somewhere? Depending on these the task can vary from several man days to man years ... * full implementation in FPC, or wrapper for an existing FP128 library? * 32/64 bit and little-/big-endian architecture support? * based on IEEE754? * exposure of an internal, more efficient format too? * designed to allow replacement of some kernel functions by asm routines? * how much trade is allowed between exactness and speed? * ... We already have the core routines in rtl/inc/softfpu.pp (which is based on IEEE754; usable using the units sfpu128 and ufloat128) as such any implementation of the additional functions must work together with those. External libraries are a no-go, the license must be compatible to the RTL's (LGPL with static linking exception) and due to this being especially necessary for cross compilation a full Pascal implementation that works correctly in (16/)32/64-bit in both big and little endian is a necessity. As a first step exactness is more important than speed. ---------------------------------------------------------------------- MathMan · 2022-06-14 08:51 Quote from: PascalDragon on June 13, 2022, 03:36:01 pmQuote from: MathMan on June 11, 2022, 12:16:34 pm"software 128-bit FP support" is a very generic term. Are the exact requirements noted down somewhere? Depending on these the task can vary from several man days to man years ... * full implementation in FPC, or wrapper for an existing FP128 library? * 32/64 bit and little-/big-endian architecture support? * based on IEEE754? * exposure of an internal, more efficient format too? * designed to allow replacement of some kernel functions by asm routines? * how much trade is allowed between exactness and speed? * ... We already have the core routines in rtl/inc/softfpu.pp (which is based on IEEE754; usable using the units sfpu128 and ufloat128) as such any implementation of the additional functions must work together with those. External libraries are a no-go, the license must be compatible to the RTL's (LGPL with static linking exception) and due to this being especially necessary for cross compilation a full Pascal implementation that works correctly in (16/)32/64-bit in both big and little endian is a necessity. As a first step exactness is more important than speed. Thanks for the clarification PascalDragon. I'll take a look at rtl/inc/softfpu.pp, sfpu128 & ufloat128 to understand exactly what "core routines" are available and what will be required for implementation of elementary functons.