Re: [Quantlib-dev] Possible sub-project for calendaring ?

[Luigi B. <lui...@gm...>]

Hello Dirk,
    I must say, seeing you take on project after project gives me hope that
I'll have some more time when the kids are all grown up :)

Luigi



On Fri, Oct 29, 2021 at 3:46 PM Dirk Eddelbuettel <ed...@de...> wrote:

>
> Hi Francois,
>
> On 29 October 2021 at 14:53, Francois Botha wrote:
> | Thanks for this. I think this is a great idea. In fact, in-house I built
> | something similar in C# based on a subset of the classes in QLNet.
>
> Nice to know too!
>
> | Is your idea that QuantLib links to this "QLCal" project? I'm  just
>
> Link as in code, or link as in http URL on website?
>
> QuantLib is also of course the 'mothership' and retains all code. I am
> simply
> thinking it may be useful to have a (clearly related) 'derivative' project.
>
> I would suggest that the code bases remain separate for simplicity, at
> least
> initially, but 'not too separate' as we saw with Quantuccia that updates
> may
> not happen if they take effort.  'QlCal' as it presently stands is just my
> (current) RcppQuantuccia snapshot which has copies. As just how I have
> updated the Debian build of QuantLib (and whatever changes RQuantLib
> needed)
> for twenty years now, I can similarly refresh the copies of QuantLib
> calendaring code in this new project to keep it current.
>
> But I figured I should bring it up here as QuantLib-at-large has ownership
> of
> these files (just like you do for Botswana.{cpp,hpp}) and might want to be
> involved.  One other idea I had is to maybe try in QlCal to remove the
> Boost
> dependency further. (I looked into `bcp` and find the minimal set of Boost
> headers to create a truly dependency-free source tar.gz, it is still too
> much.)  Using Hinnant's Date class instead of Boost's may be an idea too.
>
> | wondering about the maintenance of public holiday rules and especially ad
> | hoc public holidays (like 1 Nov 2021 was recently declared a special
> public
> | holiday for election/voting purposes). If both projects have to be
> | maintained separately there is of course a risk that they diverge, which
> | could cause some confusion among users.
>
> That is precisely why I rebooted this. I will try to keep it current on an
> ongoing basis, at least in RcppQuantuccia and possibly in extensions. If I
> find time I will produce a small standalone executable one could call from
> scripts and pipelines.  It sounds like you have something you could base on
> this if we went the Swig route for interfaces (or created a C language FFI
> around the C++ layer for easier C-level FFI).
>
> So in short, I just tossed a flare in the sky ("hey, I did this") and I am
> glad to hear from you about both a similar, local initiative ("hey, I am
> not
> crazy, there is demand") and the reply.  So let's talk and see if there is
> something to be done together.  I mostly wanted folks to be aware and have
> the option of being involved.
>
> Dirk
>
>
> | thanks
> | Francois Botha
> |
> |
> | On Tue, 26 Oct 2021 at 21:39, Dirk Eddelbuettel <ed...@de...> wrote:
> |
> | >
> | > So a few years ago Peter had this nice idea and trial balloon of
> | > Quantuccia.
> | > I jumped on it as the 20 years (!!!) with RQuantLib have clearly shown
> that
> | > expecting systems to have the QuantLib library installed is (still) a
> | > hurdle.
> | > Quantuccia overcame that by being header-only and depending only on
> | > header-only Boost. Very nice indeed. So I built RcppQuantuccia around
> it.
> | >
> | > But copies are of course extra effort to maintain, especially when you
> have
> | > to do a slight modification in each file (in essence: concat hpp and
> cpp
> | > into
> | > one hpp, prefix each function with inline; a tool _could_ do this). So
> my
> | > RcppQuantuccia got stale as Quantuccia got stale.
> | >
> | > The recent QuantLib 1.24 updates, new (US) calendaring, and user
> requests
> | > for
> | > extra calendars (that I was not yet exporting) made me take another
> look.
> | > And
> | > consequently I did a few small things over a couple of days:
> | >
> | >  - update Quantuccia to QuantLib 1.24, but also remove everything from
> | >    Quantuccia that was not used in RcppQuantuccia
> | >  - undo the header-only internal design for the R package and just
> list the
> | >    two or three dozen files explicitly as a Make dependency
> | >  - effectively I created a 'QuantLib Calendaring' sublibrary
> | >
> | > This now exists, and is current to 1.24.
> | >
> | > And I think that this has merit, possibly beyond RcppQuantuccia.  The
> | > current
> | > master branch of github.com/eddelbuettel/rcppquantuccia contains it,
> take
> | > a
> | > look.  I needed to make minimal changes to a few files I need to
> document,
> | > in
> | > essence a) comment out the #pragam statements as CRAN will not let use
> them
> | > and b) include the errrors.hpp header in a handful of files.
> | >
> | > So five paragraphs in, here is my question: Would anybody else be
> | > interested
> | > in a 'QuantLib Calender Lite' library?
> | >
> | > One could possibly wrap Python bindings around (though I am unsure
> what to
> | > do
> | > about Boost header and Python), and/or use Swig, and I think it may
> make
> | > sense to turn this into a small standalone cmdline app al
> | >
> | >     qlcal holidays --calendar UnitedStates --from 2021-10-01 --to
> | > 2021-10-31
> | >
> | > I poked a little at GitHub and qlcal was open to I 'parked this' as an
> org
> | > if
> | > we wanted to put it there.
> | >
> | > Thoughts? Anybody else up for this?
> | >
> | > Dirk
> | >
> | > --
> | > https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
> | >
> | >
> | > _______________________________________________
> | > QuantLib-dev mailing list
> | > Qua...@li...
> | > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> | >
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | ed...@de...
>
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>