Hello, everyone! Just for fun, I am making a challenge for you to complete. This challenge is targeted toward those who don't have a lot of experience in TI-Basic programming. But anyone with any experience level may participate.

In this challenge, you will convert the current date and time to a percentage that represents the progress of the year.

For an example input of the current date and time, the following temporary lists will be used:

Code:

getDate→L1
getTime→L2


And the output will be a percentage that looks like this:

Code:

32.18 (% symbol is NOT required!)


Another example is the start of the year is the very beginning of the year is 00.00 and the end is 99.99.

Requirements:

* The program must be equal to or less then 750 bytes
* The program must be compatible on all models of the TI-84 Plus family (including color editions)
* The program must be compatible with OS 2.20+ (no 2.53MP+ commands)
* The code must be YOURS! You may not copy it from other people.
* The output MUST have a fixed decimal place of two. (eg. 56.32)
* The output value must be >0 and <100.01
* No assembly is permitted. This includes ICE, Axe, BBC Basic, Grammar, etc.
* No libraries of any kind are permitted including Celtic III, xLib, Axe, BatLib, etc.
* You must work on this by your own. If you had help from others, what's the point?
* The deadline is 12:00 AM on January 1st, 2021 UTC.
* This program must work with any date and time of any year, INCLUDING LEAP YEARS.

You can take all the time you need, no need to rush!
I think I have something in less than 200 bytes. Could we get a few examples or expected outputs to check our programs?
Like L1 = {2020 12 1}, L2 = {12 0 0}: output = XX.YY?
Alright I decided to give this a try for fun, I have a program that is 82 79 77 76 72 69 bytes.
I'm pretty sure it gives the right results, taking into consideration leap years and the time of day.
Here's my solution (small size for spoiler)
getDate
sub(int(|E4(365+not(fPart(max(Ans)/4)))⁻¹(sum(getTime{30,.5,5!⁻¹})/6!+dbd(81+max(Ans)%,~20+sum(Ans10^({~2,0,2


If you allow rule-bending shenanigans, there's also this 19-byte solution but meh

setDate(2|E3,1,1
setTime(0,0,0
0
Question: If (by accident) I used a token that's exclusive to 2.55MP, and you find out, will I be able to resubmit my program without that token?

Edit: I PM'd you my submission.
ShinyGardevoir wrote:
Question: If (by accident) I used a token that's exclusive to 2.55MP, and you find out, will I be able to resubmit my program without that token?

Edit: I PM'd you my submission.


Yeah, you could do that.
mr womp womp wrote:
Alright I decided to give this a try for fun, I have a program that I think is 82 bytes? I haven't actually bothered to count all the bytes and just based it off the file size.
I'm pretty sure it gives the right results, taking into consideration leap years and the time of day.
Here's my solution (small size for spoiler)
getDate
sub(int(|E4(365+not(4fPart(Ans(1)/4)))⁻¹(sum(getTime{60²,60,1})/86400-dbd(|E2Ans(3)+Ans(2)+sub(Ans(1)-2|E3),81+sub(Ans(1


Nice submission! Your program runs fast and it works for all calculators! Nice work! And it's less than 100 bytes too!
I have a submission, not quite as nice as womp-womps, but still quite small, less than 2^7 bytes.


NoahK wrote:
:cumSum({0,31,0,0,~1,1,~1,1,0,~1,1,~1,1->L3
:28+not(fPart(4^^-1L1(1->L3(3
:86400->S
:sum({60^^2,60,1}L2)+S(L1(3)-1+cumSum(L3)(L1(2->D
:sub(iPart(|E4D/(Ssum(L3



----------- I retract this submission, as it seems it does not work... -----------
71 bytes, expects radian mode:
6!5!->B
getDate
startTmr+Bint(tanh^-1(sqrt(fPart(8^tan^-1(Ans(2->A
setDate(max(getDate),1,1
rand(5!
A/B-int(startTmr/B
sub(int(|E4Ans/int(366-fPart(4^^-1max(getDate

Last I checked this seemed to work and follow the rules. Have had it for about a week and haven't looked at it. Submitting it before I forget. (Merry Christmas, womp!)

Edit: Fixed startTmr being dumb 54->71.
[spoiler]
Wait, so you can just cheese the challenge by just setting the calculator to a certain date, then hard-coding an answer? That's what I'm seeing with these setDate()s.
[/spoiler]
LogicalJoe wrote:
71 bytes, expects radian mode:
6!5!->B
getDate
startTmr+Bint(tanh^-1(sqrt(fPart(8^tan^-1(Ans(2->A
setDate(max(getDate),1,1
rand(5!
A/B-int(startTmr/B
sub(int(|E4Ans/int(366-fPart(4^^-1max(getDate

Last I checked this seemed to work and follow the rules. Have had it for about a week and haven't looked at it. Submitting it before I forget. (Merry Christmas, womp!)

Edit: Fixed startTmr being dumb 54->71.

This code is GREAT, not only is your approach really clever, but the way you deal with months is extremely impressive! Great job!

ShinyGardevoir wrote:
[spoiler]
Wait, so you can just cheese the challenge by just setting the calculator to a certain date, then hard-coding an answer? That's what I'm seeing with these setDate()s.
[/spoiler]

My 2nd entry does that, but its very cheesy and it should definitely not count as an actual entry. On the other hand, Logical's entry is not doing that at all.
Well, I'm not new to TI-BASIC. But combining the solutions so far, I have 44 bytes:


Code:

// seconds since start of year: checkTmr(5!6!int(365.25(Ans-1997
max(getDate
sub(int(25/6^^3/int(366-fPart(Ans/4))checkTmr(5!6!int(365.25(Ans-1997


Apparently there's some timer bug on some color OSs that causes LogicalJoe's solution to need an additional, costly correction. On 2.55MP this seems to not be needed.
lirtosiast wrote:
Well, I'm not new to TI-BASIC. But combining the solutions so far, I have 44 bytes:


Code:

// seconds since start of year: checkTmr(5!6!int(365.25(Ans-1997
max(getDate
sub(int(25/6^^3/int(366-fPart(Ans/4))checkTmr(5!6!int(365.25(Ans-1997


Apparently there's some timer bug on some color OSs that causes LogicalJoe's solution to need an additional, costly correction. On 2.55MP this seems to not be needed.

Logical's original 54 byte solution didn't account for the timer bug, which meant it didn't work on the CE, but it would work on 2.55MP. Any timer-based solution will be off on some models since the same commands just spit out different numbers on different OSs (2.55MP, early CE and M+ CE all give different values).
Looking more closely at the bug, on early CEs, the values returned are a whole number of days off, specifically, 31-(days in the specific month) off, so a date in february would be 3 days off, a date in april would be 1 day off and a date in january would give the correct answer (since it has 31 days). For rev M+, it looks like that bug is present, along with some more weirdness, I'm not exactly sure what the calculator is doing.
When creating my initial solution, I had also tried iterating on a timer-based solution and couldn't get it to output consistent values (on M+), which is why I went with a pure mathematical solution. That being said, 44 bytes is still very impressive!
How many submissions have been submitted since Dec 1, 2020? I hate to be that one guy, but the deadline has passed.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement