StrUtils.RomanToInt oddities

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

DaWorm

Just a guess here, but I would think there have now been more posts in this thread than the total number of programs to use this function.  Probably by a wide margin.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Reinier Olislagers
In reply to this post by Sven Barth-2
On 24/09/2013 13:13, Sven Barth wrote:

> Am 24.09.2013 11:27, schrieb Reinier Olislagers:
>> On 24/09/2013 11:11, Marco van de Voort wrote:
>>> In our previous episode, Reinier Olislagers said:
>>>>> Yes, but since the routine probably has low utilisation I choose for
>>>>> structuring all conversion routines all the same.
>>>> I would rather choose for maintaining backward compatiblity, the *de
>>>> facto behaviour* (return 0 on invalid values) as it is quite sensible
>>>> for this kind of numbers.
>>> It is non-orthogonal.
>> What is non-orthogonal? I'm indicating that I value backward
>> compatiblity higher than breaking compatibility to match existing
>> structures. I also indicate why this compatiblity is not such a bad
>> decision in the first place.
>> I have a bit of trouble understanding what you mean by "it's
>> non-orthogonal"
> Non-orthogonal means in this case that RomanToInt behaves different than
> e.g. StrToInt.

Sorry, but I'd rather hear that from Marco himself.
Your explanation doesn't make sense either; IMO it was sufficiently
clear in the discussion that we all agree that RomanToInt's behaviour is
different from many/all other conversion routines.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Sven Barth-2
Am 24.09.2013 13:47, schrieb Reinier Olislagers:

> On 24/09/2013 13:13, Sven Barth wrote:
>> Am 24.09.2013 11:27, schrieb Reinier Olislagers:
>>> On 24/09/2013 11:11, Marco van de Voort wrote:
>>>> In our previous episode, Reinier Olislagers said:
>>>>>> Yes, but since the routine probably has low utilisation I choose for
>>>>>> structuring all conversion routines all the same.
>>>>> I would rather choose for maintaining backward compatiblity, the *de
>>>>> facto behaviour* (return 0 on invalid values) as it is quite sensible
>>>>> for this kind of numbers.
>>>> It is non-orthogonal.
>>> What is non-orthogonal? I'm indicating that I value backward
>>> compatiblity higher than breaking compatibility to match existing
>>> structures. I also indicate why this compatiblity is not such a bad
>>> decision in the first place.
>>> I have a bit of trouble understanding what you mean by "it's
>>> non-orthogonal"
>> Non-orthogonal means in this case that RomanToInt behaves different than
>> e.g. StrToInt.
> Sorry, but I'd rather hear that from Marco himself.
> Your explanation doesn't make sense either; IMO it was sufficiently
> clear in the discussion that we all agree that RomanToInt's behaviour is
> different from many/all other conversion routines.
You want to hear it from Marco? Here:
> Yes, but since the routine probably has low utilisation I choose for
> structuring all conversion routines all the same.
Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Marco van de Voort
In reply to this post by Reinier Olislagers
In our previous episode, Reinier Olislagers said:
> >> facto behaviour* (return 0 on invalid values) as it is quite sensible
> >> for this kind of numbers.
> >
> > It is non-orthogonal.
> What is non-orthogonal?

RomanToInt uses 0 to signal error, other xxxtoint functions throw
exceptions.

> > Because that has an use. The internal FPC compatability, specially in
> > the more fringe areas like this, service no use than fattening maillist
> > archives IMHO.
>
> If you don't see a use for backward compatibility for existing code...

I see it only as an starting point, not as a rigid unbendable rule.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Reinier Olislagers
In reply to this post by Sven Barth-2
On 24/09/2013 14:11, Sven Barth wrote:

