search for: prettys

Hi every body our Calls are begging dropped for no reason and it starts with the sound quality dropping and then the caller unable to hear our call center agents. Then the call drops or the caller hangs up unable to hear. I could see following lines inside full log ---------------------------------------------------------------------------------- [Jan 20 15:21:35] DEBUG[14982] audiohook.c:

Hi, Some time ago I asked about how to use comma as decimal separator in plots and Mr. Paul Murrell wrote: ------- You could try something with axis() and chartr(), like ... par(mfrow=c(2,1)) plot(1:10/11, rep(1, 10), main="Standard X-Axis") plot(1:10/11, rep(1, 10), main="Customised X-Axis", axes=F) axis(1, at=pretty(1:10/11),

Hi, I have a following vector: > smallch [1] 0.0652840 0.1181300 0.0319370 0.0155700 0.0464110 0.0107850 [7] 0.0158970 0.0375900 0.0603090 0.0310300 0.0105920 0.0540580 [13] -0.0177740 0.0039393 Pretty (R 1.5.1) has problems with zero: > pretty(smallch) [1] -2.000000e-02 -3.469447e-18 2.000000e-02 4.000000e-02 6.000000e-02 [6] 8.000000e-02 1.000000e-01 1.200000e-01

Hi, I have a following vector: > smallch [1] 0.0652840 0.1181300 0.0319370 0.0155700 0.0464110 0.0107850 [7] 0.0158970 0.0375900 0.0603090 0.0310300 0.0105920 0.0540580 [13] -0.0177740 0.0039393 Pretty (R 1.5.1) has problems with zero: > pretty(smallch) [1] -2.000000e-02 -3.469447e-18 2.000000e-02 4.000000e-02 6.000000e-02 [6] 8.000000e-02 1.000000e-01 1.200000e-01

When I issue the command: if ( c(2.8,3)[1] < pretty (c(2.8,3))[1]) print ("problem") the result is "problem" prints. I have traced it to bits and the 2.8 of the returned vector from pretty is slightly larger. This seems to be due to the conversion to base 10 with the ns and unit variables in src/appl/pretty.c. Anyway if I do something like: hist(c(2.8,3)) it fails as well

I have written a set of functions for POSIXt objects that I would like to offer for consideration for use in base R. They augment and extend existing functions. Briefly, ## pretty.ct function(x,specs=pretty.ct.specs) ## round.ct function(x, tstr='1 min' ) ## axis.ct function(side,x,specs=NULL,...) ## parse.timeint function(dv) ## parse.tstr

Examples similar to pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) with smaller 'n': pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 -------------------------------------------- On Tue,

I've added a few LLVM GDB pretty printers a while back (& just added llvm::Optional earlier today) & thought people might be interested in how to use them, etc. I use them by adding the following to my .gdbinit: source /path/to/llvm/src/utils/gdb-scripts/prettyprinters.py Also, I can suggest adding: set print pretty on there too, it helps a lot when printing complex nested

Yes, they work now. I mentioned them partly because the commit description said overflow for large n and partly to be considered for regression tests. -------------------------------------------- On Sat, 19/8/17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c Cc: r-devel at r-project.org Date: Saturday, 19 August, 2017,

Dear all, I got stuck with a weird behavior of pretty: pretty(c(-1,1),n=1) yields -2, 0, 2 instead of the desired result -1 1. Likewise, pretty(c(-2,2),n=1) yields -5, 0, 5 instead of the desired result -2 2. With n=0, the result is the same, while with n=2 everything is as documented. This behavior nastily messed up some of my cube plots. Is there any chance that this can be fixed?

Hello everybody, This is a bug involving functions in core R package: graphics::hist.default, grDevices::nclass.FD, and base::pretty.default. It is not yet on Bugzilla. I cannot submit it myself, as I do not have an account. Could somebody else add it for me, perhaps? That would be much appreciated. Kind regards, Sietse Sietse Brouwer Summary ------- Floating point errors can cause a data

Added some basic DenseMap support in r290011 On Fri, Dec 16, 2016 at 2:05 PM David Blaikie <dblaikie at gmail.com> wrote: > I've added a few LLVM GDB pretty printers a while back (& just added > llvm::Optional earlier today) & thought people might be interested in how > to use them, etc. > > I use them by adding the following to my .gdbinit: > > source

In current versions of R, pretty(333) gives an infinite loop (due to a silent integer overflow in src/appl/pretty.c). I've looked at this problem and also at what S-plus does, (no code there to inspect, just experiments), and then I have fixed pretty.c. I think that it now behaves much more reasonably (both than before and than S / S-plus). The only problem: pretty(.) is not

Hello, I am trying to port one of my plotting S+ functions to R and I am having difficulties!!! I am including here only the troublesome code! I first produce a barplot, saving the positions of the bar's centers. par(mar = c(6.1, 5.1, 4.1, 4.1), mgp = c(3, 3.0, 0)) ticks.loc <- barplot(sum.of.weights, col = 5, xlab = "", ylab = "", axes =

patch against recent SVN ... as far as I can tell this trivial typo has been there for 20 years: https://github.com/wch/r-source/blame/ba7920a99fb2fb62b89e404e65f8b132ed4c150a/src/library/base/man/pretty.Rd =================================================================== --- pretty.Rd (revision 74426) +++ pretty.Rd (working copy) @@ -21,8 +21,8 @@ \item{min.n}{nonnegative integer giving

Hello list, what does this mean in the debug-log : [Jan 19 15:11:04] DEBUG[1475] audiohook.c: Write factory 0x153cf678 was pretty quick last time, waiting for them. [Jan 19 15:11:04] DEBUG[1701] audiohook.c: Read factory 0x14fe5ef0 was pretty quick last time, waiting for them. [Jan 19 15:11:04] DEBUG[1475] audiohook.c: Read factory 0x153cec40 and write factory 0x153cf678 both fail to provide

Excellent. I think it would make sense to add small section somewhere in documentation (e.g. LLVM Programmer’s Manual <http://llvm.org/docs/ProgrammersManual.html>) about it, so it won't be lost somewhere in the mailing list. Piotr 2016-12-17 1:04 GMT+01:00 David Blaikie via llvm-dev < llvm-dev at lists.llvm.org>: > Added some basic DenseMap support in r290011 > > On

Good point - any ideas on where in the programmer's manual would suit best? Looking around I sort of feel like it belongs in the "Picking the right data structure" section - but I fear someone merely examining existing data structures might not think to look there for help in their task (if they have no need to 'pick' a data structure for a new use, etc). On Mon, Dec 19,

Hi, I am having a difficulty with getting two realtime user?s to bridge on answer. I have managed successfully to bridge the same two users/channels via the Bridge Manager api command and confirm that the two communicate directly bypassing the asterisk server (I confirmed this with Wireshark). Does anyone have some ideas? I have put some log entries below. I haven?t attached my

See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. That pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . *lo is