BB-13: Query the domains (types) of operators

[mcmillan03]

From Suitesparse:GraphBLAS;

'GxB_UnaryOp_ztype' & return the type of the output $z$ for $z=f(x)$ 
'GxB_UnaryOp_xtype' & return the type of the input $x$ for $z=f(x)$

'GxB_BinaryOp_ztype' & return the type of the output $z$ for $z=f(x,y)$ 
'GxB_BinaryOp_xtype' & return the type of the input $x$ for $z=f(x,y)$ 
'GxB_BinaryOp_ytype' & return the type of the input $y$ for $z=f(x,y)$

Also for monoids and semirings

[DrTimothyAldenDavis]

My initial recommendation is not a good idea. Instead, querying the type of a matrix, vector, operator input/ouput, etc, should return a string. See #32 .

char type_name [GrB_MAX_NAME_LEN] ;
GrB_Matrix_type_name (type_name, A) ;

returns a string, "int8_t", "bool", "float", etc with the name of the C type, or the user-provided name of a user-defined type. This is the safe and portable way for the user application to deal with querying types.

[manoj63]

It seems to C specific, where polymorphism is absent. Appears to be useful as an assert of type compatibility.

The difference between Scotts and Tim's suggestion seems to be a minor detail, though it seems in Scott's suggestion we are comparing the ground truth more directly, as opposed to comparing the string translation of the two, from two different places.

[DrTimothyAldenDavis]

I think the string version is safer. No worries about lifetime or ownership of the output of these functions.

[rayegun]

The committee broadly agreed that it seems more desirable to receive a GrB_Type, and then you can call GrB_Name on the type. Just like we would return GrB_Monoid for the add operator of a semiring. What are the issues with lifetime and ownership there?

I would, of course, receive a GrB_Type that I guess I could free, but I don't think that leads to anything unexpected?

Of course it should be pretty simple for you to add a GxB_TypeName field to the get enum that does this in one trip.

[DrTimothyAldenDavis]

OK. I can go either way. I just was worried about what might happen if you free the result from a method that returns a type. Do you need to free it at all? Never free it? In SuiteSparse:GraphBLAS, I basically assumed the returned type wouldn't be freed. But is that the right decision? I'm unsure.

[rayegun]

I don't think you need to free it, they should be relatively tiny. But I think it should be allowed to call free on it. Of course you can choose not to free internally, and IMO that's the better design choice (making everything similar to the builtins). But that's an internal thing.