TeX, LaTeX and Friends

Kurt

00:00

@marmot no, it is not. Perhaps next time?

marmot

@Kurt We are still in the good range.between 100k and 1M there won't be a paliprime,

Kurt

@Sebastiano Perhaps this answer of mine can help you correcting some issues? See tex.stackexchange.com/a/125404/16550

marmot

04:01

@HenriMenke Rather than reinventing the wheel, I would like to ask you what in your opinion the simplest way would be to associate with a point a third coordinate, z. Have you thought about this? Would you declare a shape for that?

Henri Menke

04:18

@marmot Are you talking about TikZ?

marmot

@HenriMenke Yes.

Henri Menke

@marmot Are you referring to \pgfpoint which only takes two arguments?

marmot

@HenriMenke Yes, sort of. Or the fact that with calc I can only retrieve \x1 and \y1, but not \z1, say. (I understand that \x1 and \y1 are not the input coordinates.) It would be great to be able to find out what z value was used when setting the coordinate.

Henri Menke

@marmot Adding \z<n> to the \let expression should be possible.

marmot

I tried
\documentclass[tikz,border=3.14mm]{standalone}
\usepackage{tikz-3dplot}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}
\path (0,0,1) coordinate (A) (2,1,2) coordinate (B);
\path let \p1=(A), \p2=(B) in
\pgfextra{\typeout{A=(\x1,\y1,\z1),B=(\x2,\y2,\z2)}};
\end{tikzpicture}
\end{document}
but it causes an error.

Henri Menke

04:25

@marmot Hm, it's actually not easily possible. The \x<n> and \y<n> registers give you the position on the canvas which is naturally 2D.

marmot

