Encryption using Fast Fourier Transform

[altenbach]

---

@RTSLVU wrote:

Sheese where were you guys 6 years ago when I spent 10 minutes writing this to answer a question on encryption using LabVIEW? 😛

---

Found it and posted a quick followup. 😄

[marshaul]

Can you post

---

@altenbach wrote:

Yes, we need to protect from zero-length keys, but the math is especially simple (in=out) in that case 😄

Here's what I might do. The loop can even be parallelized, but I doubt it would make a big difference. (Same code for encryption and decryption.)

---

Can you please share this VI? This may seem ridiculous (then again, LabVIEW is a truly ridiculous thing), but I've spent about 30 minutes trying to figure out what on earth that array function is. God forbid things be named or otherwise findable. 

[Xonmyth]

I think the function is 

[wiebe@CARYA]

If you turn on text in the palette...

...you'll see the function names:

You don't need the name; you can match the function from the palette by how it looks.

Granted, it does help to have 25 years of experience. 😁

It doesn't help that the appearance changes over versions and when function inputs or options change...

[marshaul]

---

wiebe@CARYA wrote:

If you turn on text in the palette...

...you'll see the function names:

You don't need the name; you can match the function from the palette by how it looks.

Granted, it does help to have 25 years of experience. 😁

It doesn't help that the appearance changes over versions and when function inputs or options change...

---

Yes, I'm aware of how the palettes work. The problem is, that block doesn't have the same icon in the palette as it does on that vi, making it absolutely, completely less than useless. 

So, yeah. Ridiculous, like I said. 

[billko]

---

@marshaul wrote:

---

wiebe@CARYA wrote:

If you turn on text in the palette...

...you'll see the function names:

You don't need the name; you can match the function from the palette by how it looks.

Granted, it does help to have 25 years of experience. 😁

It doesn't help that the appearance changes over versions and when function inputs or options change...

---

Yes, I'm aware of how the palettes work. The problem is, that block doesn't have the same icon in the palette as it does on that vi, making it absolutely, completely less than useless. 

So, yeah. Ridiculous, like I said. 

---

Sorry I have trouble taking a person's opinion of LabVIEW seriously that calls nodes on the palette "blocks". Calling them "blocks" is ridiculous. VIs. Functions. Even primitives. Not "blocks".

[Bob_Schor]

---

@marshaul wrote:

---

Yes, I'm aware of how the palettes work. The problem is, that block doesn't have the same icon in the palette as it does on that vi, making it absolutely, completely less than useless. 

---

When I started learning LabVIEW, I also didn't notice that many of the Array functions are written to deal not only with 1D arrays (where they have one input for the index) but with 2-D, 3-D, ...n-D arrays just by "pulling down" the lower edge of the function to "spawn" another "Index Input".  Indeed, one of my first posts on this Forum involved a (maybe 3-)D array, and I'd actually wired "0", "1", and "2" into the three left-hand Index inputs.  Some kind soul (may have even been @Altenbach) pointed out to me I could save a lot of time by leaving them "unwired", whereupon they take up the sensible "default" assignments 0, 1, 2, ... 

So this "logical feature" that allows, say, Index Array, to work for arrays of any dimension in an "intuitive" manner is a feature, sensible, and not a "bug".

Bob Schor

[altenbach]

---

@marshaul wrote:
Yes, I'm aware of how the palettes work. The problem is, that block doesn't have the same icon in the palette as it does on that vi, making it absolutely, completely less than useless. 

So, yeah. Ridiculous, like I said. 

---

• Chances are that a "real" LabVIEW programmer does not try to recreate code given a picture. That would be ridiculous!
• Chances are that a "real" LabVIEW programmer uses Quick Drop and never even looks at the palette.
• A palette that would contain pictures of every single polymorphic alternative of each function (limited to e.g. 3D max. dimensions) would be 10x lager, making finding any specific function 100x harder. Nobody wants that! 😮 (Palette bloat is a serious problem and I tend not to install even e.g. OpenG tools.)

I post code pictures if the code is simple and fully visible (there is even a note that the other case is empty!). This makes it version invariant and students learn something when trying to recreate it from scratch (hint, hint!). 

I strongly recommend not to use AI for now. For example Google thinks that this function is "index array" instead of "reshape array". 😮

[avogadro5]

---

@billko wrote:

---

@marshaul wrote:

---

wiebe@CARYA wrote:

If you turn on text in the palette...

...you'll see the function names:

You don't need the name; you can match the function from the palette by how it looks.

Granted, it does help to have 25 years of experience. 😁

It doesn't help that the appearance changes over versions and when function inputs or options change...

---

Yes, I'm aware of how the palettes work. The problem is, that block doesn't have the same icon in the palette as it does on that vi, making it absolutely, completely less than useless. 

So, yeah. Ridiculous, like I said. 

---

Sorry I have trouble taking a person's opinion of LabVIEW seriously that calls nodes on the palette "blocks". Calling them "blocks" is ridiculous. VIs. Functions. Even primitives. Not "blocks".

---

And here's the block diagram, containing 0 blocks...

[BertMcMahan]

---

@billko wrote:

---

---

Sorry I have trouble taking a person's opinion of LabVIEW seriously that calls nodes on the palette "blocks". Calling them "blocks" is ridiculous. VIs. Functions. Even primitives. Not "blocks".

---

I mean, it is called the "block diagram" 😉