(Changed Subject line) Hi Sepp and calendar people,On Tue, Jan 31, 2017 at 5:41 PM, Sepp ROTHWANGL <[hidden email]> wrote:
 Amos Shapir

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 Am 01.02.2017 um 08:43 schrieb Amos Shapir <[hidden email]>:

In reply to this post by Amos Shapir2
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 nearpresentera 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 nearpresentera 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 timeofday precisely when the date is the integer part and the timeofday 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 timeofday. 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 nearpresentera 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 timerelated 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 tradeoff being modestly longer computation time  I always use this option in SOLEX, as well as the higherorder 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 timeofday, so that SOLEX always has full precision for both the date and the timeofday. Anyway, Sepp presented this idea as an initial easytoaccept 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 nearpresentera 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 datetime representation.  Irv Bromberg, Toronto, Canada http://www.sym454.org/kalendis/ 
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 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. 
In reply to this post by Irv Bromberg
On 20170201 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 tradeoff being modestly longer computation time  I always use this option in SOLEX, as well as the higherorder 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 timeofday, so that SOLEX always has full precision for both the date and the timeofday. 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 nearpresentera 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 datetime 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 G00010101 to G100000101  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 
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 multithreaded 256bit 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 nearpresentera 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 datetime 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 doubleprecision 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 timeofday 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 G69370907 to G120000101), 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 G00010101 to G100000101  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 G100000101 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/ 
Dear Calendar People, If I'm following correctly, the 1900 leap day bug was created on purpose in order to be compatible with Lotus 123. Victor On Thu, Feb 2, 2017 at 12:03 PM, Irv Bromberg <[hidden email]> wrote:

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 multithreaded 256bit 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 highend PCs use similar Xeon CPUs as well. Not only are the floating point registers 256bits but also the integer registers are too, and these Xeon CPUs perform 256bit integer arithmetic. I suppose that going to 256bit floating point made sense so that any 256bit 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 64bit floating point operands. Of course even without explicitly using 256bit 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 64bit 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/ 
On 20170203 00:19, Irv Bromberg wrote:
> The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multithreaded 256bit 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 
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers [[hidden email]]
Sent: Friday, February 03, 2017 02:39 On 20170203 00:19, Irv Bromberg wrote: > The hardware of the current Mac Pro cylindrical computer (which I don't have, and never have used) supports multithreaded 256bit 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 
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 nearpresentera 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

In reply to this post by Irv Bromberg
On 20170203 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 
From: East Carolina University Calendar discussion List [[hidden email]] on behalf of Michael Deckers [[hidden email]]
Sent: Friday, February 03, 2017 08:19 On 20170203 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 64bit double precision floating point representation and the floating point hardware. 
Free forum by Nabble  Edit this page 