Closed canturk closed 6 years ago
Hi @canturk,
Sorry for the late response. I can't remember the details on top of my head, but when I allowed arbitrary node values, there were many awkward edge cases that i could not work around (e.g. user-supplied values were complex objects that did not support random generation or comparison). Pretty printing the tree was also an issue when the __repr__
of values were lengthy (the tree would get really wide). To avoid such future headaches I decided that integer is probably enough for users to practice their algorithms. Floats, however, should be easy to add back so I will consider it. Just out of curiosity, what is your use case with floats that you can't use ints instead?
Best Joohwan
Hi Joowani, Thank you for asking. The reason why I need floating point values in my application is the following. First, I generate a floating point number between 0 and 1 based on an algorithm in my application. Then I insert that value into the binary tree. This process will iterate until a certain number.
Concerning the data types in binarytree, I understand the reasons why you tried to get rid of other data types. However, in my opinion, every node in a binary tree must support all data values (including custom based data type) without any restriction. And I think it would be wise to restrict the use of the features you mentioned above for only integers and leave the full responsibility and management of other type of objects to the user. Regards MC
Hi @canturk,
It's been a while, but I've finally released binarytree 4.0.0 which adds back support for all "number" type node values (e.g. int, float, decimal.Decimal). You can check out the release notes for full details. As for accepting other user-defined values, I will have to work out all the kinks before I can allow full customization again (no timeline for this yet). Feel free to re-open this issue or send me a message if you have any other problems!
Hi there, I did not get the reason why the value of Node class in binarytree must be integer in the new version (3.0.1.), whereas it worked perfectly for floating point value in the old version (1.1.1). Can you fix that? Thanks MC