similar to: Double complex with gcc and Intel v9 Fortran (PR#8699)

Recently I reviewed my RPM spec files for DU 4.0, and noticed that I forgot to post some problems + patches: 1. ./configure fails to choose a PIC flag, I simply removed the AC_MSG_ERROR and it works. There is actually no PIC flag for DEC cc (with DU 4.0E) --- ./configure.in.alpha-patch Mon Aug 23 06:36:28 1999 +++ ./configure.in Sun Sep 12 17:38:27 1999 @@ -541,7 +541,9 @@

Hello, I had to set CPPFLAGS and FC=fort77 but configure saw atlas and used it instead of blas. However atlas for hp seems to missing some libs. I had to add -lblas in Makeconf. Everything builds ok. But modreg and tcltk doesn't load. R : Copyright 2000, The R Development Core Team Version 1.2.0 Under development (unstable) (2000-August-9) R is free software and comes with ABSOLUTELY NO

Here are a few comments on the new release (1.2.0), most about R CMD check. I have managed to install and check my libraries only making one change to a C function (see point 1) and one to an R function because of the way formulae now look for their data. That is the good news. Of course, more extensive checks are liable to find further problems. 1. I need to be able to define F77_SYMBOL. This

Hi, I am searching for a way to solve the following problem: I want to use an external function, defined in a dyn.load()ed shared object, in another dyn.load()ed shared object. Currently I have to take the sources (Fortran) from one libraries src/ directory and copy them into the src/ dir of the other library, resulting in two copies of this function. This is bad for maintanance and maybe also

At present the documentation for nlm refers the reader to Dennis and Schnabel for details on the algorithms. It also states that the function is liable to change. Can anyone tell me if the current version of nlm uses only function values or if it can use gradients and Hessians when they are available? I would like to get an idea of how difficult it would be to port the development versions of

> On 22 Mar 2019, at 18:07 , Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > gives (on Linux R 3.5.3, Fedora 28) > > d=10 d=7 d=2 d=1 d=0 > [1,] "123456" "123456" "123456" "1e+05" "%#4.0-1e" > [2,] "12345.6" "12345.6" "12346"

While implementing R's new 'altrep' functionality in the TERR engine, I discovered a bug in R's 'deferred_string' altrep object: it is not using the correct value of the 'OutDec' option when it expands a deferred_string. See the following example: R 3.5.1: (same results in R 3.6.0 devel engine built 10/5) > options(scipen=0, OutDec=".") >

On 4/3/23 14:07, Michael Milton wrote: > Hi all, > > There seems to have been a breaking change in the R trunk caused by a fix > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that > relates to the layout of the Rcomplex typedef. Previously it was a struct, > but now it's a union by default >

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition

Hello, I am trying to call the BLAS Level1 function zdotc from R via a .C call like this: #include "R.h" #include "R_ext/BLAS.h" void testzdotc() { Rcomplex zx[3], zy[3], ret_val; zx[0].r = 1.0; zx[0].i = 0.0; zx[1].r = 2.0; zx[0].i = 0.0; zx[2].r = 3.0; zx[0].i = 0.0; zy[0].r = 1.0; zy[0].i = 0.0; zy[1].r = 2.0; zy[0].i = 0.0; zy[2].r = 3.0;

Hi Tomas, Thanks for this explanation. As you can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are right that this error is confused by bindgen's inability to handle anonymous types, but

o `Rcomplex' is preferred to `complex' (a future reserved word in C) for R complex objects passed to C. I'm a bit confused here. Is "complex" or "Rcomplex" the future reserved word in C (I thought "complex" already was, but I'm not a C programmer) and is this because R storage modes should or should not have names corresponding to C reserved

Full_Name: Alessandro Usseglio V. Version: 1.5.0 OS: Linux RH 7.1 Submission from: (NULL) (130.60.71.55) Error during configure $ ./configure [...] checking for an ANSI C-conforming const... yes checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking for long double... yes

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here since that would break the C API. Can I ask, would it make sense for us to hard code

Hola compañeros de la lista. Tengo el siguiente set de datos: Repeticiones <- c(rep("RI", 14), rep("RII", 14), rep("RIII", 14)) Tiempo <- rep(c(0, 2, 4, 6, 8, 10, 12, 24, 36, 48, 60, 72, 96, 120), 3) Concentracion_celular <- c(0.4862, 0.5375, 0.4309, 0.4390, 0.4603, 0.4733, 0.3936, 0.9085, 0.5838, 0.5477, 0.6331, 0.8693, 1.0092, 0.6341, 0.5350,

Full_Name: Peter Fortini Version: 2.0.1 OS: Windows 2000 Submission from: (NULL) (65.246.187.164) When the imaginary part of the argument is very large, the complex tangent function returns 0+NaNi. For example, tan(1+1000i)=0+NaNi; it should be 0+1i Easy to fix in complex.c, as the original NaN came from division of sinh and cosh that had reached machine infinity. static void z_tan(Rcomplex

Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by default

Hi, I am trying to compile R as a shared library (need to run RMAGEML, which depends on SJava) on 64bit SUSE Linux 9.1 . I am using the source code for R 2.0.1 (Nov 15 04) > ./configure R_PAPERSIZE=LETTER R_BROWSER=/opt/kde3/share/applications/kde/konqbrowser.desktop --enable-R-shlib results in several errors (selected errors below), and make check also yields errors (at bottom) The errors

Can anyone spot the problem here. Following is an edited script of the install session. The gist is: * syntax error in original src/main/dotcode.c Easily remedied (or at least, such that compiles without error message ... ) change line 449-450 (two lines preceding return) #ifdef HAVE_F77_UNDERSCORE if(PRIMVAL(op)) { *q++ = '_'; *q = '\0'; #endif }

I'm probably misunderstanding something in "Writing R Extensions" version 1.0.0. In the chapter on the R API, section 4.7, it is stated that the functions listed in R_ext/Linpack.h are available to users' Fortran code. I am developing a developing a library of ode solvers, based on lsoda and ddassl, and which in turn call some routines from linpack and double precision blas. I