Re: CEP an alternative to JDN

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Amos Shapir-2
(Changed Subject line)

Hi Sepp and calendar people,

Day number counts differ by only one element: their epoch, i.e. which day is defined as "day one" of the count.  How this day was chosen is irrelevant to the merits of one count over another, and so are all reasons Sepp lists as faults of the JDN count.

There was however one factor of defining JDN which is relevant, but not mentioned by Sepp: its epoch was set far enough in the past, so that for most of known history, all dates would have positive JDN numbers, and the AD/BC confusion would be avoided.  This is the main advantage of JDN, and exactly the one the definition of CEP does away with.


On Tue, Jan 31, 2017 at 5:41 PM, Sepp ROTHWANGL <[hidden email]> wrote:
Dear List,

The Christian calendar is outdated, corrupted, wrong, manipulative, superstitious, religious, fictitous  and so on…
When you read my articles about Anno Domini, you will be confirmed.

But to establish a new secular calendar - basing on real facts and celestial movements-  will be a long way to go.

Thus I started with a tiny first step, an alternative to the Julian Days, because Julian Days is also based upon the religious Christian calendar.

https://www.academia.edu/24708257/CEP_an_alternative_to_JDN

See here a German article of Austrian governmental Newspaper: 



--
Amos Shapir
 
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Sepp Rothwangl
Hi Amos, 
you are true about the math problem of the epoch, but not on the veritable.
And what is the problem of negative numbers? They change into positive after zero.
… -3, -2, -1, 0, +1, +2, +3, …
Why not use negative and positive numbers, as we do also with astronomical years.

servus
Sepp Rothwangl, CEP -240.376
[hidden email]
www.calendersign.com
facebook.com/sepp.rothwangl



Am 01.02.2017 um 08:43 schrieb Amos Shapir <[hidden email]>:

(Changed Subject line)

Hi Sepp and calendar people,

Day number counts differ by only one element: their epoch, i.e. which day is defined as "day one" of the count.  How this day was chosen is irrelevant to the merits of one count over another, and so are all reasons Sepp lists as faults of the JDN count.

There was however one factor of defining JDN which is relevant, but not mentioned by Sepp: its epoch was set far enough in the past, so that for most of known history, all dates would have positive JDN numbers, and the AD/BC confusion would be avoided.  This is the main advantage of JDN, and exactly the one the definition of CEP does away with.


On Tue, Jan 31, 2017 at 5:41 PM, Sepp ROTHWANGL <[hidden email]> wrote:
Dear List,

The Christian calendar is outdated, corrupted, wrong, manipulative, superstitious, religious, fictitous  and so on…
When you read my articles about Anno Domini, you will be confirmed.

But to establish a new secular calendar - basing on real facts and celestial movements-  will be a long way to go.

Thus I started with a tiny first step, an alternative to the Julian Days, because Julian Days is also based upon the religious Christian calendar.

https://www.academia.edu/24708257/CEP_an_alternative_to_JDN

See here a German article of Austrian governmental Newspaper: 



--
Amos Shapir
 

Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Irv Bromberg
In reply to this post by Amos Shapir-2
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Amos Shapir [[hidden email]]
Sent: Wednesday, February 01, 2017 02:43

Day number counts differ by only one element: their epoch, i.e. which day is defined as "day one" of the count.  How this day was chosen is irrelevant to the merits of one count over another, and so are all reasons Sepp lists as faults of the JDN count.

There was however one factor of defining JDN which is relevant, but not mentioned by Sepp: its epoch was set far enough in the past, so that for most of known history, all dates would have positive JDN numbers, and the AD/BC confusion would be avoided.  This is the main advantage of JDN, and exactly the one the definition of CEP does away with.


Irv replies: I would agree with Sepp that there is no problem using negative numbers and zero in the context of a day numbering system (but then again wait until my last paragraph below).

Kalendis allows any arbitrary date to be used as the epoch for its day numbering system, although always starting at midnight. (The JDN started at noon on the epoch.) If I recall correctly, its default epoch is the Gregorian epoch.

I have mentioned previously that the main reason in my mind for using a different epoch, specifically a near-present-era epoch (my preferred epoch is January 1, 2001, the start of the current millennium), is to reduce the number of digits in the day number for near-present-era dates. This isn't because I'm "lazy" about day numbering but specifically because the available number of significant figures in double precision floating point numbers actually presents a limitation for resolving the time-of-day precisely when the date is the integer part and the time-of-day is the decimal fraction part of the floating point number, for JDNs. Many PCs calculate with 18 significant figures internally but only 14 significant figures externally (displayed or printed).

