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
