[SOLVED] DSRN (dog slow roman numerals)

[kakima]

(06-15-2014 07:29 PM)Thomas Klemm Wrote:  But then 4 + { 1 2 3 } = { 5 6 7 }.

Actually it's { 4 1 2 3 }. At least it's consistent in that + adds an element to the list. Well, that's not quite right. What's { { 1 1 } { 2 4 } { 3 9 } } + { 4 16 } ? I initially expected { { 1 1 } { 2 4 } { 3 9 } { 4 16 } } but got { { 1 1 } { 2 4 } { 3 9 } 4 16 } instead. I suppose an argument could be made either way...

Quote:I still think this was the worst decision when designing RPL.

I don't know whether I would call it the worst, but it's certainly near the top of my list.

Also note that the same commutativity violation occurs with STO+ when the variable holds a list or a string.

[Claudio L.]

(06-15-2014 07:29 PM)Thomas Klemm Wrote:  

(06-15-2014 06:48 PM)Claudio L. Wrote:  What would be a down side in your opinion?

I have a problem with overloading + for operations that violate basic rules of addition.
In the case of string concatenation it is the commutative property: "a" + "b" ≠ "b" + "a"
For this operation another symbol should be used: . or ~ or ++ or whatever.

It's the same with concatenating lists. But it gets worse with the "addition" of an element to a list.
Why is { 1 2 3 } + 4 = { 1 2 3 4 } but { 5 6 7 } - 4 = { 1 2 3 }?
But then 4 + { 1 2 3 } = { 5 6 7 }.
And if you really want to add a number to each element you have to use ADD: { 1 2 3 } ADD 4 = { 5 6 7 }
I still think this was the worst decision when designing RPL.

Cheers
Thomas

We are on the same page, here. But that's not a downside of overloading operators, it's just a bad choice! newRPL already has the '+' operator working on lists by adding element by element. The ADD command will concatenate lists.
And for what is worth, I don't have a problem with making '+' fail for strings and have ADD or CONCAT, etc. to concatenate strings.

That's actually the beauty of overloading operators, you can make them do whatever you want.

Actually, thanks to "proper" overloading of the '+' operators for lists, doing things like MAP, with nested lists is a breeze, just apply the same '+' operator recursively to all elements, whether they are lists or not. It's already done and working fine. The resulting code is surprisingly clean, so I was wondering what the downsides are (I'm still wondering).

Claudio

[Thomas Klemm]

(06-15-2014 09:55 PM)kakima Wrote:  

(06-15-2014 07:29 PM)Thomas Klemm Wrote:  But then 4 + { 1 2 3 } = { 5 6 7 }.

Actually it's { 4 1 2 3 }.

Thanks for the correction.

Quote:

Quote:I still think this was the worst decision when designing RPL.

I don't know whether I would call it the worst, but it's certainly near the top of my list.

Now I'm curious. Would you make that list public?

Cheers
Thomas

[DavidM]

The algorithm in DM1/TK3 doesn't handle 0 or negative values properly. So as I'm in the mood of late to force myself to use the list-processing commands more, I thought I'd fix that. In the process I ran into yet another DOLIST quirk.

What would you expect the result of DOLIST to be when presented with the following? These are the values in the lists at that step when 0 is the original input value to the DM1/TK3 apps:

Code:

{ "M" "CM" "D" "CD" "C" "XC" "L" "XL" "X" "IX" "V" "IV" "I" }
{  0   0    0   0    0   0    0   0    0   0    0   0    0  }
2 \<< NDUPN DROP \>> DOLIST

My expectation was { }, since NDUPN would delete all the strings and DROP would get rid of all the resulting Ns. The actual result: nothing. No list, no error message, nothing.

So accommodating that scenario requires an additional list-processing workaround. The one I chose wasn't too involved: I added yet another list at the top of that step that was filled with empty strings. This guaranteed that there was always some kind of result for the DOLIST step, and that output won't adversely affect the final string. It also ended up negating the need to work around the \GSLIST quirk as well. But as expected, it made the code bigger, a bit slower, and somewhat uglier all at the same time.

I really want to like the list processing commands. This application is clearly not a good one for them, though.

[Claudio L.]

(06-16-2014 03:40 AM)DavidM Wrote:  The algorithm in DM1/TK3 doesn't handle 0 or negative values properly. So as I'm in the mood of late to force myself to use the list-processing commands more, I thought I'd fix that. In the process I ran into yet another DOLIST quirk.

What would you expect the result of DOLIST to be when presented with the following? These are the values in the lists at that step when 0 is the original input value to the DM1/TK3 apps:

Code:

{ "M" "CM" "D" "CD" "C" "XC" "L" "XL" "X" "IX" "V" "IV" "I" }
{  0   0    0   0    0   0    0   0    0   0    0   0    0  }
2 \<< NDUPN DROP \>> DOLIST

My expectation was { }, since NDUPN would delete all the strings and DROP would get rid of all the resulting Ns. The actual result: nothing. No list, no error message, nothing.

So accommodating that scenario requires an additional list-processing workaround. The one I chose wasn't too involved: I added yet another list at the top of that step that was filled with empty strings. This guaranteed that there was always some kind of result for the DOLIST step, and that output won't adversely affect the final string. It also ended up negating the need to work around the \GSLIST quirk as well. But as expected, it made the code bigger, a bit slower, and somewhat uglier all at the same time.

I really want to like the list processing commands. This application is clearly not a good one for them, though.

Yes, we've also changed that already in newRPL. Makes no sense to get nothing! The empty list is the correct answer, no doubt.
As much as we wanted 100% compatibility, there's things we consider design problems and we are not willing to replicate that.
Want another one? The number of lists is an optional argument, and the system is supposed to correctly guess, under some obscure circumstances only, how many arguments it needs. The AUR gives an example of the command << DUP >>, which I tested and... didn't work (Bad Argument count). So it's optional in some cases but it's either not clear when, or it doesn't work as designed (or at least as explained in the AUR). So we opted to make the parameter not optional.

