Skip to content
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

saving with higher precision #300

Closed
rcurtin opened this issue Dec 29, 2014 · 2 comments
Closed

saving with higher precision #300

rcurtin opened this issue Dec 29, 2014 · 2 comments
Assignees
Milestone

Comments

@rcurtin
Copy link
Member

rcurtin commented Dec 29, 2014

Reported by fleischhauf on 12 May 44022099 07:14 UTC
I am working with HMMs for chord recognition and the limited precision of the save restore utility gave me some headaches.
It would be nice to have an option for saving floating point numbers with higher precision.
This could easily be done with std::setprecision(number) in the save restore utility for the file output stream.

@rcurtin rcurtin self-assigned this Dec 29, 2014
@rcurtin rcurtin added this to the mlpack 1.0.9 milestone Dec 29, 2014
@rcurtin rcurtin closed this as completed Dec 29, 2014
@rcurtin
Copy link
Member Author

rcurtin commented Dec 30, 2014

Commented by rcurtin on 13 Nov 44026748 07:19 UTC
Hello there,

The correct solution to this is to store the transition matrix values and the emission probability values in binary instead of as a string, but for now I've done what you suggested and added a std::setprecision(15) to the relevant calls. I've attached a patch you can apply (or modify if 15 isn't enough). The reason I didn't go through and start storing HMM values in binary format is that the SaveRestoreUtility is going through a bit of overhaul right now, so I don't want to make an svn merging nightmare for the guy working on it. If you're using svn trunk already, I merged these changes in in r16136.

Definitely in the future, though, binary saves is the right way to go. Feel free to reopen the ticket if this doesn't solve the problem.

Thanks,

Ryan

@rcurtin
Copy link
Member Author

rcurtin commented Dec 30, 2014

Commented by fleischhauf on 20 Sep 44034784 15:57 UTC
thanks for the quick reply !

Nik

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant