0

I have a code where cfit objects are passed back and forth between functions\classes and I would like to have a "tag" that contains some information about my fit (i.e. its name), such that I instantiate it at some point and can access it later whenever it's needed.

Ideally, this would be right inside the object, so that whenever I need to access the information, it's available without the need to drag around (or in appdata) additional vectors\cells.

Attempts & Thoughts

Normally, one would simply subclass cfit and add a property that contains this data. However, the declaration of cfit (see below) tells us that it is Sealed, and therefore cannot be subclassed.

classdef (Sealed = true) cfit < fittype

Alternatively, we could try to "hijack" some property that is not used by the current objects and use it to store the required data (not that it's a technical problem, but this is equivalent to ignoring the developers' warnings that these properties shouldn't be touched).

Moreover, from the above classdef we also learn that this is a subclass of fittype which may have some properties\methods we could use for this purpose.

Finally, the question remains - what is the best place to save my additional bit of data, so that it is both convenient to set\get (convenient means that if I want to access it inside a loop, I don't have to use eval()), and doesn't interfere with the normal operation of cfit objects?

Community
  • 1
  • 1
Dev-iL
  • 23,742
  • 7
  • 57
  • 99

2 Answers2

1

One way that seems to work is by accessing the .p structure of a cfit object and adding whatever to it:

Before:

>> F378

F378 = 

     Shape-preserving (pchip) interpolant:
       F378(x) = piecewise polynomial computed from p
     Coefficients:
       p = coefficient structure

>> F378.p

ans = 

      form: 'pp'
    breaks: [1x40 double]
     coefs: [39x4 double]
    pieces: 39
     order: 4
       dim: 1

After F378.p.tag = '3.78';:

F378.p

ans = 

  form: 'pp'
breaks: [1x40 double]
 coefs: [39x4 double]
pieces: 39
 order: 4
   dim: 1
   tag: '3.78'

I found this from the following error:

Error using cfit/subsref (line 18)
The name 'probnames' is not a coefficient or a problem parameter. You can only use dot 
notation to access the coefficients and problem parameters of a cfit or sfit, for example 
'f.p'.

For the current object the properties you can access like this are:

p

Caution is advised: I did not test whether this solution interferes with normal operation.

Dev-iL
  • 23,742
  • 7
  • 57
  • 99
0

Rather than subclass cfit, make a new class and store the cfit object as a property, along with your tag as another property.

Sam Roberts
  • 23,951
  • 1
  • 40
  • 64
  • So you're basically suggesting a wrapper class for `cfit` (or a box\unbox pattern). This is an interesting idea - what worries me is that this solution is a bit dangerous with regard to [type safety](http://en.wikipedia.org/wiki/Type_safety) (which MATLAB disregards anyway most of the time), and hence compatibility, since in the rest of the codebase objects are assumed to be `cfit`s - and so inherited fittype\cfit functions will not be "exposed" anymore unless "pipelined" separately. – Dev-iL Mar 01 '15 at 15:29
  • Yes, I'm suggesting you just use the class as a thin wrapper around cfit, to enable you to collect it together with your tag - barely more functionality than a struct with a cfit as one field and the tag as another, just a bit more formalised. You'd only have to modify your code to use myobject.mycfitprop rather than the original cfit. – Sam Roberts Mar 01 '15 at 16:23
  • 1
    Also, I suggest submitting an enhancement request to MathWorks, asking them to stop sealing all their classes- I find it kind of antisocial. – Sam Roberts Mar 01 '15 at 16:25