Wolfram Mathematica

1:23 AM

@halirutan I haven't touched Diophantine equations in a long while, but my first instinct would be to try using the Vieta formulae first

John Fultz

2:06 AM

@b3m2a1 Definitely not 2018. Beyond that, I just don't have enough information to commit to any timeline, yet.

b3m2a1

6:10 AM

@JohnFultz I see. What all do you figure you can get the requisite number of programmers to be able to implement? I think getting Mathematica fully up to speed with, say, python or JavaScript in terms of developer support is going to require lots of work, especially without some concerted internal effort and decent number of developers.

kirma

9:44 AM

Histogram of editing activity on Helsinki region on OpenStreetMap... Pretty straight-forward to produce, but took couple hours to parse three months of OSM history XML data!

Is XML importing slow or do I just think so?

Carl Lange

@kirma No idea about whether it's slow, just wanted to say that that's pretty cool!

kirma

;)

Henrik Schumacher

10:28 AM

@kirma Nice hex-map. Reminds me of old strategy games...

kirma

10:45 AM

@HenrikSchumacher Also, it's available as a GeoHistogram, which uses hexagons by default... :)

Szabolcs

11:20 AM

@kirma I don't think XML importing itself is much slower than it could be (given the limitations imposed by M's expression structure). But manipulating the imported expression is often slow. This is based on my subjective experience when trying to import XML-based graph formats.

Szabolcs

2:59 PM

No more Mathematica for Raspberry Pi? :-(

2

Arnoud Buzing

3:24 PM

:47168001

We're working on resolving this issue. Wolfram is committed to providing the WL on the RPi. I should have more information for you later today.

Szabolcs

@ArnoudBuzing I suspected so. What's nasty is that everyone takes it for granted that it was Wolfram who cut off the license because, "as everyone knows", all commercial companies are evil.

Arnoud Buzing

We're not evil, we're very nice :)

By the way I read your email and responded (and I see that you written about some additional concerns on this chat recently...)

I'm happy to talk more about it

Szabolcs

3:40 PM

@ArnoudBuzing Thank you, I will respond in email

b3m2a1

4:10 PM

I'm looking for a fun side project as most of my others have stalled or are in a state where I don't have the willpower to touch them. Any suggestions?

Arnoud Buzing

4:41 PM

@b3m2a1 I have a project to connect the Wolfram Language to the new Vernier wireless devices (GoDirect) that I have not yet been able to complete

It's a librarylink based project, and I have a working prototype, but it needs to be generalized to work on the full set of devices

b3m2a1

@ArnoudBuzing sounds interesting, but I'm not much of a devices person unfortunately (I can't remember the last time I took a measurement for anything outside of home improvement)

Arnoud Buzing

@b3m2a1 No problem :) Are there areas you typically work on?

Or are interested in?

b3m2a1

My side-projects tend to be development, web, or data-science oriented.

I was thinking I might make a light-weight customizable alternative to the data repository off some of my site-building work

Since the actual thing is a bit clunky, static, and not really customizable to my tastes.

I figure JSON data stored on GitHub with a nice site interface would be better

And then package that up for people to use on their own

That also gives the benefit of version control which I don't think the data repository has and it's easy to collaborate with GitHub so you can nicely use it with a friend or team

Which, again, the data repository is a bit too heavy to handle nicely.

The problem is just that it's too close to the paclet server I got up and running and few people have really found that interesting so I'm uninspired to do this

C. E.

5:06 PM

I've wanted a package that can export graphics to SVG, like Export["img.svg", expr] only it will also take into account special options given to primitives. I'm thinking like Polygon[pts, ElementID -> "id", ElementClass -> "green, movable"]. It will turn those options into attributes. Then we can use libraries like D3.js to make things move or be interactive in the browser, because we can refer to those elements by their IDs and classes.

This could be the basis for a larger project, which would be to export charts from Mathematica to browsers in a way that preserves tooltips and more.

