@SjoerdC.deVries I think my download was something like 35 MB/s, which would be closer to 300 Mbps... it is not unimaginable that it was actually bottlenecked by my home wifi (wifi router behind a wall). Usually I have been using phone mobile hotspot for this download (it's great to live in a country where data contracts tend to be unlimited), so it's hard to compare if it has improved since <100 Mbps long term speeds on 4G network definitely make it more painful.
(Operators definitely deprioritize you if you download gigabytes of data over mobile network at full throttle.)
@Kuba Good catch - I was too preoccupied by the fact that TextClipboardType->"Package" seemed to give something acceptable... "f[({{a,b},{c,d}}),3]^2" as output would be nice
The goal is to be able to convert the resulting string back into a box structure using FrontEnd`UndocumentedTestFEParserPacket - so I'm looking for something like "Box structure" -> "Readable string" -> "very similar box structure"
@Kuba I think I'll go hide under a rock for a while - of course, you're completely right. For the cell structure above, the output would be "f[a,b]+g[c,d]". The output pasted above ("f[({{a,b},{c,d}}),3]^2") belongs to
@LukasLang as usual the devil is in the details. And that matters even more if you want to do a round trip. So here is another one problem: "f[({{a,b},{c,d}}),3]^2" the information about Grid is lost here, isn't it?
Do you want the string to be in InputForm or OutputForm, if the former, how do you want to preserve information about 2D typesetting of the original structure?
I assume InputForm because even though OutputForm can contain more information it will look ugly and the round trip won't be so much easier anyway
@KraZug, the method of lines will never be obsolete since that is the main mechanism to time integrate PDEs with different spatial discretizations like the FEM or the FDM.
@CarlLange Just curious: is it slow also for repeated application of the operator form? In theory it could build a reusable search data structure...
Also I wonder if, when using entities, getting one point of the loc entity and calling GeoWithinQ (or the operator) would be significantly faster and sufficiently precise...
Baseline polygon intersection test on a geoid sounds pretty nasty... and overkill.
Seems pretty slow to me... `Select[Thread@ RandomGeoPosition[Entity["GeographicRegion", "Europe"], 100], GeoWithinQ[Entity["Country", "France"]]]` takes a billion years
aha, in the docs there's an example using Pick that might be a lot faster actually
Yes, the Grid is lost, but I'm fine with that. I'll try to formalize my goals a bit: * The goal is to do "Box structure IN" -> "String STR" -> "Box structure OUT" * Highest priority is that IN and OUT are semantically equivalent for all cases (i.e. evaluating both should do the same) * Next priority is to make STR as readable as possible - i.e. not box structures etc. * Next priority is to preserve as much of IN as possible, e.g. postfix notation, line breaks, ...
(I'll probably post a question about this soon, since it is starting to be scattered over many messages already...)
Still pretty slow though, really. If I have satellite data of europe with some relatively high resolution (100k points, let's say, but even that is kinda low), getting only the points within dublin city takes a long time.
@kirma Yes, I think the big thing here is projections and so on. There's definitely potential for a lot of complexity in a GeoWithin function, but I kind of want PerformanceGoal or something.
any other Mac users tried out FindFaces or FacalFeatures? I consistently get an empty list returned - even if I evaluate the cells in the documentation. Windows version seems fine.
What is still missing is the same for Mathematica -> Python. I hope to see it in 12.1! The groundwork is clearly done in the Wolfram Client for Python, but it is not currently being used by ExternalFunction.
Sometimes I'm annoyed to high hell by the fact Mma likes to turn discrete GPU on for no apparent reason and not to release it. Especially on long intercontinental flights...
Hi, is this not the chatroom to ask general mathematica questions that may not warrant a question on the site?
Should I be asking on the Wolfram community forums instead?
I've asked some questions on TeX SE and these were all very well received. Coming to Mathematica, Stack Overflow and here is in tremendous contrast with that. I don't think anyone ever even bothered with my question...
I just don't really understand
I've checked the meta but nothing significantly different to tex..
@1010011010 You can talk about anything in this chat, the chat description even says so. ("Other than the general guidelines in place, anything goes here.")
Be assured that you haven't done anything wrong.
If you want to increase your chance of getting an answer, the same principles work here as on the main site. Explain your question clearly. Share code. Provide an MWE.
@Szabolcs First questions about procedural programming (other acc), then questions about symbolic integration, then questions about back-end and Integrate's option TraceInternal, and now questions about list structures. I'm just trying to understand if it's me or something. This problem has been so stubborn I can feel my cortisol levels rising in real-time
Sorry to be blunt, but I hope you did explain the issues clearly, stated a question explicitly, linked to relevant materials and addressed comments/questions below the post. In this discussion you did not point to a concrete example even after I asked about it twice. If something similar happened on the main site, that would explain why your post was ignored.
@1010011010 If you don't receive answers here, why not ask on the main site? very many users don't use this chat room. My apologies that I didn't respond to your query earlier, but I know absolutely nothing about your area of concern. I would strongly recommend asking on the main site if your question doesn't get any traction here.
In my opinion, this chatroom is good for answering questions if your question is of a complexity level like "I've forgotten the name of the function that does X and I can't find it, does anyone know it?" I think in general any detailed questions at all are better suited for the main site.
Far more users see questions on the main site (for instance, kglr, who answers 50% of the questions on the site, has never set foot in this room) - and the point system doesn't apply within this room. And the history of the room is very hard to reference in the distant future or for other users, as opposed to a question on the main site (even if it is closed for being a simple mistake, for example)
@Szabolcs: How do you find the performance of the new 12.0 MMA/Python interface? I have seen your criticism of the ExternalEvaluate (?) interface on Wolfram Community saying it was too slow for general work. I am looking at your description here on SE of ExternalEvaluate for networkx and it sounds like you are more optimistic. Would the 12.0 ExternalEvaluate for Python be able to pump through thousands of calls to Python and back in a reasonable amount of time? Or is there a lot of overhead?
@Kuba no, sorry, just pointing out that generally it seems it should be supported, except I didn't see anything about being able to pass args using the Get/<< syntax
@berniethejet I have not played enough to give a good assessment, but I think it's going in the right direction and I can't wait for when the Mma -> Python conversion will also work in a structured way.
I don't know about thousands of calls because of latency, but transferring large data from Py -> Mma should work much better in 12.0 now
Thanks @ArnoudBuzing. I guess there are a few components of the roundtrip overhead: conversion from MMA to Python types, transmission, reception, and deconversion, is that right? So I guess the conversion/deconversion of the arrays is the speedup you are talking about, is that right? That is very good news.
@berniethejet this is a good 1 hour overview of all the improvements: youtube.com/watch?v=YXGyrkKQuVo (it's from the 2018 developer conference in Champaign, Illinois)
@CarlLange NumericArray is more like the documented successor for the undocumented RawArray(but the syntax is different and they are not quite the same). Functions which used to returnRawArray (for example RandomImage[1,{10,10}]//InputForm) now return NumericArray.
@ArnoudBuzing Aha, I see! That's good to know. It's a bit strange that PackedArray isn't documented yet considering how much of a speedup it can give you (particularly with regard to Parallel and friends)
@CarlLange It is documented to some extent, reference.wolfram.com/language/Developer/ref/PackedArrayQ.html Tutorials dealing with it will invariably mention it. But yes, there could be a better description in the docs. Packed arrays are very different from NumericArray because they are transparent. They are observable merely through performance measurements and a few developer functions. NumericArray is an expression type in its own right (mainly useful in conjunction with LibraryLink)
Correction: "Tutorials dealing with it" -> "dealing with performance"
@ArnoudBuzing But only way way (Py->M). Looking forward to the other direction.
For me, ExternalFunction/ExternalValue are one of the big highlights. They increase the utility of this system tremendously.