Talk:Farey sequence: Difference between revisions
m (→REXX program encoding: caught a typo, fixed with a STRIKE thingy.) |
(→Grumble about "marked as incorrect": new section) |
||
Line 15: | Line 15: | ||
----- |
----- |
||
== Grumble about "marked as incorrect" == |
|||
I got a "marked as incorrect" flag: |
|||
{{incorrect|J| <br> First and last Farey terms aren't expressed as fractions as per the definition, <br> no terms shown are expressed as fractions, <br> (see the '''C''' programming example's output as an example). <br> }} |
|||
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. |
Revision as of 11:24, 2 April 2014
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 3rd 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 1st 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 3rd 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:
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.