I had two dates for my checking. One when I wrote the check or deposit and the date that it cleared. I was able to match them to the penny. It was nice to be able to sort by cleared date and I could do a binary search to find where I entered something wrong when balancing.
On Mon, Sep 18, 2017 at 8:33 AM, Raul Miller <[email protected]> wrote: > If I had to do that, I'd do it at "reporting time". (Possibly cached, > if that turns out to take too long.) > > Thanks, > > -- > Raul > > > On Mon, Sep 18, 2017 at 9:08 AM, Don Guinn <[email protected]> wrote: > > I went to one cent and went to a lot of trouble to make sure I rounded > the > > same way that banks did. > > > > On Mon, Sep 18, 2017 at 6:44 AM, Raul Miller <[email protected]> > wrote: > > > >> That depends on what I am doing. > >> > >> In professional contexts: I often work with 1000000 = 1 dollar for > >> archive purposes (because I deal with stuff that's not worth very > >> much). But for reporting purposes I'll change that to 1 = 1 dollar. > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > >> On Mon, Sep 18, 2017 at 8:24 AM, Don Guinn <[email protected]> wrote: > >> > 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 > >> ---------------------------------------------------------------------- > >> 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
