-
-
Notifications
You must be signed in to change notification settings - Fork 359
Euclidean algorithm: Output standardization #877
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Euclidean algorithm: Output standardization #877
Conversation
This also fixes a bug in the original implementation.
Printing stuff properly seems impossible in this language, but as it is not planned to automatically matlab code anyway, the missing newlines after `[#]` won't matter.
Fixed bug in the original implementation (euclid -> euclid_sub).
I know this is still a draft, but is it close to being reviewed? |
The languages which I standardized already can be reviewed, however it would be good to gather some more implementations before the final review. |
This reverts commit 84210b0.
I don't know that much about OCaml, so I'm not sure how idomatic this is.
I am done with all the implementations which can be standardized properly (excluding esoteric and graphical languages). Clojure / Factor / Smalltalk / viml were not standardized, as I could not figure out how to run them. I suspect that they either contain syntactic/semantic errors or that they do not run/build with newer versions of their respective programming language. Apart from these outliers everything should be ready for review. Currently there do not seem to be any reviewers active, which could take a look at the broken implementations. However I really do want to stay back from merging this until those aforementioned implementations are fixed or removed, as just leaving them out would be against the original intent of this standardization work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will approve this, but it does need to be merged up to master. There were a few small changes to the C and scheme code, but they are easy fixes
@@ -3,8 +3,8 @@ object Euclid { | |||
def euclid_sub(a: Int, b: Int): Int = | |||
(Math.abs(a), Math.abs(b)) match { | |||
case (0, _) | (_, 0) => 0 | |||
case (x, y) if x < y => euclid(x, y - x) | |||
case (x, y) if x > y => euclid(x - y, y) | |||
case (x, y) if x < y => euclid_sub(x, y - x) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, how did this code run before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It didn't.
The scala and javascript implementation needed some (small) fixes to work.
|
||
WRITE(*,'(a)') '[#]' | ||
WRITE(*,'(a)') 'Subtraction-based euclidean algorithm result::' | ||
WRITE(*, '(g0)') euclid_sub(a, b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we just not run the fortran code before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We ran the two methods the other way around
Since implementation and review of the missing languages don't seem to be planned any time soon, I'll just merge this as long as everything compiles correctly. |
The following implementations were not fully standardized:
Implementations which seem to contain errors or do not run:
No need to and/or not standardizable:
[#]
, but as there are no plans in automatically validating it, I think this can be ignored)Two implementations had bugs (fixed now):