5 kyu
Vector Class
124 of 871Detry322
Loading description...
Fundamentals
Object-oriented Programming
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Can data be transferred as numbers or a list?
This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/121.
Please join the discussion to help us identify duplicate kata and retire them.
Really nice initiation and practice to those unfamiliar with class construction. Thanks for the kata!
I am stuck in this challenge. Would be really grateful if someone can direct me. Having these errors Expected: #<Vector:0x000056332da9c0c0 @coordinates=[1, 2, 3]>, instead got: #<Vector:0x000056332da9c1b0 @coordinates=[1, 2, 3]> from the creation test and Expected: #<Vector:0x000056332da92a98 @coordinates=[0, 0, 0]>, instead got: #<Vector:0x000056332da92b60 @coordinates=[0, 0, 0]> Expected: #<Vector:0x000056332da92598 @coordinates=[2, 4, 6]>, instead got: #<Vector:0x000056332da92688 @coordinates=[2, 4, 6]> from the addition & subtraction tests I know the objects id's does not match but I am creating a new object on both methods
I got the same problem. Make sure to implement the __eq__(equal) method correctly, the v1==v2 method.
Thanks sooo much! After adding the == method, everything worked well!
Description of the kata did not state that a tuple can be passed as an argument however in the random test, a tuple was passed instead of a list.
Vector([a,b,c]) # creates a new Vector from the supplied 3D array. Vector(a,b,c) # same as aboveThe tests for my solution pass except for exit... curious if this is an issue with the test (code in python):
Traceback (most recent call last): File "main.py", line 19, in test.assert_approx_equals(Vector(examples[0]).magnitude, 3.741, 0.001) File "/runner/frameworks/python/cw-2.py", line 84, in assert_approx_equals div = max(abs(actual), abs(expected), 1) TypeError: bad operand type for abs(): 'method'
Magnitude is not a method, it should be implemented as a property.
The exact same question was answered in the third post below yours.
Thank you.
I'm fairly new to Python OO programming, but is it advisable to access class variables directly? My understanding was to use "getter" functions, but that does not work here for v.x, v.y, v.z, and v.magnitude (v is the Vector) as they're specified and tested without function brackets (e.g,, v.x() )
Python objects are free to intercept attribute get/set operations. And, if all you're doing is getting and setting with no restriction, adding getters and setters for it would be writing a whole lot of code to do exactly nothing different from default behaviour.
Yes, using getter and setter is a better way. But that is not what this kata asks for.
Learned about Python Operator Overloading because of the kata.Thank you @Detry322!!!
I have passed all tests except for the magnitude test and am getting the error shown below. My magnitude function works in my personal test, but the error seems to have an issue with the test input. Can anyone provide some insight?
Traceback (most recent call last): File "/runner/frameworks/python/cw-2.py", line 111, in wrapper func() File "main.py", line 104, in _ test.assert_approx_equals(Vector(examples[0][:]).magnitude, 3.741, 0.001) File "/runner/frameworks/python/cw-2.py", line 84, in assert_approx_equals div = max(abs(actual), abs(expected), 1) TypeError: bad operand type for abs(): 'method'
magnitude should be a property and not a method
I pass almost all the random tests but I get 14 errors. I think it all stems from the first error saying that both initializatoins should result in the same vector, what am I doing wrong? In my side IDE when I define a vector with a list, tuple, or just 3 inputs they all show the same in the IDE
Without knowing what you are doing it's difficult to say what you are doing wrong :)
Nvm figured it out
Maybe this was the same error I'm running into:
Test.assert_equals(Vector.new(1,2,3), Vector.new([1,2,3]))
yields
#<Vector:0x0000559eb6bc3b08 @x=1, @y=2, @z=3>, instead got: #<Vector:0x0000559eb6bc3f68 @x=1, @y=2, @z=3>
in my implementation, although the initialization itselfs seems to do, what it is supposed to.
Answer to myself and maybe others:
The tests do not want to compare the instances, as they (hopefully) are always different. Take care of this early and all will be fine :)
Description says
Vector([a,b,c]) # creates a new Vector from the supplied 3D array. Vector(a,b,c) # same as aboveHowever, test case also gives a Vector((a,b,c)). Maybe point this out in the description?already raised as issue
there is error in python test test.assert_approx_equals(Vector(examples[0]).magnitude, 3.741) shoud be test.assert_approx_equals(Vector(examples[0]).magnitude(), 3.741) please fix it in all tests
magnitudeis a property, not a method. Nothing to fix.getting errors like -
37989 should equal -37989
there are several of them. the error is not very descriptive. Any one knows which case it may be trying to test?
the test cases for getting individual items (eg. a.x) is working fine.
Nevermind
There is a problem with random testing taking attributes x and z. Example:
there are always 20 of them. although the rest of the tests for obtaining the attributes x and z have been successfully passed
Not an issue. All tests are working correctly.
This comment has been hidden.
nope, magnitude is supposed to be a property, not a function.
i'm still sleeping, all done, thanks!
Python: error messages are not clear:
Hint: this happens if you haven't defined the equality method...
This comment has been hidden.
should be good now. Plz tell me.
Issue cleared, thank you
Magnitude tests should use
assert_approx_equals, otherwise this happens:444.83565465426 should equal 444.835654654263:o
how the hell did you do your calculations??? The problem shouldn't happen, there.
(tell me, you didn't convert the inputs to floats? )
This comment has been hidden.
some would disagree on this (unnamed or the translator, for instance): if you use the correct definition, you shouldn't run into troubles. I've mixed feelings about this... Dunno.
When it comes to float comparison, you can never be sure exact comparison works.
It essentially produces the same result only if same implementation is used and I don't think that is something you want to enforce - for example you can change addition orders for example and result won't be the same.
That is why
assert_approx_equalsis always the right way to handle such teststhat, I know about. ;) Thing is, I already argued with unnamed, asking for approx equality while he was arguing that, if all inputs are integers, the calculus are simple, and there is only one division/float operation, it's the programmer that is responsible for handling the calculus with the best precision.
I'm not sure about this. Using math.hypot for this isn't really the proper way, since up to python 3.8 it's only meant for 2D points (if codewars supported 3.8, your approach would be undoubtedly proper and the tests would pass), so no wonder it yields slightly erroneous results. And no, changing the addition order will not result in different results. The vector's magnitude in 3-dimensional euclidian space is well-defined so the results should be as precise as possible.
only because the inputs are all integers. Send floats to the constructor and that will be another story.
I don't see why converting input to float should be forbidden due to floating point error in test case assertions.
It seems that even valid solutions will be rejected, not a good idea in my opinion
well, at least I found someone else thinking that approx should always be used... x)
I'll change that later.
done
This comment has been hidden.
self.haveSameDirAs(other)must be replaced withself.haveSameDirAs(Solution(*other.to_tuple()))I don't know why this happened, but try it now.
na that was actually another problem: the classic copy/paste trouble: you still had some
Vectorinside the ref solution instead ofSolution. I corrected it.Ok, thanks.
This comment has been hidden.
Resolved.
No sample tests.
Added.
Python translation
I didn't solve this yet, so I cannot answer in the translation tab, but, @FArekkusu:
Vector.to_ashouldn't be replaced bylist(Vector). It makes perfect sense to provide the method through the api/class. What you're suggesting is a requirement about providing an iterator for the class, which is totally different than providing a "method that returns an array/list representation of the vector instance".to_aas method name is weird for python but ok. If a change needs to be done, it should be renamed to.to_list, but no more. Tho, that will require an update of the description and will introduce new differencies between languages. Since this is not critical, I'd keepto_afor that one. On the other side,to_sneeds to be made consistent with python environment and effectively needs to be replaced by the__str__method, yes.Yes, because that's the correct way to convert an object of our custom class into a list. The users don't have to know why or how it works under the hood - they can utilize a familiar function and simply write
list(Vector(1, 2, 3))to get what they want. This is basic software design, you know?No, I completely disagree with you. You're changing the requirements from one language to the other, and that's bad on the "point of view of the kata".
Moreover, your point makes no real sense:
The point is not "is it basic design or not?". It's "is that consistent when you translate the kata?"
???
Amend the specifications for a language to fit its established practices? - Bad :( Provide trash API because you're trying to write language X in language Y? - Good :)
Seriously? What if we want to convert a
Vectortotuple(because that is the correct choice in terms of Python instead oflist)? Are you going to pile up even more trash by implementing a separateto_tuplemethod, or make theVectoriterable getting rid of all this headache and essentially turning theto_listmethod obsolete as an "old and poor design choice"?I agree this is not ideal. But you're going too far from the original (kata-)specs, doing so, because providing a method returning some stuff is not on the same level than providing an iterator (yes, it's not that hard, but that's still a complete different matter).
edit: moreover if you really ask for an iterator, it needs to be tested properly, which leads to a full battery of tests that do not have any equivalent in the original language.
edit²:
and, AGAIN, with what you're suggesting, you're not even following the specs, because the conversion to a list is left to the user.
=> since when
provide a list representationis the same thanprovide an iterator so that you can do whatever you want with it?I'm not asking for an iterator, I'm asking the user to allow the conversion using the
list(Vector(...))syntax. My first comment says "The users don't have to know why or how it works under the hood" - we're interested in a solution corresponding to the requirements (point 1) using idiomatic Python syntax (point 2), but not how exactly it works (even though there's only 1(?) way to achieve this)....!?! XD
Well, your idea is just bad for the translation. Translation should stick to the specs when possible => It is possible, here => A function needs to be implemented. That's all.
Or you can continue to be dishonset (with yourself? with us??) since, definitely, what you're asking for doesn't fit with your point 1.
Ok, what am I missing? Tests fail upon first addition attempt:
The result is what my implementation is returning, and - to my understanding - this is the right thing to expect. Why is it failing then?
Ok, nevermind, I've solved it, but I have to say - the test messages are extremely vague and unhelpful.
This comment has been hidden.
.
Needs random tests. And
Test.expectshould never be used.Added random and sample tests with proper assertions.
I think it would be better to change the parameters for the following lines from a,b,c to x,y,z because those aren't vectors.
a.to_s # returns a string representation of the vector in the form "<a, b, c>" Vector.new([a,b,c]) # creates a Vector from the supplied 3D array. Vector.new(a,b,c) # same as above
Could you either explain better the functions required in a vector or point us to a suitably informative article on these constructs in the description?
"Test::Error: Value is not what was expected" is not a sufficient error message for this kata.
Checked solutions to give better suggestions, found that your second test expects != to be defined, which is not part of the spec.