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

[Dirk E. <ed...@de...>]

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...