b3m2a1

@C.E. That's an interesting idea... SVG is XML-like right?

C. E.

@b3m2a1 Yes, it's just normal XML

b3m2a1

So it could be done by rewriting Polygon and stuff in terms of XMLElement?

and doing some wrangling to prevent tokens from being destroyed, but I've done that for style elements before anyway

C. E.

Yes, I've thought about this before and my impression has been that it is about converting primitives to XMLElement, but that's challenging enough because Mathematica primitives don't map one-to-one to SVG which is quite limited.

b3m2a1

@C.E. hmm... I wonder if to start we could do a 2-part export. First export to SVG string with some identifying token for special objects that is preserved, then reimport in Mathematica as XML and insert metadata where such tokens are observed.

C. E.

5:12 PM

Another problem with the current SVG exporter is that it relies too much on the "path" SVG element. The path element is a general way of representing a lot of different shapes. However, if you represent a circle as a path then you can no longer easily change its radius, for example, with JavaScript. One would like to have in mind how to make it so that the exported objects are easy to manipulate.

b3m2a1

Ahhh. So definitely have to circumvent the current exporter where possible.

Or I suppose where necessary

It looks like the current exporter also depends on the FE which it really shouldn't have to.

Ah wait. I bet that's to inherit styles or something.

Or maybe to get bounding coordinates for these path elements? Somewhat unclear.

My current thought is: 1) define DSL for building good, clean SVG from basic things like Polygon and supported primitives 2) define extensible converter for more complicated things to this DSL 3) support things like Graphics by parsing the structure down to this SVG structure

J. M. is computer-less

A tiny favor: could someone edit my post here to include the second figure?

b3m2a1

It seems like the cleanest path-of-attack and 2) will make it easy to change if we need to. The DSL is could just be the XML representation, but I think life will be better with a better one.

@J.M.iscomputer-less will do

J. M. is computer-less

Thanks! :D

C. E.

@b3m2a1 Me and Kuba thought about this and we uploaded some things here, but what I contributed was probably bad. It was a couple of years ago. Also we didn't get very far. But there you can see both the approach that I took (the notebook) and the approach that Kuba took.

But basically what you described is what I wanted to do. I just wasn't good enough.

b3m2a1

5:28 PM

Yeah it looks like you took the same type of approach, parsing the Mathematica structures into their SVG relatives. I'm think it'll be cleaner to start with a more faithful representation of SVG in Mathematica and then map from there.

C. E.

Yeah, I can't see any downside with it

b3m2a1

I can probably set up simple representations for the shape elements and then build out as I need it

@Kuba's split directives function in his notebook will probably be handy too. Parsing a Graphics structure isn't entirely trivial in my experience.

And if life is good, I can leverage this DSL to get first-stage import and try to reverse my conversions to get a partial importer.

C. E.

@b3m2a1 if you can get the framework up then I would be more than happy to contribute where I can, I really believe in this idea. How it would make it possible to create interactive visualizations for the web etc.

b3m2a1

@C.E. I'll see what I can do. I'm hopeful. I'd also like to be able to embed interactive visualization in my websites.

halirutan

6:46 PM

@C.E. @b3m2a1 There are however problems to be solved. One thing that comes to mind is that it is possible in Mathematica to have 2D polygons that have different colours on each vertex.

Graphics[{Polygon[{{0, 0}, {1, -1}, {1, 1}},  VertexColors -> {Yellow, Blue, Green}]}]

When my memory serves me right, this is not possible with SVG.

b3m2a1

@halirutan I don't expect to be able to make a perfect map. My goal is good enough for a reasonably sophisticated user to get enough done easily enough.

I want to build the framework and then if things like that become possible in future versions of SVG it can potentially be included

C. E.

+1 for this way of thinking.

halirutan

@b3m2a1 Yes, I got that, but it's the (almost) perfect map that would be of great value. Any custom front end, GUI with kernel backend, etc would be able to render Mathematica graphics without relying on the front end.

