Displaying 20 results from an estimated 135 matches for "incoherent".
Did you mean:
coherent
2005 Sep 27
2
Using unsplit - unsplit does not seem to reverse the effect of split
...(=ID). So I do
library(MASS)
OMEsub <- split(OME, OME$ID)
OMEsub <- lapply(OMEsub,function(x)x[1:5,])
unsplit(OMEsub, OME$ID)
- which results in
[[1]]
[1] 1 1 1 1 1
[[2]]
[1] 30 30 30 30 30
[[3]]
[1] low low low low low
Levels: N/A high low
[[4]]
[1] 35 35 40 40 45
[[5]]
[1] coherent incoherent coherent incoherent coherent
Levels: coherent incoherent
[[6]]
[1] 1 4 0 1 2
............
[[1094]]
[1] 4 5 5 5 2
[[1095]]
[1] 100 100 100 100 100
[[1096]]
[1] 18 18 18 18 18
[[1097]]
[1] N/A N/A N/A N/A N/A
Levels: N/A high low
There were 50 or more warnings (use warnings() to see the first...
2020 Feb 19
0
dimnames incoherence?
>>>>> Serguei Sokol
>>>>> on Wed, 19 Feb 2020 15:21:21 +0100 writes:
> Hi,
> I was bitten by a little incoherence in dimnames assignment or may be I
> missed some point.
> Here is the case. If I assign row names via dimnames(a)[[1]], when
> nrow(a)=1 then an error is thrown. But if I do the same when nrow(a) > 1
>
2009 Sep 29
0
Incoherence between arima.sim and auto.arima
Hello,
I have a question about function arima.sim
I tried to somulate a AR(1) process, with no innovation, no error term.
I used this code:
library(forecast)
e=rnorm(100,mean=0,sd=0)
series=arima.sim(model=list(ar=0.75),n=100,innov=e)+20
Then I tried to applicate ti this series auto.arima function:
mod1<-auto.arima(series,stepwise=FALSE,trace=TRUE,ic='aicc')
The best model returned
2009 Mar 23
1
incoherent treatment of NULL
somewhat related to a previous discussion [1] on how 'names<-' would
sometimes modify its argument in place, and sometimes produce a modified
copy without changing the original, here's another example of how it
becomes visible to the user when r makes or doesn't make a copy of an
object:
x = NULL
dput(x)
# NULL
class(x) = 'integer'
# error: invalid
2015 Jul 16
0
4.2.2 as AD with 2 DCs: database incoherency
On 16/07/15 07:19, Daniel Müller wrote:
> On my site with samba 4.18 on centos 6:
>
> 'samba-tool ldapcmp ldap://DC1 ldap://DC2 -Uadministrator' failed with this result msDS-NC Type failed :
>
> [root at s4master ~]# samba-tool ldapcmp ldap://s4master ldap://s4slave -Uadministrator
> Password for [TPLK\administrator]:
>
> * Comparing [DOMAIN] context...
>
2015 Jul 15
0
4.2.2 as AD with 2 DCs: database incoherency
On 15/07/15 14:31, mathias dufresne wrote:
> Hi all,
>
> I'm having a test AD domain composed with 2 DC, using Sernet's version of
> Samba 4.2.2.
>
> These two DC are Centos 6.6 (dc20) and Debian 7.8 (dc00).
>
> These two are using TDB as a backend (as we have no other choice at this
> stage of Samba's development).
>
> *dc20*:~# ldbsearch -H $sam
2015 Jul 16
2
4.2.2 as AD with 2 DCs: database incoherency
Am 16.07.2015 um 14:02 schrieb Rowland Penny:
> /etc/hosts should be:
>
> 127.0.0.1 localhost.localdomain localhost
uhm no - you want 127.0.0.1 normally resolved to localhost and hence
127.0.0.1 localhost localhost.localdomain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
2015 Jul 27
0
4.2.2 as AD with 2 DCs: database incoherency
Thank you Rowland for this.
I tried using Sernet's Samba 4.2.2 and failed:
All the following command were ran on DC20
samba-tool dns zonecreate dc20.ad.domain.tld 0.0.10.in-addr.arpa
Password for [administrator at AD.DOMAIN.TLD]:
Failed to bind to uuid 50abc2a4-574d-40b3-9d66-ee4fd5fba076 for
2020 Feb 19
3
dimnames incoherence?
Hi,
I was bitten by a little incoherence in dimnames assignment or may be I
missed some point.
Here is the case. If I assign row names via dimnames(a)[[1]], when
nrow(a)=1 then an error is thrown. But if I do the same when nrow(a) > 1
it's OK. Is one of this case works unexpectedly? Both? Neither?
a=as.matrix(1)
dimnames(a)[[1]]="a" # error: 'dimnames' must be a list
2015 Jul 15
2
4.2.2 as AD with 2 DCs: database incoherency
Hi all,
I'm having a test AD domain composed with 2 DC, using Sernet's version of
Samba 4.2.2.
These two DC are Centos 6.6 (dc20) and Debian 7.8 (dc00).
These two are using TDB as a backend (as we have no other choice at this
stage of Samba's development).
*dc20*:~# ldbsearch -H $sam '(objectclass=group)' dn | tail -3
# returned 27392 records
# *27389* entries
# 3 referrals
2020 Feb 21
0
dimnames incoherence?
If we change the behavior NULL--[[--assignment from
`[[<-`(NULL, 1, "a" ) # gives "a" (*not* a list)
to
`[[<-`(NULL, 1, "a" ) # gives list("a")
then we have more consistency there *and* your bug is fixed too.
Of course, in other situations back-compatibility would be
broken as well.
Would that change the result of
L <-
2020 Feb 22
0
Change 77844 breaking pkgs [Re: dimnames incoherence?]
>>>>> Martin Maechler
>>>>> on Sat, 22 Feb 2020 20:20:49 +0100 writes:
>>>>> William Dunlap
>>>>> on Fri, 21 Feb 2020 14:05:49 -0800 writes:
>> If we change the behavior NULL--[[--assignment from
>> `[[<-`(NULL, 1, "a" ) # gives "a" (*not* a list)
>> to
>>
2015 Jul 16
0
4.2.2 as AD with 2 DCs: database incoherency
On 16/07/15 12:20, mathias dufresne wrote:
> Here I obtained:
> ---------------------
> * Comparing [DOMAIN] context...
> Failed search of base=DC=ad,DC=domain,DC=tld
> ERROR(ldb): uncaught exception - LDAP client internal error:
> NT_STATUS_UNEXPECTED_NETWORK_ERROR
> File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line
> 175, in _run
>
2005 Jul 29
0
incoherent oplock request/reply
Hello,
I'm running a samba 3.0.14a server in production on a fedora core 3 (kernel
2.6.9-1.667smp) with a least 250 clients (XP Pro SP2) (up to 400 sometimes).
A few days ago, a problem appeared with a soft that we are using for a long
time. (Petit Robert, a french dictionnary).
When someone launch the dictionnary, many clients are freezed when they try to
access to the "start
2006 Oct 19
2
problem with queries
...o ferret 0.10.10 and I noticed a strange behaviour with queries.
Now the queries return strange results. For example, the two following
queries return the same results:
familynames|firstnames:andre
familynames|firstnames:andr
Another example, the first query returns a correct result + incoherent
results, the second query returns only the correct result:
(familynames|firstnames:baus)
(familynames|firstnames:baus*)
Could you help me please?
Thank you
Johan
2015 Jul 23
0
4.2.2 as AD with 2 DCs: database incoherency
Hi all,
I tried "samba-tool ldapcmp" several times to solve this issue, without
success.
On DC acting as full FSMO:
dc20:~# samba-tool ldapcmp ldap://dc00.ad.dgfip.lan
ldap://dc20.ad.dgfip.lan domain
ERROR(ldb): uncaught exception - ldb_wait: Time limit exceeded (3)
File "/usr/lib64/python2.6/site-packages/samba/netcmd/__init__.py", line
175, in _run
return
2016 Jan 04
2
[PATCH v2 20/32] metag: define __smp_xxx
On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> +#ifdef CONFIG_SMP
> +#define fence() metag_fence()
> +#else
> +#define fence() do { } while (0)
> #endif
James, it strikes me as odd that fence() is a no-op instead of a
barrier() for UP, can you verify/explain?
2016 Jan 04
2
[PATCH v2 20/32] metag: define __smp_xxx
On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> +#ifdef CONFIG_SMP
> +#define fence() metag_fence()
> +#else
> +#define fence() do { } while (0)
> #endif
James, it strikes me as odd that fence() is a no-op instead of a
barrier() for UP, can you verify/explain?
2016 Jan 04
1
[PATCH v2 20/32] metag: define __smp_xxx
...s) whenever a write is performed, and by
smp_mb/smp_rmb to try to catch other cases, but I've never been
confident this fixes every single corner case, since there could be
other places where multiple CPUs perform unsynchronised writes to the
same memory location, and expect cache not to become incoherent at that
location.
It seemed to be sufficient to achieve stability however, and SMP on Meta
Linux never made it into a product anyway, since the other hw thread
tended to be used for RTOS stuff, so it didn't seem worth extending the
generic barrier API for it.
Cheers
James
-------------- next...
2009 Mar 18
2
incoherent conversions from/to raw
i wonder about the following examples showing incoherence in how type
conversions are done in r:
x = TRUE
x[2] = as.raw(1)
# Error in x[2] = as.raw(1) :
# incompatible types (from raw to logical) in subassignment type fix
it seems that there is an attempt to coerce the raw value to logical
here, which fails, even though
as.logical(as.raw(1))
# TRUE
likewise,
x[2]