Yes, I know. There are crazy ways out like
\documentclass[tikz,border=3.14mm]{standalone}
\usepackage{tikz-3dplot}
\pgfkeys{/tikz/3D coordinates/.is family}
\tikzset{store 3D coordinates/.code args={#1 at (#2,#3,#4)}{
\typeout{#1 at (#2,#3,#4)}
\globaldefs1
\pgfkeys{/tikz/3D coordinates/#1/.is family,
/tikz/3D coordinates/#1,
x/.initial=#2,y/.initial=#3,z/.initial=#4}
\typeout{try:\pgfkeysvalueof{/tikz/3D coordinates/#1/x}}},
3D coordinate/.style args={#1 at (#2,#3,#4)}{%
store 3D coordinates={#1 at (#2,#3,#4)},

@HenriMenke but ^^^ this is crazy (not only because of \globaldefs1.

Henri Menke

04:45

@marmot I quickly hacked a proof of concept.

\documentclass[tikz,border=3.14mm]{standalone}
\usepackage{tikz-3dplot}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}
\path (0,0,1) coordinate (A) (2,1,2) coordinate (B);
\path let \p1=(A), \p2=(B) in
\pgfextra{\typeout{A=(\actualx1,\actualy1,\actualz1),B=(\actualx2,\actualy2,\actualz2)}};
\end{tikzpicture}
\end{document}

In the log I get

A=(2,1,2),B=(2,1,2)

@marmot ^^^ Is that what you are looking for?

marmot

@HenriMenke Yes, precisely. That's fantastic! (Maybe \rawx etc, instead of \actualx etc)?

Henri Menke

@marmot That leave a lot of questions though. What about polar coordinates? \rawradius and \rawangle? What about elliptical coordinates where you have (45:1 and 2)?

marmot

@HenriMenke Yes, in principle these are all valid questions. There is, however, one conceptual difference. Given a coordinate, I can use the calc syntax to find out what \rawradius and \rawangle are. On the other hand, this is impossible for \rawx, \rawy and \rawz because they get projected to \x and \y, so there is some loss of information.

Henri Menke

@marmot I'll add them but leave them undocumented for now.

marmot

@HenriMenke That's absolutely great! Thanks a lot!

Henri Menke

05:05

@marmot Carefully read the commit message: sourceforge.net/p/pgf/git/ci/…

marmot

Thanks! There is a huge problem when trying to make `\coordinate (A) at (1,2,3);
\path let \p1=(A) in ...` work?

In your above code it seems to have worked.

Henri Menke

@marmot Yes, because (A) has already been transformed into a pgfqpoint.

@marmot No, it didn't. The output was A=(2,1,2),B=(2,1,2), but expected was A=(0,0,1),B=(2,1,2)

marmot

@HenriMenke Even if it worked for just one coordinate at a time that would be great.

@HenriMenke You are probably telling me that, once B is defined, the z coordinate of A is inevitably lost, right?

Henri Menke

@marmot Yes, that is by virtue of the way I implemented this, namely just making \pgftemp@x,y,z global.

marmot

@HenriMenke I see. (I'll just look if there is something I can do. Most likely the answer will be no.)

Henri Menke

05:29

@marmot I added an additional check, so you don't have global definitions leaking into \rawx,y,z.

marmot

@HenriMenke Thanks!

manooooh

If you have to show the projection of a point into the coordinate axes, would you use dotted or dashed?

Henri Menke

@marmot Now the previous example just gives A=(,,),B=(,,) because no literal 3D point was supplied.

marmot

@HenriMenke I see. Yes, that's a tricky business. (My above crazy code might not be entirely crazy because the user has to explicitly specify that these are 3d points.)

@manooooh That's completely up to you. You could also take solid thin gray lines, for instance.

@HenriMenke In any case, what you are showing is that one could store the x, y and z coordinates by something that saves \pgftemp@x,y,z somehow just after the point has been set. This is certainly more elegant than what I had.

Henri Menke

@marmot One possibility would be to store the “declared” coordinates alongside the proper coordinates when defining a node.

marmot

05:37

@HenriMenke Are you saying one could declare a new shape for that?

Henri Menke

@marmot I wanted to have it generically for any named coordinate.

marmot

@HenriMenke Sure, that would be even better. I must say I have no idea how to do that.

Henri Menke

06:22

@marmot How about this?

\path (0,0,{cos(45)}) coordinate (A) (2,1,2) coordinate (B);
\path let \p1=(A), \p2=(B) in \pgfextra{\typeout{A=\coord1,B=\coord2}};

Output is

A=(0,0,{cos(45)}),B=(2,1,2)

marmot

@HenriMenke That would be absolutely wonderful!

Henri Menke

@marmot That also supports polar and everything else.

@marmot But you'd have to parse the components yourself.

marmot

@HenriMenke Yes, that's neat. (Yes, there is no problem in parsing the coordinates. The only conceptual problem is that so far there is some information lost, which is irrecoverable.)

Henri Menke

@marmot With the current solution options are lost, i.e. ([xshift=2pt]0,0,{cos(45)}) loses stuff in square brackets.

@marmot But storing options globally as well is really easy.

marmot

@HenriMenke I think this is all minor in comparison. (In a 3d picture ([xshift=2pt]0,0,{cos(45)}) is not a very helpful coordinate because the shift is in the screen coordinates, not in the 3d ones, so it is very confusing.)

Henri Menke

06:38

@marmot Again, read the commit message: sourceforge.net/p/pgf/git/ci/…

marmot

06:49

@HenriMenke Thanks!

Paulo Cereda

08:15

@yo' Hi Tom!

Paulo Cereda

08:29

Microsoft Super Bowl Commercial 2019: We All Win (Extended Version)

►

yo'

08:50

@PauloCereda hi!

Paulo Cereda

@yo' what's up, pal?

For those who like keming, there's a Reddit community about it, r/keming. Some jewels...

yo'

09:12

@PauloCereda quite a lot of tough stuff, actually, was even calling a laywer because of some scout stuff, sand that's not really confortable of course...

And other things, at works etc.

Paulo Cereda

@yo' oh my, I hope everything gets sorted out...

@yo' ooh

yo'