There are other cases, always. Of course, there are examples like bayesian numbers, complex numbers, and quaternions where we indeed generally use integers or floating point numbers under the covers. But we do have high precision rational numbers for cases where that's necessary.
Anyways, math is an open ended subject... We do indeed usually work with "measurable" values, where limited precision is assumed. And when we go beyond that we do indeed usually stick with integer values. But both of these are just "usually"... Thanks, -- Raul On Mon, Sep 18, 2017 at 5:04 AM, Erling Hellenäs <[email protected]> wrote: > Hi all! > > I think either we work with integers or with floating point. We use floating > point when we have non-countable and integers when we have countable data. > Non countable data is things like measurable quantities in engineering. > Countable data is when we count a certain number of things, when the result > has to be exact numbers. Currency, time, date, indices, hashes, cryptos. > When we use floating point we want the results to be as accurate as > possible. We want a certain number of accurate digits. We want efficient > calculations. We round the results. > When we use digital data the results typically have to be exact. The credit > and debit sides must match when we do book-keeping. When we work with date > and time data we expect the results to be exact. Our indices have to be > exact. Hashes and cryptos have to be exact. > Yet when we work with countable data we sometimes have to do floating point > calculations. We have to divide. We want to calculate the power of a number > in an efficient way. This is where our fuzzy floor, ceiling, residue and > antibase comes in. They are not there to give us any "fuzzy" results. They > are there for giving us exact results when we convert our floating point > data back to integer! > To convert a 64-bit integer to floating point without losing accuracy we > need a 128-bit float? That's no problem, our computers could handle this for > a long time? A floating-point unit in todays processors are 128 bit? > Comparison tolerance can then be set to something between 2^64 and 2^112, > which is the precision of IEEE quadruple precision floating point? We can > avoid any risk of small errors in the calculations slipping into our exact > integer calculations? When converting back to integer our results can be > exact? > J is seriously fucked up regarding this and has to be fixed? > > Cheers, > > Erling > > > Den 2017-09-16 kl. 00:38, skrev Erling Hellenäs: >> >> Hi all ! >> >> Yes, but for now my discussion was restricted to the fuzz as such. For now >> I held the conversion errors out of my argumentation. We can then see an >> inconsistency? We get different results for float and integer arguments? >> With integers fuzzy floor and ceiling is not used, with floats it is? We >> should get the same results? Either both should use fuzzy floor and ceiling, >> or none should? >> >> We can also see that we get zero results, when they should not be zero? >> Our program recognizes an error, but does not notify the user of it? Is that >> a reasonable behavior? We recognize an error, write no error message and >> instead give the user a faulty result? >> >> Then there is the question of possible random faults when the result of >> floor is larger than it's argument, the error is multiplied with a large >> number and digits are cut from the front of the result in the subtraction. >> We have to find out if we can get faulty results that are not acceptable? >> >> For the conversion error case it is reasonable to assume that the >> programmer should be aware of the auto-conversion of integers when they are >> used in a float operation? That the float can hold only 16 digits? The >> alternative is to not have auto-conversion, to have an explicit conversion >> operator? That's how it is in most programming languages? As soon as there >> is a risk associated with the conversion the programmer is forced to be >> explicit about it? Or it is not even allowed? >> >> Another question raised in the thread is if (14^2) should be real or >> integer. In Nial, for example, it was integer. In F# you had to explicitly >> make 14 and 2 to float before the operation. The result could be easily >> calculated with 128 bit floats? >> >> /Erling >> >> On 2017-09-15 23:14, Don Guinn wrote: >>> >>> Unfortunately, there are limits which computers give "right" answers. >>> Here >>> is a case where the wrong answer is given: >>> >>> (14^2) |!.0] 57290824867848391 >>> 104 >>> 196 | 57290824867848391 >>> 99 >>> >>> Because the number on the right has no exact representation in float >>> double. >>> >>> x:57290824867848391 0.5 >>> 57290824867848392 1r2 >>> >>> So, it's a hardware restriction. Either mod only accept integer arguments >>> or we have to deal with it. The fuzz is applied to the result, which is >>> within fuzz. One thing I have thought might help is that fuzz be applied >>> to >>> the arguments and if they are both integral values, convert them to >>> integer >>> before applying mod. >>> >>> On Fri, Sep 15, 2017 at 12:49 PM, Erling Hellenäs >>> <[email protected]> >>> wrote: >>> >>>> Even if we take care of the zero case, a fuzzy residue will deliver >>>> random >>>> errors much higher than the small errors which naturally affects real >>>> numbers? Multiplied with a big number and then the lost precision of the >>>> subtraction can make these errors very significant? /Erling >>>> >>>> >>>> On 2017-09-15 17:25, Erling Hellenäs wrote: >>>> >>>>> Hi all! >>>>> >>>>> OK. I guess there is some way to implement this so that both Floor and >>>>> Residue are fuzzy without having the circular dependency. It seems to >>>>> basically be the implementation we have. >>>>> It seems Floor gives the closest integer within comparison tolerance in >>>>> the way it is specified then. >>>>> 9!:19 [ 5.68434e_14 >>>>> >>>>> >>>>> 25j5": (9!:18'') * 5729082486784839 % 196 >>>>> >>>>> 1.66153 >>>>> >>>>> 25j5":a=: 5729082486784839 % 196 >>>>> >>>>> 29230012687677.75000 >>>>> >>>>> 25j5": <. a >>>>> >>>>> 29230012687678.00000 >>>>> >>>>> It means that this result, which we find strange, is according to >>>>> specification? >>>>> >>>>> (14^2) | 5729082486784839 >>>>> >>>>> 0 >>>>> >>>>> It also means that this result, which we find correct, is not according >>>>> to specification? >>>>> >>>>> 196 | 5729082486784839 >>>>> >>>>> 147 >>>>> >>>>> >>>>> So, now there is a question about if we should live with this >>>>> inconsistency or change the specification or the part of the >>>>> implementation >>>>> that is not according to this specification? >>>>> >>>>> I think the efforts to create a consistent algebra is good. However, in >>>>> my practical experience I found it important that functions give >>>>> correct >>>>> results. Incorrect results without any fault indication could mean that >>>>> the >>>>> patient dies, the bridge collapses or the company gets insolvent. Could >>>>> the >>>>> zero result really be considered correct? If not, is there a way in >>>>> which >>>>> we could deliver a fault indication instead of the zero result? This >>>>> means >>>>> we should have an error in the integer case and a NaN in the real case? >>>>> >>>>> Cheers, >>>>> >>>>> Erling Hellenäs >>>>> >>>>> Den 2017-09-15 kl. 14:13, skrev Raul Miller: >>>>> >>>>>> Eugene's work should be thought of as specification, rather than >>>>>> implementation. >>>>>> >>>>>> That said, chasing through the various implementations of floor for >>>>>> the various C data types can be an interesting exercise. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>> ---------------------------------------------------------------------- >>>>> For information about J forums see http://www.jsoftware.com/forums.htm >>>>> >>>> >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>>> >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >> >> >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
