@Szabolcs I've just been putting non-standard stuff in. But I think a better way to go is to add a new "Extensions" type, like "PacletServer" and then one can add the metadata there. Presumably the PacletManager doesn't care if there are random non-standard extensions.

@Szabolcs Sounds good. I'm trying to resolve some of last this stuff now plus the issues on the repo (thanks for submitting them).

Is it a bug?

BinarySerialize[-439414247676962567095] // BinaryDeserialize

Known issue? ChromaticPolynomial@GridGraph[{2, 2, 2}] crashes the kernel occassionally on my v11.3 installation.

Are there any ways to reduce memory usage of Boolean satisfiability computations? I'm trying find solutions to relatively small problems but often use of memory explodes to tens of gigabytes, and I don't even want to think of larger versions. The machine is basically spending all time swapping and performing virtual memory compression operations...

Ah. I guess my real troublemaker is Resolve of Exists over Booleans.

@kirma What kind of problems are you working on?

@Szabolcs Mostly toying around Hadwiger–Nelson problem (frankly with way too small graphs), trying to do various kinds of satisfiability queries on graphs represented as Boolean variables marking edges...

Resolve + Exists + Booleans is all about finding graphs which are not four-colorable, but that doesn't really seem like a scalable way to approach the problem.

@kirma How do you encode the constraint that each edge is of the same length?

@kirma I mean, I guess first you create a unit distance graph, then check if it's 4-colourable (and hope it's not). How do you deal with the first step?

@Szabolcs I don't. But it's at least plausible to start with constraints like that no four-vertex complete subgraphs are not allowed, and that every vertex has to have at least three edges to be meaningful. And then check if a graph is not four-colorable.

If one would actually find such a graph, then it would be possible to check if it is geometrically plausible.

Just toying around, not really particularly seriously... :)

@kirma Did you see that I was working on a colouring function for IGraph/M, based on an encoding to SAT? Did you try it? If you have your own method for the same, I'd be interested in comparing performance.

I must say I haven't tried IGraph/M :I

@kirma Actually, I also need someone to test that it works on their macOS system (to verify that the binary didn't get tangled up with my MacPorts). I know you use macOS too. Would you give it a try and report back? Paclet will be ready in half an hour.

The current published version doesn't have the function yet.

@Szabolcs I'm not quite certain how I would "try it", but if you tell how, I can... :)

I'll ping you when it's ready (30 min). Here's the discussion: mathematica.stackexchange.com/q/171510/12 Some improvements have been made since then, though.

OK, I'll hang around...

@kirma BTW do you have a quick link for a downloadable version of de Grey's original non-4-colourable graph? (Not the smaller ones found later.)

@Szabolcs Nope, I haven't looked for one, really...

I must say I haven't thought of more specific way of measuring 4-colorability than the above, rather simplistic Exists construct (which Resolve expands basically to all possible solutions, which grows at quite a rate...).

@kirma Sorry, some things went wrong with compilation on Windows (as usual), and I want to make the package complete. It is going to take a while. I suggest you don't wait.

@Szabolcs No problem. I was already in the pub... ;)

@kirma Here it is: dropbox.com/s/4jupu8pepb6q0jx/IGraphM-0.3.97.82.paclet?dl=0 See the Graph colouring section of the documentation.