Hopefully our implementation of list processing commands will be more "likable" than the original.

Claudio

[kakima]

(06-15-2014 10:13 PM)Thomas Klemm Wrote:  Now I'm curious. Would you make that list public?

I didn't actually have a list, just a collection of little pet peeves, each of which has bitten me more than once. So, in no particular order:

IF THEN ELSE END, One of them is superfluous. Depending on some condition, you either do clause_A or maybe do clause_B. Only three words should be necessary as in FORTH. IF 'X' 3 > THEN A ELSE B END is the same as 'X' 3 IF > THEN A ELSE B END . It could just be 'X' 3 > IF A ELSE B END .

Similar with DO UNTIL END. UNTIL isn't necessary.

+ does the wrong thing with lists. It should do element-by-element addition, similar to -, *, and / . Some other operator (I favor &) should do concatenation for lists and possibly strings. Likewise with STO+ .

Lack of BREAK and CONTINUE. Discussed elsewhere.

Lack of ROT4 and UNROT4 to ease porting of RPN programs. Easy enough to simulate, but...

Lack of rotate/shift left/right by n bits, a la 16C. Also rotate through carry.

\GSLIST and \PILIST do not work for one-element lists. This appears to be more of an implementation issue than a language design issue.

The numerical integrator hasn't been updated since the 34C in 1979. Again perhaps an implementation issue.

Just my opinions. Your mileage may vary.

[Thomas Klemm]

(06-16-2014 03:40 AM)DavidM Wrote:  The algorithm in DM1/TK3 doesn't handle 0 or negative values properly.

This is the code I used for my HP-48 instead of \<< NDUPN DROP \>>:

Code:

\<<
  "" SWAP
  WHILE DUP 0 >
  REPEAT
    ROT ROT OVER +
    ROT 1 -
  END
  ROT DROP2
\>>

Wasn't particulary proud but handles both 0 and negative values correctly. Whatever that is.

Quote:I really want to like the list processing commands. This application is clearly not a good one for them, though.

Not sure about that. It has indeed to do with what we pass to DOLIST. But then just returning nothing instead of an empty list is a surprize to me as well.

[HP67]

(06-15-2014 06:48 PM)Claudio L. Wrote:  

(06-15-2014 12:02 PM)HP67 Wrote:  As much as command and operator overloading look nice on the surface, I think this is another example of where the downside is apparent and TIINSTAFL.

Now that Massimo helped me with the language (thanks!), I finally understood what you meant, but what's the downside that is so apparent? I fail to see it, the backend is been working solid for several months now with overloadable operators doing all the grunt work.
What would be a down side in your opinion?

Thomas covered my objections pretty well. This has nothing to do with NewRPL by the way.

Overloading is a problem when operators or commands work similarly in most cases but fall apart for edge cases and act inconsistently. We had a few examples already in this thread. Just because something is convenient or easy most of the time doesn't mean it's a good choice all the time.

[Claudio L.]

(06-16-2014 06:09 AM)HP67 Wrote:  Thomas covered my objections pretty well. This has nothing to do with NewRPL by the way.

Overloading is a problem when operators or commands work similarly in most cases but fall apart for edge cases and act inconsistently. We had a few examples already in this thread. Just because something is convenient or easy most of the time doesn't mean it's a good choice all the time.

OK, I thought you we talking in general about the concept of overloaded operators, not the particular way they are implemented in userRPL.
I agree with your view and Thomas (and everyone here seems to agree).

Claudio

[DavidM]

(06-16-2014 05:07 AM)Thomas Klemm Wrote:  Not sure about that. It has indeed to do with what we pass to DOLIST. But then just returning nothing instead of an empty list is a surprize to me as well.

I guess I'm just getting the sense that DOLIST is better suited for situations where there's more independence amongst the list members.

In this particular case, the relationships of the list members are highly dependent on each other. Processing doesn't really need to address each and every character position; once the final string is known, processing can (and should) stop. Order and inclusion have direct/major significance to the final outcome, so any aspect of the list processing that adds complexity to those areas decreases its usefulness.

Conversely, consider a situation where there's much greater independence: renaming all of the objects in a directory. A pseudo-code version might look like this:

Code:

Get List of Objects
IF list isn't empty, THEN
  Get/Make List of renaming data
  Provide renaming executable
  DOLIST

In that case, DOLIST would be very useful to simplify the code. That type of scenario seems much more applicable to me.

[Thomas Klemm]

Now you may call me a traitor of my own position, but I wondered whether it was useful to overload * to multiply a string by a number: like "M" * 3 = "MMM".
What if we use Forth's /MOD (n1 n2 - rem quot) instead of IDIV2 (n1 n2 - quot rem)?

Code:

\<<
  { 1000 900 500 400 100 90 50 40 10 9 5 4 1 }
  \<< /MOD \>>
  MAP
  { "M" "CM" "D" "CD" "C" "XC" "L" "XL" "X" "IX" "V" "IV" "I" }
  DOT
  NIP
\>>

But then I noticed: MAP can't access the stack below the list. Furthermore if more than one element is created they are enclosed within a list.

Example:
{ 1 2 3 }
\<< DUP \>>
MAP

returns:
{{ 1 1 } { 2 2 } { 3 3 }}

So that won't work. I'd prefer that MAP just pushes an element of the list on the stack, applies the program and then pops the top of the stack back to the list.
Thus the result would be:
1
2
3
{ 1 2 3 }
You can still create a list if you want to. But now it happens under the hood and you can't avoid it.

Cheers
Thomas