Help please - date math

[Dutchman]

Dutchman, I was looking through your code and I found an error, which I do not think will effect the results. The Gregorian Calendar actually starts on Thursday, 14 September 1752 in the United States, not on 15 October 1582.
…

That is not an error. The Gregorian Calendar starts on 15 October 1582.
The USA however have been quite slow to accept the new development.
That is why I also wonder when the SI system will become commonplace in the USA.
Another 150 years?

[Henko]

And back to Steve:
After considerable, combined effort of dutchman, george, henko and rbytes the following should do the trick:

Code: Select all

' test program of category function
'
do
  if dat()=0 then continue    ' get a date somehow
  mm=dat.m ! dd=dat.d ! yy=dat.y
  print dat.dt$ & ": " & category(mm,dd,yy)
  until forever
end

' Function that compares a date with todays date and places it
' in one of 3 categories: 7 days interval, 14, or 30 days.
' if neither category, the function returns zero.
'
def category(mm,dd,yy)
y=current_year()! m=current_month() ! d=current_date()
n_today=g(y,m,d)
n_date=g(yy,mm,dd)
diff=n_today-n_date
cat=0
if diff%7=0  then return 7
if diff%14=0 then return 14
if diff%30=0 then return 30
return 0
end def

' function that provides a date in 3 integers
' returns 1 if ok, 0 if invalid date-format was entered
' 
def dat()
ob=option_base ! option base 1
input "mm-dd-yyyy":dt$
split dt$ to d$,nd with "-"
if nd<>3 then return 0        ' error
m=d$(1) ! d=d$(2) ! y=d$(3)
return 1
end def

DEF g(y,m,d)
    m = (m + 9) % 12
    y = y - floor(m/10)
    nd = 365*y + floor(y/4) - floor(y/100) + floor(y/400) + floor((m*306 + 5)/10) + ( d - 1 )
    RETURN nd
ENDDEF

[Dutchman]

However, be aware of the strange USA-habit of "mm-dd-yyyy" as date format.
Better change it to the international ISO-date sequence: https://en.wikipedia.org/wiki/ISO_8601

[Bish99&@]

I want to clarify my initial problem, it was not that the Date Calculaor code didn't work, it was that I couldn't figure out how to how to obtain the result of the function and use it in my program. When I ran the Date Calculator function by itself with a couple of input dates I received the correct interval, I just didn't know how to use it. I really didn't mean to impugn the effectiveness of Dutchman's date functions, my problem was my ignorance using Smart Basic, I still have that same problem, but just a little less do. Rbytes and Henko's modification to the date calculator function made it possible for me to understand and extract the value returned from the function so I could use it in my program. Thank again for everyone's responses and help.

[Henko]

It will not, because enclosing the entire formula in parentheses, it makes each division obey the INT, or more accurately, it applies it to each division.

George, this is not true. Because of precedence rules, anything between brackets will be evaluated first, irrespective of what's outside the brackets. After that, the INT operation will be applied to the result.

And integer division does not round the decimal fraction after division, but simply truncates the division result to an integer. In SmartBasic, this means that FLOOR must be used, instead of INT.

[GeorgeMcGinn]

