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