b3m2a1

@halirutan that's a good point...I'll keep in mind that I should try to make things as sophisticated as possible, but for now I'm going to try to build a really good foundation we can extend upon.

halirutan

This issue was one of the obstacles that prevented me from implementing a real Graphics3D to SVG export without rasterizing.

b3m2a1

6:51 PM

This is true. @C.E. do you know if things like D3.js can make that a reality by starting from SVG and including metadata?

I can always build in more metadata that'll be ignored by the basic SVG parser.

C. E.

D3.js – which I have only read about – as I understand it is just a tool for selecting elements, changing attributes etc. in a functional way and updating them to reflect data (data driven elements.) It doesn't add capabilities to SVG AFAIK.

One cool side effect of this will be that Expreduce will have a means of outputting graphics.

halirutan

@b3m2a1 @C.E. Not only Expreduce, think about Jupyter Notebooks. IMO rendering graphics as png and using them in an application is not the best choice. One step along the way to a more open Mathematica is to make independent of the beast that is our current front end. This will not be possible easily since too much stuff happens there, but if (somehow) one would get Graphics, Graphics3D and Dynamics working without the use of the frontend.. oh my, that would be great.

b3m2a1

@halirutan I was thinking about Jupyter as I recently wrote up that python link. I currently have Graphics showing up as PNG but as you note, SVG would be much nicer.

halirutan

@b3m2a1 Yep, correct. One easy argument here is that an SVG can be edited and you can add labels, arrows, or move, recolor, adjust lines and curves.

b3m2a1

By the way, in terms of extensibility, this is how conversion aliases are currently registered:

