Hi Ahmed,

Thanks a lot for getting the ball rolling with the discussion :-)

Disclaimer: I'm probably just adding some noise here, but let me try to
convey my understanding.

I think this ("untemplated", generic API) has to do with the trade-off
between
(1) writing algorithms in a high-level and clear manner, without needing to
take care of details such as the #bits to store numbers, the types of
Shogun features and labels;
(2) efficiency or the C++ way: abstractions at zero-cost. For example,
having the power to choose the #bits in case it is really needed (e.g. huge
data sets where using float64_t iso float32_t would involve relying on
swap).

For inspiration of (1), think of a simple algorithm (linear regression as
Heiko pointed out) written in Python or even just equations.

How to achieve this? I think this is still up for being designed and
discussed.

You are asking about requirements and I believe that is definitely the crux
at this stage. It can be that we don't have them 100% clear yet. A way
forward here is to start with a sample (draft) design, and from there we
can see whether it presents limitations (which would become requirements of
the desired solution).

Please Heiko, Viktor, Sergey, etc. attack and correct me if any of this was
misleading 🏹

Cheers,
Fernando.

On Fri, 14 Jun 2019 at 12:20, Heiko Strathmann <heiko.strathm...@gmail.com>
wrote:

> Hi
> Very good questions
>
>
> On Fri, 14 Jun 2019 at 11:48, Ahmed Essam <theartful...@gmail.com> wrote:
>
>> Hi all,
>>
>> I have a few questions about this:
>> 1. Is this mutually exclusive with expression templates?
>>
>
> It is orthogonal i would say
>
> 2. Should it be solved on the Feature classes level, or the container
>> level?
>>
>
> Very good question! Both is possible, we don’t know what is better. But
> think about this: what is the return type of
> CDotFeatures::cov() ?
>
> Next question is when to dispatch feature class and type. I think the best
> solution is to do that inside CMachine and then algorithms only implement a
> typed train method. However, algorithms are a different level of
> abstraction than typed algorithms. Eg linear regression
> Cov = f.cov()
> W = linalg::solve(cov, labels.get())
> So there is a questions what is better: Compile time typed implementations
> or runtime stuff. I can elaborate more in irc st some point
>
>
> 3. What are the use cases where this is useful, so as to think about them?
>>
>
> To be able to write algorithms in a mathy way, without templates types,
> see above
>
> 4. What are the general requirements? Should every class contain a list of
>> types it deals with? Will this use linalg?
>>
>
> Not sure what you mean here...
>
>
>> Thanks,
>> Ahmed.
>>
>> --
> Sent from my phone
>

Reply via email to