Dutchman, I have no idea when we will officially adopt the metric system, but I know it is taught in school today (I know it wasn't taught to great extent in the 70's and 80's, but our military uses the SI system almost exclusively (when giving info to the public they still use the inches/feet/yard/miles). But I agree with you we need to make it official. But that very fact is at the center of my disagreement with you about card blanch use of when the Gregorian Calendar was adopted.

Yes, the Pope Gregory XIII did introduce the calendar 15 October, 1582, but only 4 countries started using it then, and one more the next year. Then there as a long gap before Britain and the colonies adopted it, and then another long period of time before it was next adopted.

Not only did its use not happen all at the same time, not everyone added 10 days. Some added more to it, because they needed to account for the fact that they used that many more leap year day(s) that were not in the Gregorian Calendar.

Maybe error should be explained better by me, which I thought I didi. Your program and now my formula works, but if not used correctly will produce erroneous results, as I proved in my prior post. Your program got the day of week right, but only if the US started to use the calendar on 10/15/1582. It is only when used improperly (without considering the facts below) will it produce wrong results.

Like saying that in the US, 2 September 1752, your program said it was a Saturday, when in fact it was a Wednesday (last day we used the Julian Calendar). If we adopted the calendar as soon as it came out, your program calculates correctly. But my use of it produced an error because of when the calendar was adopted. In fact, because of when it was adopted, any country not adopting it on 10/15/1752, your program cannot be used until the calendar is adopted. When I put 9/14/1752 into Calendar.sb, it comes up with the right day of the week now, but it's the first day of the Gregorian Calendar as far as we are concerned, not the 62,062nd day.

I just think that we can't just provide a generalized statememts without providing details, like I did when Henko helped in finishing the formula. People need to know when the program can or can't be used.

So here is a simplified chart showing the period of 300+ years where everyone didn't start using the calendar on 10/15/1582.

IMG_0061.JPG (203.49 KiB) Viewed 5515 times

Let's read what this site (https://www.timeanddate.com/calendar/ju ... witch.html) had to say:

Switch Took More Than 300 Years

The Gregorian Calendar was first introduced in 1582 in some European countries (*). However, many countries used the Julian Calendar much longer. Turkey was the last country to officially switch to the new system on January 1, 1927.

The delay in switching meant that different countries not only followed different calendars for a number of years but also had different rules to calculate whether a year was a leap year.

This explains why the years 1700, 1800, and 1900 were leap years in countries still using the Julian calendar (e.g. Greece), while in countries that had adopted the Gregorian calendar (e.g. Germany), these years were common years.

Sweden and Finland had a "double" leap year in 1712. Two days were added to February, creating February 30, 1712. This was done because the Leap Year in 1700 was dropped and Sweden's calendar was not synchronized with any other calendar. By adding an extra day in 1712, they were back on the Julian calendar. Both countries introduced the Gregorian calendar in 1753.

Our tools are only good when we take into account real life. And if not careful and used improperly, our used when it does not apply, without this added info, how will you know the results are correct?


————————————————————————
George McGinn (@GJMcGinn — Twitter)
Computer Scientist/Cosmologist/Writer
Member: IEEE, IEEE Computer Society, IEEE Sensors Council
Scientific and Mathematical consultant & reviewer of the peer paper and the book "Flying Through The Year 200 000" (available on Kobo)

Dutchman, I was looking through your code and I found an error, which I do not think will effect the results. The Gregorian Calendar actually starts on Thursday, 14 September 1752 in the United States, not on 15 October 1582.
…

That is not an error. The Gregorian Calendar starts on 15 October 1582.
The USA however have been quite slow to accept the new development.
That is why I also wonder when the SI system will become commonplace in the USA.
Another 150 years?

[GeorgeMcGinn]

That is true of SmartBASIC, but other languages like "R" and TechBASIC (from what I read) will apply the function throughout, even converting data types before doing the division.

I am testing this with as many languages (mobile, desktop (Windows, MAC, UNIX), and mainframe languages) as Rbytes was the first to tell me that the use of MATH functions are treated differently, depending on the language used. Even same language can apply them differenly. So I'm going to test a good number of these to see just how each treats them.

But according to the SB documentation, INT rounds to the nearest. Here is how it is written by Mr. k:
INT (X)
returns integer nearest to [x]. *** This suggests rounding

Here is how FLOOR is written:
FLOOR (X)
returns largest integer not greater than [x]. *** this implies that it does not round up

Is the documentation wrong? Or does these functions not work as expected?

The documentation seems to contradict what you are saying.

In the case of the formula I posted, yes, FLOOR is the right choice to use. But if what you are saying is correct that INT truncates, yet the documentation says to the nearest, which means it rounds up if needed. And FLOOR does no rounding up, but suggests it will round down.

I have to find it, but I wrote a program that tests what all the Math Functions do to a series of numbers.

George

It will not, because enclosing the entire formula in parentheses, it makes each division obey the INT, or more accurately, it applies it to each division.

George, this is not true. Because of precedence rules, anything between brackets will be evaluated first, irrespective of what's outside the brackets. After that, the INT operation will be applied to the result.

And integer division does not round the decimal fraction after division, but simply truncates the division result to an integer. In SmartBasic, this means that FLOOR must be used, instead of INT.

[Henko]

George, i was referring to the term "integer division", as was mentioned in the website that you referrerenced. The common meaning is that it means division, followed by truncation of the result.

The standard practice for the INT function is truncation. Originally, this was also the case in SmartBasic. At a certain moment, the function of the INT function was changed into rounding. I noticed this, because some of my programs gave suddenly erronous results or even abended. Then a truncating function FLOOR was introduced.

I have never seen that an INT before a bracketed expression will apply its function individually to all terms within the brackets, but i will gladly take your word for it. All i know is that this is NOT the case for C, Fortran, Python and SmartBasic.

So, the functions of INT and FLOOR are well described by the documentation and i have no other thoughts about that.

[GeorgeMcGinn]

Got it now and yes, I agree with you.

As for the how the functions work in other languages, I will let them ou know after I run test cases through the formula we worked on here. For I have read whst Rbytes said he noticed in Stack Exchange, but this was in the Mathematics Stack, not the coding, so I will run these to see for myself (while it may or may not be true, I want to see for myself and if true, then I have at least a magazine article, if not a paper for the IEEE).

But I know it does not work in SB for while I was half asleep and testing with the entir formula bracketed with FLOOR(), you got it to work using it individually.

I have access to 50+ different languages or variations on the same languages (10-12 different BASICs alone), on my Win and Mac OS's, 20+ more (most are on Windows, and 2 are DB languages - Borland Paradox and MS Access, and 9 languages from Hercules' z/390 mainframe emulator, Microfocus Net Express, CA Realia Visual COBOL and its mainframe emulator, I will have enough to prove, disprove, or to try and understand why.

For you may be right, and while I know TechBASIC will change a variable's type before executing a formula, that also isn't true everywhere else.

Since the results will be beyond the scope of SB, I will email you the results. I still have your email address. Like the program I use to test a compiler's ability to handle precision numbers, I plan use that as a model and run it in as many languages as I can. I plan to include a matrix (if I can find it again) on how FLOOR, CEIL, INT, etc. are supposed to work.

As far as the formula, you again helped me greatly, and I thank you. Also, I think everyone should understand that you have to limit the use of it and Calendar.sb based on when your country adopted its changes if you plan to use it for historical events. At least until some can come up with a function that takes the switch over into account and combines formulas for both Julian and Gregorian Calendars, then you can find out all the information provided by Dutchman's programs for dates up to about 3,000 years ago.

It is an interesting project, but while I might work on it on and off, maybe someone might want to work on it here.

Thanks again Henko, your help and contributions are always are always on the mark. Dutchman and Rbytes, the same goes with both of you as well.

George.

George, i was referring to the term "integer division", as was mentioned in the website that you referrerenced. The common meaning is that it means division, followed by truncation of the result.

The standard practice for the INT function is truncation. Originally, this was also the case in SmartBasic. At a certain moment, the function of the INT function was changed into rounding. I noticed this, because some of my programs gave suddenly erronous results or even abended. Then a truncating function FLOOR was introduced.

I have never seen that an INT before a bracketed expression will apply its function individually to all terms within the brackets, but i will gladly take your word for it. All i know is that this is NOT the case for C, Fortran, Python and SmartBasic.

So, the functions of INT and FLOOR are well described by the documentation and i have no other thoughts about that.

[Mr. Kibernetik]

Most likely you are experiencing problems at the initial level of mathematics, I advise you to visit online math courses. You will be able to improve your knowledge in algorithms and will not get confused in the tables. By the way, I already told my child, because he experiences almost the same problems. After two weeks of intensive math learning on this site, my child is getting a much better score.

Please avoid posting non-relevant links, otherwise you will be treated as a spam bot and blocked. Thank you.