The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,152 other subscribers

Archive for the ‘Floating point handling’ Category

On my research list: Unum – The End of (Numeric) Error

Posted by jpluimers on 2020/06/24

From about 4 years ago, so time to see how many development stacks support Unum by now: [WayBackThe End of (Numeric) Error

Crunching numbers was the prime task of early computers. The common element of these early computers is they all used integer arithmetic. John Gustafson, one of the foremost experts in scientific computing, has proposed a new number format that provides more accurate answers than standard floats, yet saves space and energy. The new format might well revolutionize the way we do numerical calculations.

Back then, I found these links through my G+ circles:

Read the rest of this entry »

Posted in Algorithms, Development, Floating point handling, Software Development, Unum | Leave a Comment »

Firebird – adjusting Delphi stored TDateTime (or OLE Automation date) fields that contain Dates, Times or DateTimes

Posted by jpluimers on 2017/02/15

Delphi programmers often store TDateTime (be it date, time or date+time values) as floating points in the database. They take the easy way out basically because TDateTime is nothing but a typed alias for the Delphi Double type (which is equivalent to the IEEE 754 double-precision binary floating-point format: binary64 type) .

Actually, TDateTime is equivalent to the OLE Automation date (which is described in the remarks of  DateTime.ToOADate Method (System)) which has an epoch of  midnight at 1899-12-30 (to be compatible with Lotus-123 including its leap-year-bug, background on that is at Why are the Microsoft Office file formats so complicated? (And some workarounds) – Joel on Software).

Anyway: the definition is this:

An OLE Automation date is implemented as a floating-point number whose integral component is the number of days before or after midnight, 30 December 1899, and whose fractional component represents the time on that day divided by 24. For example, midnight, 31 December 1899 is represented by 1.0; 6 A.M., 1 January 1900 is represented by 2.25; midnight, 29 December 1899 is represented by -1.0; and 6 A.M., 29 December 1899 is represented by -1.25.

The base OLE Automation Date is midnight, 30 December 1899. The minimum OLE Automation date is midnight, 1 January 0100. The maximum OLE Automation Date is the same as DateTime.MaxValue, the last moment of 31 December 9999.

The sample values are remarkably the same as the ones for TDateTime:

Value Description
0 December 30, 1899; 12:00 A.M.
2.75 January 1, 1900; 6:00 P.M.
-1.25 December 29, 1899; 6:00 A.M.
35065 January 1, 1996; 12:00 A.M.

The below SQL example uses the Firebird date/time/timestamp casting shortcuts:

select date      '1899-12-30'              + 42452.670590278 as Date20160323,
       timestamp '1899-12-30 00:00:00.000' + 42452.670590278 as DateTime20160323160539,
       time       '00:00:00'                + 60*60*24 * 0.5 as Noon,
       timestamp '1899-12-30 00:00:00.000' + 0          as DateTime18991230Midnight,
       timestamp '1899-12-30 00:00:00.000' + 2.75           as DateTime190001011800,
       timestamp '1899-12-30 00:00:00.000' + -1.25          as DateTime189912290600,
       timestamp '1899-12-30 00:00:00.000' + 35065          as DateTime19960101Midnight
from   rdb$database

Which – using DMY date format and 24 hour clock format settings – results in:

DATE20160323 DATETIME20160323160539 NOON       DATETIME18991230MIDNIGHT DATETIME190001011800 DATETIME189912290600 DATETIME19960101MIDNIGHT CONSTANT
---------------------------------------------------------------------------------------------------------------------------------------------------
24-3-2016    23-3-2016 16:05:39     12:00:00   30-12-1899               1-1-1900 18:00:00    28-12-1899 18:00:00  1-1-1996

Which basically taught me a new thing about firebird: Times are calculated in seconds, so date fractions need to be multiplied by 60 * 60 * 24.

You can see this in the following query and results:

select (cast('Now' as time) - cast('00:00:00.000' as time)) / (24 * 60 * 60) as DelphiTime,
        cast('Now' as time) - cast('00:00:00.000' as time) as SecondsSinceMidnight,
        cast('Now' as date) - cast('1899-12-30' as date) as DelphiDate,
        cast('Now' as timestamp) - cast('1899-12-30 00:00:00.000' as timestamp) as DelphiDateTime,
        24 * 60 * 60 as SecondsPerDay,
        cast('Now' as date) as "Date",
        cast('Now' as time) as "Time",
        cast('Now' as timestamp) as "TimeStamp"
from rdb$database
DELPHITIME           SECONDSSINCEMIDNIGHT DELPHIDATE  DELPHIDATETIME       SECONDSPERDAY        Date       Time         TimeStamp          
------------------------------------------------------------------------------------------------------------------------------------------------
0,4366               37722,284            42835       42835,436600509      86400                10-4-2017  10:28:42     10-4-2017 10:28:42      

Note this post is complementary to Date format converter from Text or Unix/Mac/Filetime/Microsoft to virtually any readable form (which mentions the wrong Microsoft epoch as it should be 1899-12-30 midnight): the above shows how to do the conversion to readable dates in Firebird (might work in InterBase as well, but I’ve not used that for a long time).

–jeroen

PS: for Microsoft SQL Server: passing dates to the sql server: pass it as float – 2. -2 is the difference between delphi tdatetime start date and mssql start date.

 

Posted in Algorithms, Database Development, Development, Firebird, Floating point handling, Software Development | 2 Comments »

Delphi history – on the FINITEFLOAT compiler option that has no one-character shortcut

Posted by jpluimers on 2016/12/14

Back in the .NET days, Delphi had an FINITEFLOAT compile option that came without a single-character shortcut.

It was about the handling of infinite float and other special float values in cases like overflow and underflow (including +Inf, -Inf and  [Wayback] NaN).

At first – in the [Wayback] Delphi 8 (Octane) era of which few people want to be reminded off – it was the [Wayback] undocumented counterpart of the [Wayback] 8087 exception mask in x86 mode. Hallvard Vassbotn wrote an article about it and Chee Wee Chua documented it before it got documented in Delphi 2009 (that coincidentally dropped .NET support in the compiler – go figure):

Whereas the native Delphi compilers had exceptions turned on, Microsoft compilers (including .NET) had them turned off, hence the compiler option.

Like most new Delphi features in this century, FINITEFLOAT didn’t come without quirks. Often these are fleshed out in 2-3 product releases, but this one wasn’t:

The FINITEFLOAT compile option didn’t have a single-character shortcut. This made it impossible to use the {$IFOPT ...} construct as IFOPT only works for single-character compiler options.

Which means you get questions like [Wayback] Why doesn’t {$ifopt FINITEFLOAT ON} compile? – Stack Overflow (I actually got into writing this article because I found a {$DEFINE FINFINITEFLOAT_ENABLED} in some pretty old code) and compiler enhancement requests like [WayBackQualityCentral – Please enhance the IFOPT directive for long switch names. It’s easier to read (which will likely never bee fixed).

For completeness some more information about exception masks in the native compiler:

  1. In the past you could only set the exception mask as part of the full control word using [Wayback] Set8087CW, nowadays you can use [Wayback] SetExceptionMask.
  2. Next to a precision mask, there are five exception masks you can set, see for instance this table from the [Wayback] Simply FPU Chap.1 Control Word section:

PM (bit 5) or Precision Mask
UM (bit 4) or Underflow Mask
OM (bit 3) or Overflow Mask
ZM (bit 2) or Zero divide Mask
DM (bit 1) or Denormalized operand Mask
IM (bit 0) or Invalid operation Mask

–jeroen

Posted in 8087, Algorithms, Delphi, Delphi 2005, Delphi 2006, Delphi 2007, Delphi 2009, Delphi 8, Development, Floating point handling, History, QC, Software Development | 1 Comment »

Spring4D, Extended floating point values and Mac OS X: the 16-byte stack alignment

Posted by jpluimers on 2016/12/13

Just a few quick notes after solving a stack corruption issue in Spring4D on Mac OS X involving the Extended data type and 16-bit Stack Alignment:

–jeroen

Posted in Algorithms, Delphi, Delphi XE4, Delphi XE5, Development, Floating point handling, Software Development, Spring4D | Leave a Comment »

SQL Server, Modulo, floats

Posted by jpluimers on 2016/12/08

SQL server % (modulo, not mod) operator doesn’t like floats (with reason).

You should get rid of the floats as they will give inaccurate results.

As a workaround, cast either through an integer or through a decimal: sql server modulo float – Google Search

CAST(CAST(TheInaccurateFloatValue AS decimal(38,19)) % ModuloValue AS float)

The decimal(38,19) is the maximum non-float precision you get.

( cast(dividend as integer) % divisor ) + ( dividend - cast(dividend as integer))

–jeroen

Posted in Algorithms, Database Development, Development, Floating point handling, Software Development, SQL, SQL Server, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014 | Leave a Comment »

 
%d bloggers like this: