Re: [Rd] string concatenation operator (revisited)

[Bob Rudis]

FWIW {stringi} has %+% for this functionality (and I occasionally use
it), tho I do enough processing of quite ughly string content that I
pretty much always have {stringi} loaded. That may not be true for
many other folks.

On Fri, Dec 10, 2021 at 2:07 PM Grant McDermott  wrote:
>
> Sorry I haven't had a chance to reply to anyone. I feel like I dropped a 
> grenade in a room and promptly bolted...
>
> Just to say, then, that I really appreciate everyone's comments and 
> suggestions. While I'm tempted to push back on some points, I don't think 
> it's worth on balance, or will add much beyond what's already been said.
>
> It's interesting to see that there appears to be at least some appetite for 
> additional (f)string operators in base R... notwithstanding the valid 
> objections and the difficulties raised in this thread.
>
> Cheers,
> Grant
>
> Get Outlook for Android
> 
> From: Grant McDermott
> Sent: Saturday, December 4, 2021 12:36:44 PM
> To: r-devel@r-project.org 
> Subject: string concatenation operator (revisited)
>
> Hi all,
>
> I wonder if the R Core team might reconsider an old feature request, as 
> detailed in this 2005 thread: 
> https://stat.ethz.ch/pipermail/r-help/2005-February/thread.html#66698
>
> The TL;DR version is base R support for a `+.character` method. This would 
> essentially provide a shortcut to `paste0`, in much the same way that `\(x)` 
> now provides a shortcut to `function(x)`.
>
> > a = "hello "; b = "world"
> > a + b
> > [1] "hello world"
>
> I appreciate some of the original concerns raised against a native "string1 + 
> string2" implementation. The above thread also provides several 
> use-at-your-own-risk workarounds. But sixteen years is a long time in 
> software development and R now stands as something of an exception on this 
> score. Python, Julia, Stata, and SQL (among various others) all support 
> native string concatenation/interpolation using binary/arithmetic operators. 
> It's been a surprising source of frustration for students in some of the 
> classes I teach, particularly those coming from another language.
>
> Many thanks for considering.
>
> PS. I hope I didn't miss any additional discussion of this issue beyond the 
> original 2005 thread. My search efforts didn't turn anything else up, except 
> this popular Stackoverflow question: 
> https://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r
>
> Grant McDermott
> Assistant Professor
> Department of Economics
> University of Oregon
> www.grantmcdermott.com
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Improved LP/MIP solver

[Julian Hall]

Dear All,

I am leading the development of HiGHS, which is now the top performing open 
source linear optimization software on the industry standard benchmarks. In 
particular, our MIP solver out-performs SCIP, and is way ahead of the COIN-OR 
solver Cbc.

HiGHS solves LPs via simplex or interior point, MIPs via branch-and-cut, and 
QPs via an active set method.

We were wondering what interest there would be in developing an R interface to 
HiGHS. I'm not an R user, but have done a bit of searching and see references 
to Rsymphony and an interface to Lpsolve.

Performance-wise Lpsolve is very poor, but I know that it has a community of 
devoted followers. I've not seen benchmark results for Symphony, but I know 
that Cbc is the preferred COIN-OR MIP solver when it comes to general 
performance.  And, as I observed, the performance of HiGHS is way better than 
Cbc.

Are people in the R community tearing their hair out over the performance of 
software requiring the solution of LPs or MIPs?

Would a significantly better LP/MIP solver be valuable to the R community?

Thanks,

Julian
--
Dr. J. A. Julian Hall, Reader, School of Mathematics,
University of Edinburgh, James Clerk Maxwell Building,
Peter Guthrie Tait Road, EDINBURGH, EH9 3FD, UK.
Room: 5418 Phone: [+44](131) 650 5075 Email: 
j.a.j.h...@ed.ac.uk
Web: https://www.maths.ed.ac.uk/school-of-mathematics/people/a-z?person=47
[HiGHS]

My working hours may not be your working hours. Do not feel pressure to reply 
to this email outside your working hours.
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh 
Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improved LP/MIP solver

[Avraham Adler]

On Sun, Dec 12, 2021 at 3:44 PM Julian Hall  wrote:
>
> Dear All,
>
> I am leading the development of HiGHS, which is now the top performing open 
> source linear optimization software on the industry standard benchmarks. In 
> particular, our MIP solver out-performs SCIP, and is way ahead of the COIN-OR 
> solver Cbc.
>
> HiGHS solves LPs via simplex or interior point, MIPs via branch-and-cut, and 
> QPs via an active set method.
>
> We were wondering what interest there would be in developing an R interface 
> to HiGHS. I'm not an R user, but have done a bit of searching and see 
> references to Rsymphony and an interface to Lpsolve.
>
> Performance-wise Lpsolve is very poor, but I know that it has a community of 
> devoted followers. I've not seen benchmark results for Symphony, but I know 
> that Cbc is the preferred COIN-OR MIP solver when it comes to general 
> performance.  And, as I observed, the performance of HiGHS is way better than 
> Cbc.
>
> Are people in the R community tearing their hair out over the performance of 
> software requiring the solution of LPs or MIPs?
>
> Would a significantly better LP/MIP solver be valuable to the R community?
>
> Thanks,
>
> Julian
> --
> Dr. J. A. Julian Hall, Reader, School of Mathematics,
> University of Edinburgh, James Clerk Maxwell Building,
> Peter Guthrie Tait Road, EDINBURGH, EH9 3FD, UK.
> Room: 5418 Phone: [+44](131) 650 5075 Email: 
> j.a.j.h...@ed.ac.uk
> Web: https://www.maths.ed.ac.uk/school-of-mathematics/people/a-z?person=47
> [HiGHS]
>
> My working hours may not be your working hours. Do not feel pressure to reply 
> to this email outside your working hours.
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336. Is e buidheann carthannais a th’ ann an 
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

Hello, Julian.

I cannot speak for the R community, but as someone who needs
optimization on a regular basis, this sounds intriguing. The fact that
HiGHS appears to be FLOSS, and thus usable as-is in the corporate
setting, appeals to those of us who use R in industry. Would you have
any statistics on how the solvers in HiGHS compare with similar ones
currently available in R, specifically the following in NLOPT [1]
(which is called through nloptr): SLSQP (gradient-based) and COBYLA
(gradient-free) both of which support equality and inequality
constraints, and MMA/CCSA (gradient based) which supports inequality
constraints? As for integer or mixed integer programming, I believe
that there is a lot of room for improvement in R. Personally, I've
resorted to using DEOptim with the "fnMap" entry calling a round
function similar to [2]. So speaking for myself, giving richer options
for optimization is a good thing, especially if the installation
procedure can be simplified!

Thank you,

Avi

[1] https://nlopt.readthedocs.io/en/latest/NLopt_Algorithms/
[2] 
https://stackoverflow.com/questions/42197353/how-to-set-integer-constraint-using-fnmap-in-deoptim-r

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improved LP/MIP solver

[Avraham Adler]

On Sun, Dec 12, 2021 at 4:24 PM Avraham Adler  wrote:
>
> On Sun, Dec 12, 2021 at 3:44 PM Julian Hall  wrote:
> >
> > Dear All,
> >
> > I am leading the development of HiGHS, which is now the top performing open 
> > source linear optimization software on the industry standard benchmarks. In 
> > particular, our MIP solver out-performs SCIP, and is way ahead of the 
> > COIN-OR solver Cbc.
> >
> > HiGHS solves LPs via simplex or interior point, MIPs via branch-and-cut, 
> > and QPs via an active set method.
> >
> > We were wondering what interest there would be in developing an R interface 
> > to HiGHS. I'm not an R user, but have done a bit of searching and see 
> > references to Rsymphony and an interface to Lpsolve.
> >
> > Performance-wise Lpsolve is very poor, but I know that it has a community 
> > of devoted followers. I've not seen benchmark results for Symphony, but I 
> > know that Cbc is the preferred COIN-OR MIP solver when it comes to general 
> > performance.  And, as I observed, the performance of HiGHS is way better 
> > than Cbc.
> >
> > Are people in the R community tearing their hair out over the performance 
> > of software requiring the solution of LPs or MIPs?
> >
> > Would a significantly better LP/MIP solver be valuable to the R community?
> >
> > Thanks,
> >
> > Julian
> > --
> > Dr. J. A. Julian Hall, Reader, School of Mathematics,
> > University of Edinburgh, James Clerk Maxwell Building,
> > Peter Guthrie Tait Road, EDINBURGH, EH9 3FD, UK.
> > Room: 5418 Phone: [+44](131) 650 5075 Email: 
> > j.a.j.h...@ed.ac.uk
> > Web: https://www.maths.ed.ac.uk/school-of-mathematics/people/a-z?person=47
> > [HiGHS]
> >
> > My working hours may not be your working hours. Do not feel pressure to 
> > reply to this email outside your working hours.
> > The University of Edinburgh is a charitable body, registered in Scotland, 
> > with registration number SC005336. Is e buidheann carthannais a th’ ann an 
> > Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>
> Hello, Julian.
>
> I cannot speak for the R community, but as someone who needs
> optimization on a regular basis, this sounds intriguing. The fact that
> HiGHS appears to be FLOSS, and thus usable as-is in the corporate
> setting, appeals to those of us who use R in industry. Would you have
> any statistics on how the solvers in HiGHS compare with similar ones
> currently available in R, specifically the following in NLOPT [1]
> (which is called through nloptr): SLSQP (gradient-based) and COBYLA
> (gradient-free) both of which support equality and inequality
> constraints, and MMA/CCSA (gradient based) which supports inequality
> constraints? As for integer or mixed integer programming, I believe
> that there is a lot of room for improvement in R. Personally, I've
> resorted to using DEOptim with the "fnMap" entry calling a round
> function similar to [2]. So speaking for myself, giving richer options
> for optimization is a good thing, especially if the installation
> procedure can be simplified!
>
> Thank you,
>
> Avi
>
> [1] https://nlopt.readthedocs.io/en/latest/NLopt_Algorithms/
> [2] 
> https://stackoverflow.com/questions/42197353/how-to-set-integer-constraint-using-fnmap-in-deoptim-r

Also, to be good R-citizens, this thread should probably be moved to
R-package-devel [1].

Thanks,

Avi

[1] https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel