@OleksandrR. For me, it hangs with an array-length of 2^14

I tried this

ParallelEvaluate[
  LinkWrite[link, ConstantArray[0., 2^14]];
  LinkFlush[link];
  While[! LinkReadyQ[link], Pause[0.1]];
  Print[ToString@ByteCount@LinkRead[link] <> " bytes received"]
  ];

several times and it worked with 2^13 but instantly hung with 2^14.

@OleksandrR. With protocol "TCPIP" it worked until 2^20, where it hung too.

@halirutan thanks a lot. I guess it depends on the system type then, but the same problem appears to affect all platforms.

@OleksandrR. Ah, yes. This was Linux 64bit.

@halirutan I think the actual size threshold probably depends on how fast the computer is as well, and how efficient the interprocess communication is on that platform. I don't think it's a buffer overrun or anything like that, but more likely that the problem just requires both kernels to be sending on the link simultaneously. For small messages one probably finishes before the other starts.

@halirutan I wonder, can this be reproduced with other MathLink programs (Mma and another program, or two other programs)? I'm not sure many people will have even tried simultaneous bidirectional MathLink communications. But it could also be specific to the Mma side of MathLink (e.g. implementation of LinkWrite).

@OleksandrR. Maybe the sending of data could be more synchronized so that a traffic jam will more likely occur.

@halirutan actually, never mind. It even hangs if you do the write first from one kernel, then the other.

@OleksandrR. Uh... you mean simply like making a LinkWrite two times but from different kernels?

The second write hangs. Even if you put LinkFlush[link] after the first.

@OleksandrR. This might be a stupid question, but you tried it with parallel subkernels because you thought it was the writing at the same time that was problematic, yes?

@halirutan that's what I thought but the motivation was to be able to do an all-to-all communication (not just 2 kernels, but 216) and benchmark this

Also, it's easier to control parallel slaves than to manually evaluate the sequence in two separate kernels.

@OleksandrR. OK, but now the next logical step is to try it without parallel subkernel. Just a MathLink connection and you write from both ends.

@halirutan you're right. I didn't try it yet because I don't think parallel subkernels are actually different to ordinary kernels.

@OleksandrR. They are, but I'm not sure why this should be a problem in such a low-level case.

This is really strange

@halirutan they just have $ParentLink as the master kernel rather than the front end, right?

@OleksandrR. No, no.. they are really crippled as far as I know.

For instance when you try to use Rasterize on a subkernel, it will break because it needs some UseFrontEnd stuff.

I'm pretty sure they are restricted in other parts too just to ensure that you don't mis-use them as real kernel.

@halirutan well, it hangs on full kernels as well. I typed the sequence manually and there was no difference that I could tell.

@halirutan interestingly, it un-hangs and fails with a LinkObject::linkw: Unable to write data to closed link message if you close the partner to which it is trying to write. It could be that the kernel is not prepared to receive such a big message

@OleksandrR. I really doubt that. What if the kernel has to receive an image or a volume? It's not broken into chunks.

@halirutan I know, it sounds really weird

There must be something else wrong in our assumptions. I would need to read some doc again as I haven't used MathLink in a while but right now, I really need to sleep :-)

@halirutan me too. Thanks for the help. Goodnight.

@OleksandrR. No problem. Fun as always. See you later.

@halirutan I had a hunch. While LinkWrite was hung on the one kernel, I posted LinkRead on the other. It completed. It seems that for big writes it blocks until a matching read is posted. This is something I never knew about before. Did you? @Szabolcs?

@OleksandrR. This is what I meant when I said "I need to recheck the docs". This error was too basic that it could be a bug but I remembered that it is not a problem to write several expressions from one side into the link. So the conclusion is that you should always check if you can read something from a link before writing to it?

@ybeltukov The master version is in a state of mess right now ... I haven't pushed everything that's needed to make it work well yet. It would be best if we could figure out why the precompiled version doesn't work on Linux. I'll take a look on the weekend.

@halirutan well, I don't know. I don't remember having read this anywhere in the documentation. Is it documented? Did you know this? To be honest, most of the documentation makes a point of how LinkWrite is non-blocking. Apparently it is blocking but only for large messages, but I never knew of this before. If I had then obviously I wouldn't have been so confused.

@OleksandrR. I have to lie but I believe it was written in MathLink Mode by Wagner (?). Or by something from Tom-W Johnes. There, it was described how a loopback-link is one of the most useful things, because you can build up expression by constantly pushing parts of it into the link.

@OleksandrR. Nope, not MathLink Mode. I'll find it because I clearly remember how it looked on the page.

@halirutan thanks

@OleksandrR. Got it What I mean is in 1.10.2 Loopback Links. Let me check whether it is applicable in your case.

@halirutan in MathLink Mode, Wagner points out explicitly that LinkWrite is non-blocking. It's strange

@OleksandrR. And in the document by Todd that I linked, he clearly writes several times into the link (from the same side!). This was what I remembered.

@halirutan you can indeed write as much as you want to a loopback link and it won't block. I guess the reason for that is obvious, but I never understood that this behavior was special to loopback links

@halirutan at least I know how to salvage the situation and make the all-to-all communication work. But I still want to see what WRI says about this because I think this is not really acknowledged anywhere

