casting problem float <-> double #106
Description
The LEGEND ICPC DSP config json file contains processors which take arguments where the data type has to be specified. Two examples are tail_pars and wf_cusp:
"tail_pars": {
"description": "finds ",
"function": "poly_fit",
"module": "dspeed.processors",
"args": [
"wf_logged[round(60*us, wf_logged.period):]",
"tail_pars(5, 'f')"
],
"init_args": ["len(wf_logged[round(60*us, wf_logged.period):])", "4"],
"unit": "ADC"
},
"wf_cusp": {
"description": "convolve optimised cusp filter",
"function": "convolve_wf",
"module": "dspeed.processors",
"args": [
"wf_blsub[:round(len(wf_blsub)-(33.6*us/wf_blsub.period))]",
"cusp_kernel",
"'v'",
"wf_cusp(round((4.8*us/wf_blsub.period)+2), 'f')"
],
"unit": "ADC"
},The relevant lines are tail_pars(5, 'f') and wf_cusp(round((4.8*us/wf_blsub.period)+2), 'f'). In both cases, the 'f' signifies the data type of the array elements to be float. Using the processors like this does not work universally on all machines. Both build_dsp() and run_one_dsp() return exclusively arrays which are full of zeros for tail_pars and wf_cusp, when running on a local server at TUM.
Using the processors manually via from dspeed.processors import poly_fit, etc. works just fine. The issue only arises when a DSP config is used. I created a jupyter notebook to showcase this problem and attached it here (I cannot upload HTML to GitHub).
Hotfix: If you have a similar problem, the "solution" is to use double as the datatype, i.e. changing the 'f' to a 'd' in both cases above.
Goal: Make dspeed robust(er) against type conversion.