Huh? Simplify[Overflow[] > Overflow[]] (* True *)

Simplify[Overflow[] <= Overflow[]] (* False *)

@VladimirReshetnikov I bet something like .equals isn't implemented for Overflow objects

But > is

It's ambiguous what should happen there honestly.

Without Simplify both expressions are returned non-evaluated, which makes sense, because overflows might represent different too large numbers, possibly, of different signs. But Simplify decides it knows better.

Oof

-3 in 30 minutes. I'm glad we're not on SE.

What's the cleanest way to turn f[a[b[c[d]]]] into f[a][b][c][d]?

@b3m2a1 do you have an example of what you have in mind? Do you mean something like ifun = ElementMeshInterpolation[mesh, solution]?

@user21 maybe but does that construct an interpolating function or does it remain the kind of thing where you can cleanly take Cartesian products with another one of those? I do a lot of solving a series of 1D problems and then working with a mesh built off of those as a direct product

Or just generally I work with functions defined over grids

Sometimes separable, sometimes not, but the underlying grid is really important

And to my limited knowledge it seems like FEM would need this kind of thing too

@b3m2a1, I have trouble understanding what you are looking for. Do you perhaps have a simple code example that shows the issue?

@user21 it's just always messy to work with this stuff is the issue

Here's an example of something I might have:

grid = CoordinateBoundsArray[{{-1, 1}, {-1, 1}}, {.1, .1}];
vals = Map[Norm, grid, {2}];

Except instead of Norm I have some somewhat more involved solution of a BVP

Now I need to do things with those vals, like numerically integrate them over their grid, numerically integrate their product with other functions, take FD derivatives, etc.

Basically really standard stuff

But it'd be much nicer to have as a proper object so I can do OOP with it

Also removes unpacking danger and various nasty performance issues

And I was hoping you'd needed the same kind of thing for the FEM stuff

I've been implementing a lot of it in OOP fashion piecemeal, but obviously I only make changes when I need them so the changes are all kinda scatter shot

@user21 that's...pretty good.

But I really do think having access to the underlying grid in the object would be nice

It allows you to easily transform your underlying space, or stuff without having to recompute anything (assuming it's like a rotation, translation, etc.)

On the other hand I do think I will use that in my code to do nastier integrations

@b3m2a1, there are a few caveats though, you could have a look at the ElementMesh generation tutorial

@user21 can I take a structured grid and directly go to a mesh?

Like if I had that CoordinateBoundsArray can I directly map over to an ElementMesh object?

And can it work with a non-tensor product mesh?

@b3m2a1 you could but that will produce a first order mesh.

The problem is that from a set of coordinates you typically can not infer a higher order mesh structure. So you'd need the connectivity.

Hmmm...I think that might be good enough for me.

I have a particularly nice grid and set of values in general for a lot of this stuff

Then the derivatives will not be as good as for a higher order mesh

I see that was a thing I was gonna ask about

It should not be hard to convert your grid to mesh. Here is one thing you could do:

mesh = ToElementMesh[Flatten[grid, 1]]

Ops:

mesh = MeshOrderAlteration[ToElementMesh[Flatten[grid, 1]], 2]

This will generate the additional coordinates to make this a second order mesh. If you can compute values at those points you should be fine.

Also, It should not be too hard to generate a QuadElement mesh for your data and convert that to a second order mesh.

Sounds good. Can I directly use some internal finite difference stuff on these mesh objects?

Also how will they work with something like this:

grid =
  Tuples[
   Sort@Eigenvalues@
     Normal@
      SparseArray[{Band[{2, 1}] -> -1., Band[{1, 2}] -> -1.}, {60,
        60}],
   2
   ];

That's another type of grid I work with reasonably often

If you do not have the connectivity use ToElementMesh[grid], else you can use the QuadElement mesh approach from above. You'd need to compute the incidences.

@user21 Sounds good. Any reason why it can't infer it from a structured grid of points ATM?

Have a look at FEM documentation, a lot of stuff is explained there. If you find things that are unclear, need improvement or something let me know and I'll try to improve.

ATM?

ATM->at the moment

So right now it constructs a Delaunay grid from points. While I could make ToElementMesh accept grids that would be a different kind of a mesh, I'll think about this.

I see. Sounds good to me. If I use any of this stuff and have suggestions I'll let you know.

Also if you do not use it let me know why - that may actually be more important for me

@user21 at this point I've implemented enough stuff to make the switch over potentially more work than it might be worth

OK, fair enough!

I can foresee myself doing a thing where I write something to convert from my internal structure to an ElementMesh, though, especially if ElementMesh can be used to compute FD derivatives and things

And then probably store the ElementMesh as a property using @JasonB.'s trick of backing up caches with an ExpressionStore[]

Internally are they pretty fast to build?

Like construct an ElementMesh object with the correct structure already in place

Those ElementMesh that we are taking about here should be fast, if not it's possible to tune them a bit.

Word

@b3m2a1 Git["add", "."] does not work/.

I'll give it a look

What do you mean with Like construct an ElementMesh object with the correct structure already in place

@Kuba Ah shit. What should that be doing?

@user21 like get all the arguments right so it doesn't have to guess or convert anything

"git add . stages new files and modifications, without deletions"

@Kuba oh it needs a directory passed

Yep

@user21 sure or whatever is the fastest construction syntax

That is problematic for two reasons. 1) When I need to change it, 2) it still does need to do checks. ElementMesh actually has options. But very careful here.

