<div dir="ltr"><div><div><div><div><div><br></div>So PoleZeroType (used in PolesZerosType) has a "number" attribute.<br><br>NumeratorCoefficient in FIRType has a "i" attribute, presumably for the same indexing purpose.<br>
<br></div>CoefficientType, which is very similar to FIRType in actual usage (ie a FIR is a like a Coefficient with no denominators) has Numerator as a FloatType, which does not have an indexing attribute .<br><br></div><div>
ResponseListType which has ResponseListElementTypes, also has no indexing attribute.<br><br></div>PolynomialType has Coefficient as FloatNoUnitType but does have a "number" indexing attribute.<br><br></div><div>
Other things besides subtypes of ResponseStageType are indexed as well, like the actual ResponseStageType, indexed with a "number" attribute and Comment indexed with a "id" attribute.<br></div><div><br>
</div><div>In actual usage from the iris fdsnws/station, it appears to me that only poles and zeros actually make use of the indexing attribute. Not clear why order would be more important for poles/zeros as opposed to the other types. In fact I think order does not matter mathematically for poles and zeros (multiplication is commutative), but it does matter very much for coefficients of a polynomial!<br>
</div><div><br></div>Is there any rhyme or reason as to when indexing attributes are used? If indexing of poles, zeros, coefficients, numerators and denominators seem to me like they should all be the same, either available for all or not available for all. And if they are there, they should use the same attribute name as the index.<br>
<br></div><div>Another question is why FIRType would use a basic double, while CoefficientType makes use of FloatType when they are basically the same type of information.<br><br></div>thanks<br>Philip<br></div>