That assert says that the feature-vector passed in to GDecisionTree::predict
contains a nominal value that is inconsistent with the meta-data use to train
the decision tree. Unfortunately, I cannot determine from the stack trace how
that occurred. If the issue is due to user-error rather than a bug in my code,
then that assert should be changed to an exception so that it will appear in
optimized builds too. Are repro steps available? (You could email them to me
if you'd rather not post them on the forum, and I would agree to only use your
data for the purpose of debugging this issue, and then delete it.)
Many of the users of this project are researchers in other fields who just
want everything to work, and don't want to know about development issues. The
instructions in README.txt are deliberately terse, and are written to get
people started quickly. I think that most developers would know that debugging
works better in debug mode, but there's always room to improve the
documentation. Even small wording changes to the documentation would be a
welcome contribution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if there was an inconsistency in the file, then it should have been
caught when the file was parsed. So I don't yet know where the bug is. I
suspect there is probably a bug in the GDecisionTree class somewhere, but I
don't have a repro.
Thanks for your suggestion to improve the portability of the GAssert. I
removed the "int 3" as you suggested, but I changed it to call
"__debugbreak()" because this seems to make Visual Studio break, whereas
"raise(SIGABORT)" just seems to make it terminate. You seem to be a good
programmer, so if you would like to contribute changes, I would be happy to
give you commit access to our Subversion repository.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you can see stack strace at
http://i56.tinypic.com/2hforxh.jpg
btw, in the build instructions, why do you insist on building release ? not
helpful when user gets asserts
dra90n
That assert says that the feature-vector passed in to GDecisionTree::predict
contains a nominal value that is inconsistent with the meta-data use to train
the decision tree. Unfortunately, I cannot determine from the stack trace how
that occurred. If the issue is due to user-error rather than a bug in my code,
then that assert should be changed to an exception so that it will appear in
optimized builds too. Are repro steps available? (You could email them to me
if you'd rather not post them on the forum, and I would agree to only use your
data for the purpose of debugging this issue, and then delete it.)
Many of the users of this project are researchers in other fields who just
want everything to work, and don't want to know about development issues. The
instructions in README.txt are deliberately terse, and are written to get
people started quickly. I think that most developers would know that debugging
works better in debug mode, but there's always room to improve the
documentation. Even small wording changes to the documentation would be a
welcome contribution.
Message "Value XYZ in column #12, row #3456 is inconsistent with metadata"
would be lead user in the right way -- assuming this happened from input-file
data.
I do not understand fromyour reply wherther inconsistent data in user file
cause you to assert.
assert signals internal inconsistency in the program. normally, without
debugger, one can't uncover reasong of assert.
regarding int 3. you assume intel processor here ....
more portable way to abort like assert(0) does is
raise(SIGABORT)
this works on win32, & unix
Well, if there was an inconsistency in the file, then it should have been
caught when the file was parsed. So I don't yet know where the bug is. I
suspect there is probably a bug in the GDecisionTree class somewhere, but I
don't have a repro.
Thanks for your suggestion to improve the portability of the GAssert. I
removed the "int 3" as you suggested, but I changed it to call
"__debugbreak()" because this seems to make Visual Studio break, whereas
"raise(SIGABORT)" just seems to make it terminate. You seem to be a good
programmer, so if you would like to contribute changes, I would be happy to
give you commit access to our Subversion repository.