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

Martin Frb
On 23/09/2013 22:30, Alberto Narduzzi wrote:
>> What about making an option of it?
>>
>> Anyhow, if the function accepts invalid combinations, what should it
>> return? For some, the answer would be obvious (IIII), but some
>> combinations are indeed ambiguous (IIIIM) So that we maybe could accept
>> unambiguous invalid combinations, but I don't see how to accept
>> ambiguous ones.
>
> they are not ambiguous, they are simply INVALID.

So the question is, what does or should do RomanToInt for invalid input?

It is NOT called "CheckValidRoman", so it could be that the result for
invalid input is simply undefined. If it is, then all is ok.
_______________________________________________
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
> So the question is, what does or should do RomanToInt for invalid input?
>
> It is NOT called "CheckValidRoman", so it could be that the result for
> invalid input is simply undefined. If it is, then all is ok.

so, what does "10AT" (or "$10AT" for tht matter) return for HexToDec???
maybe NaN, if there is such a definition in Pascal??? Looks acceptable
to me.

But IsValidRoman is as good as a solution too, indeed...
_______________________________________________
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
In reply to this post by Martin Frb
On 9/23/13, Martin <[hidden email]> wrote:

> So the question is, what does or should do RomanToInt for invalid input?

Probably return 0.
Romans seemed to have no zero at all.
It also will not break backwards compatibility, current
implementatiosn returns zero if an invalid character is found (docs
say otherwise though).

We could also leave things as they are and have a new
TryRomanToIntStrict() function added to StrUtils.

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

Bart-48
In reply to this post by Alberto Narduzzi
On 9/23/13, Alberto Narduzzi <[hidden email]> wrote:

>>> Are you sure regarding M considering there is no symbol for 5000? Or
>>> didn't Romans count to more than 5000 - 1?
>
> yes I am. as 5000 - 1 would need to be written MMMMCMXCIX, which has the
> 4-M-in-a-row, that is invalid, as a maximum of three is allowed.
>

It's more or less common practice to allow > 3 M's if you need values > 3999.

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

Marco van de Voort
In reply to this post by Martin Frb
In our previous episode, Martin said:
> > they are not ambiguous, they are simply INVALID.
>
> So the question is, what does or should do RomanToInt for invalid input?

Raise an exception and have a try* version to avoid the exception, just like
all other str*to<numeric> functions.
_______________________________________________
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
In reply to this post by Alberto Narduzzi
On 9/23/13, Alberto Narduzzi <[hidden email]> wrote:

> But IsValidRoman is as good as a solution too, indeed...

Trying to determine if it is valid is 90% of calculating the output.
Hence my previous approach of TryRomanToInt.
It returns FALSE if the string isn't a legal Roman numeral.
And it is compliant with our other conversion routines like TryStrToInt etc.

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

Bart-48
In reply to this post by Marco van de Voort
On 9/24/13, Marco van de Voort <[hidden email]> wrote:

> Raise an exception

This will break existing implementations that either expect IM to be
999, or ABC to be 0 (indicating failure), and that certainly do not
expect that this function throws an exception at them.

> and have a try* version to avoid the exception, just
> like
> all other str*to<numeric> functions.

You beat me by a few minutes ....

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

Marco van de Voort
In our previous episode, Bart said:
> > Raise an exception
>
> This will break existing implementations that either expect IM to be
> 999, or ABC to be 0 (indicating failure), and that certainly do not
> expect that this function throws an exception at them.

Yes, but since the routine probably has low utilisation I choose for
structuring all conversion routines all the same.

Moreover I don't think that first attempts should fixate interfaces
and behaviour forever.
 
And let's not beat about the bush: the main reason for the routine is to
show beginning programmers that their homework can be done using a fixed
function :-)
_______________________________________________
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 Bart-48
On 24/09/2013 08:57, Bart wrote:
> On 9/23/13, Martin <[hidden email]> wrote:
>
>> So the question is, what does or should do RomanToInt for invalid input?
>
> Probably return 0.
> Romans seemed to have no zero at all.
> It also will not break backwards compatibility, current
> implementatiosn returns zero if an invalid character is found (docs
> say otherwise though).

Yes, I agree that returning 0 is a good solution. The docs can be changed.

> We could also leave things as they are and have a new
> TryRomanToIntStrict() function added to StrUtils.
As there are no issues with compatibility that would IMO only make the
solution needlessly more complex.
_______________________________________________
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
In reply to this post by Marco van de Voort
On 9/24/13, Marco van de Voort <[hidden email]> wrote:

> And let's not beat about the bush: the main reason for the routine is to
> show beginning programmers that their homework can be done using a fixed
> function :-)

LOL

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

Reinier Olislagers
In reply to this post by Marco van de Voort
On 24/09/2013 09:09, Marco van de Voort wrote:
> In our previous episode, Bart said:
>>> Raise an exception
>>
>> This will break existing implementations that either expect IM to be
>> 999, or ABC to be 0 (indicating failure), and that certainly do not
>> expect that this function throws an exception at them.
>
> 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.

> Moreover I don't think that first attempts should fixate interfaces
> and behaviour forever.
It's quite strange though that Delphi compatibility is quite insistently
adhered to (BTW a good decision IMO).
The function has been in FPC stable (for presumably a while?) so I would
really think hard before changing it.

> And let's not beat about the bush: the main reason for the routine is to
> show beginning programmers that their homework can be done using a fixed
> function :-)
Nice going to show beginning programmers how to break backward
compatibility then ;)

However, this is all just me 2c so it's up to the FPC devs to decide....

Regards,
Reinier
_______________________________________________
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 Alberto Narduzzi
On 23/09/2013 23:34, Alberto Narduzzi wrote:
>> I don't believe though Romans knew negative numbers.
Well, they could subtract, couldn't they :)

>> But I'm certainly not an expert on the matter.
>
> never though about, but if the only matter is DEBT, then just write
> positive numbers under the DEBT column, and everybody shall be happy
> too, provided they know the meaning of such a column ;-)
You just described an alternative indication of a negative number...
only instead of a minus sign, you use column position as an indicator ;)
To calculate net equity, you'd still have to subtract the debts from the
possessions, i.e. deal with the debt as negative numbers.

> P.S. Have no clue of roman arithmetics, thou', which looks a little
> more weird to implement, or just to think about :-O

I would be very careful in definining too many restrictions on what you
accept as Roman numerals as the number of fixed rules is rather small
and there are a lot of exceptions, especially in later years (i.e.
Bart's example of bigger numbers).
In other words, the system of Roman numerals was not fixed; it changed
over time, it was mostly based on conventions that fell short of actual
rules.
_______________________________________________
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

Frederic Da Vitoria
In reply to this post by Reinier Olislagers
2013/9/24 Reinier Olislagers <[hidden email]>
On 24/09/2013 09:09, Marco van de Voort wrote:
> In our previous episode, Bart said:
>>> Raise an exception
>>
>> This will break existing implementations that either expect IM to be
>> 999, or ABC to be 0 (indicating failure), and that certainly do not
>> expect that this function throws an exception at them.
>
> 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.

> Moreover I don't think that first attempts should fixate interfaces
> and behaviour forever.
It's quite strange though that Delphi compatibility is quite insistently
adhered to (BTW a good decision IMO).
The function has been in FPC stable (for presumably a while?) so I would
really think hard before changing it.

I could not find any trace of it on the embarcadero web site. Wouldn't we be taking into account a compatibility with something which does not exist, by any chance?


> And let's not beat about the bush: the main reason for the routine is to
> show beginning programmers that their homework can be done using a fixed
> function :-)
Nice going to show beginning programmers how to break backward
compatibility then ;)

Well, the alternative would be showing how to maintain buggy implementations because you don't want to break backward compatibility :-) Or it could show that sometimes rules have to be infringed. Or it could show the merits of exploring thoroughly the limits of a problem before committing code which could later place you in such a conflicting situation (I am not throwing stones to the developer who committed this function first, I have too often done the same mistake myself)

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
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

Frederic Da Vitoria
In reply to this post by Reinier Olislagers
2013/9/24 Reinier Olislagers <[hidden email]>
On 23/09/2013 23:34, Alberto Narduzzi wrote:
>> I don't believe though Romans knew negative numbers.
Well, they could subtract, couldn't they :)

>> But I'm certainly not an expert on the matter.
>
> never though about, but if the only matter is DEBT, then just write
> positive numbers under the DEBT column, and everybody shall be happy
> too, provided they know the meaning of such a column ;-)
You just described an alternative indication of a negative number...
only instead of a minus sign, you use column position as an indicator ;)
To calculate net equity, you'd still have to subtract the debts from the
possessions, i.e. deal with the debt as negative numbers.

Not quite. The mathematical result would be the same, but try explaining what a negative number is to a kid :-) You may have forgotten it, but there was a time when you had to be explained that a - b = a + (-b) (which is not exactly using a negative number but closely related to it). In the above example, the debt is to be subtracted, this does not automatically trigger the abstract concept of negative number in the user's mind. I even think that if the romans really had the concept of negative numbers, they would have devised a notation for it allowing them to include them in texts. Does such a notation exist?


