Programming puzzles: processing lists!

[John Keith]

(05-24-2017 03:29 PM)DavidM Wrote:  OK, now that I've given some thought to this, a potential issue has come to mind. 5 of the functions I created do inherent equality comparisons between elements of a list. In the case where the elements are numeric, there's a distinct difference between approximate and exact integers (eg. "1" vs. "1." [or "1," depending on your current fraction mark]). The way things are currently handled, "1" is considered to be different from "1.". So, for example, the LEQ command referenced above returns FALSE (0.) for the list { 1 1. }. It's not clear to me right now if this is actually a problem, or simply a non-intuitive feature.

Even some of the built-in functions handle this situation differently. For example:
{ 1 } { 1. } == returns 0., whereas 1 1. == returns 1 (note that you have to be in exact mode to begin with when typing this in manually).

I could change the commands to make them look for this situation and accommodate it, but it would degrade performance somewhat. Is it worth it?

I would leave them as they are. One can use I->R and R->I as necessary to convert. I believe it is better to have faster, simpler functions wherever possible.

OTOH, if you decide to post the code for your functions, you may want to post both versions and let subsequent users decide which version they want to use.

John