Threaded Mode | Linear Mode

Ángel Martin · (This post was last modified: 06-18-2018 09:18 AM by Ángel Martin.)

(06-17-2018 10:26 PM)Valentin Albillo Wrote: .

(06-17-2018 10:16 AM)Ángel Martin Wrote: Not a bad way to round up this updating project, which highlights are listed below:

It's "whose", not "which" ... 8-D.

What sais you? It ain't the first time I was critizized for/to my grammar yet didn't no saw those coming from a fellow comrade.... you say tomatoe I say tomaíto, but at the end of the day I'd rather reserve "whose" for people and friendly pets ;-)

(06-17-2018 10:26 PM)Valentin Albillo Wrote: Don't know a thing about this ROM of yours but I'll suggest the following in case you might consider it a worthwhile thing to do:

- the new function to zero the diagonals and anti-identity matrix building seem to me quite unimportant, I don't see any worthwhile applications for them apart from being used in one or two mini-challenges and such. I feel that including such miscellaneous functions in the ROM is a waste of space, like filler. If in some rare application you need either of them, they're quite easy to replicate with the existing functions. All IMHO, of course.

There are breakthrough enhancements and gap-filling ones. Of course the zero diagonalization belongs to the second kind and was only added to take even further advantage of the existing code for the MIDN function. No need to see more to that. And BTW you *do* know a lot about this ROM since it's fundamentally built upon the HP-41 Advantage; that you knew inside out at least when you wrote the "Long Live..." article- - which (or was it whose?) has made its way into the ROM, re-incarnated as the program POLFIT in case you wonder.

(06-17-2018 10:26 PM)Valentin Albillo Wrote: - on the other hand, and just in case the ROM doesn't actually include this functionality already (I don't really know), implementing matrix subarray handling would be a real must, as it's something very frequently needed and can't be replicated in user code without one or two complicated nested loops.

An Mcode implementation would run hundreds of times faster while saving lots of RAM. By subarray handling I'm referring of course to, e.g., clearing part of a matrix, extracting part of a matrix to another matrix, assigning a value to part of a matrix, copying part of a matrix into a part of another matrix (or even the same), as seen in my 71B code to recursively compute the determinant of a real/complex matrix by minor expansion. The 71B Math ROM doesn't include this functionality but if you're willing I don't see any reason why your MMM ROM can't include it as well.

No need to sing the excellencies of a well-designed subarray handling functionality, I've been suffering from the lack thereof ever since. The thing is this project's initial goal was to provide support for the CL Y-Registers. That alone justified a new release, and getting it done wasn't trivial. The MCODE in the advantage was derived from the CCD Module Array functions -you can tell which routines come from the CCD-era and which ones come from HP, a bit of a jigsaw puzzle where it wasn't trivial to insert here and there snippets to allow for RAM addresses above 0x3FF.

(06-17-2018 10:26 PM)Valentin Albillo Wrote: - including a program to calculate "Complex Determinants" but only up to order 4 seems to me kinda lame. Either include a proper program which can do order N or else save the space for something more worthwhile. At just order 4 it's pretty miscellaneous as well.

Here's where we disagree. I don't consider it to be lame, but I grant you the fact that it is not perfect. The recursive approach you used in the minor expansion routine is rather impossible with the function set in the Advantage, precisely due to the lack of capable subarray handling capability. Also don't forget you're using HP-BASIC (with complex number support, no less!!), which (or is it whose?) gives you access to a wonderful way to define variables and control their values very easily.

There are two functions (MMOVE and MSWAP ) that could be used as a proto-rudimentary sub-matrix handlers, but there's where the MCODE becomes real spaghetti quality, all very discouraging to patch. Also I ran out of available room (and frankly stamina, don't underestimate the taxing nature of the beast) to do more changes at least for this time...

(06-17-2018 10:26 PM)Valentin Albillo Wrote: All said with the best intention to motivate you to include the best, most useful functionality in your excellent ROM. You can also consider all of the above suggestions as a personal challenge ... :-)

Allay your fears, I know your comments are constructive and in no way take them the wrong way. Besides as I said, they are the most natural and best way to improve the module even further but it'll have to wait for the next project!

Best wishes,
ÁM