Return codes

[mcmillan03]

Do we use GrB_Info or have LAGr_Info that contains (possibly) a GrB_Info and a much richer set of information.

Is there an LAGr_error() that does analogous tasks to GrB_error() or something completely different.

[ScottKolo]

Given the discussion in #6, if we go with LAGr_Matrix, we should probably go with LAGr_Info.

As you've pointed out, we can include algorithm-specific error messages and other LAGraph-specific functionality. I think this would be particularly useful given that the LAGr_Matrix being discussed is not opaque, and so we may need to notify the user of a lot more possible errors (e.g. "Hey, you told me this matrix was symmetric and it's not!").

[tgmattso]

I agree with you …. LAGr_info rather than GrB_info. I really hope that LAGraph is successful as a standalone library and that most of our users will not really know (or care) that GraphBLAS is running behind the scenes.

…

--Tim From: Scott Kolodziej <[email protected]> Reply-To: GraphBLAS/LAGraph-Working-Group <[email protected]> Date: Wednesday, April 8, 2020 at 6:19 AM To: GraphBLAS/LAGraph-Working-Group <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [GraphBLAS/LAGraph-Working-Group] Return codes (#4) Given the discussion in #6<#6>, if we go with LAGr_Matrix, we should probably go with LAGr_Info. As you've pointed out, we can include algorithm-specific error messages and other LAGraph-specific functionality. I think this would be particularly useful given that the LAGr_Matrix being discussed is not opaque, and so we may need to notify the user of a lot more possible errors (e.g. "Hey, you told me this matrix was symmetric and it's not!"). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AATVMEZLZ2IFKZVHIWG6F3TRLR2SRANCNFSM4LZC7HEQ>.