alias@
  Line[{pts : {_?NumericQ, _?NumericQ} ..},
   ops : OptionsPattern[]] :=

 svgLine[#, ops] & /@
      Partition[Riffle[Most@pts, Rest@pts], 2]

for example

The ops will be populated by parsing the Graphics structure and then there is a nice conversion process for known Graphics options but with room for custom SVG-only stuff too

You can register new DSL types like:

register[svgRect, "rect",
   {x_?NumericQ -> "x", y_?NumericQ -> "y"},
   {w_?NumericQ -> "width", h_?NumericQ -> "height"}
   ]

And each of those Rule objects gets pushed down to an attribute. This seemed to provide the cleanest mapping from Mathematica to SVG to me.

I'm now to the actual parsing of the Graphics structures. My plans for determining whether something is a primitive or not in the Graphics sense is to simply check whether it has an alias.

Duck-typing seems the way to go, here.

C. E.

7:07 PM

ok, cool

b3m2a1

@C.E. @Kuba do you have any good way to get rules directly out of a directives list?

e.g.

{
 EdgeForm[Directive[Dashing[{Small, Small}],
        Thickness[Large]]],
 RGBColor[0, 0, 1]
 }

could become

{
 Dashing -> {Small, Small},
  Thickness -> Large,
 FaceForm -> RGBColor[0, 0, 1]
 }

Or something along those lines (what to do with FaceForm is still a bit up in the air)

C. E.

7:43 PM

I don't

J. M. is computer-less

23

Q: Is there a GraphicsPrimitiveQ (or a complete list of Heads of graphics primitives)?

For various reasons related to workflow associated with creating figures for journals, I am creating functions that will accept graphics primitives and a set of options and spit out a Graphics object with those primitives and those options in some configuration. (Of course, this sounds like all ...

b3m2a1

9:46 PM

@C.E. @halirutan do you have any suggestions for handling things like Dashing[Small]? I don't know how that's handled internally...

There seem to be different conventions for thicknesses vs dashings and things

halirutan

10:08 PM

@b3m2a1 It is not enough to create mappings for all graphics primitives. You need to simulate the state machine that is used in Graphics. That is, if you use Blue anywhere, it will be used as colour throughout until this state is changed again. FaceForm and EdgeForm are good examples as well.

b3m2a1

@halirutan already have that in place. That's in the directive distribution code.

I have a nice test case from @C.E. and @Kuba that I'm making sure I can implement cleanly

The test is:

Graphics[{EdgeForm[
   Directive[Dashing[{Small, Small}], RGBColor[0, 0, 1],
    Thickness[Large]]], {RGBColor[1, 0, 0],
   Disk[{Sqrt[3]/2, -(1/2)}], {RGBColor[1, 1, 0],
    Disk[{Sqrt[3]/2, 1/2}]}},
  Disk[{0, 1}], {RGBColor[0, 0, 1], EdgeForm[
RGBColor[1, 0.5, 0]], FaceForm[Opacity[0.5`]],
   Disk[{-(Sqrt[3]/2), -(1/2)}]}}]

And currently the SVG looks like:

I need to handle the PlotRangePadding and things but for the most part I can do the test case. It's certainly not the most robust yet, but it should be extensible which is the main goal.

(for now)

I also make sure that directives apply in the proper context. e.g. a color in the context of a Line becomes a "stroke" coloring while a color in the context of a Disk becomes a face coloring.

Once I have the base down I need to do PlotTheme inheritance and things

Ah. Also PlotRegion and friends...

halirutan

10:33 PM

@b3m2a1 What are you going to do with Axes, Ticks, ...?

b3m2a1

@halirutan I'll cross that bridge when I get there :) but I imagine I'll have to do a bunch of spelunking, make use of some of the built-in Ticks utilities, and probably fake a few things for the Axes.

It will likely require implementing a partial patch for FullGraphics and then pushing through the base framework.

I also foresee GeometricTransformation being a huge pain.

There's a decent chance I'll need to fallback on some of the built-in stuff for more complicated elements and find a way to merge the two.

Oh interesting. I didn't realize this was possible in SVG: transform="matrix(1,0,0,1,-74,-13)"

halirutan

@b3m2a1 Yeah.. an optimal solution wouldn't use Mathematica at all but do it in a different language that can be accessed. Kotlin is a good choice since it can directly be used with Java and it compiles to JS and native.

But I suspect I have a slightly different view on the topic.

b3m2a1

@halirutan I can see that being nice as a method to interpret Mathematica Graphics objects in a different language, which would of course be powerful. But for getting something up and running I think Mathematica'll be much faster. Packet processing is pretty tedious.

At least that was my experience working with Mathematica packets in python

b3m2a1

11:12 PM

@C.E. @halirutan if you want to take a look the package is on GitHub here: github.com/b3m2a1/mathematica-tools/blob/master/SVG.m

Here's a sample export: wolframcloud.com/objects/b3m2a1.testing/svg_test.html

Here's the same with the built-in exporter: wolframcloud.com/objects/b3m2a1.testing/svg_test_baseline.html

If you look at the source you can see how much cleaner this method is

Of course, it's not as robust, but it's only been alive for a few hours. I should add things like Triangle and friends now, probably.

Or maybe getting GraphicsComplex support takes priority...

Probably.

halirutan

@b3m2a1 It seems toXML is missing from this package.

b3m2a1

Huh. How'd that happen.

I'll figure that out.

halirutan

@b3m2a1 And yes, that's more important in my view.

b3m2a1

Hmm. It seems to be there. Is something not converting that should?

halirutan

@b3m2a1 This here

Ah, OK. You didn't include circle.

It's a disk you used up there as example..

b3m2a1

11:25 PM

Eh Circle should still work. I screwed up an alias I think.

Oh...my fallthrough code isn't ignoring svgElement. It returns a Failure by default, but...it isn't smart about svgElement.

I reduce Circle in terms of Disk.

b3m2a1

11:46 PM

@halirutan fixed some reduction issues (gonna do a bit more before I push though). Here's a blue Circle and a red Disk wolframcloud.com/objects/b3m2a1.testing/test3.svg

Transcript for