RPL MiniChallenge: All Odd Digits?

07172017, 11:26 AM
(This post was last modified: 07172017 11:29 AM by Gilles59.)
Post: #41




RE: RPL MiniChallenge: All Odd Digits?
(07172017 06:26 AM)Werner Wrote: SAME and == are not .. the same. In exact mode R= : 1 1. == returns 1 in approx mode R~ : 1 1. == returns 1. Not very logical... Not really a bug in R= mode but ... a mistake 

07172017, 08:43 PM
Post: #42




RE: RPL MiniChallenge: All Odd Digits?
(07172017 06:26 AM)Werner Wrote: SAME and == are not .. the same. Yes, and another way to show the difference is to tag one of the numbers: 1 :A:1 SAME returns 0. 1 :A:1 == returns 1 (07172017 11:26 AM)Gilles59 Wrote: In exact mode R= : 1 1. == returns 1 I wonder if this is unique to specific firmware versions. My v2.15 50g returns an exact 1 for both modes when executing "1 1. ==". <, >, ≤, ≥, and ≠ also work the same way for me. The only way I can get a real "1." or "0." result from any of the boolean comparisons is if the two arguments are both reals. 

07172017, 09:09 PM
(This post was last modified: 07172017 09:11 PM by Gilles59.)
Post: #43




RE: RPL MiniChallenge: All Odd Digits?
(07172017 08:43 PM)DavidM Wrote:(07172017 06:26 AM)Werner Wrote: SAME and == are not .. the same. My mistake ! I enter the program in R~ mode and the 1 became a 1. I tough I run << 1 1. == >> but it was <<1. 1. == >> Sorry. 

07292017, 07:12 AM
Post: #44




RE: RPL MiniChallenge: All Odd Digits?
Thread has gone quiet  Who won?


07292017, 01:26 PM
Post: #45




RE: RPL MiniChallenge: All Odd Digits?
(07292017 07:12 AM)Gerald H Wrote: Thread has gone quiet  Who won? You and Gilles did, according to Bill Butler: Bill Butler via email 3 days ago Wrote:... But it is Gerald H's original idea (Gilles' IFTE version of Gerald's third 0702 program) that proves to be the winning one  if one uses POS for SREPL with a couple of technical adjustments (like using e.g. TYPE for DROP 0.) one has PSTY (#E169h, 59.) at .0359/2.12 while a LASTARGversion of the same, PSLA (#299Ah, 56.5), gives the best so far at .0367/2.07. A score of 2.07 is less than half my original score of 4.8. Congratulations! <0ɸ0> Joe 

07302017, 09:52 AM
Post: #46




RE: RPL MiniChallenge: All Odd Digits?
(07292017 01:26 PM)Joe Horn Wrote:(07292017 07:12 AM)Gerald H Wrote: Thread has gone quiet  Who won? I guess this is Bill's programme: Code:
which has a size of 56.5 Bytes. He's optimistic about the timing, which assumes a zero near the beginning of the test number. Anyway fastest & smallest. Bravo! If you really want a minimally sized programme for 1,000 digit numbers, how about: Code:
Doesn't often err. I haven't timed it but guess it's fast. 

07302017, 02:19 PM
Post: #47




RE: RPL MiniChallenge: All Odd Digits?
Bill's program is the fastest in the best case scenario but your program in post #40 is the fastest for worstcase integers ( a single 8 near the last digit). I would consider it a tie, but in the real world most large integers will have many even digits, so the best case is actually more likely.
This has been a very entertaining thread and could serve as a minitutorial in RPL programming. John 

07312017, 03:43 AM
Post: #48




RE: RPL MiniChallenge: All Odd Digits?
(07302017 09:52 AM)Gerald H Wrote: If you really want a minimally sized programme for 1,000 digit numbers, how about: Heh heh! Yes, it's very fast. << FP >> is even shorter, but much slower. You win! I haven't timed other single commands that replace any integer object with a 0, e.g. IM, ARG, etc, but I suspect that DROP 0 can't be beat for speed. <0ɸ0> Joe 

08042017, 07:10 PM
Post: #49




RE: RPL MiniChallenge: All Odd Digits?
A side note, of little relevance but perhaps somebody finds this interesting:
I rushed to add any missing functionality to newRPL to run the solutions to this challenge. In particular I wanted to see how routines compare in size vs. classic RPL David's solution (and Joe's) Couldn't run this one, since it uses a relatively dark feature of AND and OR: Strings are treated like arbitrary streams of bytes. In newRPL strings are valid UTF8 streams, and doing AND/OR this way would cause illegal strings to be generated, so I had to discard this method, it won't run under newRPL. 3298's solution Size in newRPL = 72 bytes Time for the average number: 0.0077 sec Score: 0.56 Gerald H's solution Size in newRPL = 92 bytes Time for the average number: 0.00548 sec Score: 0.503 Gerald+Gilles (IFTE) Size in newRPL = 88 bytes Time for the average number: 0.00548 sec Score: 0.482 Notice the identical timing of the last two. So IFTE didn't speed up things, but it did cut 4 bytes off. Last, I wondered is there's newRPL "native" solution, since it has more advanced string functions and came up with this one: Quote:« NTHTOKENPOS looks for the 'nth' (in this case n=1) token within a string, considering any characters given in the second string as separators. It returns the position of the start of a token (here token=anything that doesn't contain the separators), or 1 if not found. In the code above, it considers all odd digits as separators (spaces), and looks for the first nonodd character on the string. If it doesn't find any it means the number was all odd digits. This is very similar to 3298's solution, but saves you from running POS multiple times. This code scores as follows: Size in newRPL = 40 bytes Time for the average number: 0.00191 sec Score: 0.076 All tests above were done using the average number posted somewhere in this thread (100 ones, 100 two's, 100 three's.... 1000 digits total). Comparing code size is roughly what was expected: there's always a 4/2.5 growth factor (a single word in newRPL takes 4 bytes, a single word in classic RPL takes 2.5 bytes), and it seems to hold true in this case. 

08092017, 06:48 AM
Post: #50




RE: RPL MiniChallenge: All Odd Digits?
Nice claudio!
Wikis are great, Contribute :) 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)