Is the clojure version really fixed? Sample tests give:
Exception in thread "main" java.io.FileNotFoundException: Could not locate math_evaluator__init.class or math_evaluator.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name., compiling:(/home/codewarrior/./test.clj:7:1)
The input is capitalized too, it's like that in the kata, so I think if the original kata uses realistic examples (capitalized) for the fixed tests, then tranlsation probably should too.
(Plus I added test-ns-hook so that the fixed tests are executed before the random tests.)
just re-wrote my Clojure code in Python (pretty much verbatum) and it passed all the tests. In both implementations word,,,,word --> word,,,,SPACE word.
.. to me this is a correct and resonable interpretation of th rules.
Yes, I am facing the same confusion. I am certain I can make my program behave in the way the tests are demanding. What I really cannot understand is what interpreation of the rules would lead to the input output behaviour you documented, ie:
word,,,,word --> word, ,, , word
does not seem to follow from the rules. ( I am also working in Clojure )
You're welcome! Glad you fixed things ( and that the Clojure version is more or less not broken ).
eval and import might be in string quotes in the description, but even that might not alert people to the fact it's not the functions but the literal strings that are forbidden.
Does anybody actually use Floats? I once even saw an argument made that languages are more optimised for Doubles than for Floats, because that's what people use, so that is what you should use, perpetuating Doubles and all but rendering Floats obsolete. Don't use Floats ( but the description could specify it. it reads as if even an Int should be acceptable for integer results. this may of course be an artifact from the original kata, being in JavaScript, which only has Numbers, which are Doubles ), and strong, static typing has its advantages.
The kata specifies order of operations, so this is one of the exceedingly few kata that can get away with looking for an exact floating point answer. I don't know if it does, but it can and it actually should. I don't understand how you can arrive at slightly different answers. Are you correctly implementing the specified order of operations?
You might be having a datatype problem, but I really know too little Clojure to assess that ( I don't know what datatypes, or even what typing, Clojure has ).
I think the Submit tests don't even look for math-evaluator, and expect the solution to be in math-parser. If you namespace your solution to math-parser, can you submit? ( You will not be able to run the example tests that way - unless you edit them again - but that does not keep you from submitting. )
I'm a total nono when it comes to Clojure, so I don't really trust myself to make changes to it. But I can read source, and the Submit imports look different from the Example ones.
This issue is fixed
duplicate issue
thank you :)
There is no 'end' Thus execution is
mov a, 5
inc a
div a, 2
msg '(5+1)/2 =', a
div a, 2
Undefined end: return -1
Is the clojure version really fixed? Sample tests give:
The input is capitalized too, it's like that in the kata, so I think if the original kata uses realistic examples (capitalized) for the fixed tests, then tranlsation probably should too.
(Plus I added
test-ns-hook
so that the fixed tests are executed before the random tests.)just re-wrote my Clojure code in Python (pretty much verbatum) and it passed all the tests. In both implementations word,,,,word --> word,,,,SPACE word.
.. to me this is a correct and resonable interpretation of th rules.
Yes, I am facing the same confusion. I am certain I can make my program behave in the way the tests are demanding. What I really cannot understand is what interpreation of the rules would lead to the input output behaviour you documented, ie:
word,,,,word --> word, ,, , word
does not seem to follow from the rules. ( I am also working in Clojure )
You're totally right!
:O
You're welcome! Glad you fixed things ( and that the Clojure version is more or less not broken ).
eval
andimport
might be in string quotes in the description, but even that might not alert people to the fact it's not the functions but the literal strings that are forbidden.Does anybody actually use
Float
s? I once even saw an argument made that languages are more optimised forDouble
s than forFloat
s, because that's what people use, so that is what you should use, perpetuatingDouble
s and all but renderingFloat
s obsolete. Don't useFloat
s ( but the description could specify it. it reads as if even anInt
should be acceptable for integer results. this may of course be an artifact from the original kata, being in JavaScript, which only hasNumber
s, which areDouble
s ), and strong, static typing has its advantages.The kata specifies order of operations, so this is one of the exceedingly few kata that can get away with looking for an exact floating point answer. I don't know if it does, but it can and it actually should. I don't understand how you can arrive at slightly different answers. Are you correctly implementing the specified order of operations?
You might be having a datatype problem, but I really know too little Clojure to assess that ( I don't know what datatypes, or even what typing, Clojure has ).
The anti-cheat is looking for
"clojure.java.shell"
,"ns-name"
,"all-ns"
,"import"
and"eval"
.I think the Submit tests don't even look for
math-evaluator
, and expect the solution to be inmath-parser
. If you namespace your solution tomath-parser
, can you submit? ( You will not be able to run the example tests that way - unless you edit them again - but that does not keep you from submitting. )I'm a total nono when it comes to Clojure, so I don't really trust myself to make changes to it. But I can read source, and the Submit imports look different from the Example ones.
Thanks
Revised and APPROVED
Loading more items...