Talk:Farey sequence

REXX program encoding

What language encoding should the file be saved in, and what should the LC_* env vars be before invoking Regina on a Unixy OS? Currently under UTF-8 everything, Regina (-v: REXX-Regina_3.6(MT) 5.00 31 Dec 2011) complains:

    10 +++    say center('Farey sequence for order '   n   " has"   #   'fractions.', 150, '═')
Error 40 running "/tmp/test.rex", line 10: Incorrect call to routine
Error 40.23: CENTER argument 3 must be a single character; found "═"

It goes away after changing that "═" to any ASCII char. The same problem is present in many Rexx examples on this site. --Ledrug (talk) 21:30, 1 April 2014 (UTC)

I suspect the mechanism that is being used in saving (or downloading) the REXX program (file) from Rosetta Code is storing the character(s) of the extended ASCII (ASCII-8) as some flavor of Unicode, which Regina REXX is seeing as a two- or three-byte character. The extended-ASCII character that was being used is the 'cd'x (═) character (the horizontal double-line boxing character) from the Microsoft (DOS) code page 437 (which, I think, is probably the default code page in the USA). What you are showing (in the line with 10 +++ message) looks like a one-character (the 3^rd argument for the center ~~BUF~~ BIF), but the REXX program source file probably has a two-character field stored there, thereby incurring Regina REXX's wrath (as witnessed by it issuing the error message(s). -- Gerard Schildberger (talk) 23:44, 1 April 2014 (UTC)

To address the 1^st question: all Classic REXXes that I know of only support bytes, not Unicode characters. I'm not very familiar with Unixy thingys, so I don't know what can be specified (if anything) for Regina REXX regarding this issue. As far as I know, there isn't anything as far as REXX switches or environmental variables that will "fix" the above-mentioned problem; the only fix is to put in a single-byte character (which that 3^rd argument is just essentially used for fodder for a line separator, a dash would work as well, ··· or a minus sign will do in a pinch --- but then it looks chintzy, and we can't have that.) -- Gerard Schildberger (talk) 23:44, 1 April 2014 (UTC)

Grumble about "marked as incorrect"

I got a "marked as incorrect" flag:

This example is incorrect. Please fix the code and remove this message.

Details:
First and last Farey terms aren't expressed as fractions as per the definition,
no terms shown are expressed as fractions,
(see the C programming example's output as an example).

Here's an example:

<lang J> Farey 1 0 1

  Farey 2

0 1r2 1

  Farey 3

0 1r3 1r2 2r3 1</lang>

And yet,

(a) the definition currently places no specification on output format, and (b) this is the native J format for fractions.

I could "change the output format to match C" but that's not a part of the task description. It would be trivial to match the C display, but there's actually nothing in the task description (other than "completely reduced") that seems relevant here. (And a person could easily argue that 0 and 1 are completely reduced while 0/1 and 1/1 are not.)

As a first pass, I'm going to address this "incorrect" with documentation. If the task description itself gets changed to document the "completely reduced format" I will of course comply, but I wanted to put my reasoning here, before I did that.