I'm trying to figure out if I should cache or if it's not worth it since they build so fast

@user21 hello :)

Try ToElementMesh if you need a speedup send me an example.

Sounds good

@Kuba good morning

@Kuba did you want something like this: Git["Add", dir, "All" -> True]? I think whatever parsing I'm doing with Git doesn't think "." is a directory.

RunProcess[{"git", "add", "."}] works. I think they are slightly different: stackoverflow.com/questions/572549/…

@user21 since I have you and @MichaelE2 here's another question. I want to add an "ExtrapolationHandler" to an existing InterpolatingFunction. Is there a good way to do this?

I don't know if I need to pull out the extrapolation grid and points first or something

@Kuba yeah Git tries to sanitize arguments and make sure all the ProcessDirectory stuff is behaving nicely

@b3m2a1 whatever you decide, just saying that this can be a frequent issue

@Kuba Sounds good. I need to go through that stuff and do a few little clean up tweaks and sanity checks.

I just haven't had the willpower/time recently

@b3m2a1 why can you not add it at construction time?

@user21 I constructed it deep, deep within some package and don't want to have to dig up how I did that and modify it

This is a one-off thing

@b3m2a1 I have never done that so do not know how to do it.

Sounds good. I'm sure there's a best way to modify these things on the fly that would be good to know.

@user21 for my case all I needed was:

hhh = $H5DipoleSurfaceInterps[[1]];
myGrid =
  Join[
   Tuples[hhh[[3]]],
   List /@ hhh[[4, 3]],
   2
   ];

At least in 11.3 the third element is the subgrids for a direct product grid

And the third element of the 4th is the vector of values

Ah or this:

Join[
 hhh["Grid"],
 Developer`ToPackedArray@
  Map[List, hhh["ValuesOnGrid"], {Length@hhh["Domain"]}],
 Length@hhh["Domain"] + 1
 ]

@b3m2a1 I did it here: mathematica.stackexchange.com/questions/19042/… Also this:

ifn = NDSolveValue[{y'[x] == y[x], y[0] == 1}, y, {x, 1}];
ifn2 = NDSolveValue[{y'[x] == y[x], y[0] == 1}, y, {x, 1},
   "ExtrapolationHandler" -> {Indeterminate &,
     "WarningMessage" -> False}];

$flags = {2, 2}; $warningbit = 0;
$extrapolationhandler = {2, 10};
handler = Indeterminate &;
warningQ = False;
ifn3 = ReplacePart[ifn, {
    $flags ->
     Switch[warningQ, False, BitClear, _, BitSet][
      Extract[ifn, $flags], $warningbit],
    $extrapolationhandler -> handler
    }];

ifn2 === ifn3

Descriptions of most the parts of InterpolatingFunction can be found here: mathematica.stackexchange.com/a/152861/4999

@MichaelE2 Thanks again for that heroic answer BTW

Unbelievable that it only has four upvotes... after I put mine in earlier today...