so I had a response variable that was not normally distributed and was negatively skewed. So I tried many different approaches like using log, cube root but none did the trick. Finally I tried using sqrt(max(x+1) - x) and the distribution finally appeared to be normal. My problem is, I have read from some articles that the square root transformation is used for positively skewed data. Hence, my question is whether sqrt(max(x+1) - x) can be considered as a square root transform ? If not, what is it called then?
I think you can still consider it a square root transformation, but it is one that is specifically designed to work with negative skews. The normal square root transformation works only well with positive skews.
Related
I am currently learning how to sculpt in Blender; working on my own projects after completing BlenderGuru's Beginner & Intermediate classes, and some of Grant Abbitts videos with pleasing results. I am trying to sculpt a plasmapistol with a skull on it, which can be seen in the reference photo that I have provided.
However, when I sculpt, I get these really odd linear artefacts (See picture below, circled in black). I added a Subsurf Modifier to the primitive UV Sphere, with the Viewport and Render Values set to 4, so it is a fairly fine mesh. However, these still artefacts occur.
I assume it is due to the stretching of the polygons when I grab the sphere with the Snake Hook tool and deform it to encompass the frontal part of the skull.
EDIT: Whilst writing this comment I went back, and switched on Dynamic Topology with Relative Detail selected.
It appears that I am no longer getting the issues that I was getting last night with the linear artefacts.
Can I confirm that these problems are a result of having the incorrect Dynamic Topology settings for using the Snake Hook Tool; I was using Constant Detail instead of Relative Detail, or is this being caused by another issue?
Also, any advice on avoiding common pitfalls when choosing the settings in sculpting would be most appreciated.
I will continue to ask this question incase anyone has a similar problem and it can be resolved by reading this.
Sculpt, showing lineations
Experimenting with Dynamic Topology
In Object Mode, does the object have uniform X, Y, & Z scaling? If not, you can apply the scale from the object menu.
Object ‣ Apply ‣ Scale / Rotation & Scale
I'm new to CGAL and I'm trying to cut a cube with an arbitrary surface mesh in 3d (no self intersections, not closed/no volume). The goal is to get a volume which consists of one "side" of the cut cube, closed by the part of the surface inside the cube.
The surface itself consists of unordered triangles which should have the same winding order (consistent normal directions) but have no neighborhood information and could contain same points multiple times for different triangles.
I tried to use the clip function, like:
CGAL::Polygon_mesh_processing::clip(cube,surface,true);
Which of course does not work because the surface is not closed (as far as I understood). But It shows the idea on how the operation should work.
Boolean operations (https://doc.cgal.org/latest/Polygon_mesh_processing/index.html#title14)) cannot be used for this as well since they are calculated on volumes and the surface has no volume.
I also thought about extending the outside of the surface so that it is closed. This, however, does not seem like a good approach.
Sadly, my research on similar problems was not successful.
I'm pretty sure that there is a nice way to do this in CGAL. Maybe someone with more experience in CGAL knows how to do this.
What would be the best approach for getting this volume?
Regards
EDIT:
By removing redundant points in my surface mesh I was able to get clip to work. Nevertheless, I do not always get the right side of the volume, even though the winding order should yield normals which point to the outside.
Is it necessary to calculate the normals and pass them as an extra parameter (see here) of the surface before the cut in order to always get the same "inner" side of the volume?
Also, the clip function seems to be quite slow. I have to do this cut for a very high number of cubes and different surfaces.
I use CGAL as header only lib and without GMP and MPFR, since it crashed my other application. How big is the speedup using these libraries and are there any other tricks which can be used to speedup computation, e.g. using parallelization?
I saw that CGAL uses Intel's TBB which. But in the header files which are included by the clipping algorithm CGAL_LINKED_WITH_TBB is not tested.
Thanks
It was a problem with the clipping mesh. Clipping could not be done properly. I increased it size and now it always intersects the volume.
I'm not sure what is going wrong here. It works in some projects, but not in others. I can't figure out what the difference is between them. To test the problem, I created a point set with a single point at a position I am sure is inside the cube. When I call IndexAtPosition, I sometimes get obviously wrong answers. For example, I sometimes get inline or crossline indexes that are negative or way beyond the maximum index. The z-dimension index also comes back with a very unrealistic answer too.
I am fairly certain that my data is all consistent, i.e. same domain and CRS. There must be some settings I'm not checking.
My guess is that your point is a point like x, y, 1000m in depth
the cube however is probably in the time domain. So if you try to find a point in the cube you are going to be looking at x,y, 1000Seconds. This would be VERY far out of range and would give you a crazy number for your k index (super high). Based on the angle from north your i,j could be crazy too that far away from reality. You need to have your point in time or some way to convert it from Depth to Time.
Unfortunately, I made a mistake. One of my data points was in fact outside of the cube area when the cube was rotated.
The affine transforms Apple use have "scale" defined as "does not affect translation"
This seems to me completely wrong, and doesn't match what I'd expect from normal affine transforms (where a scale multiplied by a translation DOES affect the translation), and makes it extremely difficult to work with real-world problems, where "scaling" is expected to scale the entire co-ordinate system, not just the local co-ords of a single object at a time.
Is there a safe way within Apple's library to workaround this problem (i.e. make "scale" apply to the whole matrix, not just the non-translation parts)?
Or have I made a stupid mistake and completely misunderstood what's happening with the scaling, somehow?
I'm pretty sure that just means it doesn't affect the translation values in the matrix. CGAffineTransform isn't some special brand of math, it's just a regular transformation matrix. It works like any other transformation matrix you've ever used.
Ah. Embarassing. My mistake: arguments to concat were wrong way around! At least I can leave this here and hopefully help the next person to make such a dumb mistake.
I had a Concat call with the arguments the wrong way around; obviously, "translating" a "scale" works as expected - the scale doesn't affect the translate!
When I googled this issue, I hit a couple of pages that talked about CGAffineTransform doing scale and translate independently. Confirmation bias :( I read that and assumed it was true. Doh.
FYI: CGAffineTransformConcat( A, B ) ... does: Matrix A * Matrix B ... i.e. "A's effects first, then B's effects"
So, make sure your scaling matrix is the second argument (or the "later" argument if you have a chain of nested Concat calls).
How can I find the maximum number of edges from a graph using only a limited number of nodes say N nodes. A selected edge uses both sides of it.
A known problem. Sounds as though your problem is known as k-densest subgraph problem (your N playing the role of k).
Bad news: This problem is known to be NP-hard, even if none of your IPs occur more than three times or the input graph is bipartite. Are you aware of any other special properties of your graph?
More bad news: From a quick look around the recent literature, it looks as though not even algorithms with good error bounds are readily available. To my mind, the problem could be nasty even with "only" 100 input nodes.
Best of luck!