@OleksandrR. In my opinion the MathLink topic is very hard to understand as it is not explained very well in the documentation. Additionally, they changed things in version 3 so that LinkOpen is now superseded by LinkCreate, LinkConnect, LinkLaunch etc and I have to constantly look at the doc.

@OleksandrR. No, I didn't. I don't have time to test today but I want to take a look on the weekend.

@halirutan Indeed it's not explained well. The 20 year old ML tutorial that circulates as a PDF is much easier to use and more useful than the current documentation centre version.

edenwaith.com/development/tutorials/mathlink/ML_Tut.pdf

Yep, that PS file you linked.

@Szabolcs Exactly what I think too.

There comes a Todd Gayley and writes one single tutorial that explains most things by magnitudes better than the built-in doc.

@halirutan I think they are all just synonyms; you can still use LinkOpen as far as I know. But when you have to LinkOpen followed by LinkOpen followed by LinkOpen to make the link work, it is pretty confusing, plus I suppose they thought one day the protocol may change so that LinkOpen can't do all these different jobs

@Searke Could you take a look at this (or ask an expert to take a look)? mathematica.stackexchange.com/q/104299/12 I think it's a bug in MathLink. I'm not sure the OP will report it. I don't want to report myself because it's not really "my" bug, and I don't want to be the guy who keeps writing to support all the time ... but I am interested in what is going on.

@Szabolcs I'm sorry I didn't reply to your message about this before. It was because I really don't have anything useful to say about this. It's mystifying; surely must be a bug?

Table[FindSequenceFunction[Table[n/2^n, {n, i}], n], {i, 6, 12}] // TableForm

I sense something for a bug report.

@kirma Well, the result is not technically incorrect :)

I know...

but mightily misleading

Nagged to WRI anyway... ;)

Hi guys, I have a problem that I couldn't get an answer for in a thread, and thought I'd try here to see if anyone can point me in the right direction

I have this term, t22, that is complex, and I'm trying to find its conjugate, and when I get that, it times its conjugate

It might be too lengthy for chat, so here's a paste of it: pastebin.com/cy0tdRFV

Conjugate[] won't solve it like that, because it doesn't know the value of energy, so it can't tell if the square root terms will be real or not, which makes sense

But I give it some assumptions that should allow it to solve it, in this case, energy < 2 && energy >= 0

However, it's leaving Conjugate[]'s in the answer, where it could solve them. If I do this: Assuming[energy < 2 && energy >= 0, Simplify@Conjugate[t22]]

it gives me this paste: pastebin.com/xAtjjg3S

In that example, Conjugate[Sqrt[(-2 + energy) energy]] should simplify, because it knows energy>=0, so that should get brought outside the Sqrt[], and then -2+energy is <0, so that should turn into I*Sqrt[2-energy]

At which point it should be very easy to just multiply out and separate the real and imaginary terms

I've tried Refine, FullSimplify, and ComplexExpand

ComplexExpand could possibly work, but it gives me weird things like Arg[] in the answer, when it really shouldn't have to

So, how can I make Mathematica actually solve it?

Pick four random points on a circle. How many of them leave a half-circle empty?

That's just a visualization, OrderDistribution is the key to really having an answer to that.

@kirma, I thought you can solve that one analytically? I did a similar one a while back

@YungHummmma It is not that hard to solve analytically once you know the machinery. Beyond four points I haven't found a practical solution using Mma probability functions beyond Monte Carlo sampling, though.

It's roughly a two-liner in Mma.

A bit of a hack on it: With[{n = 4}, Probability[1/2 > 1 - Max @@ ({v[1] + 1 - v[n]}~Join~(#2 - #1 & @@@ Partition[v /@ Range@n, 2, 1])), (v /@ Range@n) \[Distributed] OrderDistribution[{UniformDistribution[{0, 1}], n}, Range@n]]]

Cool

@YungHummmma you might try ComplexExpand[expr, TargetFunctions -> {Re, Im}] // FullSimplify?

Thanks, I'll try that in a minute!

@YungHummmma sorry, the expression pasted wrong. That should still work but ComplexExpand[expr, TargetFunctions -> {Re, Abs}] // TrigToExp // Simplify // FullSimplify works a bit better.

> AlphaGo won over 99% of games against the strongest other Go programs. It also defeated the human European champion by 5–0 in tournament games, a feat previously believed to be at least a decade away.

deepmind.com/alpha-go.html

@JacobAkkerboom That was definitely the thing at the office today.

@kirma You must have a nice office :)

Got theoreticians, machine learning enthusiasts, Go players, and people with professional Go players in their circles interested...

If I recall correctly there is a starcraft bot tournament either ongoing or just finished. Such fun stuff

@kirma Do you like to play go yourself?

@JacobAkkerboom I don't really play... basically anything. I do appreciate theoretical aspects, but I don't play.

I know there are plenty of jokes of such people... :)

Heh I don't think you are a dull boy :P. Anyway maybe I played too much. I've wanted to make game AIs for a long time.. But sometimes I end up playing the games myself :)

:)

Anyway the guys who made the go bot were also good at chess and go, I suppose that makes sense too :)

I think successful methods differ quite a bit, though. I remember genius PhD colleagues that were very much into "solving" go 15 years ago... well, it's a tought nut to crack.

@OleksandrR. Oleksandr, I think something's off with the result from that...

@OleksandrR., Yeah, so for example, applying Re and Im to that answer should give very simple results, but it doesn't simplify them much