Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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, a

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 implenetatio

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 24/09/2013 14:25, Marco van de Voort wrote: > In our previous episode, Reinier Olislagers said: >>> 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 f

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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. > > B

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 c

[fpc-pascal] Re: StrUtils.RomanToInt oddities

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 conversi

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 mai

[fpc-pascal] Re: StrUtils.RomanToInt oddities

On 23/09/13 17:18, Bart wrote: > On 9/23/13, Lukasz Sokol 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; >>

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 *

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 24/09/2013 11:07, Frederic Da Vitoria wrote: > 2013/9/24 Reinier Olislagers > > > 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 >

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

Am 24.09.2013 11:07, schrieb Frederic Da Vitoria: 2013/9/24 Reinier Olislagers > 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

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

2013/9/24 Reinier Olislagers > 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 >

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

2013/9/24 Reinier Olislagers > 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, the

[fpc-pascal] Re: StrUtils.RomanToInt oddities

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

[fpc-pascal] Re: StrUtils.RomanToInt oddities

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 except

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/24/13, Marco van de Voort 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 - fpc-pascal@

[fpc-pascal] Re: StrUtils.RomanToInt oddities

On 24/09/2013 08:57, Bart wrote: > On 9/23/13, Martin 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

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 ha

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/24/13, Marco van de Voort 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 excep

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Alberto Narduzzi 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 ou

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 functions.

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Alberto Narduzzi 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 CMXCIX, which has the > 4-M-in-a-row, that is invalid, as a maximum of three is allowe

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Martin 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

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 the

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 (), but some combinations are indeed ambiguous (M) So that we maybe could accept unambiguous

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 CMXCIX, which has the 4-M-in-a-row, that is invalid, as a maximum of three is allowed. Yes, probably ancient Romans had no need to

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

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 (), but some combinations are indeed ambiguous (M) So that we maybe could accept unambiguous invalid combinations, but I don't see how to a

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

What about making an option of it? If it accepts, then it should apply the subtraction rule: only the (one) numeral left to the other (bigger one) can be subtracted. So IIIM would be III + IM = 3 + 1000-1 = 1002 (and not 1000-3 = 997) There should be no ambiguity there, it's only a pain to watc

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Frederic Da Vitoria wrote: > What about making an option of it? It's up to the fpc devels. > Anyhow, if the function accepts invalid combinations, what should it > return? For some, the answer would be obvious (), but some combinations > are indeed ambiguous (M) So that we m

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

2013/9/23 Bart > The question was: is current behaviour (accepting IIMIIC etc.) a bug or > not. > 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 (), but some combinations are indeed ambigu

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Sven Barth wrote: > Are you sure regarding M considering there is no symbol for 5000? Or > didn't Romans count to more than 5000 - 1? > There are numerous extensions upon the scheme. In later times adding horizontal lines above or under a Roman numeral meant multiply by 1000. I don'

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Alberto Narduzzi wrote: > Thing is: > > 1. in the roman numerals, not all the digits can be subtracted from the > others > 2. no more than three same roman numerals can appear in a row. My implementation is a little more relaxed as to rule 2. It is more often "violated" than rule 1.

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 23.09.2013 21:17, Alberto Narduzzi wrote: Ooops, I also forgot to mention that only I, X, C and M can appear up to three times in a row. V, L and D does not; they can only once. Are you sure regarding M considering there is no symbol for 5000? Or didn't Romans count to more than 5000 - 1?

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

Ooops, I also forgot to mention that only I, X, C and M can appear up to three times in a row. V, L and D does not; they can only once. Cheers again, A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

Premise: I didn't go through your entire implementation, thou' at first sight looks much better than the current one. I know roman numerals since I was 8 or 9 yo, that makes a quick and dirt result of about 35 years. Thing is: 1. in the roman numerals, not all the digits can be subtracted fr

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/23/13, Lukasz Sokol 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

[fpc-pascal] Re: StrUtils.RomanToInt oddities

On 20/09/13 19:49, Bart wrote: > On 9/20/13, Reinier Olislagers wrote: > >> 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. >> > > Here's my implementat

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/20/13, Reinier Olislagers wrote: > 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. > Here's my implementation: program test; {$mode objfpc} {$H+}

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/20/13, Reinier Olislagers wrote: > 2. The other cases you mentioned in your OP are bugs, not features. Unless the Greek do the same, someone with recent Delphi should test. If that's the case we're doomed to follw that. Bart ___ fpc-pascal mailli

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

And please, before anyone gets offended by my postings in this thread: - I just stubled on this whils doing a kind WTF implementation of something like this (and at that time I didn't even knew we had StrUtils.RomanToInt). - I don't think it is the end of the world just because the StrUtils versio

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/20/13, Reinier Olislagers wrote: > 1. I'll respond with the expected answer: "What does Delphi do" (if it > has this function? D7 PE does not have it. > 2. I wouldn't be bothered by negative numbers... even the Romans used to > have negative posessions (= debts) and they didn't have double

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 20/09/2013 18:33, Bart wrote: > On 9/20/13, Reinier Olislagers 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. >

Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities

On 9/20/13, Bart wrote: > Any invalid char in S will result in Result being 0; > So doc is wrong about that. Reported that in bugtracker: http://bugs.freepascal.org/view.php?id=25061 Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org htt

[fpc-pascal] Re: StrUtils.RomanToInt oddities

On 18/09/2013 16:19, Bart wrote: > RomanToInt acceps rather ludicrous values: > > RomanToInt('MDCLXVIVXLDM') = 2209 > RomanToInt('M') = 1002 //calculated as 3 + (1000-1) > > Both examples represent invalid roman numbers by any standard. > Also I do not think Roman numerals can be negative...