So, when you work with money, do you have the number 1 equal to one dollar or one cent? Ten cents is not exact in floating point if you units are dollars.
On Mon, Sep 18, 2017 at 5:25 AM, Raul Miller <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
