In keeping with my tendency to find odd command behavior, I've stumbled onto some strangeness involving dayOfWk(. Normal use cases constitute passing in a year, month, and day, with checks in place to ensure that the month and day make sense.
However, the year can be almost whatever you want. The first tier of this is passing in an absurdly large or absurdly negative year; the output will be in line with the Gregorian calendar if it continues to or as if it did exist in the given year. The next tier is decimals: the fractional part of the year will appended to the output day, with the integer part used for calculation. Continuing along, complex years will ignore their real part; evaluation proceeds using the imaginary part and follows the previous rules.
We finally come to the strangest behavior: all the other types. Given any other kind of year (that doesn't immediately error for other reasons), dayOfWk( will pretend the year is 0. Leap year checks will reasonably fail, meaning only March and later can be queried. We might summarize these results thusly:
Code:
However, there is still one more bit of trickery. See, if you put dayOfWk({420},4,17) into an equation and check the output, you'll find it to be 6 instead of 2, which just so happens to align with dayOfWk(420,4,17). This is because of equations' ability to graph lists by graphing each of their elements as if they were own equation; putting in a longer list of years and checking the graph can confirm this.
Now, I must confess this tomfoolery lies now entirely in retrospect: dayOfWk( checks for integers in every argument as of OS 5.8. However, we can still take this old behavior as a sign of some real madness afoot with the equation parser and grapher; after all, dayOfWk( never actually outputs a list!
Those knowing ones who can offer a pickle of further or insider detail would be appreciated, and I imagine there isn't anything too weird actually happening; just some questionable parser shortcuts, as are TI's specialty. A breakdown of the entire process would also be interesting, as, for instance, we have the interesting DIM MISMATCH error that occurs from graphing seq(A,A,1,X).
However, the year can be almost whatever you want. The first tier of this is passing in an absurdly large or absurdly negative year; the output will be in line with the Gregorian calendar if it continues to or as if it did exist in the given year. The next tier is decimals: the fractional part of the year will appended to the output day, with the integer part used for calculation. Continuing along, complex years will ignore their real part; evaluation proceeds using the imaginary part and follows the previous rules.
We finally come to the strangest behavior: all the other types. Given any other kind of year (that doesn't immediately error for other reasons), dayOfWk( will pretend the year is 0. Leap year checks will reasonably fail, meaning only March and later can be queried. We might summarize these results thusly:
Code:
dayOfWk(2023,4,17 // 2
dayOfWk(0,4,17 // 2, funnily enough
dayOfWk(2023.7,4,17 // 2.7
dayOfWk(8+0.9i,4,17 // 2.9
dayOfWk({420},4,17 // 2
dayOfWk([A],4,17 // 2
However, there is still one more bit of trickery. See, if you put dayOfWk({420},4,17) into an equation and check the output, you'll find it to be 6 instead of 2, which just so happens to align with dayOfWk(420,4,17). This is because of equations' ability to graph lists by graphing each of their elements as if they were own equation; putting in a longer list of years and checking the graph can confirm this.
Now, I must confess this tomfoolery lies now entirely in retrospect: dayOfWk( checks for integers in every argument as of OS 5.8. However, we can still take this old behavior as a sign of some real madness afoot with the equation parser and grapher; after all, dayOfWk( never actually outputs a list!
Those knowing ones who can offer a pickle of further or insider detail would be appreciated, and I imagine there isn't anything too weird actually happening; just some questionable parser shortcuts, as are TI's specialty. A breakdown of the entire process would also be interesting, as, for instance, we have the interesting DIM MISMATCH error that occurs from graphing seq(A,A,1,X).