<Aakash-kaushikAa>
Btw i can see that this container only solves the dependencies and adds jenkins as a user group, do we then create containers out of those images and then jenkins uses that to build the actual docs ?
<Aakash-kaushikAa>
I thought that we can have a image that has all the dependencies and we you actually use that image it copies models repo and and generates documentation.
<rcurtin[m]>
I noticed today that `dealgood`, one of our build systems that's supposed to have 16 cores to build on, actually only has 1. this explains why the nightly docker build is taking forever when some of the jobs run on dealgood. :) I'm looking into it now, but it might be a BIOS setting which means I have to negotiate with the Georgia Tech College of Computing support to set up an appointment to look at the BIOS (or get one of the support people
<rcurtin[m]>
to look through the BIOS)
<Aakash-kaushikAa>
I guess getting the appointment would be the hard part ?
<rcurtin[m]>
maybe, we'll see how quickly they respond. last time dealgood went down, I couldn't get an appointment set up for a year 🙈
<rcurtin[m]>
(admittedly, I kept forgetting about it, and so did they...)
<Aakash-kaushikAa>
Maybe you can keep reminding them about this.
<Aakash-kaushikAa>
I mean the best reminder are the things that cause you problem everytime you look at them so you are dedicated to solve them
<rcurtin[m]>
yeah :) I have to remind myself about it too
<rcurtin[m]>
for now I'll just drop the number of executors on dealgood down to 1
<zoq[m]1>
<Aakash-kaushikAa> "https://gist.github.com/Aakash-..."; <- Yes, that is great, the reason why we don't do this for the other docker image is that we use it for different workloads.
<zoq[m]1>
<rcurtin[m]> "I noticed today that `dealgood`,..." <- Does it fully utilize the core?
<zoq[m]1>
I thought we have enough nodes at this point now :) But maybe that is not true.
<rcurtin[m]>
yeah, it uses one just fine, but with 16 executors it just thrashes
<zoq[m]1>
<Aakash-kaushikAa> "makes sense this particular file..." <- The way you do it right now is good.
<zoq[m]1>
<heisenbuugGopiMT> "[These](https://github.com/boost..."; <- The question I have why do we reproduce the boost approximation, because the solution is faster?
<heisenbuugGopiMT>
s/L320/L314/
<heisenbuugGopiMT>
s/L320/L314/
<heisenbuugGopiMT>
Yup and more accurate as well. If we use the simple formulae mentioned on the wiki then there is a difference in the values.
<zoq[m]1>
Yeah, I have seen the comparison, but was wondering if boost outputs an approximation because it's faster or if the mlpack result is wrong because it's a corner case.
<zoq[m]1>
Might be worth to compare this with R or MATLAB and see what the output is.
<heisenbuugGopiMT>
We are only facing issues with small numbers, and small negative numbers.
<heisenbuugGopiMT>
I can try running on matlab as well.
<heisenbuugGopiMT>
Our implementation is different from boost.
<zoq[m]1>
Maybe we are trying to replicate an approximation, but we don't actually need to.
<heisenbuugGopiMT>
They are solving a series to find the answer, and we are using a single formula.
<zoq[m]1>
If you use the single formula does it break the test suite?
<heisenbuugGopiMT>
Yup.
<zoq[m]1>
I would say let's compare it with another framework, and see what the output is.
<zoq[m]1>
But to answer your question I would go with `long double` directly no need for a typedef.
<heisenbuugGopiMT>
Okay, I will try matlab and add the comparisons to the table. I Will also go through the implementation to make sure that I am not doing anything wrong.
<heisenbuugGopiMT>
Oh, okay, no need for typedef then, but first I will compare with other framework
<heisenbuugGopiMT>
@marcusedel:matrix.org I tried in R, it's giving same values as boost's implementation.
<heisenbuugGopiMT>
So we can't use direct formula for negative numbers.
<heisenbuugGopiMT>
We are using reflection formula