Support Forum / Форум поддержки

Have you ever wondered when Easter will come in the years ahead or in the past. Computing the date of Easter requires finding the remainder of a bunch of integer divisions. For that you need a mod operator that this basic doesn't have. Another def function to the rescue!

Enjoy,
Dale

print "EASTER DATE CALCULATION FOR YEARS 1583 TO 4099"
rem y is a 4 digit year 1583 to 4099
rem d returns the day of the month of Easter
rem m returns the month of Easter
rem Easter Sunday is the Sunday following the Paschal
rem Full Moon (PFM) date for the year
rem This algorithm is an arithmetic interpretation of the 3
rem step Easter Dating Method developed by Ron Mallen 1985.
rem from http://www.assa.org.au/edm
def mod(a,n)=a-(n* int(a/n))
start:
input "year":y
gosub calc
d$=d
print m$;" ";d$;",";y
goto start
rem Subroutine EasterDate (d, m, y)
calc:
FirstDig = int(y / 100) rem first 2 digits of year
Remain19 = mod(y,19) rem remainder of year / 19
rem calculate PFM date
temp = int((FirstDig - 15)/2) + 202 - 11 * Remain19
on FirstDig-20 goto once,done,done,once,once,done,once,once, once,once,once,once,twice,once,once,twice,twice,once,twice, twice
goto done
twice: temp = temp - 1
once: temp = temp - 1
done:
temp = mod(temp,30)
tA = temp + 21
If temp = 29 Then tA = tA - 1
If temp = 28 And Remain19 > 10 Then tA = tA - 1
rem find the next Sunday
tB = mod((tA - 19),7)
tC = mod((40 - FirstDig),4)
If tC = 3 Then tC = tC + 1
If tC > 1 Then tC = tC + 1
temp = mod(y,100)
tD = mod((temp + int(temp / 4)),7)
tE = mod((20 - tB - tC - tD),7) + 1
d = tA + tE rem return the date
If d > 31 Then
d = d - 31
m = 4
m$="April"
else
m = 3
m$="March"
End if
return

I've noticed I get different results for many of the programs on this forum.
When I run 2001-2020, the only years that are correct are 2005,2008,2013,2016
The other years compute a date 1-36 days too early.

foxbase wrote:I've noticed I get different results for many of the programs on this forum.
When I run 2001-2020, the only years that are correct are 2005,2008,2013,2016
The other years compute a date 1-36 days too early.

I can make a guess where the error is.
The program is coded years ago when the "int" function had a truncation function. In one of the updates of SB, the "floor" function was introduced, and the "int" function was changed into a rounding function. A number of programs using the "int" function suddenly gave erronous results. This program is probably one of them.

So, changing the "int" in the "def mod.. etc." line after the REM's by a "floor" might do the trick. (Maybe there are more INT's in the code, i didn't check)

Dalede wrote:For that you need a mod operator that this basic doesn't have. Another def function to the rescue!

Smart basic has a mod-operator:

Numeric math operations are: +, -, *, /, %, ^.
Operation % is a remainder of division …

There is some work to do DaleDe in order to make it correct and at SB-level

Dutchman wrote:

Dalede wrote:For that you need a mod operator that this basic doesn't have. Another def function to the rescue!

Smart basic has a mod-operator:

Numeric math operations are: +, -, *, /, %, ^.
Operation % is a remainder of division …

There is some work to do DaleDe in order to make it correct and at SB-level

Yes, mod operator % was added later.

Dutchman wrote:

Dalede wrote:For that you need a mod operator that this basic doesn't have. Another def function to the rescue!

Smart basic has a mod-operator:

Yes but NOT at the time of coding. Please look at the date of the original posting.

Numeric math operations are: +, -, *, /, %, ^.
Operation % is a remainder of division …

There is some work to do DaleDe in order to make it correct and at SB-level

It WAS at SB level and would still operate correctly if the "int" function was not changed.
Such change is very annoying for hobby programmers and could be disasterous in case of professional usage. SB is an interpreter, not a compiler. That makes a difference in this case.

Henko wrote:It WAS at SB level and would still operate correctly if the "int" function was not changed.
Such change is very annoying for hobby programmers and could be disasterous in case of professional usage. SB is an interpreter, not a compiler. That makes a difference in this case.

Yes, maybe this decision was not the best one. Now I have this experience...

But this is a common practice
If you'd know how much Apple is changing in each iOS version (usually each new iOS release is disastrous for my apps), sB is very stable in its coding paradigm

Mr. Kibernetik wrote:But this is a common practice

I hope not.


If you'd know how much Apple is changing in each iOS version (usually each new iOS release is disastrous for my apps),

Unbelievable (for a company like Apple)

sB is very stable in its coding paradigm

Yes it is very stable indeed. I hope you have enough income from it to stay connected...

New users are in better position because they skipped time of sB's growth