> P.S. Have no clue of roman arithmetics, thou', which looks a little
> more weird to implement, or just to think about :-O

I would be very careful in definining too many restrictions on what you
accept as Roman numerals as the number of fixed rules is rather small
and there are a lot of exceptions, especially in later years (i.e.
Bart's example of bigger numbers).
In other words, the system of Roman numerals was not fixed; it changed
over time, it was mostly based on conventions that fell short of actual
rules.


--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
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:
> >
> > 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.

>
> > Moreover I don't think that first attempts should fixate interfaces
> > and behaviour forever.
> It's quite strange though that Delphi compatibility is quite insistently
> adhered to (BTW a good decision IMO).

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.

_______________________________________________
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
In reply to this post by Frederic Da Vitoria
Am 24.09.2013 11:07, schrieb Frederic Da Vitoria:
2013/9/24 Reinier Olislagers <[hidden email]>
On 24/09/2013 09:09, Marco van de Voort wrote:
> In our previous episode, Bart said:
>>> Raise an exception
>>
>> This will break existing implementations that either expect IM to be
>> 999, or ABC to be 0 (indicating failure), and that certainly do not
>> expect that this function throws an exception at them.
>
> 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.

> Moreover I don't think that first attempts should fixate interfaces
> and behaviour forever.
It's quite strange though that Delphi compatibility is quite insistently
adhered to (BTW a good decision IMO).
The function has been in FPC stable (for presumably a while?) so I would
really think hard before changing it.

I could not find any trace of it on the embarcadero web site. Wouldn't we be taking into account a compatibility with something which does not exist, by any chance?
When there is no Delphi-compatibility needed there is still backwards compatibility to code developed in FPC.

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

Reinier Olislagers
In reply to this post by Frederic Da Vitoria
On 24/09/2013 11:07, Frederic Da Vitoria wrote:

> 2013/9/24 Reinier Olislagers <[hidden email]
> <mailto:[hidden email]>>
>
>     On 24/09/2013 09:09, Marco van de Voort wrote:
>     > In our previous episode, Bart said:
>     > Moreover I don't think that first attempts should fixate interfaces
>     > and behaviour forever.
>     It's quite strange though that Delphi compatibility is quite insistently
>     adhered to (BTW a good decision IMO).
>     The function has been in FPC stable (for presumably a while?) so I would
>     really think hard before changing it.
>
>
> I could not find any trace of it on the embarcadero web site. Wouldn't
> we be taking into account a compatibility with something which does not
> exist, by any chance?

Ave Frederice ;)

Just to be clear: I'm talking about backward compatibility with FPC
code. I think Bart is, too.
I haven't seen found any Delphi equivalent for the function either.

>     Nice going to show beginning programmers how to break backward
>     compatibility then ;)
>
>
> Well, the alternative would be showing how to maintain buggy
> implementations because you don't want to break backward compatibility
> :-)
Nice one ;)
.. and TBH, breaking implementations is sometimes necesary.
However, see below for why I don't think the returning 0 part is buggy.

> Or it could show that sometimes rules have to be infringed. Or it
> could show the merits of exploring thoroughly the limits of a problem
> before committing code which could later place you in such a conflicting
> situation (I am not throwing stones to the developer who committed this
> function first, I have too often done the same mistake myself)

Remember though that we're talking about choosing between:
If invalid [2] input is found:
1. returning 0 - as the function already does, it's just not documented
as such.
2. raising an exception like a lot of other conversion functions

Keeping in mind that there is no Roman number symbol for zero [1],
option 1 seems quite valid and obvious.

I don't deeply care which choice is made. It's just that I don't think
the additional work and possible impact on changing code outweigh the
benefits. Others obviously disagree, fine ;)

[1] Unless, yes, another exception, you think of Bede's use of N...
[2] Ignoring the discussion about what's invalid as that has little to
doe with the choice mentioned here.
_______________________________________________
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 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"

>>> Moreover I don't think that first attempts should fixate interfaces
>>> and behaviour forever.
>> It's quite strange though that Delphi compatibility is quite insistently
>> adhered to (BTW a good decision IMO).
>
> 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...
let's just say I'll stop fattening maillist archives right now.
_______________________________________________
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

el_es
In reply to this post by Bart-48
On 23/09/13 17:18, Bart wrote:

> On 9/23/13, Lukasz Sokol <[hidden email]> wrote:
>
>> function TryRomanToInt(AInput:String; out AResult: integer):boolean;
>> var i, Len, N, Np1 : integer;
> [snip]
>>
>>
>>         if N >= Np1 then AResult := AResult + N
>>         else AResult := AResult - N;
>>
>>       end;
>>     else // i = Len-1 = last char we just add (consider : MCM : add 1000,
>
> Compiler doesn't like the else here. I removed the ; after the end 1 line above.
I said below it's only mind-compiled ;)

>
>> sub 100, add 1000 = 1900)
>>      begin
>>        AResult := AResult + N;
>>      end;
>>   end; // for
>>   // if the above, after all characters are through, has resulted in 0 or
>> less,
>>   // we invalidate everything at the end (consider : CMLM, IIIM )
>>
>>   Result := AResult > 0;
>>   if not Result then AResult := 0;
>> end;
>>
>> (only mind-compiled ;) tests welcome ;) )
>>
>
> It produces "odd" output though:
>
> C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
> Enter Roman numeral: LL  //should be illegal
> TryRomanToInt('LL') -> 50
> StrUtils.RomanToInt('LL') = 100
Oh I see the loop needs to run from 0 to Len-1 ?.... it missed the last (or first) char

>
> Enter Roman numeral: MM
> TryRomanToInt('MM') -> 1050  //obviously should be 2000
But this looks like you're adding the results? Or are you reusing the
same variable ? In that case stick AResult := 0 at the top of the function please

> StrUtils.RomanToInt('MM') = 2000
>
> Enter Roman numeral: II
> TryRomanToInt('II') -> 1051  // nice one!  
Yeah totally added to former Aresult, and missed last char ...

> StrUtils.RomanToInt('II') = 2
>
> So, it's a little bit flawed.

:)

function TryRomanToInt(AInput:String; out AResult: integer):boolean;
var i, Len, N, Np1 : integer;

  function TryRomanCharToInt(AIn: Char; out AOut: integer): boolean;
  begin
    case AIn of
      'M' : AOut := 1000;
      'D' : AOut := 500;
      'C' : AOut := 100;
      'L' : AOut := 50;
      'X' : AOut := 10;
      'V' : AOut := 5;
      'I' : AOut := 1;
    else
      AOut := 0;
    end;
    Result := (AOut > 0);
  end;

begin
  // if it looks like shameless c&p, it's because it is ;)
  Result := False;
  AResult := 0; // << here you've reused the variable passed to AResult somewhere
  AInput := UpperCase(AInput);  //don't use AnsiUpperCase please
  Len := Length(AInput);
  if (Len = 0) then Exit;
  //
  i := 1;
  for i := 0 to Len-1 do // which char am I actually missing here???
  begin
    if not TryRomanCharToInt(AInput[i], N) then
    begin
      AResult := -1; // invalidate everything
      exit;
    // writeln('Not a valid roman numeral at position ',i);
    end;

    if (i > Len-1) then
      begin
        if not TryRomanCharToInt(AInput[i+1], Np1) then
        begin
          AResult := -1; // invalidate everithing
          exit;
        // writeln('Not a valid roman numeral at position ',i+1);
        end;
         
        // according to wikipedia, .
        if not (((N = 100) and (Np1 > 100)) or  // C can be placed before L or M
                ((N = 10) and (Np1 > 10) and (Np1 <= 100)) or // X can be placed before L or C
                ((N = 1) and (Np1 > 1) and (Np1 <= 50)))  // I can be placed before V and X << here too
        then
          begin
            AResult := -1; // invalidate everithing: catches MDCLXVIVXLDM
            exit;
            // writeln('Not a valid roman numeral combination at position ',i, ' and ',i+1);
          end;
 

        if N >= Np1 then AResult := AResult + N
        else AResult := AResult - N;
       
      end // i > Len-1, you're right about the ;
    else // i = Len-1 = last char we just add (consider : MCM : add 1000, sub 100, add 1000 = 1900)
     begin // alternatively this should exit the loop maybe on the N-1th character
       AResult := AResult + N;
     end;
  end; // for
  // if the above, after all characters are through, has resulted in 0 or less,
  // we invalidate everything at the end (consider : CMLM, IIIM )
 
  Result := AResult > 0;
  if not Result then AResult := 0;
end;


>
> Anyhow, let's not focus upon what the new code should be.
> The question was: is current behaviour (accepting IIMIIC etc.) a bug or not.
>
> Bart
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>


_______________________________________________
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
In reply to this post by Reinier Olislagers
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.

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