RPL Mini-Challenge: All Odd Digits?

[Gilles59]

(07-17-2017 06:26 AM)Werner Wrote:  SAME and == are not .. the same.

1 1. SAME returns 0.
1 1. == returns 1

Don't know why one would return an integer and the other a real, though..

Cheers, Werner

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

[DavidM]

(07-17-2017 06:26 AM)Werner Wrote:  SAME and == are not .. the same.

1 1. SAME returns 0.
1 1. == returns 1

Don't know why one would return an integer and the other a real, though..

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

(07-17-2017 11:26 AM)Gilles59 Wrote:  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

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.

[Gilles59]

(07-17-2017 08:43 PM)DavidM Wrote:  

(07-17-2017 06:26 AM)Werner Wrote:  SAME and == are not .. the same.

1 1. SAME returns 0.
1 1. == returns 1

Don't know why one would return an integer and the other a real, though..

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

(07-17-2017 11:26 AM)Gilles59 Wrote:  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

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.

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.

[Gerald H]

Thread has gone quiet - Who won?

[Joe Horn]

(07-29-2017 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 07-02 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 LASTARG-version 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!

[Gerald H]

(07-29-2017 01:26 PM)Joe Horn Wrote:  

(07-29-2017 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 07-02 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 LASTARG-version 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!

I guess this is Bill's programme:

Code:


« →STR 0 8
  FOR i DUP i →STR
POS 9 2 IFTE
  STEP LASTARG 2
SAME NIP
»

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:


<< DROP 0. >>

Doesn't often err.

I haven't timed it but guess it's fast.

[John Keith]

Bill's program is the fastest in the best case scenario but your program in post #40 is the fastest for worst-case 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 mini-tutorial in RPL programming.

John

[Joe Horn]

(07-30-2017 09:52 AM)Gerald H Wrote:  If you really want a minimally sized programme for 1,000 digit numbers, how about:

Code:


<< DROP 0. >>

Doesn't often err.

I haven't timed it but guess it's fast.

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.

[Claudio L.]

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 UTF-8 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:«
→STR "13579" 1 NTHTOKENPOS 0 <
»

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 non-odd 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.

[pier4r]

Nice claudio!