<jonpsy[m]>
Hey, so I was reading about the flaws of `double` datatype, and that makes me wonder how do we handle large datatypes in mlpack?
<jonpsy[m]>
* Hey, so I was reading about the flaws of `double` datatype, and that makes me wonder how do we handle large float values & their printing in mlpack?
jjb[m] has joined #mlpack
<jjb[m]>
zoq> looks like the <https://vis.ensmallen.org/ needs the HTTPS cert renewed. Getting: `NET::ERR_CERT_DATE_INVALID`
<rcurtin[m]>
jonpsy: we don't do anything special for them (although LAPACK and BLAS do for very small float values)
<jonpsy[m]>
Hmm, so the problem is: Let's say if you try `double num=1e24`, in my Mac I get `999999999999999983222784.000000`
<rcurtin[m]>
right
<jonpsy[m]>
seeing the problem? It's wrong by more than 10^3 order.
<jonpsy[m]>
s/3/7/
<jonpsy[m]>
Although I guess it dwarfs compared to 1e24, but still 24/7 ~= 30% of your precision is gone
<rcurtin[m]>
I don't see the issue with this though (or, at least, I don't see anything that we should do about it). every floating point representation in every (non-esoteric, non-niche) language has this issue, and imprecision is also introduced by every computation on floating-point values
<jonpsy[m]>
True, but just because language itself doesn't handle it. Doesn't always mean we shouldn't, right?
<jonpsy[m]>
For example, language gets confusing when comparing really close `float` numbers. So we handle it using `fabs(a-b) < EPSILON`.
<rcurtin[m]>
I think the inherent expectation is that a user understands enough about floating-point representations to know they are not exact; I don't see what we could reasonably do about it that wouldn't be confusing for users who do know how floating-point representations work
<jonpsy[m]>
I get the "that's just how it works". But idk, its a little hard for me to digest that this norm exists
<zoq[m]>
<jjb[m]> "zoq> looks like the <https://vis..." <- Thanks, I thought I enabled the autocert bot, I'll check what went wrong.
<rcurtin[m]>
jonpsy: yeah, it is a bit of an ugly revelation at first :) there is an entire field of error analysis built around issues like this, and huge amounts of work go into the lower-level LAPACK and BLAS implementations to handle low precision of very small values
<rcurtin[m]>
imagine things like, during say an eigendecomposition or something, if values are getting too small, multiplying all the elements of the eigenvector that's getting refined by 1e10 so that the values are back in a "good" range for floating-point errors, and then dividing the result by 1e10 at the end of it all
<jonpsy[m]>
yes, thats a common practice
<jonpsy[m]>
in shogun we used to take log to handle low precision values.
<jonpsy[m]>
s/low/high/
<NabanitaDash[m]>
Is the backtrace limited to one single file in mlpack? How to get a more elaborate backtrace? I have used flags for the same already.
CaCode- has joined #mlpack
CaCode_ has quit [Ping timeout: 240 seconds]
CaCode- has quit [Ping timeout: 256 seconds]
kristjansson has quit [Excess Flood]
kristjansson has joined #mlpack
CaCode has joined #mlpack
CaCode_ has joined #mlpack
CaCode has quit [Ping timeout: 272 seconds]
_slack_mlpack_U7 has quit [Quit: You have been kicked for being idle]
CaCode_ has quit [Quit: Leaving]
<zoq[m]>
<NabanitaDash[m]> "Is the backtrace limited to..." <- I guess in your case it makes more sense to step through the code with gdb.
<NabanitaDash[m]>
I am bit shocked as how it can store empty numpy arrays inside object as in the documentation but not empty arma matrices. Cpp objects can not have empty elements. Maybe yes, i will setup gdb and check what is going on.