Talk:Generalised floating point addition

Clarify?

I have a few questions:

1. Why?
2. A floating point number involves three integers: the significand, the base and the exponent. Wouldn't it be more of a hoot to allow them to be in different bases?
3. Suppose I want to compute a + b. Is it acceptible to first convert them into machine native format, add up, then convert back to whatever base they were in? Could a and b be in different bases to begin with? --Ledrug 16:52, 28 October 2011 (UTC)

1. re: Why?

This pattern (or subsets of this pattern) happen often enough that it is worth implementing it in general. Hence the emphasis on a "Mixin" or Template" solution. More generally the "DIGITS" are not specifically numerical, they only require a "+" operation, a digit index, MSD, LSD and the concept of ZERO.

2. re: ... allow them to be in different bases?

That would depend on a natural example of the significand, the base and the exponent in different bases. IEEE_754 Basic_formats has Decimal128 floating-point format appears to be an example BCD significand and "modified" Binary exponent. /* I'm guessing that this is because the input and output data are decimal */. But your suggestion is reasonably close and if it can be implemented reasonably cleanly then it would probably fit the Rosettacode's spirit of "codifying your suggestion". The one thing I love about Rosettacode is the surprises that emanate from other languages and other interpretations.

3. re: ... Is it acceptible to first convert them into machine native format.

I saw this more as a Templating and significand "list processing" "algorithm" definition task. /* Esp as the "DIGITS" may not even be numerical. */ So my preference is to avoid normalising to a canonical form based on a specific hardware implementation. [ If you know what I mean... I can almost say that last paragraph in one breath... :-) ]

NevilleDNZ 11:10, 29 October 2011 (UTC)

Repeating the "why"?

I have posted an implementation of J, based on the answer given here for "why" (ignoring concepts that seem unnecessary and focusing on the desired result). I believe that this implementation is convenient to use, fast to implement, and that it performs reasonably well. Is this an acceptable implementation? If so, could the task description be changed to allow it? If not, perhaps you could expand on the "why" to explain why I need to do something different? Thanks! --Rdm 08:22, 30 October 2011 (UTC)

The task requires "Calculate the terms for -8 to 20 in this sequence". I notice J only got as far as -4. Most programming languages are constrained by their hardware floating point. Maybe J isn't, but most are. Hence the need for a Template/Library in these less advanced languages.

> More generally the "DIGITS" are not specifically numerical, they only require a "+" operation, a digit index, MSD, LSD and the concept of ZERO.

IEEE has Decimal128 floating-point format in BCD for just this reason. In this case BCD is used where performance and/or accuracy is required.

NevilleDNZ 08:45, 30 October 2011 (UTC)

Yes? I am being lazy here, and asking for a clarification of the task. And, since no sequence was defined, I am being too lazy to derive the sequence for myself. I am also ignoring most of the details of the task -- I am, in fact, not using "floating point" at all here, except as a notation (and that only loosely). That said, I am confident that my implementation will have significantly better performance than BCD for these calculations -- the BCD implementation multiplies by 81 using 81 successive additions where I am just multiplying. That said, performance is generally something we try and ignore on this site (except where it gets in the way). --Rdm 09:07, 30 October 2011 (UTC)

I have clarfied the definition of the sequence for avoid confusion. I elected to demonstrate the sequence by example as seems to be the easiest way to describe it.

I have removed the reference to "Kudos" as I suspect that this word may be too loaded, and may have resulted in the emotive responses. I will remove other such reference to "Kudos" from my drafts over the next day or so.

I am thinking that the reference to "self" in tasks should be removed: eg

• "I am not currently able to implement the task exactly because I do not quite understand what is being asked for (nor why it would be useful)."

Mostly because "I am" and "I do" look "unencyclopaedic", but also the "I" carries no ".sig" for the general reader to relate to. For me it looks OK in a draft task, but past draft it looks a little strange.

Good luck with the task. Bear in mind a test case is only the test case. The real "meat" is the task.

Thanks for the feed back. ;-)

NevilleDNZ 10:14, 30 October 2011 (UTC)

I can remove the "I" from my task implementation when that ceases to be relevant. But you asked for the reason that the task cannot be implemented in a certain fashion and my lack of understanding is the reason. So, for now, "I" stays... Note that I am not using BCD at all here -- the closest I come to that is the initial and final representations of the numbers, but that's ASCII, not BCD.

Also, analyzing your sequence: the exponents 63, 54, 45, 36, ... each differ by 9, and correspond to 9 * (7, 6, 5, 4). So if 63 corresponds to the -8 value in your sequence, then the exponent of 9*0 corresponds to -1 value in your sequence, and the exponent of 9*-1 corresponds to the 0 value in your sequence. I suspect this is an off-by-one error? Wouldn't it make more sense for 63 to correspond to -7? Or, better yet, make 63 correspond to 7, and ask for the values from 7 through -21 (or whatever -- since these values are bulky perhaps it would be better for the task page to ask for fewer, well chosen values)? --Rdm 12:22, 30 October 2011 (UTC)

Good idea. Changed sequence to be from -7 to 21. It makes it easier to mentally digest. I also changed the multiplication to be from -15 to 13 for the same reason. NevilleDNZ 13:46, 30 October 2011 (UTC)

Ok, I have updated the J implementation to generate the full sequence. But that leaves me with my previous question, so I will repeat it for this updated implementation: Is this an acceptable implementation? If so, could the task description be changed to allow it? If not, perhaps you could expand on the "why" to explain why I need to do something different? --Rdm 14:54, 30 October 2011 (UTC)

To be honest I don't know J, hence cannot read it, so at the end of the day you are the judge of your own code. The task test case requires "Perform the multiplication of 81 by repeated additions". The repeated pattern "12345679" was picked to maximise the varieties of "carries" performed during addition, hence the requirement "Perform the multiplication of 81 by repeated additions" is a significant part of the test case. At the end of the day you are the judge of your own code, and visa-versa. NevilleDNZ 21:18, 30 October 2011 (UTC)

I've had a thought. This method of adding (and multiplying) two numbers together is taught to kids when counting their pocket money, then at grade school in basic decimal arithmetic (about the same time they learn fractions). Then it is in reapplied in highschool maths classes when dealing with numbers bases. And again the technique is reapplied as the student learns about binary computers where they also learn about hex & octal etc. So... I will change the task emphasis to be on emulating the general technique that is taught in junior classrooms. NevilleDNZ 22:48, 30 October 2011 (UTC)

I am currently not doing BCD at all -- I do not see any point in using BCD -- I have explained this, and I am asking why because I do not see the point. I could change from multiplication to repeated addition, and it still would not be testing BCD carry. I also do not know what "template" means -- I might already be doing that, or it might be trivial. Anyways, if the task is going to require BCD shouldn't it include something that demonstrates that BCD is in use? (Though, honestly, I cannot imagine anything that actually requires the use of BCD.) Maybe if you ask for intermediate results on the addition though? --Rdm 00:53, 31 October 2011 (UTC)