Jump to content

Inplace Structure and Datatype Conversion


Recommended Posts

Are you going to explain that comment...

Ohhhh - I get what you mean. Um, in that case, they are indeed both 32 bit, but they're not the same datatype. I agree that it would be nice to see some implaceness here, but it's certainly not something I would have expected. More importantly, why would you want to do that? Can't you just use the I32 convesion outside of the structure and get implaceness, or are you trying to demonstrate the root issue that would normally be applied to something bigger?

Link to comment

Sorry for the brusqueness. I thought you knew something about LabVIEW's internal memory and were being cute... :unsure:

I was trying this inplace trick because when I tried doing the conversion normally, it was not done inplace. I was hoping that the inplace structure would get rid of a buffer allocation on the output of a Single->U32 conversion

Link to comment
Sorry for the brusqueness. I thought you knew something about LabVIEW's internal memory and were being cute...

No worries - I don't need to know anything about LabVIEW's internal memory to be cute ;)

I was trying this inplace trick because when I tried doing the conversion normally, it was not done inplace.

I can understand why the inplace structure doesn't have it yet, but I'd expect the normal manual conversion to have it :(

Link to comment
I'm surprised there's no allocation dot on the output of the decimate.

OK - now I'm really confused - why would there be a allocation dot on the output of the decimate? The output is still a 1D array of SGLs - it's just got fewer elements.

Link to comment

OK - now I'm really confused - why would there be a allocation dot on the output of the decimate? The output is still a 1D array of SGLs - it's just got fewer elements.

I didn't realize that it would be able to reuse the same space for the new array, especially given the fact that one is a decimation of the other (i.e. the output elements are not contiguous in input array).

Link to comment

I didn't realize that it would be able to reuse the same space for the new array, especially given the fact that one is a decimation of the other (i.e. the output elements are not contiguous in input array).

I'm scratching my head as well. Are you possibly confusing array copies with coercion?

Link to comment

Why can't I do this?

post-4344-124819521441_thumb.png

Both data type are 32-bit, so is there any reason why I shouldn't be able to do that conversion inplace?

Pure speculation here...

My guess is that in memory, the computer not only needs to know the value of the 32 bits, but it needs to know the type of data it is as well. It's been eons since I've done any C/C++ programming, but I believe changing the data type in place would mess up the pointers. They would think they are still pointing to a sgl but are in fact pointing to an int. ('New math' takes on a whole new meaning!) Therefore, type casting will always create a new buffer with a new pointer (and new pointer type) pointing to it.

Link to comment
I didn't realize that it would be able to reuse the same space for the new array, especially given the fact that one is a decimation of the other (i.e. the output elements are not contiguous in input array).

Right - the contigious part doesn't have anything to do with whether it can be inplace or not - it's about the space (and the datatype of that space(s)), not the values.

Link to comment

It's a wonderful wonderful place to be :) As an aside, anyone hear about the new "Alice in Wonderland" movie coming out? Depp and Burton - here we go again...

Well just to stay of topic, a lot of that was filmed last year down in Cornwall and Devon, a friend of mine who is a school teacher took one months unpaid time of to be an extra in the film.

She said it was a very interesting but bizarre experience.

Link to comment

It looks like the decimate never shows an allocation.

Given that the decimated arrays each has an extra 4 bytes (for dimSize) padded onto the front, they couldn't all be re-using the same memory... The sum of the parts would be greater than the whole.

wacko.gif

Link to comment

An array is an array - don't they all have dimSize at the front?

Right, so I think that what he's saying is that when the decimation turns an N-element array into 4 N/4-element arrays, there should be 3 extra dimSizes as compared to the original array. That should mean that more memory is needed.

Link to comment
Right, so I think that what he's saying is that when the decimation turns an N-element array into 4 N/4-element arrays, there should be 3 extra dimSizes as compared to the original array. That should mean that more memory is needed.

That might be the case if you wire out two or more of the decimated arrays, but not in the BD above where only one of them is wired out.

Link to comment

Well just to stay of topic, a lot of that was filmed last year down in Cornwall and Devon, a friend of mine who is a school teacher took one months unpaid time of to be an extra in the film.

She said it was a very interesting but bizarre experience.

Dude! You have a friend who was an extra in a Burton film?! worshippy.gif

Tim Burton is brilliant. One of my all-time favorites. thumbup1.gif

I remember watching Mars Attacks! with my 10 and 12 year old (at the time) nephews. Talk about a party. laugh.giflaugh.giflaugh.gif

PaulG now returns this hijacked thread to it's proper subject. ph34r.gif

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.