[WSG23] Daily Study Group: Wolfram Language Basics

Ideas
, , , , ,
1

A Wolfram U daily study group covering the implementation of Wolfram Language for tasks ranging from basic programming to video analysis begins on January 17, 2023 and runs through February 3. This study group will run on weekdays from 11:00AM–12:00PM Central US time.

This study group is an incredible way either to start learning Wolfram Language or to explore new functionality you haven’t yet used. We will cover a very broad variety of topics, including but not limited to image and sound analysis, symbolics and numerics, function visualization and even cloud computation and deployment. We will even cover useful tips and tricks to help you work efficiently with notebooks!

meechstogram.jpg
meechstogram.jpg2816×845 381 KB

No prior Wolfram Language experience is necessary. As usual, we will have questions, study materials, quizzes along the way to help you master the subject matter.

You can REGISTER HERE. I hope to see you there!

WolframUBanner_OP_1_CP__OP_1_CP_.jpeg
WolframUBanner_OP_1_CP__OP_1_CP_.jpeg1467×198 12.3 KB

12 Likes
2

Hi.

As someone with previous Mathematica experience (over 20 years ago!), I’m looking forward to this review. Since I work from an iPad, I’m interested in learning the differences between the desktop and on-line versions of the program. So far, the distinction between commands like CloudExport, and Export are lost on me. Hope we can (briefly) address these topics.

Look forward to getting started. Thanks.

J.

3

Hi J! We’ll talk a little bit about the difference between local and cloud functionalities for sure. Of course, if you want more information or clarification or would like to get into specifics more than we do in the lessons, you can submit your question for one of our weekly review sessions and I’ll go over it in more detail :).

Looking forward to seeing you there!

2 Likes
4

Arben, do you have a sampledata.xls file that we can download into our local computers? Alternatively, do you have the URL for a sampledata.xls? You may have identified teh URL in your presentation, but I didn’t write it down. TY.

5

Hey Phil! Good call—I’ve added that file to the Course Materials folder. The link should be in your reminder emails!

1 Like
6

Great content thus far…

I wanted to ask about wolfram being leveraged as part of a larger code base. How would that work?

7

Hi;

Yesterday I noticed that you used a picture of your cat as input to a Sin[] function. I was under the impression that all input to Sin[], Cos[], Tan[], ect. needed to be in radians and if the input was not in radians, then it had to be multiplied by 2 Pi to get it in radians.

Thanks,

Mitch Sandlin

8

Mitch,

Per the documentation for these functions, the arguments are assumed to be in radians. You can use the function Degree to convert between degrees and radians.

Hope this helps.

J.

9

