@J.M.isslightlypensive @b3m2a1 Well, why not copy the other algorithm in Bengt's paper? Actually I did:

weight = ReleaseHold@
   With[{cg = Compile`GetElement, rc = RuleCondition},
    Hold@Compile[{z, {x, _Real, 1}, {m, _Integer}},
        Module[{c, c1, c2, c3, c4, c5, mn, n = Length@x - 1},
         c = Table[0., {j, 0, n}, {k, 0, m}];
         c1 = 1.;
         c4 = x[0] - z;
         c[0, 0] = 1.;
         Do[
          mn = Min[i, m];
          c2 = 1.;
          c5 = c4;
          c4 = x[i] - z;
          Do[
           c3 = x[i] - x[j];
           c2 = c2 c3;
           If[j == i - 1,
            Do[c[i, k] = c1 (k c[i - 1, k - 1] - c5 c[i - 1, k])/c2, {k, mn, 1, -1}];

It's not Mathematica-style, but given the algorithm (originally written in fortran) isn't long, I don't make any big change.

1st argument is the grid point at which the approximation of derivative is calculated, 2nd argument is the grid points used for approximation of derivative, 3rd argument is the highest order of derivative to be approximated. For example

weight[3, Range@3, 2] // Transpose

gives

{{0., 0., 1.}, {0.5, -2., 1.5}, {1., -2., 1.}}

I copied this on the way to creating a less memory-consuming NDSolve`FiniteDifferenceDerivative. (Still unfinished though… )

@xzczd I did that too but the explicit weights on regular grid case is more common for me and can be implemented faster via vectorized operations.

But I have a C++ imp of that algorithm in a repo on GitHub

@b3m2a1 I think speed isn't very important here, because the weights in the middle part of grid are duplicate. I mean, ideally we can create a piecewise function with only a few weights therein. (Of course this is more difficult than generating weights via vectorized operations for every grid point, as done by FiniteDifferenceDerivative. )

@xzczd Prolly for another post. I still have a lot to write up before I need to go offline for a while again.

@xzczd Also, quite a lot of recurrences in there; I wonder if there's a version where you can just chain products of matrices and vectors of appropriate quantities...

but yes, prolly for another time.

@J.M.isslightlypensive Look forward to it :)

…Why does this question receive 4 reopen votes? The equation system is still incomplete, and OP's edit is still clearly careless. (Just look at the %361 and the incomplete uθ[r, θ, z], ur[r, θ, z]}, {r, θ}]!): mathematica.stackexchange.com/q/193176/1871

Well, it may be possible for someone familiar with elastic mechanics to give an answer at this point, I guess. Does anyone prepare to do him/her a favor?

@xzczd right that would have been a fine approach too. Should give the same type of control of the error, but would have been a little more work (as in like 5 more lines) to implement making it left-handed, right-handed and centered which is of course what you need to get the derivatives at every point in the grid. Nice to have both in my view :)

Also a bit easier to explain the regular grid construction, I think, since it's more "normal" in some ways

@b3m2a1 FrontEnd`UndocumentedGetSelectionPacket ?

@Kuba problem is I don't have a selection. I want to attach a cell to a BoxObject inside a DockedCell.

@b3m2a1 BaseStyle -> {LineBreakWithin -> False}

The best I can do for that is attach it to the DockedCell itself but I'd like the horizontal component to be consistent.

@Kuba Ah of course. Thanks a bunch. That'll look much better.

@b3m2a1 Then I don't know and I'd bet I've seen something related in one of your answers. So you can go through them :)

I already did that ;_; I also tried my FEPacketBrowse function to try to figure it out. The best option appears to be using UndocumentedGetBoxInformationPacket which returns all of the box info in the notebook and then trying to piece together the position from that.

If you want an example of the case I'm considering here's one:

SetOptions[EvaluationNotebook[],
 DockedCells ->
  Cell[BoxData@ToBoxes@Dynamic[dockedCell = EvaluationCell[]]]
 ]

FrontEndExecute[
 FrontEnd`AttachCell[dockedCell,
  Cell[BoxData["\"menu\""]],
  {Offset[{-150, 0}, 0], {Left, Bottom}},
  {Left, Top},
  "ClosingActions" -> {"OutsideMouseClick", "ParentChanged",
    "EvaluatorQuit"}]
 ]

That first Offset argument is the thing I'm trying to change up

Howdy

I'm troubleshooting output from FindRoot

I'm getting a bunch of warnings that the result does not converge

I've tried, for my case, some outrageous numbers like WorkingPrecision 300

Not to great success sadly

What's a good next step to determine the problem?

PS: Some background is that I know that the result must converge, since it's a physics problem that has been calculated before in this limit

I have upped machine precision of the notebook itself with a factor 6 but that doesn't change much for the result.. pff

For the ones interested in the latest blog-post of WRI, I have shared it on Hackernews. My hope is to get a discussion started because the audience on HN is vastly diverse and they are able to bring different perspectives from all kinds of languages/frameworks on the table.

I'm not yet ready to give my opinion about it as there are so many points. However, my primary critique is there seems to be a misconception that I (or better we) don't understand that WRI needs to make revenue by selling something. I don't need Mathematica to be open source. But as long as the tooling for developers is not open and well documented, there is no chance WL can thrive as a language.

@VitaliyKaurov Is this post genuine or fake? community.wolfram.com/groups/-/m/t/1645253 The person who is displayed as an author (MRB) has posted many times before. But is he really the genuine poster this time or something went wrong? I am pretty sure I have already seen an almost identical post on W|C (could be because a writing class asks this all the time..)

I went to W|C today to complain about how badly it works to use it for writing, and how many things could be improved even with very little effort .... then I saw this post and decided not to.

While using the parallel command like ParallelTable. Do we use DistributeDefinitions multiple times or just one time?

Since I have many ParallelTable commands. So do we write it for every one if there different inputs in each tables?

Guys whats wrong with this two polygons: pastebin.com/myEdDXVu can not get them as a region in mathematica to use RegionMember. My RAM blows out when I try DiscretizeGraphics[Graphics[#]] & /@ poly where ploy is the above list. Also BoundaryDiscretizeGraphics gives up. Can anybody test with more RAM. This is surprising.

Tried to explicitly create the mesh region with BoundaryMeshRegion[#, Line[(Range@Length@#)~Join~{1}]] & /@poly no error and it does not work. This two polygons are actually two localities in Germany. Here is GeoGraphics output on them imgur.com/1Wd5uFQ . Any idea guys how to tackle these two polygons? All other 9k polygons for Germany were fine and processed.

@PlatoManiac You can use RegionMember @ RegionUnion[DiscretizeRegion /@ polys]. In M11.3 it seems that RegionMember[polys[[2]]] hangs, but this is fixed in M12.

@CarlWoll Thank you for the quick help. I was a bit dumbfound to find these tow outliers in the dataset :) and the polygons too were looking pretty harmless.

@Szabolcs thanks for keeping an eye though :-)

@VitaliyKaurov I know he is a real person. What I was worried about was that someone hijacked his account as I was sure I've seen a very very similar post in the past. We've also had some spam which was based on re-posting old content and inserting an almost invisible link.

@PlatoManiac I know from experience that the people living at these place are rather headstrong and do not stick to conventions ^^

So much for my hope of an April 1 version 12 release. Oh, well.

@JimB let's hope the delay is to make the first Mathematica release without some glorious bugs :)

@Kuba things have gone meta in IDE world. I'm now writing the code for the IDE inside the IDE.

@b3m2a1 Concerning bugs, Mathematica before 6.0 was nearly perfect. I'm only aware of one little bug. Nothing to do with other softwares.

@Szabolcs i know you meant that - and what i meant is that that post was made by the real person and not hijacked ;-) yep there were sometimes spammy similar things but here it is not the case. Thanks again for watching out :-)

@b3m2a1 soon after I started with mma I tried to deploy a package for deploying a package. It didn't go well :)

@Kuba I keep expecting some total meltdown but the meltdown doesn't seem to be coming

It's actually really nice except I have to retrain myself not to try to search through hundreds of windows and to actually use the IDE like a regular IDE

At least for now, though, things are behaving well

@b3m2a1 is there a release of EasyIDE?

Not quite yet. I want to make sure the thing is reasonably robust before setting it free.

But I'm currently using it to write the documentation plugin to it.

So things are looking decent-ish

Quite a discussion emerged from that blog post. Would be nice to get a summary of thoughts from comments there, here and HN.

After a week or so.

I find HN posts about WRI to be surprisingly caustic

(to be honest, I find the majority of posts on HN to be caustic...)

I'd like to write a comment on that blog, but it is a lot of effort and time to phrase it well ... Wouldn't be able to get to it for a while.

What concerns me is no that they are talking about reasons not to make it FOSS (even though the points made do not apply to FOSS per se but to a certain method of development that not all FOSS projects follow)

It's the design philosophy that is expressed, and the feeling that they are out of touch with the practical needs of those who use Mathematica to get real work done daily.

The top-down design sounds good in principle, but if they don't consider real, practical use cases and make sure that they are actually solvable with the proposed design, then it's even worse than not having a coherent design ...

People solve practical problems with ugly open source software all the time. They wrote the software to solve those problems!

I often have the feeling that some Mathematica functions are designed to achieve some idealistic generality, but in the end they end up being simply unusable for anything but toy problems.

Does anyone seriously use Dataset and SemanticImport for anything larger than a few thousand data points? In the mean time I see blog posts about how to process a billion datapoints with Python.

The motivation behind adding some functionality should always be to enable solving some real problem. Otherwise it's pointless.

@Szabolcs literally this:

FOSS development tends to react to immediate user needs—specific functionality, existing workflows or emulation of existing closed-source software

Somehow they see that as a bad thing

Like the fact that it's useful is undesirable

Like they note this:

Many open-source tools are available as a side effect of their developers’ needs or interests. Tools are often created to solve a developer’s problem and are then made available to others, or researchers apply for grants to explore their own area of research and code is made available as part of academic publication.

Which is exactly what makes good software useful. Like it was useful for one person so there's a good chance it'll be useful for another.

@Szabolcs I'm not disagreeing with your overall point, but yes, I have used and continue to use Dataset and SemanticImport for datasets >50k rows.

@CarlLange how well does SemanticImport work for it? I never use it because in the past it's been super buggy in my experience so I do just as much post-processing and cleaning as if I never used it in the first place.