| Re: What are the rules for automatic removal of singleton dimensions, and can I have a way of disabling them, please? [message #82630 is a reply to message #82553] |
Fri, 28 December 2012 02:28   |
Mats Löfdahl
Messages: 263
Registered: January 2012
|
Senior Member |
|
|
Den fredagen den 28:e december 2012 kl. 00:06:56 UTC+1 skrev Tom Grydeland:
> On Thursday, December 27, 2012 12:12:40 AM UTC+1, Mats Löfdahl wrote:
>
>> Den onsdagen den 26:e december 2012 kl. 15:12:35 UTC+1 skrev Tom Grydeland:
>
>>> In my mind, the fix is to make things behave _less_ arbitrarily, not _more_ so.
>
>> So then we agree.
>
> Good!
I guess we just do not agree on what is less or more arbitrary... :o)
I agree that it may have been a bad design decision to make IDL arrays behave in this way in the first place, although I don't know all the reasons behind it. But, as has been pointed out, the chance that IDL's default behavior would be changed in this respect is slim. What is then less arbitrary, to introduce a compile option that would make your code more difficult to read (because it would work differently from other IDL code) or to make core IDL functions work consistently with the way arrays are designed? Apparently we answer this question differently and that is fine.
So, while I don't begrudge you the solution you like, if that compile option is implemented I probably would not use it. And if it is implemented, I think it would be a good idea to make total() and other similar functions work properly anyway. Median() with the dimension keyword for example. I have sometimes wondered why mean and stddev doesn't have that keyword, but now I see that it was introduced in IDL v 8. I don't have that version so I can't test how extra dimensions are handled for those functions but I guess they have the same problem as total() and median().
For the functions I mentioned above, the exception would be very simple to handle. Unless my thinking is completely off today, total(), mean(), and median() should just return the input array if the requested dimension is larger than the number of dimensions, while stddev() should return an array of the same type and dimensions but filled with zeros. Shouldn't be too hard do figure out how to handle the higher moments.
Or would this lead to problems in other parts of IDL?
>>> That solution is worse than the problem, IMO. How many other functions will I have to replace?
>
>> How would I know? Total() is the only one you mentioned...
>
> Yes -- I believe in making my posted examples as succinct as possible.
Fine, I just didn't realize it was only an example. I agree that the problem should not be solved for total() only. I just meant that if the particular code you are working on for the moment suffers from this problem only with the total() function, your code might be easier to read (and possibly faster if you now feel you have to reorder the dimensions for large arrays?) by making a private version of total() with the simple exception I mention above.
> You pointed out something of which I wasn't aware -- that adding an extra [ ... , 0] index does not raise an exception or change the returned values. This is valuable information, but not something I would base my code on.
I think you could. It seems as unlikely that this would change as it is that the automatically removed dimensions would be ... well ... removed.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
