Hi,   A bit late to the party, but I have built a system for this at my organisation (built in SAS code), so it is possible to do what you are describing, but was quite a bit of complex work. We have a local Gitlab installation which serves as the single storage repository for a wide range of macros across a number of projects. Users may want to utilise any of these macros in various other projects, so the code ecosystem is very interlinked.   These are defined / loaded within a users session using a custom %include type statement in a format like such: %gl_includeCode(GL_PROJECT=project_name, GL_VERSION=Latest); or  %gl_includeCode(GL_PROJECT=project_name, GL_VERSION=1.0, GL_FILE=/important_macros/macro_x.sas); And then macros defined in that project can be called/ utilised as normal by the end user, without ever having to create a local copy. The systems allows for fully nested Gitlab references, and also has traceability tools to users can track what is going ok.   The underlying code is fairly complex, but relies on the Gitlab API to get a list of all SAS files present, and then individual filename statements for every piece of code to include them. It would definitely be nice if there was a more automated way to do this within SAS.   This solutions solves many of the issues we had with a similar structure using standard %includes based on the SAS file system and actually allows for a lot of novel controls which would otherwise be impossible. Every %GL_includeCode call can be logged so we have full visibility of all macro users for a project / file. The use of a custom include function also means we can build in automated nested include tracking / presentation to end users, which would otherwise not be possible. Normal Git versioning is fully accessible, so users can point to a specific version of a repository and never be concerned their referenced macro will change (but will receive log notes with suggestions to move to newer versions) All the collaborative benefits /documentation of GitLab can be leveraged in a single place, by having code live on there as it's sole home. Any code enhancements are forced to be added in the single shared repository, rather than getting lost in specific local repositories. ... View more

Thanks, On 1) this is an idea that's been explored, but X in my case is driven by a variety of class and continuous variables, with the weights of them being derived during the regression. It is not possible to know the specific X for an observation prior to the regression as it is binary data, therefore bands for C cannot be predetermined.   One idea being considered is to perform a 2 step regression, deriving X without C, then using that output to allocate C-bands for each observation, before re-running the regression with X (components) & C. However this is not ideal as every time C changes, so will X. Potentially repeating the process should converge on a stable solution for X and C eventually, but the hope with modifying the link function was that this could all be done in one step.   For 2) as X is not a single variable, but a combination of variables derived in the regression I don't believe is is possible to ask it to derive an overall spline applied on top of individual variables with their weights also being derived at the same time? (similar issue to 1))   3) Is very interesting, I've not come across the NLIN procedure, the example of probit binomial regression in the documentation suggests it might do the job. I notice the overview recommends other procedures for maximum likelihood estimations, but I assume that's just because they are easier to use for the majority of applications, whereas PROC NLIN is more complex but offers much more flexibility? But I think this holds the most potential for achieving everything I am trying to do in a single step procedure. I will see where I can get with it thank you. ... View more

Thanks, I think those were the rules I was searching for (and half suspected along with some others).   My aim is to change the shape of the logistic s-curve substantially. I am in a situation where most modelling volume occurs in the 'low probability' region of ~<=10%, where the relative impact of predictors is a constant ~2.7x for every '1' movement in logistic space (illustrated below).    My concerns are twofold: 1) That that constant 2.7x relative relationship may not be appropriate for my data, I can't see any reason this should be constant across my data range and would like to vary it. 2) Using models built on the <10% probability space to predict higher probabilities seems inappropriate (ignoring the extra issues of using models outside of observed data), as the modelled relationships entirely change how they are applied above this point (hence my attempt to use the exp function capped at 1, which would at least have a constant 2.7x relationship across the full range of probabilities.)   Given the rules you have suggested I think I can iteratively modify the logit curve to determine if shape adjustments lead to improved fitting. ... View more