Indeed, they are assumed to be in radians—but Sin (and the other trig functions) have an Attribute called Listable. This means that when you feed them a list of any kind, they automatically go inside the list and work at the lowest possible level: try, for example, Sin[{1,2,3}] or Sin[RandomInteger[{0,9},{5,5}] and you’ll see.

The magic (“”) here occurs when when feeding an image to Sin: some functions, when fed an image, bypass the Image part of the expression and work directly on the ImageData, e.g. the matrix of RGB pixel values of an image. Because a matrix of RGB pixel values is simply a nested list (height, width, then 3 color values per pixel), Sin is happy to go in there and work on all of the pixel values.

So, Sin[img] gives Image[Sin[ImageData[img]]], or: Sin of an image returns a new image where the R, G, and B values of every pixel of the image have had their sine taken. (And because Sin expects radians, it treats those values like radians.)

Hopefully that clarifies things!

TrigColors.nb (8.19 KB)

3 Likes
10

Arben,

One area I’ve struggled with concerns Levels of expressions. So in preparation for my question(s) concerning MapAt, and MapThread, I figured I’d study “the book” (Expressions—Wolfram Documentation). I do alright until almost the very end where negative Levels are introduced…

Level[u, {-1}] results in {a, a, a, a, f} because these are the bottom leaves on the TreeForm, as near as I understand it. Where things start going sideways is when Depth[] is introduced. The next example shows, Depth[g[a]] which returns 2. Why is it two? Is it because Depth counts the expression head, “g” as well as the argument “a” as a level?

IMG_1156.jpeg
IMG_1156.jpeg342×482 22.1 KB

The final example also doesn’t behave as I expect. It says, Level[u, {-2}] results in {g[a], h[a]}, but if we’re starting at the bottom of the TreeForm and proceeding up two levels, why aren’t {f[a], f[a], f[f]} also included? They all have two levels up from the bottom of the TreeForm…

2663IMG_1156.jpeg
2663IMG_1156.jpeg342×482 32.2 KB

1 Like
11

Can you explain the difference between Block[], and Module[] when used for local variable scoping? To me, but Block[] example isn’t clear…

12

From comments in the presentation today, I believe there is some other place that [many] questions are being asked/answered. I don’t see that area or any way to get to it. What am I missing? Help!

13

I see tomorrow is about visualization. I have a data-visualization project: create beautiful animations of our “Anatomy Trains”, and maybe an AT coloring book. About 20 years ago, Tom Myers authored “Anatomy Trains: Myofascial Meridians for Manual Therapists and Movement Professionals”. It’s a mapping of the major lines of tension in our structural network that give us structure, movement, and the ability to do work. Each line contains multiple muscles and tendons, with the lines passing through bones (but not at the ends of the bones). Myers describes them far more eloquently; anyone curious can see a brief description of each of the lines he wrote in this PDF file (jump to p. 12).

I would like to use Wolfram’s anatomy libraries to display a subset of human bones, muscles, and tendons. I think showing 1 or 2 lines would provide the most clarity. I’d use a 3D visualization allowing the user to rotate, zoom, and pan through the images. This sounds relatively straightforward to create the Wolfram Language code and publish as a notebook and/or a CDF.

One radical idea came to mind: it would be neat to allow a fly-through of the 3D model along a curve. The viewer could stop the fly-through at any point, and zoom/pan/rotate the model from that particular perspective. This is beyond my capability in the language: I found myself wanting a built-in operation to do fly-throughs of a 3D model. Allowing students to directly manipulate the models would be best, but it would be nice to also create videos of the lines.

Is my first part all doable? Do the built-in 3D viewers do what I need, or should I be wrapping this around a Manipulate[]?

14

Aha. I found the Q&A button in the BigMarker software while replaying today’s session. I’ll look for that icon tomorrow during the live session. Are the questions of other participants viewable, or can I only view my own questions and answers? TY.

15

Hey Phil—glad you found it, and hope you can make use of it for the rest of the sessions (And just to repeat: we collect all of these Q&As and upload them at the end of each week, as well as have a full session Q&A with questions submitted through the post-session survey.)

Questions and answers are, by default, not visible to other participants, but we can (and do) “publish” them so that they become visible. Not all questions will be published for everybody to see in real-time, but many will.

1 Like
16

Hi again Phil—the first part should be doable without issue with just the regular Graphics3D interface (e.g. what you see when you use Plot3D or anything like that). The second part is also doable, but in a few different ways… I think the best way would be to use Animate or Manipulate (along with some of the camera positioning/perspective options). This way, you could set up the visualization to animate however you like (w.r.t. the flythrough and all), and the user could pause it at any point to rotate it and so on because in the end, it’s still a Graphics3D object like discussed above.

This could be a bit tricky to set up, as flythroughs are much easier to explain than they are to code, but it can absolutely be done. Exporting a video would also be completely trivial!

3 Likes
17

Hi J—if it works for you, I’m happy to discuss that in some depth at Friday’s review session so everybody can see it and hear it explained. (If you need an answer sooner, I could write it up here.)

1 Like
18

Friday is fine. Thanks!

1 Like
19

Hi J—some great questions here, and I’m glad that you’re perusing the documentation and getting some evidently great use of it. Let’s see if I can’t help out with these questions, one by one:

Why is it two? Is it because Depth counts the expression head, “g” as well as the argument “a” as a level?

As I understand it, yes—that’s exactly why. Since you’ve asked specifically for the depth required to write g[a] (rather than, say, a), you’re getting the level at which g[a] could first appear, traversing a tree down from the top. The a inside the g[a] is indeed one level deeper (at level 3, in u), but any non-atomic expression will by necessity span multiple levels when asked for in this manner, right? I.e., any non-atomic expression can be represented as head[el,...], so if you ask for the Depth of such an expression, we return the depth corresponding to where that expression could begin, despite the fact that the el exists one level deeper (and el could itself be compound, so it could keep going down the tree).

The final example also doesn’t behave as I expect. It says, Level[u, {-2}] results in {g[a], h[a]}, but if we’re starting at the bottom of the TreeForm and proceeding up two levels, why aren’t {f[a], f[a], f[f]} also included? They all have two levels up from the bottom of the TreeForm…

I agree that this is a confusing, and I think it’s partly our eyes playing tricks on us because of how TreeForm represents expressions; I would have guessed the exact same thing that you did. However, there’s one clue in your image: what’s special about the two branches which were actually returned? They’re vertical. Why should that matter? It seems like it shouldn’t, but…

Take a look at u once again. It’s:

u=f[f[g[a], a], a, h[a], f]

Notice what’s missing: do you see any f[a] or f[f]? They don’t actually exist in u; they only exist if you’re extracting certain branches within u. Level is just telling us which expressions within u which explicitly exist and have a level of precisely -2—and that’s g[a] and h[a], and nothing else.

Hopefully that’s a sufficiently satisfying response! I’ve asked our tech folks if this understanding is correct, and will update here when I hear back.

2 Likes
20

Thanks for clarifying these issues, Arben!