Hello. I noticed you added Kotlin example for Emirp primes and couple other pages. In case you're interested, I pulled all Kotlin code into a repository on github https://github.com/dkandalov/rosettacode-kotlin Dmitry Kandalov 15/12/2016
comment about "Four is the number of letters in the ..."
Addressing the possible sentence length difference, are you keeping the commas in the never-ending sentence intact (after display the count and the word)? -- Gerard Schildberger (talk) 15:34, 12 September 2017 (UTC)
By the way, I changed the name of the task --- it had a typo that I missed (many times) of the first word.
The old name was:
Fours is the number of letters in the ...
The new name is:
Four is the number of letters in the ...
I also will be changing the requirement about showing the total number of characters of the sentence.
The change will be to show the sentence length after each display, and because you already did that, you won't have to change your Kotlin entry.
Yes, as far as I can see, the commas are being counted when computing the sentence length and this seems to be borne out by the sentence lengths being the same for N == 201.
I will re-run my version of the (REXX) program and post the complete never-ending sentence at the talk page of that Rosetta Code task.
- No, I meant, are the commas left in the never-ending sentence, that is, are the commas still in the never-ending sentence. I couldn't tell if the removal of the commas are from removing them from a word, or from the never-ending sentence. -- Gerard Schildberger (talk)
I wondered whether there might be a difference in the spelling of the numbers (or ordinals) somewhere but I haven't been able to find one. So, for the moment at least, I'm baffled!
- Yes, a difference in the spelling either the number (the length of a word), or the ordinal number (of the location of the word) may be the cause of the difference. I'll re-run a modified version of the (REXX) program and post the first
2,100 or so2,202 words of the never-ending sentence at the talk page of that Rosetta Code task; hopefully, we should be able to visually determine the difference(s). -- Gerard Schildberger (talk) 19:21, 12 September 2017 (UTC)
- Thanks Gerard. After studying your print-out I've realized what the problem was, namely a simple misunderstanding on my part. I was thinking previously that the 'sentence' was all words up to and including the 'N'th but, of course, it's all words up to and including the next comma if the 'N'th word doesn't end with a comma. In the case of the 201st and 2,202nd words it just so happened that those words did end with a copy and so our sentence lengths were in agreement.
- Yuppers, I made sure that the number chosen actually pointed to a word (a spelled ordinal number) that ended in a comma, which would make it (I had hoped) easier to find the problem of the differences in the lengths of the never-ending sentence. -- Gerard Schildberger (talk) 00:14, 13 September 2017 (UTC)
- Anyway, it was easy to fix and our two entries are now in total agreement. --PureFox (talk) 00:05, 13 September 2017 (UTC)
Incidentally, I've altered the preamble to the Kotlin entry now that you've made sentence length part of the task for all values of N.
- Yes, thanks to you, I didn't even realized that I used an incorrect phrasing of that requirement. It was fortunate that you went ahead and adhered to what I had intended. You must be a seer. -- Gerard Schildberger (talk) 19:21, 12 September 2017 (UTC)
Thanks for the recent addition of this and some other interesting tasks. --PureFox (talk) 17:48, 12 September 2017 (UTC)
- I've got quite a few more in the pipeline, now that I've recovered ... from not being at my best. -- Gerard Schildberger (talk) 19:21, 12 September 2017 (UTC)
comment about "abbreviations, automatic
Thanks for finding that error in the table (file) that holds various language names for the days-of-the-week.
I have corrected the 89th line of that file that holds the (older style) Azerbaijani [Azeri] language (for the name of Saturday.
- Thanks for correcting that line, Gerard. I thought I'd re-run the Kotlin program for the sake of good order and also remove the pre-amble which is no longer relevant. However, I haven't changed the code itself as it does no harm to allow for this possibility and prevents the program from entering an infinite loop.
- Incidentally, following the correction to the Cantonese line, I think your minimum length should now be 12 rather than 13. --PureFox (talk) 21:45, 19 September 2017 (UTC)
Go solutions: panic, gofmt
I see you've added a number of missing Go solutions recently which is excellent.
I have however noticed you have tendency to use
panic for error reporting
which is a bad practice in Go and should be avoided in examples IMO.
At a minimum I'd suggest using
log.Fatal in future examples, and ideally that would only appear in the main function,
other functions returning an
error value as is idiomatic in Go.
idiomatic uses of panic,
such as when detecting unrecoverable programming errors, are quite reasonable.)
Also, when I work on Go solutions here I tend to just copy-paste between my editor and Rosetta's edit web form which preserves the "standard" Go formatting of
goimports for me).
I noticed your code uses four space indenting instead of gofmt's tabs==eight spaces
which causes your Go solutions to look different from the majority of Go code on this site and elsewhere.
- Yes, you're right that I've been over-using 'panic' in my solutions and I'll try to avoid that in future.
- Even though I have a number of issues with 'go fmt' (including the use of tabs rather than spaces), I have in fact been running it on my more recent solutions for the sake of uniformity. However, the one thing I cannot stomach is the use of 8 space tabs for indenting and, since there doesn't appear to be a way to change the tab length in the WikiMedia software, I've had to replace tab characters with (my preferred) 4 spaces before posting.
- Although 'go fmt' uses tabs, I don't actually think there is any requirement that these be fixed at 8 spaces because Rob Pike himself stated about a year ago:
- "The indent character is tab, whose width is your decision. That's in large part why the indent character is tab: to let you choose how much to indent."
- So, if you don't mind, I'll be sticking to my 4 spaces when posting on this site whilst accepting the other strictures of 'go fmt'.
- Incidentally, it's good to see that Go has at least 3 active contributors, which is two more than most other languages can boast. As a relative newcomer to the language, it helps me a lot to study other people's solutions.--PureFox (talk) 23:20, 20 June 2018 (UTC)
- Thanks Gerard. An interesting task for me as I knew zilch before about Mayan numerals.
- I've seen the discussions on how best to display the cartouches but I'm relaxed about using the 'traditional' box drawing characters as, whatever one does, it will be sure not to display properly in some browser or platform.--PureFox (talk) 16:45, 20 January 2019 (UTC)
- Sure, I've just attended to it.--PureFox (talk) 14:59, 1 February 2019 (UTC)
Haha, sorry for misleading you with my python solution! I still have issues with my Nim solution. It also lacks eval. Typed Nim should be quicker than Python, but my solution is worse. Maybe I will copy yours! --ChristerNilsson (talk) 14:44, 20 March 2019 (UTC)
- No problem, Christer:) Your original Python solution (and my Go translation of it) were on the verbose side and I knew I'd run into problems with the lack of eval if I tried to use RE to simplify the parsing. So I thought I'd try and write something from scratch which turned out to be quite easy once I'd come up with a way to evaluate any parenthesized parts of the formula.--PureFox (talk) 15:20, 20 March 2019 (UTC)