What world have I been in - castling notation?

[Marek Soszynski]

Here's an old problem (since fixed) that Aquarium had with castling hyphens:

http://rybkaforum.net/cgi-bin/rybkaforu ... ?tid=19927

[bob]

There is two parts to this issue. The standard should be specific and precise. That's true for any specification as is taught in any software engineering course.

The standard could precisely specify that a parser shall be able to deal with 0-0, o-o and O-O...

Why would you do that? That is the kind of nonsense the C standards committee likes to do. Spell it out precisely, unambiguously, and then if some want to accept other crap, that's fine. Putting that in the standard says "any of these should be OK" which ought to be avoided.

That's actually the purpose of a GOOD standard, i.e. specifications.

[syzygy]

There is two parts to this issue. The standard should be specific and precise. That's true for any specification as is taught in any software engineering course.

The standard could precisely specify that a parser shall be able to deal with 0-0, o-o and O-O...

Why would you do that? That is the kind of nonsense the C standards committee likes to do. Spell it out precisely, unambiguously, and then if some want to accept other crap, that's fine. Putting that in the standard says "any of these should be OK" which ought to be avoided.

OK, you're just looking for another senseless discussion.

I guess the C standard should have specified that there shall be precisely one space around operators! Never mind real world programmers that have various habits and preferences!! Who cares about relevance!!

[bob]

There is two parts to this issue. The standard should be specific and precise. That's true for any specification as is taught in any software engineering course.

The standard could precisely specify that a parser shall be able to deal with 0-0, o-o and O-O...

Why would you do that? That is the kind of nonsense the C standards committee likes to do. Spell it out precisely, unambiguously, and then if some want to accept other crap, that's fine. Putting that in the standard says "any of these should be OK" which ought to be avoided.

OK, you're just looking for another senseless discussion.

I guess the C standard should have specified that there shall be precisely one space around operators! Never mind real world programmers that have various habits and preferences!! Who cares about relevance!!

I asked a simple question: Why would one write a standard, and in the standard say it is required that your program NOT follow this standard and accept input outside the specification?

And you want to say "OK, you are just looking for another senseless discussion?"

It is senseless, I agree. _I_ didn't introduce the senselessness, however.

[sje]

A True Story

Long ago in the Old Days of computing with punchcards and plugboards, there was an awful programming language called "Fortran". The language was named after its main propose: FORmula TRANslation. And while Fortran was good with representing engineering mathematical formulas, it was poor at doing everything else.

Every Fortran statement which wasn't a formula had its statement kind identified by a keyword. Some of these were easy to spell; some weren't. Two of longer keywords were DIMENSION and EQUIVALENCE. One day way back then at a university computing center, a certain Fortran coder had grown tired with having his programs rejected by the Fortran compiler because he had a difficult time remembering how to spell some of the longer keywords. In a flash of something other than brilliance, the coder got access to the school's Fortran compiler and modified the keyword table to accept all kinds of alternative spellings for the more troublesome keywords.

And with that stroke of something other than genius, not only could that coder continue to be lazy and to write sloppy unportable code, but he also enabled everyone else using the school's mainframe to be equally lazy and sloppy.

[syzygy]

There is two parts to this issue. The standard should be specific and precise. That's true for any specification as is taught in any software engineering course.

The standard could precisely specify that a parser shall be able to deal with 0-0, o-o and O-O...

Why would you do that? That is the kind of nonsense the C standards committee likes to do. Spell it out precisely, unambiguously, and then if some want to accept other crap, that's fine. Putting that in the standard says "any of these should be OK" which ought to be avoided.

OK, you're just looking for another senseless discussion.

I guess the C standard should have specified that there shall be precisely one space around operators! Never mind real world programmers that have various habits and preferences!! Who cares about relevance!!

I asked a simple question: Why would one write a standard, and in the standard say it is required that your program NOT follow this standard and accept input outside the specification?

Oh wow... what a special world you live in.

[syzygy]

In a flash of something other than brilliance, the coder got access to the school's Fortran compiler and modified the keyword table to accept all kinds of alternative spellings for the more troublesome keywords.

And this is what the PGN specification explicitly suggests to do. It is also what Bob has done in Crafty, as Crafty undoubtedly accepts "o-o" and "0-0".

The specification does that for good reasons, but it would be far better if it at least specified some minimum requirements such as "accept at least 0-0 and o-o in addition to O-O".

Import format is somewhat more relaxed and it makes allowances for moves that do not conform exactly to the canonical format. However, these allowances may differ among different PGN reader programs.

As far as I can tell those "allowances" are as vague as can be:

There are a number of suggested guidelines for use with implementing PGN reader software for permitting non-canonical SAN move representation. The idea is to have a PGN reader apply various transformations to attempt to discover the move that is represented by non-canonical input. Some suggested transformations include: letter case remapping, capture indicator insertion, check indicator insertion, and checkmate indicator insertion.

[sje]

In a flash of something other than brilliance, the coder got access to the school's Fortran compiler and modified the keyword table to accept all kinds of alternative spellings for the more troublesome keywords.

And this is what the PGN specification explicitly suggests to do.

The context was that of at that time, there was a need to convert much old data. Allow variant input was never intended for the acceptance of newly generated data. Suggesting, but never requiring, variant input was for the purpose of getting over a one time hump -- and that one time passed long ago.

For the record, none of the chess software I've written since some years before PGN has allowed any SAN variance.

Now if YOU want to write a program which accepts sloppy data, well, I don't really care. Go ahead. Have fun.

But if you think everyone who writes chess software MUST accept sloppy data, then there is a serious problem.

What is just enough slop for one person may not enough for a second person or may be too much for a third person. And some slop might be totally incompatible with other slop. Who gets to say which slop and how much of it is permitted or required?

The only consistent answer is: to have no slop at all.

And that is my last post in this thread.

[syzygy]

Suggesting, but never requiring, variant input was for the purpose of getting over a one time hump -- and that one time passed long ago.

Then I'm afraid you're not being very realistic.

In reality chess software accepts 0-0 and o-o, so there is no problem, but this is due to common sense of the programmers.

But if you think everyone who writes chess software MUST accept sloppy data, then there is a serious problem.

If the "standard" specifies what should be accepted, it is not sloppy. How difficult is that to understand. I can give you the ASCII codes for 0 and o, if you want.

[bob]

There is two parts to this issue. The standard should be specific and precise. That's true for any specification as is taught in any software engineering course.

The standard could precisely specify that a parser shall be able to deal with 0-0, o-o and O-O...

Why would you do that? That is the kind of nonsense the C standards committee likes to do. Spell it out precisely, unambiguously, and then if some want to accept other crap, that's fine. Putting that in the standard says "any of these should be OK" which ought to be avoided.

OK, you're just looking for another senseless discussion.

I guess the C standard should have specified that there shall be precisely one space around operators! Never mind real world programmers that have various habits and preferences!! Who cares about relevance!!

I asked a simple question: Why would one write a standard, and in the standard say it is required that your program NOT follow this standard and accept input outside the specification?

Oh wow... what a special world you live in.

No, more like "what a weird world you seem to live in."