casting problem float <-> double

[cVogl97]

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.

float_conversion_bug_cusp.pdf