Today is JDN 2457785.5, so to the left of the decimal point we have 7 significant figures just to specify the date. That makes it impossible to use single precision floating point calculations with JDNs. The day number calculated since the start of the current millennium only needs 4 digits, which leaves an extra 3 significant figures for resolving the time-of-day. Several on this LISTSERV have insisted that this difference isn't important, but I keep running into computational inaccuracies caused by it when using traditional JDN epoch instead of my preferred near-present-era epoch.

Of course, with January 1, 2001 as the epoch, all prior dates would have negative values, but that doesn't cause any loss of precision, since the negative state is only indicated by the sign bit, which is always present in floating point values.

In particularly critical time-related calculations, one could choose an even closer epoch to further reduce the digits to the left of the decimal point, or consider using a rolling epoch that always stays near the moments that are being processed.

I asked Prof. Aldo Vitagliano how he handles this limitation of floating point values when his SOLEX program is performing numerical integration far into the remote past or distant future. I should mention that SOLEX optionally supports extended double precision floating point calculations (80 bits instead of 64 bits, which is supported by the hardware of most PCs even though rarely used), which adds, if I recall correctly, 4 significant figures of precision, the trade-off being modestly longer computation time -- I always use this option in SOLEX, as well as the higher-order integration option that also slows calculations further, because I'm willing to wait for more precise calculations. I can't find his email reply, but as I recall he explained that he stores the JDN separately from the time-of-day, so that SOLEX always has full precision for both the date and the time-of-day.

Anyway, Sepp presented this idea as an initial easy-to-accept step toward calendar reform, but it would be essentially useless for that purpose. The only people who really care about JDNs or alternate epoch ordinal day numbering are technical chronologists (calendar geeks) and astronomical professionals who are concerned with celestial mechanics.

Note that Windows operating systems use a near-present-era epoch. Microsoft claims that day #1 was January 1st, 1900, but because they made a mistake in considering the year 1900 to be a leap year, in effect their epoch was December 31, 1899, at least for all moments on or after March 1st, 1900. Strangely, Windows doesn't allow any negative values for their ordinal day number, so it has no internal way to represent any date prior to January 1st, 1900. Windows also has a future limitation: no year numbers beyond 9999. Obviously not a problem for normal calendrical purposes, but it certainly mucks up future astronomical calculations beyond 8 millennia from the present. Kalendis does its own calendrical calculations, not relying on Windows or the Windows internal date-time representation.

-- Irv Bromberg, Toronto, Canada

http://www.sym454.org/kalendis/
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Sepp Rothwangl
Dear Irv and Amos,

IMO it is not irrelevant what is chosen as epoch, if you want to be temporally orientated in real facts (and not in fictitious or „alternative“ facts).
JDN is based upon an inconsistent religious and political base and named after Caesar (or Scaligher) and the epoch is chosen by arbitrary numbers of an religious calendar using seven day week. You cannot find any real significant event behind it, which really happened.
The epoch of JDN is a random day of the year, without any significance!

The epoch of CEP is the calendrical most decisive day of vernal equinox, which actually will take place in 240.376 days, if we are not extinct before. 
And all planets, including Sun and Moon are assembled in a planetary massing (as seen from Earth), which was seen in former times in many myths as start of the cosmos, like all hand of a watch point to zero (or 12).
This moment seems to be unique in the written history of mankind, because you cannot calculate, when it ever happened before or will repeat in this way. (in Short: all planets within 30° at  NVE)
Even AD was established in such a way focussing an alignment, but with an religious and outdated weltanschauung. And many other myths tell of it.

CEP is based on a real event that is based only on a calendrical most significant term and an extremely rare planetary incidence.
No personal, political, or religious base! 
Just science, astronomy, history of astronomy, and cultural heritage of mankind.

Servus
Sepp Rothwangl, CEP -240.375
[hidden email]
www.calendersign.com
facebook.com/sepp.rothwangl



Am 01.02.2017 um 15:48 schrieb Irv Bromberg <[hidden email]>:

Day number counts differ by only one element: their epoch, i.e. which day is defined as "day one" of the count.  How this day was chosen is irrelevant to the merits of one count over another, and so are all reasons Sepp lists as faults of the JDN count.

Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Michael H Deckers
In reply to this post by Irv Bromberg
   On 2017-02-01 14:48, Irv Bromberg wrote:


> I asked Prof. Aldo Vitagliano how he handles this limitation of floating point values when his SOLEX program is performing numerical integration far into the remote past or distant future. I should mention that SOLEX optionally supports extended double precision floating point calculations (80 bits instead of 64 bits, which is supported by the hardware of most PCs even though rarely used), which adds, if I recall correctly, 4 significant figures of precision, the trade-off being modestly longer computation time -- I always use this option in SOLEX, as well as the higher-order integration option that also slows calculations further, because I'm willing to wait for more precise calculations. I can't find his email reply, but as I recall he explained that he stores the JDN separately from the time-of-day, so that SOLEX always has full precision for both the date and the time-of-day.

   Yes, using two flaoting point values for time is common
   in astronomical libraries, eg in SOFA. There are
   standard algorithms for computing with such number
   pairs, such as Kahan summation.

   IEEE 64 bit floating point has a resolution of
   15.9 decimal digits, so that current datetimes are
   limited to ms resolution when expressed in JD.

   Moreover, robust numerical software must use wider
   formats in certain internal calculation (eg, for
   scalar products) if the 64 bit output should be
   reliable. But 128 bit floating point hardware
   is currently limited to big machines.


> Note that Windows operating systems use a near-present-era epoch. Microsoft claims that day #1 was January 1st, 1900, but because they made a mistake in considering the year 1900 to be a leap year, in effect their epoch was December 31, 1899, at least for all moments on or after March 1st, 1900. Strangely, Windows doesn't allow any negative values for their ordinal day number, so it has no internal way to represent any date prior to January 1st, 1900. Windows also has a future limitation: no year numbers beyond 9999. Obviously not a problem for normal calendrical purposes, but it certainly mucks up future astronomical calculations beyond 8 millennia from the present. Kalendis does its own calendrical calculations, not relying on Windows or the Windows internal date-time representation.

   You are apparently referring to the Datetime values
   of Excel which are indeed quite limited.
   But Windows has, for example System::DateTimeOffset
   which has 0.1 µs resolution and covers the range
   from G0001-01-01 to G10000-01-01 - 1 s. And
   programming languages such as C++ and Java run on
   Windows and offer datetime and time values with vast
   ranges and ns resolution.

   Michael Deckers.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Irv Bromberg
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers [[hidden email]]
Sent: Thursday, February 02, 2017 06:25

Moreover, robust numerical software must use wider formats in certain internal calculation (eg, for scalar products) if the 64 bit output should be reliable. But 128 bit floating point hardware is currently limited to big machines.

Bromberg: The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multi-threaded 256-bit floating point, but I don't know what's involved in accessing its full computational precision, nor which programming languages make it available. See:


Bromberg previously wrote: Note that Windows operating systems use a near-present-era epoch. Microsoft claims that day #1 was January 1st, 1900, but because they made a mistake in considering the year 1900 to be a leap year, in effect their epoch was December 31, 1899, at least for all moments on or after March 1st, 1900. Strangely, Windows doesn't allow any negative values for their ordinal day number, so it has no internal way to represent any date prior to January 1st, 1900. Windows also has a future limitation: no year numbers beyond 9999. Obviously not a problem for normal calendrical purposes, but it certainly mucks up future astronomical calculations beyond 8 millennia from the present. Kalendis does its own calendrical calculations, not relying on Windows or the Windows internal date-time representation.

Deckers replied: You are apparently referring to the Datetime values of Excel which are indeed quite limited.

