Opened 15 years ago

Closed 13 years ago

#130 closed discussion (fixed)

KernelLookups and MatrixLookups not in inheritance structure but template

Reported by: Peter Owned by: Peter
Priority: trivial Milestone: yat 0.4
Component: classifier Version: trunk
Keywords: Cc:

Description

This is just a thought:

What would happen if we removed DataLookup2D and used templates where it is used instead such as SubsetGenerator?. DataLookup2D could perhaps be an interface class for MatrixLookup? and MatrixLookupWeighted?, but the question is how it would be if we introduced templates in SubsetGenerator? and EnsembleBuilder?. How would that be? A danger is if the templates are propagating all over the code. That we do not want.

Change History (7)

comment:1 Changed 15 years ago by Jari Häkkinen

Type: idearequest

Removing type "idea" and changing this to a "request".

comment:2 Changed 15 years ago by Peter

Type: requestspecification

comment:3 Changed 14 years ago by Jari Häkkinen

Type: specificationdiscussion

comment:4 Changed 14 years ago by Peter

In the light from on going discussions on templates in example distances and KNN, I'd like to remind about this ticket.

comment:5 Changed 14 years ago by Markus Ringnér

Regarding templates in distances, I think this is the way to go (maybe the design with having a trait for different measures is not optimal but we certainly want the iterator pattern). If we do this I gave an example of how KNN could be produced with the template propagated and an example for NCC with a simple adaptor solution. Having implemented both of them I think the KNN example is appealing (it more easily provides flexibility in which iterators can be used to calculate distances). Either way the templates will in these cases not propagate beyond the derived classifiers (not into EnsembleBuilder?, ....).

Making templates of the Lookups may or may not be the way to go. I have not thought about benefits and problems with doing that at all. The reason I wanted to make a template distance is because it is similar to the std algorithms. In std, containers are templatized, but (only?) on the type they carry. This would be the case for the MatrixLookups? but I guess when incorporating KernelLookups? we would be templatizing on container "type/structure" also, so I have not thought about a way to do this or consequences.

comment:6 Changed 14 years ago by Peter

I just wanted to put some light on the issue before it was completely forgotten in its own dust. The advantage of templatizing the Lookups would be that we could avoid the runtime errors that occur when combining e.g. NCC with a Kernel. And we do prefer compiler error(!). However, the disadvantages is a bit unclear to be but my gut feeling is that it becomes rather complicated.

comment:7 Changed 13 years ago by Markus Ringnér

Milestone: yat 0.x+yat 0.4
Resolution: fixed
Status: newclosed

Fixed in [1170]

Note: See TracTickets for help on using tickets.