JuliaPhysics / JuliaPhysics/SolidStateDetectors.jl
Type instability in Torus constructor
- Dominant language
- Julia
- Stars
- 178
- Forks
- 59
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 4
Description
This came up in #285.
The construction of a Torus is not entirely type stable as some parametric types of `Torus`
depend on the values and not the types of the input arguments to the constructor:
```julia
@inferred CSG.Torus{Float64}(φ=π,θ=(π,2π)) # -> error
```
The parametric types which cause the issue are `TT1` and `TT2` of the Torus: https://github.com/SebastianRuffert/SolidStateDetectors.jl/blob/de2af27789cf8883f74ad0599acc60fc11aadd9a/src/ConstructiveSolidGeometry/VolumePrimitives/Torus.jl#L69.
These define the types of two surfaces of the Torus. If we just remove `TT1` and `TT2` from the `Torus` we would shift the type instability into the function `surfaces(t::Torus)`.
I think the best solution would be if we would came up with a way to remove the `:inwards` and `:outwards` parametric types of (all) surface primitives. Maybe by defining some field to those structs which only hold `+1` or `-1` in order to define the direction of surfaces like for the `ConeMantle` or `TorusMantle`.
However, we would still have the issue of the `:flat` case for the `Torus`.
Here, one (or two) of the surfaces of the `Torus` become not a `ConeMantle` but an
`EllipticalSurface`: see `TorusThetaSurface`.
We would need to come up with a way to define these "flat" surfaces still as `ConeMantle`. In its current implementation of `ConeMantle`, this is not possible as `hZ` would be `0`.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.