The current state of PJLink image support...

Looks about right, right?

Ahh. Now this is about right:

The support currently only goes Mathematica -> python but the goal is to get it going the other way too.

If things go as they generally have that should be the easier direction.

@xzczd Well done!

@xzczd Hmm... this picture looks more like a girl to me and not like a differential-eq. badge..

I think this question is clear enough now to be re-opened (it's still not great and the unresponsiveness of the OP is a bit frustrating, but it's fair to reopen it now): mathematica.stackexchange.com/q/182125/12

@b3m2a1 Ping me when there's a new version which might be easier to set up! Or one that has a way to manually specify the Python I want.

@b3m2a1 Does PJLink write anything onto disk, such as configuration information? Does it modify anything on my system apart from installing the paclet?

@Szabolcs I've been doing a lot of work on the python side to get this post written

(I got images linked in via PIL which I view as a big win)

But I think I also cured some bugs in InstallPython

If it doesn't work please let me know, but in the interim you can run the paclet's start_kernel.py script and simply pass it a link you started with LinkCreate then hook that into InstallPython via the LinkObject option.

@b3m2a1 Since I still couldn't get it to work, I can't comment on the specifics of the system, but here are some ideas that may help in making it more practically usable:

The approach to datatype translation:

J/Link doesn't transfer much between M and J. Instead it has handles to objects that live on the J side. That's natural for Java as most data will be in the form of custom Java objects, not standard datatypes.

Hmm... what exactly is the error you're getting? Is it something about not being able to find the executable?

MATLink focuses on standard types only because MATLAB only has a few. At the time MATLink was written, OOP was not nearly as common in MATLAB as nowadays.

Most scientific programming involves only a few datatypes, so this approach tends to be useful.

@Szabolcs this is actually something I've been working on but the dynamic-ness of python makes it a little less necessary I think

What I'd do for the next version of MATLink if I had the time to write it would be a user-extensible datatype translation framework.

Basic datatypes are translated by default. What if we encounter an "object type" (class)? Check if the framework has translation code for it, and if yes, use it.

Would it be possible to also add something like this to PJLink in addition to the object handles?

This was if I want to work e.g. with ITK images instead of Pillow images, I could write the translation code for that.

@Szabolcs That's an interesting idea although I don't know exactly how best to implement this. My current structure adds type-hints on the Mathematica side and uses these to do intelligent decoding python side.

It should be possible for the translation code to be fast (i.e. minimum number of MathLink calls, split the code between M and Py in whichever way the performance can be maximized)

On the other hand I can write some DSL which does this

People would write some translation code like this anyway, even if there's no direct support.

E.g. I'm interested in networkx graphs.

Should you support those directly? I say not. It's not the only graph library in Python. Why single it out?

But I'd like to write my own code to go between M's Graph and networkx.Graph in either direction, and hopefully have it integrate with the rest of PJLink as much as possible.

Yeah I think the way to do this is to do an extensible typehint framework on the Mathematica side and then either have the typehint itself tell python what to do or have them also write a python-side decoder DSL.

I know Leonid planned something like this for RLink too before development stopped

Just some ideas.

The big thing in all this is basically where are the arrays, what dimensions do they have, and what type are they.

You know best what can be made to work with PJLink specifically

I'm sure there'll be problems.

E.g. auto-converting Graph from M->Py may not be the best idea because I might want to have multiple converters to multiple Python-side formats ...

But what about adding a wrapper on the M side, e.g. nxGraph[Graph[...]]] and auto-convert that?

Again, just ideas.

@Szabolcs I'll try to knock something up but I'm hopeful on this. It was pretty easy to get image support in there once I had the system up for packed array.

Another thing: do think about RawArray now. It'll be included in the next version of M as NumericArray and it will be documented. It's the same as RawArray AFAICT

I think it's okay to say this publicly since it was mentioned on W|C by the ExternalEvaluate developer already

WXF supports this type directly

MathLink doesn't unfortunately

Yeah I've been converting those to packed arrays and pushing them through

Not a big deal though as RawArray can't do much on the M side right now. It's just for storage. I t can't be computed with.

However it is the underlying datatype of both Image and Audio, I think

It is for Image at least. Look at Image`InternalImageData

also for ByteArray

Does MathLink support ByteArray natively?

as far as I know, no

but WXF does

it's just a RawArray

LibraryLink also does (undocumented)

My impression is that they're slowly transitioning towards ByteArray holding binary data and strings holding unicode text. Separating the two cleanly, just like Python

Ah okay. I'll start building this typehint framework when I have the time and I'll use those as my test cases.

Right now often strings are used for binary data even though a single string character is not restricted to the 0..255 range. It's a mess.

I don't know why MathLink doesnt support these yet

Maybe in the future it will

@b3m2a1 For me, the proof of the pudding will be being able to implement something like nxFunction["betweenness_centrality"][RandomGraph[{10,20}], None, False] and have it return a list of betweenness centralities, with all of the graph, None, False auto-translated.

Of course this auto-translation for the graph should be implemented by myself (not builtin). What's important is that I should be able to do it without too much fuss.

How does this sound as a framework? PJLink`Package`RegisterType[pattern_, head_, {type-> field...}] where the fields are the functions that extract the data and the types are functions that determine the data type. To a large degree these can be reused. On the python side: TypeDecoder.register_type(head, ((type, fieldname)...), final_class = namedtuple) where the decoder automatically extracts the field data by name based on the type and passes it to the final_class

Of course this is only one direction and I'll need an encoder on the python side too, I guess.

But the nice thing is that this can be made very modular and hooks nicely into the typehint system I've been playing with.

I can also supply a default option to have PJLink insert the decoders automatically into a session if people are willing to have the final_class be a namedtuple by default.

@Szabolcs do you mind raising an issue about your failed InstallPython? I'm sure if it's happening to you it'll happen to others too.

@C.E. Thanks! :D

@halirutan Oh she was too close to the camera:

@xzczd Congrats. Well-earned.

@HenrikSchumacher Thanks! :D

@xzczd well deserved!

@Kuba Thanks! :D

@b3m2a1 I did a bit of debugging on that StartProcess, and this fails:

However, the error message is incorrect.

The problem is that the directory ProcessDirectory -> "/Users/szhorvat/Library/Mathematica/Paclets/Repository/PJLink-1.0.0/Mathematica‌​/PJLink" does not actually exist.

I guess it should be "/Users/szhorvat/Library/Mathematica/Paclets/Repository/PJLink-1.0.0/PJLink"

Can you fix this?

Hey all! Anyone knows how to calculate Mod[2 ^ 100!, 101] in wolframalpha? I can get both Mod[2 ^ 100, 101] and Mod[100!, 101] to work, but WA is unable to recognize the first expression :/ Or is there any other website where the first expression can work?

Mod[2^Factorial[100], 101] doesn't work either ...

And neither does Mod[Pow(er)[2, Factorial[100]], 101]

@Szabolcs huh for some reason I thought I’d patched something like that before but I guess I failed to. Yeah, I’ll figure that one out and push a proper version update so it’s easier to install. Also I was thinking and do you think it makes sense to provide the C library precompiled for different architectures? I couldn’t do it for Linux or Windows but I can provide all the path-finding utilities for that so that it properly looks for the x86 .so file on the different platform.

I only kept 1.0.0 through yesterday because I wanted to push a 1.0.0 as the original release :)

@GaurangTandon wolframalpha.com/input/…

2 ^ 100! caused overflow

Woah, didn't know about that PowerMod thing, thanks @ChipHurst!

also, imho, is there was overflow, then i don't think the error msg is helpful :(

have you seen this?

(I mean, it's a WR video!)