On Mon, 24 Mar 2008 10:54:46 -0700, Eric Jacobsen <eric.jacobsen@ieee.org> wrote:>On Mon, 24 Mar 2008 17:38:57 +0100, "Martin Blume" ><mblume@freesurf.ch> wrote: > >>"Eric Jacobsen" schrieb >>> >>> It's evidently file related, as I copied this back into >>> a new file and it ran fine. I took the 'end;' out of >>> the old file [...] >>> >> >>Could there be a CR/LF vs CR problem (linux to Windows >>file transfer)? >> >>If you open the file in Notepad and all lines show as only >>one line, then you have a file that follows the Unix file >>convention (CR or LF only, I keep forgetting which one it is). >>Open it in Wordpad, save it again and from then it should show >>up also in Notepad correctly. >> >>This is a long shot, I don't know whether Octave is susceptible >>to this type of issue. >> >>YMMV. >>Martin > >Well, I tried that and resaving it with either Wordpad or Word didn't >make any difference.Crap, I meant resaving it with Wordpad or Notepad... Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Questions regarding Octave
Started by ●March 23, 2008
Reply by ●March 24, 20082008-03-24
Reply by ●March 24, 20082008-03-24
On Mon, 24 Mar 2008 10:54:46 -0700, Eric Jacobsen <eric.jacobsen@ieee.org> wrote:>On Mon, 24 Mar 2008 17:38:57 +0100, "Martin Blume" ><mblume@freesurf.ch> wrote: > >>"Eric Jacobsen" schrieb >>> >>> It's evidently file related, as I copied this back into >>> a new file and it ran fine. I took the 'end;' out of >>> the old file [...] >>> >> >>Could there be a CR/LF vs CR problem (linux to Windows >>file transfer)? >> >>If you open the file in Notepad and all lines show as only >>one line, then you have a file that follows the Unix file >>convention (CR or LF only, I keep forgetting which one it is). >>Open it in Wordpad, save it again and from then it should show >>up also in Notepad correctly. >> >>This is a long shot, I don't know whether Octave is susceptible >>to this type of issue. >> >>YMMV. >>Martin > >Well, I tried that and resaving it with either Wordpad or Word didn't >make any difference. > >HOWEVER, somewhere along the way of porting all this crap across >numerous machines (all Windows-based, btw), the filename and extension >became all caps, i.e., BUTTGEN.M. So I renamed the file to buttgen.m >and PRESTO! It works. Jeebuz. > >So I changed the name of another, more complex file, from all upper >case to all lower case and that runs and generates a nice plot of a >spectrum (I'm guessing that's what it's supposed to do, it's another >really old file). In any case, it didn't generate an 'undefined' >error and it did previously when I tried that same file in Octave. > >This doesn't explain why some of the new files I created were >problematic, but I'll poke around some more and see what I can sort >out. > >Progress in any case, even in the right direction! ;)Quick follow-up: The problem appears to be two-fold: the extension needs to be lower case, and the file name is case-sensitive. Even if the extension is lower case if the filename is typed in wrong, e.g., if it's mixed-case and you get one letter wrong, it's wrong. The irritating thing is that this results in the bizarre "undefined near line xx column yy" error rather than, "can't find that file" or something actually useful. So, does it really find the file and just not interpret it correctly, which is a little odd, or is it just making stuff up? ;) Strange and unhelpful in any case, but I've now got all sorts of files running doing useful things. It does appear that the plotting functions are a bit to get used to and may have lost some functionality from the last version of Matlab that I was used to, but I need to get into that a bit further. The plot window discipline seems a bit off as well, since it'll intrude into a Remote Desktop window and that's very unusual and I'd consider it a bug. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Reply by ●March 24, 20082008-03-24
On Mar 24, 9:56 am, robert bristow-johnson <r...@audioimagination.com> wrote:> On Mar 23, 11:11 pm, dbd <d...@ieee.org> wrote: > > > > > On Mar 23, 7:49 pm, robert bristow-johnson <r...@audioimagination.com> > > wrote: > > > > ... > > > yer not the only one, after all it seems intended to be a gnu freeware > > > counterpart to MATLAB. i contacted Eaton (and got on the Octave > > > developer's list for a little while) to propose they do to Octave what > > > i have, for more than a decade, been trying to get MATLAB to do: > > > generalize handling array indices so that an array can have non- > > > positive integer indices; so that the indices of the upper-left corner > > > need not always be (1,1). > > > > fell on deaf ears. > > > > r b-j > > > So, doesn't that make Octave an accurate counterpart to MATLAB? > > > But, in the spirit of GNU freeware, what did they say when you offered > > to implement the change for them? > > i can't do it all by myself. i downloaded the whole code base, even > got it to build on my Linux machine, but i could not, for the life of > me, figure out specifically where they were doing their index > calculations. specifically, for arrays of two dimensions or more, the > *must* be subtracting 1 from the index and multiplying it by the row > length (or, in MATLAB/Octave i think it's the column length) and > adding that to the "less significant" index where either they subtract > one and add it to the array base address, or they don't bother to > subtract 1 and the base address is fudged by 1. also this should be > intimately related to the index bounds checking that either MATLAB or > Octave do. i can't find that and no one who was a regular developer > would help me because (like the Math Works) they didn't think that > this modification was a good thing to do which is still just > inexplicable to me. > > the Octave source code is spaghetti. it's shit. i cannot believe > that people take any pride in code written like that. (well, i dunno, > i see a lot of shit code where i work.) > > r b-jYour experience with the code seems to be good evidence that the cost benefit ratio is too high to justify the effort of the conversion. Dale B. Dalrymple
Reply by ●March 24, 20082008-03-24
Eric Jacobsen <eric.jacobsen@ieee.org> writes:> [...] > Quick follow-up:I submit that much of the bizarredness you're experiencing is due to your choice of operating system and toolsets. I have had none of these problems under linux (Fedora 8). Installing octave took two lines: yum install octave yum install octave-forge That's it and I'm up and running. -- % Randy Yates % "So now it's getting late, %% Fuquay-Varina, NC % and those who hesitate %%% 919-577-9882 % got no one..." %%%% <yates@ieee.org> % 'Waterfall', *Face The Music*, ELO http://www.digitalsignallabs.com
Reply by ●March 24, 20082008-03-24
"Eric Jacobsen" schrieb> > > > Well, I tried that and resaving it with either Wordpad > > or [Notepad] didn't make any difference. > >Well, if you see a multiple-lines file as a multiple-lines file in Notepad, then it isn't this problem of CR/LF (DOS) and CR (Unix) line-ends.> > > > HOWEVER, somewhere along the way of porting all this crap > > across numerous machines (all Windows-based, btw), the > > filename and extension became all caps, i.e., BUTTGEN.M. > > So I renamed the file to buttgen.m and PRESTO! > > It works. Jeebuz. > >You probably ported between FAT (case-insensitive) and NTFS (case-sensitive, at least on the file-system level, the CMD shell seems to ignore that).> > Quick follow-up: The problem appears to be two-fold: the > extension needs to be lower case, and the file name is > case-sensitive. Even if the extension is lower case if > the filename is typed in wrong, e.g., if it's mixed-case > and you get one letter wrong, it's wrong. > > The irritating thing is that this results in the bizarre > "undefined near line xx column yy" error rather than, > "can't find that file" or something actually useful. >Well, for MATLAB and Octave, a function foo is undefined, so that's why it yells "undefined 'foo' near line ...". foo could be in the file you're executing right now or in its own file foo.m. Not being defined, Octave has no way to know where it might be.> So, does it really find the file and just not interpret > it correctly, which is a little odd, >In that case you'd get an error saying "bar" undefined in "foo.m" near line xx column yy.> or is it just making stuff up? ;)I don't think so. But I think MATLAB does the same in such a situation.> > Strange and unhelpful in any case, but I've now got all sorts > of files running doing useful things. It does appear that > the plotting functions are a bit to get used to and may have > lost some functionality from the last version of Matlab > that I was used to, but I need to get into that a bit further. >Or you'll just have to get used to it. In any case, you can export the data to a separate file and plot them directly with Gnuplot, where you'll have access to the usual figure-handling routines.> The plot window discipline > seems a bit off as well, since it'll intrude into a Remote Desktop > window and that's very unusual and I'd consider it a bug. >Huh? Works as expected here (with the exception that I haven't found out how to zoom in/out on a plot window). Regards Martin
Reply by ●March 24, 20082008-03-24
On Mon, 24 Mar 2008 22:12:20 +0100, "Martin Blume" <mblume@freesurf.ch> wrote:>"Eric Jacobsen" schrieb >> > >> > Well, I tried that and resaving it with either Wordpad >> > or [Notepad] didn't make any difference. >> > >Well, if you see a multiple-lines file as a multiple-lines >file in Notepad, then it isn't this problem of CR/LF (DOS) >and CR (Unix) line-ends.That was the case, it looked fine in Notepad.>> > HOWEVER, somewhere along the way of porting all this crap >> > across numerous machines (all Windows-based, btw), the >> > filename and extension became all caps, i.e., BUTTGEN.M. >> > So I renamed the file to buttgen.m and PRESTO! >> > It works. Jeebuz. >> > >You probably ported between FAT (case-insensitive) and NTFS >(case-sensitive, at least on the file-system level, the CMD shell >seems to ignore that).I'm sure it's something like that. Many of these files are 10-15 years old.>> Quick follow-up: The problem appears to be two-fold: the >> extension needs to be lower case, and the file name is >> case-sensitive. Even if the extension is lower case if >> the filename is typed in wrong, e.g., if it's mixed-case >> and you get one letter wrong, it's wrong. >> >> The irritating thing is that this results in the bizarre >> "undefined near line xx column yy" error rather than, >> "can't find that file" or something actually useful. >> >Well, for MATLAB and Octave, a function foo is undefined, >so that's why it yells "undefined 'foo' near line ...". >foo could be in the file you're executing right now or >in its own file foo.m. Not being defined, Octave has no >way to know where it might be.Since it doesn't appear to be a problem with the file itself or the code within the file, only the name, I think the error message is inappropriate. e.g., you type 'foo' at the CMD line like so:>fooerror: undefined 'foo' near line 50 in column 1 You look inside foo.M or Foo.m and there's only ten lines. If it did find the file, then why report a problem 40 lines past the end of the file, and if it didn't find the file, why report a problem specific to a line and column number? This could be with 'foo' being the first command after starting the shell, so there's no ambiguity in the context. Since the problem evidently has to do with issues with the file name that prevent execution, I would think that an error message to that effect could be generated.>> So, does it really find the file and just not interpret >> it correctly, which is a little odd, >> >In that case you'd get an error saying "bar" undefined in "foo.m" >near line xx column yy. > >> or is it just making stuff up? ;) >I don't think so. But I think MATLAB does the same in such a >situation.I don't remember having a comparable problem in Matlab, but it's been a while, so... ;)>> Strange and unhelpful in any case, but I've now got all sorts >> of files running doing useful things. It does appear that >> the plotting functions are a bit to get used to and may have >> lost some functionality from the last version of Matlab >> that I was used to, but I need to get into that a bit further. >> >Or you'll just have to get used to it. In any case, you can export >the data to a separate file and plot them directly with Gnuplot, >where you'll have access to the usual figure-handling routines.With any application there are the various "getting used to it" issues, so I've no problem with that if the functionality/hassle reward ratio is high enough. Since I've only just got it working I have to reserve judgement on that.>> The plot window discipline >> seems a bit off as well, since it'll intrude into a Remote Desktop >> window and that's very unusual and I'd consider it a bug. >> >Huh? Works as expected here (with the exception that I haven't found >out how to zoom in/out on a plot window).FWIW, what I mean is that generally a Remote Desktop window, which I use very frequently for hours at a time, is treated as somewhat sacred by MS, i.e., nothing that pops up on the near machine appears in the window for the remote machine. The remote window only reflects what's going on at the remote machine. There are only two exceptions to this that I've seen in many years of using Remote Desktop, and those are the McAfee alert windows and Octave plot windows. In both cases I consider it a bug, since if those apps were running on both machines there'd be no way to tell which machine spawned that window. And, yeah, there's a zoom button, but it doesn't seem to do anything. There also doesn't appear to be a way to copy plots into documents, like you can with Matlab. PrtScrn and Paint always works, but that's kinda cheesy. I couldnt' find any window menu or options at all in the plot windows. The octave shell window doesn't seem to have much window or control functionality, either, not even a way to launch the editor, and that's with the "advanced" tabbed console. I'm still learning my way around this thing, so it'll probably be more comfortable once I'm further up the curve a bit. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Reply by ●March 24, 20082008-03-24
On Mar 24, 3:18 pm, dbd <d...@ieee.org> wrote:> On Mar 24, 9:56 am, robert bristow-johnson <r...@audioimagination.com> > wrote: > > > > > On Mar 23, 11:11 pm, dbd <d...@ieee.org> wrote: > > > > On Mar 23, 7:49 pm, robert bristow-johnson <r...@audioimagination.com> > > > wrote: > > > > > ... > > > > yer not the only one, after all it seems intended to be a gnu freeware > > > > counterpart to MATLAB. i contacted Eaton (and got on the Octave > > > > developer's list for a little while) to propose they do to Octave what > > > > i have, for more than a decade, been trying to get MATLAB to do: > > > > generalize handling array indices so that an array can have non- > > > > positive integer indices; so that the indices of the upper-left corner > > > > need not always be (1,1). > > > > > fell on deaf ears. > > > > > So, doesn't that make Octave an accurate counterpart to MATLAB? > > > > But, in the spirit of GNU freeware, what did they say when you offered > > > to implement the change for them? > > > i can't do it all by myself. i downloaded the whole code base, even > > got it to build on my Linux machine, but i could not, for the life of > > me, figure out specifically where they were doing their index > > calculations. specifically, for arrays of two dimensions or more, the > > *must* be subtracting 1 from the index and multiplying it by the row > > length (or, in MATLAB/Octave i think it's the column length) and > > adding that to the "less significant" index where either they subtract > > one and add it to the array base address, or they don't bother to > > subtract 1 and the base address is fudged by 1. also this should be > > intimately related to the index bounds checking that either MATLAB or > > Octave do. i can't find that and no one who was a regular developer > > would help me because (like the Math Works) they didn't think that > > this modification was a good thing to do which is still just > > inexplicable to me. > > > the Octave source code is spaghetti. it's shit. i cannot believe > > that people take any pride in code written like that. (well, i dunno, > > i see a lot of shit code where i work.) > > > Your experience with the code seems to be good evidence that the cost > benefit ratio is too high to justify the effort of the conversion. >it's not that i wouldn't find the benefit is worth the effort, it's just that i cannot take on a project where i have to read and decode dozens of files of C++. it should be constructed so that whereever the code is that needs to know the limits (or lengths in present Octave) of each dimension of the array, the code that messes with that should be in only a very few places, and they should all have to reference these parameters (NxM for a 2-dim array) through a single classes member functions. (what do they call that in C++? i can't remember.) then whenever indices of an array need to be checked at the top end, the lower limits of the indices can also be checked and the net offset is calculated as a linear combination of each index minus its lower limit. but, i cannot be confident that i'll know every place where this address arithmetic needs to be done. but someone who actually wrote the code that does the limit checking and address arithmetic that might know all of the salient places to look. so the first thing i would want to do is add to the class that has the array length for each dimension, an index base or origin value that is initialized to 1 when an object of that class is created. and then wherever we have to subtract 1 from an index, usually to access an array element, but for any reason, we would subtract the index origin for that dimension of that particular instantiation of an array. it should work the same as it does presently (perhaps a microscopic amount slower). if someone who knows the code better than me can point to the places where that needs to be done, then i think it would be worth my effort to try to enhance Octave so we could have 0-based or even negatively based arrays. i wonder how long the fft() with the present definition would be used once someone writes a "dft()" that does the same thing but assumes (and returns) the correct indexing? we could pass it an array with indices from -512 to +511 and the dft() would know that (because the array parameters like origin and length of each dimension is available) and know where t=0 is. and the DC value would be returned in bin #0. (to me, it's just astonishing that it's 2008 and we don't have an fft() in the most common signal processing model/emulating software that returns the DC value in bin #0! that's just stupid, and like some other software shit, compared to the 1990s, i think our tools today are ickyer and harder to use than in the 90s. i guess i'm just a Mac wus, but even the OSX Mac stuff is harder to deal with than what we were using in the olden days.) r b-j
Reply by ●March 24, 20082008-03-24
On Mar 24, 3:18 pm, dbd <d...@ieee.org> wrote:> On Mar 24, 9:56 am, robert bristow-johnson <r...@audioimagination.com> > wrote: > > > > > On Mar 23, 11:11 pm, dbd <d...@ieee.org> wrote: > > > > On Mar 23, 7:49 pm, robert bristow-johnson <r...@audioimagination.com> > > > wrote: > > > > > ... > > > > yer not the only one, after all it seems intended to be a gnu freeware > > > > counterpart to MATLAB. i contacted Eaton (and got on the Octave > > > > developer's list for a little while) to propose they do to Octave what > > > > i have, for more than a decade, been trying to get MATLAB to do: > > > > generalize handling array indices so that an array can have non- > > > > positive integer indices; so that the indices of the upper-left corner > > > > need not always be (1,1). > > > > > fell on deaf ears. > > > > > So, doesn't that make Octave an accurate counterpart to MATLAB? > > > > But, in the spirit of GNU freeware, what did they say when you offered > > > to implement the change for them? > > > i can't do it all by myself. i downloaded the whole code base, even > > got it to build on my Linux machine, but i could not, for the life of > > me, figure out specifically where they were doing their index > > calculations. specifically, for arrays of two dimensions or more, the > > *must* be subtracting 1 from the index and multiplying it by the row > > length (or, in MATLAB/Octave i think it's the column length) and > > adding that to the "less significant" index where either they subtract > > one and add it to the array base address, or they don't bother to > > subtract 1 and the base address is fudged by 1. also this should be > > intimately related to the index bounds checking that either MATLAB or > > Octave do. i can't find that and no one who was a regular developer > > would help me because (like the Math Works) they didn't think that > > this modification was a good thing to do which is still just > > inexplicable to me. > > > the Octave source code is spaghetti. it's shit. i cannot believe > > that people take any pride in code written like that. (well, i dunno, > > i see a lot of shit code where i work.) > > > Your experience with the code seems to be good evidence that the cost > benefit ratio is too high to justify the effort of the conversion. >it's not that i wouldn't find the benefit is worth the effort, it's just that i cannot take on a project where i have to read and decode dozens of files of C++. it should be constructed so that whereever the code is that needs to know the limits (or lengths in present Octave) of each dimension of the array, the code that messes with that should be in only a very few places, and they should all have to reference these parameters (NxM for a 2-dim array) through a single classes member functions. (what do they call that in C++? i can't remember.) then whenever indices of an array need to be checked at the top end, the lower limits of the indices can also be checked and the net offset is calculated as a linear combination of each index minus its lower limit. but, i cannot be confident that i'll know every place where this address arithmetic needs to be done. but someone who actually wrote the code that does the limit checking and address arithmetic that might know all of the salient places to look. so the first thing i would want to do is add to the class that has the array length for each dimension, an index base or origin value that is initialized to 1 when an object of that class is created. and then wherever we have to subtract 1 from an index, usually to access an array element, but for any reason, we would subtract the index origin for that dimension of that particular instantiation of an array. it should work the same as it does presently (perhaps a microscopic amount slower). if someone who knows the code better than me can point to the places where that needs to be done, then i think it would be worth my effort to try to enhance Octave so we could have 0-based or even negatively based arrays. i wonder how long the fft() with the present definition would be used once someone writes a "dft()" that does the same thing but assumes (and returns) the correct indexing? we could pass it an array with indices from -512 to +511 and the dft() would know that (because the array parameters like origin and length of each dimension is available) and know where t=0 is. and the DC value would be returned in bin #0. (to me, it's just astonishing that it's 2008 and we don't have an fft() in the most common signal processing model/emulating software that returns the DC value in bin #0! that's just stupid, and like some other software shit, compared to the 1990s, i think our tools today are ickyer and harder to use than in the 90s. i guess i'm just a Mac wus, but even the OSX Mac stuff is harder to deal with than what we were using in the olden days.) r b-j
Reply by ●March 24, 20082008-03-24
On Mar 24, 3:18 pm, dbd <d...@ieee.org> wrote:> On Mar 24, 9:56 am, robert bristow-johnson <r...@audioimagination.com> > wrote: > > > > > On Mar 23, 11:11 pm, dbd <d...@ieee.org> wrote: > > > > On Mar 23, 7:49 pm, robert bristow-johnson <r...@audioimagination.com> > > > wrote: > > > > > ... > > > > yer not the only one, after all it seems intended to be a gnu freeware > > > > counterpart to MATLAB. i contacted Eaton (and got on the Octave > > > > developer's list for a little while) to propose they do to Octave what > > > > i have, for more than a decade, been trying to get MATLAB to do: > > > > generalize handling array indices so that an array can have non- > > > > positive integer indices; so that the indices of the upper-left corner > > > > need not always be (1,1). > > > > > fell on deaf ears. > > > > > So, doesn't that make Octave an accurate counterpart to MATLAB? > > > > But, in the spirit of GNU freeware, what did they say when you offered > > > to implement the change for them? > > > i can't do it all by myself. i downloaded the whole code base, even > > got it to build on my Linux machine, but i could not, for the life of > > me, figure out specifically where they were doing their index > > calculations. specifically, for arrays of two dimensions or more, the > > *must* be subtracting 1 from the index and multiplying it by the row > > length (or, in MATLAB/Octave i think it's the column length) and > > adding that to the "less significant" index where either they subtract > > one and add it to the array base address, or they don't bother to > > subtract 1 and the base address is fudged by 1. also this should be > > intimately related to the index bounds checking that either MATLAB or > > Octave do. i can't find that and no one who was a regular developer > > would help me because (like the Math Works) they didn't think that > > this modification was a good thing to do which is still just > > inexplicable to me. > > > the Octave source code is spaghetti. it's shit. i cannot believe > > that people take any pride in code written like that. (well, i dunno, > > i see a lot of shit code where i work.) > > > Your experience with the code seems to be good evidence that the cost > benefit ratio is too high to justify the effort of the conversion. >it's not that i wouldn't find the benefit is worth the effort, it's just that i cannot take on a project where i have to read and decode dozens of files of C++. it should be constructed so that whereever the code is that needs to know the limits (or lengths in present Octave) of each dimension of the array, the code that messes with that should be in only a very few places, and they should all have to reference these parameters (NxM for a 2-dim array) through a single classes member functions. (what do they call that in C++? i can't remember.) then whenever indices of an array need to be checked at the top end, the lower limits of the indices can also be checked and the net offset is calculated as a linear combination of each index minus its lower limit. but, i cannot be confident that i'll know every place where this address arithmetic needs to be done. but someone who actually wrote the code that does the limit checking and address arithmetic that might know all of the salient places to look. so the first thing i would want to do is add to the class that has the array length for each dimension, an index base or origin value that is initialized to 1 when an object of that class is created. and then wherever we have to subtract 1 from an index, usually to access an array element, but for any reason, we would subtract the index origin for that dimension of that particular instantiation of an array. it should work the same as it does presently (perhaps a microscopic amount slower). if someone who knows the code better than me can point to the places where that needs to be done, then i think it would be worth my effort to try to enhance Octave so we could have 0-based or even negatively based arrays. i wonder how long the fft() with the present definition would be used once someone writes a "dft()" that does the same thing but assumes (and returns) the correct indexing? we could pass it an array with indices from -512 to +511 and the dft() would know that (because the array parameters like origin and length of each dimension is available) and know where t=0 is. and the DC value would be returned in bin #0. (to me, it's just astonishing that it's 2008 and we don't have an fft() in the most common signal processing model/emulating software that returns the DC value in bin #0! that's just stupid, and like some other software shit, compared to the 1990s, i think our tools today are ickyer and harder to use than in the 90s. i guess i'm just a Mac wus, but even the OSX Mac stuff is harder to deal with than what we were using in the olden days.) r b-j
Reply by ●March 24, 20082008-03-24
On Mar 24, 3:18 pm, dbd <d...@ieee.org> wrote:> On Mar 24, 9:56 am, robert bristow-johnson <r...@audioimagination.com> > wrote: > > > > > On Mar 23, 11:11 pm, dbd <d...@ieee.org> wrote: > > > > On Mar 23, 7:49 pm, robert bristow-johnson <r...@audioimagination.com> > > > wrote: > > > > > ... > > > > yer not the only one, after all it seems intended to be a gnu freeware > > > > counterpart to MATLAB. i contacted Eaton (and got on the Octave > > > > developer's list for a little while) to propose they do to Octave what > > > > i have, for more than a decade, been trying to get MATLAB to do: > > > > generalize handling array indices so that an array can have non- > > > > positive integer indices; so that the indices of the upper-left corner > > > > need not always be (1,1). > > > > > fell on deaf ears. > > > > > So, doesn't that make Octave an accurate counterpart to MATLAB? > > > > But, in the spirit of GNU freeware, what did they say when you offered > > > to implement the change for them? > > > i can't do it all by myself. i downloaded the whole code base, even > > got it to build on my Linux machine, but i could not, for the life of > > me, figure out specifically where they were doing their index > > calculations. specifically, for arrays of two dimensions or more, the > > *must* be subtracting 1 from the index and multiplying it by the row > > length (or, in MATLAB/Octave i think it's the column length) and > > adding that to the "less significant" index where either they subtract > > one and add it to the array base address, or they don't bother to > > subtract 1 and the base address is fudged by 1. also this should be > > intimately related to the index bounds checking that either MATLAB or > > Octave do. i can't find that and no one who was a regular developer > > would help me because (like the Math Works) they didn't think that > > this modification was a good thing to do which is still just > > inexplicable to me. > > > the Octave source code is spaghetti. it's shit. i cannot believe > > that people take any pride in code written like that. (well, i dunno, > > i see a lot of shit code where i work.) > > > Your experience with the code seems to be good evidence that the cost > benefit ratio is too high to justify the effort of the conversion. >it's not that i wouldn't find the benefit is worth the effort, it's just that i cannot take on a project where i have to read and decode dozens of files of C++. it should be constructed so that whereever the code is that needs to know the limits (or lengths in present Octave) of each dimension of the array, the code that messes with that should be in only a very few places, and they should all have to reference these parameters (NxM for a 2-dim array) through a single classes member functions. (what do they call that in C++? i can't remember.) then whenever indices of an array need to be checked at the top end, the lower limits of the indices can also be checked and the net offset is calculated as a linear combination of each index minus its lower limit. but, i cannot be confident that i'll know every place where this address arithmetic needs to be done. but someone who actually wrote the code that does the limit checking and address arithmetic that might know all of the salient places to look. so the first thing i would want to do is add to the class that has the array length for each dimension, an index base or origin value that is initialized to 1 when an object of that class is created. and then wherever we have to subtract 1 from an index, usually to access an array element, but for any reason, we would subtract the index origin for that dimension of that particular instantiation of an array. it should work the same as it does presently (perhaps a microscopic amount slower). if someone who knows the code better than me can point to the places where that needs to be done, then i think it would be worth my effort to try to enhance Octave so we could have 0-based or even negatively based arrays. i wonder how long the fft() with the present definition would be used once someone writes a "dft()" that does the same thing but assumes (and returns) the correct indexing? we could pass it an array with indices from -512 to +511 and the dft() would know that (because the array parameters like origin and length of each dimension is available) and know where t=0 is. and the DC value would be returned in bin #0. (to me, it's just astonishing that it's 2008 and we don't have an fft() in the most common signal processing model/emulating software that returns the DC value in bin #0! that's just stupid, and like some other software shit, compared to the 1990s, i think our tools today are ickyer and harder to use than in the 90s. i guess i'm just a Mac wus, but even the OSX Mac stuff is harder to deal with than what we were using in the olden days.) r b-j