Bromberg: Actually that is the normal internal date format for Windows, not limited to Excel. Windows, Visual Basic, Excel, Visual Basic for Applications all use these as the ordinary date/time format. In Visual Basic one can declare a variable as "Date" type, but it is basically a relabeling of the double-precision floating point type, and the programmer can freely interchange between these two types. Thus one can take a "Date" type MOD 1 to obtain the time, or can extract the time using the TIME( ) function. One can perform the usual arithmetic operations (mainly addition or subtraction) on "Date" types to carry out calendrical calculations, and the values added or subtracted can be integers or floating point values or "Date" types. Kalendis also uses double precision floating point to store moments, but doesn't declare them as "Date" types, because the "Date" type has the limitations that I previously discussed, whereas floating point representation doesn't. So the "Date" limitation in Windows isn't due to the internal representation, it is just an arbitrary limitation imposed by Microsoft, presumably because at the time they didn't know how to carry out calendrical calculations properly (as evidenced by their designating the year 1900 as a leap year, which persists to this day, purportedly so that "legacy" code doesn't malfunction). It is the floating point precision that limits the ability to resolve time-of-day accurately when Kalendis is evaluating remote past or distant future dates, and that, along with uncertainty of the Earth axial tilt and Delta T with present knowledge, is the reason why I did program in a limit on the Kalendis date range (currently G-6937-09-07 to G12000-01-01), or roughly 9000 years into the past and 10000 years into the future -- admittedly that range is a rather liberal limitation relative to the uncertainties just mentioned.

Deckers continued: But Windows has, for example System::DateTimeOffset which has 0.1 µs resolution and covers the range from G0001-01-01 to G10000-01-01 - 1 s. And programming languages such as C++ and Java run on Windows and offer datetime and time values with vast ranges and ns resolution.

Bromberg: Interesting. G0001 adds 1900 years on the "bottom end", but apparently no negative year numbers are allowed, and G10000-01-01 doesn't add anything on the top.  I was unaware of these Windows alternatives, where can I find more information about them?

-- Irv Bromberg, Toronto, Canada

http://www.sym454.org/
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Victor Engel
Dear Calendar People,

If I'm following correctly, the 1900 leap day bug was created on purpose in order to be compatible with Lotus 1-2-3.

Victor

On Thu, Feb 2, 2017 at 12:03 PM, Irv Bromberg <[hidden email]> wrote:
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers [[hidden email]]
Sent: Thursday, February 02, 2017 06:25

Moreover, robust numerical software must use wider formats in certain internal calculation (eg, for scalar products) if the 64 bit output should be reliable. But 128 bit floating point hardware is currently limited to big machines.

Bromberg: The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multi-threaded 256-bit floating point, but I don't know what's involved in accessing its full computational precision, nor which programming languages make it available. See:


Bromberg previously wrote: Note that Windows operating systems use a near-present-era epoch. Microsoft claims that day #1 was January 1st, 1900, but because they made a mistake in considering the year 1900 to be a leap year, in effect their epoch was December 31, 1899, at least for all moments on or after March 1st, 1900. Strangely, Windows doesn't allow any negative values for their ordinal day number, so it has no internal way to represent any date prior to January 1st, 1900. Windows also has a future limitation: no year numbers beyond 9999. Obviously not a problem for normal calendrical purposes, but it certainly mucks up future astronomical calculations beyond 8 millennia from the present. Kalendis does its own calendrical calculations, not relying on Windows or the Windows internal date-time representation.

Deckers replied: You are apparently referring to the Datetime values of Excel which are indeed quite limited.

Bromberg: Actually that is the normal internal date format for Windows, not limited to Excel. Windows, Visual Basic, Excel, Visual Basic for Applications all use these as the ordinary date/time format. In Visual Basic one can declare a variable as "Date" type, but it is basically a relabeling of the double-precision floating point type, and the programmer can freely interchange between these two types. Thus one can take a "Date" type MOD 1 to obtain the time, or can extract the time using the TIME( ) function. One can perform the usual arithmetic operations (mainly addition or subtraction) on "Date" types to carry out calendrical calculations, and the values added or subtracted can be integers or floating point values or "Date" types. Kalendis also uses double precision floating point to store moments, but doesn't declare them as "Date" types, because the "Date" type has the limitations that I previously discussed, whereas floating point representation doesn't. So the "Date" limitation in Windows isn't due to the internal representation, it is just an arbitrary limitation imposed by Microsoft, presumably because at the time they didn't know how to carry out calendrical calculations properly (as evidenced by their designating the year 1900 as a leap year, which persists to this day, purportedly so that "legacy" code doesn't malfunction)
. It is the floating point precision that limits the ability to resolve time-of-day accurately when Kalendis is evaluating remote past or distant future dates, and that, along with uncertainty of the Earth axial tilt and Delta T with present knowledge, is the reason why I did program in a limit on the Kalendis date range (currently G-6937-09-07 to G12000-01-01), or roughly 9000 years into the past and 10000 years into the future -- admittedly that range is a rather liberal limitation relative to the uncertainties just mentioned.

Deckers continued: But Windows has, for example System::DateTimeOffset which has 0.1 µs resolution and covers the range from G0001-01-01 to G10000-01-01 - 1 s. And programming languages such as C++ and Java run on Windows and offer datetime and time values with vast ranges and ns resolution.

Bromberg: Interesting. G0001 adds 1900 years on the "bottom end", but apparently no negative year numbers are allowed, and G10000-01-01 doesn't add anything on the top.  I was unaware of these Windows alternatives, where can I find more information about them?

-- Irv Bromberg, Toronto, Canada

http://www.sym454.org/

Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Irv Bromberg
In reply to this post by Irv Bromberg
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Irv Bromberg [[hidden email]]
Sent: Thursday, February 02, 2017 13:03

The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multi-threaded 256-bit floating point, but I don't know what's involved in accessing its full computational precision, nor which programming languages make it available.

Bromberg adds: I've just learned that Apple didn't put in special hardware for this, rather it is a standard feature of the Xeon CPUs that they use in the Mac Pro. Of course many high-end PCs use similar Xeon CPUs as well. Not only are the floating point registers 256-bits but also the integer registers are too, and these Xeon CPUs perform 256-bit integer arithmetic. I suppose that going to 256-bit floating point made sense so that any 256-bit machine register could read or write any floating point register in one operation, hence a major speed improvement.

I just read through the Apple Swift programming documentation for floating point operations, and the maximum precision that that language supports is 64-bit floating point operands. Of course even without explicitly using 256-bit operands there will still be a precision gain for internal operations within the floating point hardware, especially when multiple consecutive floating point operations are performed before reading back the result, but when storing such a result in a 64-bit variable I expect that it will be either truncated or rounded to fit.

On the other hand, there is the NSDecimalNumber class whose mantissa can have "up to 38 digits":

https://developer.apple.com/reference/foundation/nsdecimalnumber

I'm guessing that this is provided so that any calculating program will run on any compatible CPU regardless of the size of the floating point registers, and that the "up to 38 digits" means that it could be 38 digits if the hardware supports it.


-- Irv Bromberg, Toronto, Canada

http://www.sym454.org/

Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Michael H Deckers
   On 2017-02-03 00:19, Irv Bromberg wrote:


> The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multi-threaded 256-bit floating point, but I don't know what's involved in accessing its full computational precision, nor which programming languages make it available.

   Yes, but these 256 bits are interpreted as a collection of
   four 64 bit floating point values, or 64 bit integers, or
   a collection of 16 floating point values with 32 bit, etc.

   Such "streaming extensions" do not provide wider floating
   point formats but provide for parallel computations where
   a single operation (like ADD) is applied at the same time
   to many operands. They enhance the speed of graphical
   operations, and they are also used in supercomputers
   for number crunching.

   The widest floating point format for a single numeric
   value on Intel CPUs is 80 bit wide (and is ignored by
   Microsoft). Hardware for 128 bit wide floating point
   exists on IBM mainframes but not (yet) on common
   microprocessors.

   Michael Deckers.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Irv Bromberg
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers [[hidden email]]
Sent: Friday, February 03, 2017 02:39

On 2017-02-03 00:19, Irv Bromberg wrote:

> The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multi-threaded 256-bit floating point, but I don't know what's involved in accessing its full computational precision, nor which programming languages make it available.

Yes, but these 256 bits are interpreted as a collection of four 64 bit floating point values, or 64 bit integers, or a collection of 16 floating point values with 32 bit, etc.

Such "streaming extensions" do not provide wider floating point formats but provide for parallel computations where a single operation (like ADD) is applied at the same time to many operands. They enhance the speed of graphical operations, and they are also used in supercomputers
for number crunching.

The widest floating point format for a single numeric value on Intel CPUs is 80 bit wide (and is ignored by Microsoft). Hardware for 128 bit wide floating point exists on IBM mainframes but not (yet) on common microprocessors.

Bromberg replies: OK, thanks, that's interesting, but if so then how does Apple get "up to 38 digits" with their NSDecimalNumber class in their floating point mantissa? (Link given in my previous message.)

-- Irv Bromberg, Toronto, Canada
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Irv Bromberg
In reply to this post by Sepp Rothwangl
This is irrational and futile. If you find CEP useful, then enjoy using it, but you'll likely be on your own.

Hey, I'm probably on my own using my near-present-era ordinal day numbering epoch (January 1, 2001).

Astronomers often use J2000.0 as an epoch, but that is one year earlier plus 12 hours (starts at noon at the Prime Meridian), and it's for Terrestrial Time (atomic), not Universal Time (solar). Before that they used B1950.0, and before that B1900.0
(often called the Besselian epoch).

-- Irv


From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Sepp ROTHWANGL [[hidden email]]
Sent: Thursday, February 02, 2017 05:20

IMO it is not irrelevant what is chosen as epoch, if you want to be temporally orientated in real facts (and not in fictitious or „alternative“ facts).
JDN is based upon an inconsistent religious and political base and named after Caesar (or Scaligher) and the epoch is chosen by arbitrary numbers of an religious calendar using seven day week. You cannot find any real significant event behind it, which really happened.
The epoch of JDN is a random day of the year, without any significance!

The epoch of CEP is the calendrical most decisive day of vernal equinox, which actually will take place in 240.376 days, if we are not extinct before. 
And all planets, including Sun and Moon are assembled in a planetary massing (as seen from Earth), which was seen in former times in many myths as start of the cosmos, like all hand of a watch point to zero (or 12).
This moment seems to be unique in the written history of mankind, because you cannot calculate, when it ever happened before or will repeat in this way. (in Short: all planets within 30° at  NVE)
Even AD was established in such a way focussing an alignment, but with an religious and outdated weltanschauung. And many other myths tell of it.

CEP is based on a real event that is based only on a calendrical most significant term and an extremely rare planetary incidence.
No personal, political, or religious base! 
Just science, astronomy, history of astronomy, and cultural heritage of mankind.

Servus
Sepp Rothwangl, CEP -240.375
[hidden email]
www.calendersign.com
facebook.com/sepp.rothwangl
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Michael H Deckers
In reply to this post by Irv Bromberg
    On 2017-02-03 11:42, Irv Bromberg wrote:

> From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers
>
>> The widest floating point format for a single numeric value on Intel CPUs is 80 bit wide (and is ignored by Microsoft). Hardware for 128 bit wide floating point exists on IBM mainframes but not (yet) on common microprocessors.
>
> Bromberg replies: OK, thanks, that's interesting, but if so then how does Apple get "up to 38 digits" with their NSDecimalNumber class in their floating point mantissa? (Link given in my previous message.)

    By software emulation. Microsoft has System::Decimal
    with 102 bit and 28 decimal digits precision,
    Java, Lisp and MATLAB even provide arbitrarily
    big precision.  It is just much slower than
    hardware arithmetic.

    Such arithmetic is needed in financial applications,
    not only because of the huge numbers, but also
    because the scaling can be done in powers of ten
    rather than in powers of two, as is common in hardware
    arithmetic (where 0.1 is not exactly representable).

    Michael Deckers.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Reply | Threaded
Open this post in threaded view
|

Re: CEP an alternative to JDN

Irv Bromberg
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers [[hidden email]]
Sent: Friday, February 03, 2017 08:19

On 2017-02-03 11:42, Irv Bromberg wrote:

> From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers
>
>> The widest floating point format for a single numeric value on Intel CPUs is 80 bit wide (and is ignored by Microsoft). Hardware for 128 bit wide floating point exists on IBM mainframes but not (yet) on common microprocessors.
>
> Bromberg replies: OK, thanks, that's interesting, but if so then how does Apple get "up to 38 digits" with their NSDecimalNumber class in their floating point mantissa? (Link given in my previous message.)

By software emulation. Microsoft has System::Decimal with 102 bit and 28 decimal digits precision, Java, Lisp and MATLAB even provide arbitrarily big precision. It is just much slower than hardware arithmetic.

Such arithmetic is needed in financial applications, not only because of the huge numbers, but also because the scaling can be done in powers of ten rather than in powers of two, as is common in hardware arithmetic (where 0.1 is not exactly representable).


Bromberg replies: Right, I know about the Microsoft Decimal type, but it is only for integers, with the scaling in powers of ten allowing for accounting for pennies, etc. The Apple NSDecimalNumber class, however, is a true floating point class, with "up to 38 digits" in the mantissa and an exponent ranging from -128 through 127.

Arbitrary precision engines, like that used in Common LISP, will calculate exact results as long as all coefficients are either integers or fractions, mainly in software, but as soon as a floating point decimal number appears as a coefficient, the precision becomes limited by the 64-bit double precision floating point representation and the floating point hardware.