I would appreciate some help from people: Can you please test that the above paclet works on your system? Just download the .paclet file, install it by passing the file name (full path) to PacletInstall, then load the package using <<IGraphM` and test the binary component by evaluating IGVersion[]

I am looking for one report for Windows, macOS and Linux, each. Please also mention the specific OS version / distro.

@Szabolcs MacOS 10.13.4 / MMA 11.3 success: "IGraph/M 0.3.97.82 (April 22, 2018), igraph 0.8.0-pre+669ed53f (Apr 22 2018), Mac OS X x86 (64-bit)"

@Szabolcs Success on Ubuntu 16.04.4 LTS

Thanks @ChrisK and @halirutan! Now only Windows is needed, but that is probably fine in this case.

The big change in how it's compiled was for os OS X / Linux.

@Szabolcs Is there some test suite to perform?

@halirutan Yes, but it's some trouble to run, and it seems very unlikely that it would fail on your machine if it worked on mine. What I had trouble with before was (binary) library compatibility and dependencies. The problem is that I do not fully understand how this works. I can check with ldd, but (based on experience) some other OS versions may come with incompatible libraries.

@Szabolcs OK. Usually dyn-libs should only rely on very basic other libs and everything special should be provided if possible. If things like libc are wrong, it's a pain.

@halirutan But it's a good idea to make a test package, so here it is: dropbox.com/s/b806gi67hedyylx/IGraphM-0.3.98-tests.zip?dl=0

@Szabolcs Uh-oh, I apparently didn't make it on time...

In V11.3:

prod = Compile[{{a, _Real, 1}}, Fold[Times, a]];

SeedRandom[1];
foo = RandomReal[{1/10, E^(1 + ProductLog[(-1 - Log[2] - Log[5])/(10 E)])}, 2000000];

Fold[Times]@foo // AbsoluteTiming
Apply[Times]@foo // AbsoluteTiming
Tr[#, Times] &@foo // AbsoluteTiming
prod@foo // AbsoluteTiming
(*
{0.18105, 0.}
{0.338381, 2.81742*10^229}
{0.384251, 2.81742*10^229}
{0.176814, 0.}
*)

In V11.2, Fold[Times]@foo agrees with Apply and Tr. Compile/prod returns 0., which is probably underflow.

@user554252 Yes, the derivative of the delta function. In Mathematica, that is undefined. The user can substitute her/his own definition in one way or another.

@Szabolcs All tests ran through.

@user554252 No, I don't think so. -- Wait, I take back the assertion that DiracDelta'[t] is undefined. DiracDelta'[2.] evaluates to 0. However, it's not quite correct to say that it is Infinity at t == 0. The function has certain properties with respect to integration that cannot be reduced simply to saying that it is infinite at zero.

@user554252 Before you proceed, make sure you have the theoretical background right. The Dirac delta is a distribution and makes only sense under an integral.

Any idea why Fold[Times]@foo and Apply[Times]@foo disagree above?

@MichaelE2 I have a hunch. Try this several times:

Fold[Times]@foo
Apply[Times]@RandomSample[foo]

and look at this:

Fold[Times]@Reverse[Sort[foo]]

@kirma That's fine, enjoy the colouring functions ;-)

@user554252 The Dirac δ is not really a function. It can be misleading to think of it has having values at certain points. That intuition works sometimes, but fails in other cases. That's why it's described as a distribution, i.e. a functional, when constructing a well-founded mathematical theory for it. What matters is what happens in \int f(x) δ(x) dx type definite integrals.

I wonder, what is the effective value of ValidationLength option in FindSequenceFunction when ValidationLength->Automatic is specified, or when this option is omitted? Does it depend on the complexity of a candidate function found?

@halirutan I think I get it, though it's hard to describe. Overflow into bignums is happening but the final result happens to be machine-size; but if underflow happens, the accumulated product stays at zero.

And underflow in V11.2 resulted in bignums, so the calculation does not become 0.

@b3m2a1 What is your opinion on quality control for the paclet server? PackageData has a few dubious looking packages: community.wolfram.com/groups/-/m/t/1324679 This particular one (mentioned in the W|C post) just links to a zip file, with no description, and is also broken. It has syntax errors.

The problem with a paclet server is how easy it is to install packages, and (probably) trigger the immediate evaluation of code. It would be too easy to distribute malware this way.

While malware is unlikely, a sloppily designed package wreaking havoc with the system could happen ...

What I'm trying to say is that it would be good for us to examine any submitted paclets and make sure that they follow some quality standards before accepting them.

I usually end up having to delete and re-add all the newlines after the ; characters. That fixes it.

If this could be made easier, that would be a big improvement for my day-to-day work. Ideally the indentation would happen automatically.

^ This is why I cannot feel bad about the post I made on Wolfram Community about the state of the graphs and networks functionality.

I know that it turned out that some graph fixes did go into 11.3. But if I cannot even trust functions as fundamental as UndirectedGraph, then how can I trust any graph-work I did with Mathematica??

@Szabolcs This was one of the first things I coded up, a block indentation / replacement event binding. Without it writing serious code in the FE is a serious exercise in tedium

@Szabolcs I can do this to start, until we have an idea of how this should work. I imagine we can just check the packages of people who don't have a serious presence either here or on community?