[fpc-pascal] Re: StrUtils.RomanToInt oddities

[Reinier Olislagers]

On 20/09/2013 18:33, Bart wrote:
> On 9/20/13, Reinier Olislagers <reinierolislagers at gmail.com> wrote:
>> 2. I wouldn't be bothered by negative numbers... even the Romans used to
>> have negative posessions (= debts) and they didn't have double entry
>> bookkeeping yet ;) Also, the documentation [1] mentions it as a feature.
> 
> If I mention in documentationn that result is unpredicted for any
> input [snip irrelevant part] then this would
> also not considered to be a bug, just it because does what the docs
> say?

Well, if you want a black and white answer: yes, because the
implementation follows the documentation/specifcations.

However, as I indicated in the rest of my post, I do think the
implementation(+documentation) needs to be changed for other cases. I
just don't see that many problems by allowing negative numbers.

>> 3. The rest... well, depending on 1. I'd agree it's a bug.
>> [1] mentions "Invalid characters are dropped from S"... which I think is
>> a bit strange (S is a const) but assuming it means "Invalid characters
>> in S are ignored" it means somebody thought checking the input for valid
>> Roman numbers was a good idea. The question however becomes "what is the
>> algorithm for deciding invalid characters" which IMO will become a mess
>> very quickly. Much better to just consider the entire input as invalid.
> 
> Any invalid char in S will result in Result being 0;
> So doc is wrong about that.

Seems we agree here:
1. Changing docs to mention any invalid character will lead to result
being 0. No idea what the policy is about needing to raise exceptions in
case of errors - in this particular case, returning 0 should actually be
enough by itself as there is no Roman numeral that stands for the value 0...
2. The other cases you mentioned in your OP are bugs, not features.