Skip to content
Snippets Groups Projects

Kernel/LHCbMath: add Bernstein3D and Positive3D

Merged Vanya Belyaev requested to merge vanya-lhcbmath-3D-v0 into 2017-patches

Kernel/LHCbMath:

  • add generic 3D-polynomial Bernstein3D
  • add positive 3D-polynomial Positive3D
Edited by Marco Cattaneo

Merge request reports

Checking pipeline status.

Approval is optional

Merged by avatar (Mar 15, 2025 10:55pm UTC)

Merge details

  • Changes merged into 2017-patches with 67ab47fe.
  • Deleted the source branch.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Marco Cattaneo
  • Marco Cattaneo
  • Author Developer

    Hi Marco, @cattanem

    1. all member variable are prefixed with m_
    2. it is not initialization. It is a single declaration of several constructor with different combination of default arguments. If I initialize members as you suggest, I will need to duplicate (actually multiplicate) constructors, that is not nice at all
  • Hello @ibelyaev

    1. Yes, I fixed my comment when I saw this...
    2. Agreed for the constructor, but that does not prevent to initialise the member variables anyway, on lines 2178 to 2106?
  • Marco Cattaneo resolved all discussions

    resolved all discussions

  • Marco Cattaneo resolved all discussions

    resolved all discussions

  • Marco Cattaneo changed title from Kernel/LHCbMath: to Kernel/LHCbMath: add Bernstein3D and Positive3D

    changed title from Kernel/LHCbMath: to Kernel/LHCbMath: add Bernstein3D and Positive3D

  • Marco Cattaneo changed the description

    changed the description

  • Marco Cattaneo mentioned in commit 67ab47fe

    mentioned in commit 67ab47fe

  • Marco Cattaneo mentioned in merge request !955 (closed)

    mentioned in merge request !955 (closed)

  • @ibelyaev When trying to merge this to master, I get several conflicts (same file modified in both master and 2017-patches), like this:

    ++<<<<<<< HEAD
     +  double result = 0 ;
     +  for  ( unsigned short ix = 0 ; ix <= m_nx ; ++ix )
     +  {
     +    for  ( unsigned short iy = 0 ; iy <= m_ny ; ++iy )
     +    { result += par ( ix , iy ) * fx[ix] * fy[iy] ; }
     +    //
     +  }
     +  //
     +  const double scalex = ( m_nx + 1 ) / ( xmax() - xmin() ) ;
     +  const double scaley = ( m_ny + 1 ) / ( ymax() - ymin() ) ;
     +  //
     +  return result * ( scalex * scaley ) ;
    ++=======
    +   return calculate (  fx , fy ) ;
    ++>>>>>>> 2017-patches

    Which should I keep?

  • Author Developer

    keep the latest (2017-patches)

  • Author Developer

    @cattanem can we discuss the issues in person? I am a bit confused. If we propagate full file from 2017-patched to master, we'll lose a lot of very useful functionality :-(

  • Marco Cattaneo mentioned in merge request !956 (merged)

    mentioned in merge request !956 (merged)

  • @ibelyaev We don't propagate the full file, only the diffs. We get a merge conflict if the file has changed in both branches since the branches were split. See !956 (merged)

  • Marco Cattaneo mentioned in commit 71252585

    mentioned in commit 71252585

  • Marco Cattaneo mentioned in commit c2cf6992

    mentioned in commit c2cf6992

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading