Force increment step in parameter

I'm guessing that the libId and cellId are for a different cell, which is why you're doing it this way rather than using get(cdfgData param2)? 

I did realise that actually it's bad practice for me to have suggested using get() for this. The right way is cdfFindParamByName(cdfgData get_string(param1))->value . A bit longer, but this will still work if your CDF parameter name happens to be one of a number of "reserved" slots on the CDF object (e.g. a parameter called "id", amongst others).

Similarly, your dep variable could be found:

dep=cdfFindParamByName(cdfGetBaseCellCDF(ddGetObj(libID cellID)) get_string(param2))->value

rather than looping over all of them yourself.

Now onto the case(). Two problems - one is that the target values in a case statement have to be literal values, not expressions. In other words, it will not evaluate the target values and so it will in fact be trying to check if the value is either the symbol min, or the list (max dep lower). Which it won't be, which is why it doesn't work. 

Instead, you could use cond:

value=cond(
  (dep==min(max(dep lower)) ... value1)
  (dep==min(max(dep yy.yyy)) ... value2)
  (...)
)

cond is like a nested if-then-elseif-elseif-else type structure.

Note however that you should be rather cautious about using == type checks on floating point numbers if there is any chance that the floating point number might suffer from rounding errors. There are a number of solutions and posts on this before, but floating point numbers in SKILL (and C, and Java, and Python and Perl and Tcl for that matter) are represented with IEEE floating point representation, which can suffer from rounding errors even with a 52 bit mantissa (in the same way that 1/3 can't be represented exactly in decimal, 1/10 can't be represented exactly in binary). So it's generally dangerous to do equality checks on floating point numbers - instead one usually does things like abs(value1-value2)<smallNumber to check if value1 and value2 are effectively equal.

So your condition may want to change a bit.

Regards,

Andrew.

I'm guessing that the libId and cellId are for a different cell, which is why you're doing it this way rather than using get(cdfgData param2)? 

I did realise that actually it's bad practice for me to have suggested using get() for this. The right way is cdfFindParamByName(cdfgData get_string(param1))->value . A bit longer, but this will still work if your CDF parameter name happens to be one of a number of "reserved" slots on the CDF object (e.g. a parameter called "id", amongst others).

Similarly, your dep variable could be found:

dep=cdfFindParamByName(cdfGetBaseCellCDF(ddGetObj(libID cellID)) get_string(param2))->value

rather than looping over all of them yourself.

Now onto the case(). Two problems - one is that the target values in a case statement have to be literal values, not expressions. In other words, it will not evaluate the target values and so it will in fact be trying to check if the value is either the symbol min, or the list (max dep lower). Which it won't be, which is why it doesn't work. 

Instead, you could use cond:

value=cond(
  (dep==min(max(dep lower)) ... value1)
  (dep==min(max(dep yy.yyy)) ... value2)
  (...)
)

cond is like a nested if-then-elseif-elseif-else type structure.

Note however that you should be rather cautious about using == type checks on floating point numbers if there is any chance that the floating point number might suffer from rounding errors. There are a number of solutions and posts on this before, but floating point numbers in SKILL (and C, and Java, and Python and Perl and Tcl for that matter) are represented with IEEE floating point representation, which can suffer from rounding errors even with a 52 bit mantissa (in the same way that 1/3 can't be represented exactly in decimal, 1/10 can't be represented exactly in binary). So it's generally dangerous to do equality checks on floating point numbers - instead one usually does things like abs(value1-value2)<smallNumber to check if value1 and value2 are effectively equal.

So your condition may want to change a bit.

Regards,

Andrew.