> Am 24.09.2013 13:47, schrieb Reinier Olislagers:
>> On 24/09/2013 13:13, Sven Barth wrote:
>>> Am 24.09.2013 11:27, schrieb Reinier Olislagers:
>>>> On 24/09/2013 11:11, Marco van de Voort wrote:
>>>>> In our previous episode, Reinier Olislagers said:
>>>>>>> Yes, but since the routine probably has low utilisation I choose for
>>>>>>> structuring all conversion routines all the same.
>>>>>> I would rather choose for maintaining backward compatiblity, the *de
>>>>>> facto behaviour* (return 0 on invalid values) as it is quite sensible
>>>>>> for this kind of numbers.
>>>>> It is non-orthogonal.
>>>> What is non-orthogonal? I'm indicating that I value backward
>>>> compatiblity higher than breaking compatibility to match existing
>>>> structures. I also indicate why this compatiblity is not such a bad
>>>> decision in the first place.
>>>> I have a bit of trouble understanding what you mean by "it's
>>>> non-orthogonal"
>>> Non-orthogonal means in this case that RomanToInt behaves different than
>>> e.g. StrToInt.
>> Sorry, but I'd rather hear that from Marco himself.
>> Your explanation doesn't make sense either; IMO it was sufficiently
>> clear in the discussion that we all agree that RomanToInt's behaviour is
>> different from many/all other conversion routines.
> You want to hear it from Marco? Here:
<snip earlier quote>

Depends on what he meant by "it" and "non-orthogonal", doesn't it?
I had trouble believing Marco thought just repeating his point about the
function not fitting in with the rest of the conversion functions would
be any use - especially because we both agreed about that point.

Now it seems Marco cannot appreciate that I was discussing weighing
various arguments pro and con changing the function, and was just
stating and maintaining a black and white position that looks extremely
odd to me ("backward compatibility is irrelevant").
That's why I asked him what he meant.

All in all, this *is* really getting useless. I'll leave this thread for
what it is. I think everything that could usefully have been said has
already been said.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Reinier Olislagers
In reply to this post by Marco van de Voort
On 24/09/2013 14:25, Marco van de Voort wrote:
> In our previous episode, Reinier Olislagers said:
<snip>
>>> Because that has an use. The internal FPC compatability, specially in
>>> the more fringe areas like this, service no use than fattening maillist
>>> archives IMHO.
>>
>> If you don't see a use for backward compatibility for existing code...
>
> I see it only as an starting point, not as a rigid unbendable rule.
> _

There is just *no* way the second and the first statements can possibly
match.
Furthermore you ignore any nuanced response I post and just repeat some
point you stated earlier.
Yes, I suppose it's an exchange of views but it is not useful at all.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Bart-48
My 2 cents on the "backwards compatibility" discussion.

First: backwards compatibility must be broken if the old
implementation is wrong. This seems obvious, but I have had
discussions about that in the past when I corrected another conversion
routine in fpc.
Wether or not the current implenetation is wrong, is open for discussion.

Breaking backwards compatibility for consistency with similar RTL
behaviour is IMO not a bad thing. We have done so in th epast for
Lazarus as well.
As said before: given the expected number of users of this function, I
weould consider doing it.
For consistency we should also have a TryRomanToInt(S: String; out
Value: Integer): Boolean; function.

As stated before: Delphi compatibility does not seem to be apply here.


My 2 cents on the "strictness" of the parsing.

Since there are various, more or less accepted, "rules", a
"strictness" parameter could be added as an optional parameter to the
function.
It does not break consistency with other conversion functions, since
they are hardly open for interpretation, and so they don't need such a
thing.

Strictness modes could be:
- Strict: most strict set of rules (it does not accept numbers > 3999,
nor more than 3 repeats of the same numeral)
- Relaxed: allows unlimited number of starting "M", and allows up to 4
repeats of C, X and I.
- DontCare: like current behaviour.

Bart
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: StrUtils.RomanToInt oddities

Alberto Narduzzi
> My 2 cents on the "strictness" of the parsing.
>
> Since there are various, more or less accepted, "rules", a
> "strictness" parameter could be added as an optional parameter to the
> function.
> It does not break consistency with other conversion functions, since
> they are hardly open for interpretation, and so they don't need such a
> thing.
>
> Strictness modes could be:
> - Strict: most strict set of rules (it does not accept numbers>  3999,
> nor more than 3 repeats of the same numeral)
> - Relaxed: allows unlimited number of starting "M", and allows up to 4
> repeats of C, X and I.
> - DontCare: like current behaviour.

Now, this is a very nice and clean approach to the problem, together
with an equally nice and clean solution.

Cheers, A.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123