That wasn't "endian" argument, this is an arithmetic operation question,
avoiding extra operations in the common case of small (mag < 2^56)
operands. Since I posted that I've figured out some other optimizations
that work better the way they laid it out, and it makes more sense now.
On Thu, Jan
On 03/01/2019 22:22, Peter da Silva wrote:
Why is the exponent in the low bits, since it forces unnecessary shifts for
integer operations?
That's easy, because the high bits are closer to the barrel shifter, so
it takes less time for the electron to get there![1][2]
Cheers,
Why is the exponent in the low bits, since it forces unnecessary shifts for
integer operations?
On Thu., 3 Jan. 2019, 03:34 Pavlos Christoforou Happy new year all,
>
> Have not followed the full thread, in case it has not been mentioned
> already:
>
> http://dec64.com/
>
>
> Cheers
>
>
> On Tue,
Happy new year all,
Have not followed the full thread, in case it has not been mentioned
already:
http://dec64.com/
Cheers
On Tue, 18 Dec 2018 at 02:42, Keith Medcalf wrote:
> >This thread is getting out of hand. Firstly there is no such binary
> >representation ( in this universe ) for a
On Sat, 15 Dec 2018 at 15:10, Frank Millman wrote:
> On Dec 15, 2018, at 08.58, Jay Kreibich wrote:
>
> > > On Dec 15, 2018, at 12:49 AM, Frank Millman
> wrote:
> > >
> > > I know that floating point is not precise and not suitable for
> financial uses. Even so, I am curious about the following
On Dec 20, 2018, at 3:38 PM, Igor Tandetnik wrote:
>
> On 12/20/2018 1:34 PM, Dennis Clarke wrote:
>> A more interesting topic of discussion would be the speed and complexity
>> of circuitry designed for another number base such as 5 or even decimal.
>
>
On 12/20/2018 1:34 PM, Dennis Clarke wrote:
A more interesting topic of discussion would be the speed and complexity
of circuitry designed for another number base such as 5 or even decimal.
https://en.wikipedia.org/wiki/Ternary_computer
--
Igor Tandetnik
On 12/19/18 7:51 PM, James K. Lowden wrote:
On Tue, 18 Dec 2018 17:34:29 -0500
Dennis Clarke wrote:
some serious reading and experiments are needed to get a good
handle on why numerical computation is as much art as it is science.
If we wander into the problem without sufficient study and
On Tue, 18 Dec 2018 17:34:29 -0500
Dennis Clarke wrote:
> some serious reading and experiments are needed to get a good
> handle on why numerical computation is as much art as it is science.
> If we wander into the problem without sufficient study and VERY
> careful consideration then we are
On Wed, Dec 19, 2018 at 4:57 PM Keith Medcalf wrote:
>
>
> >All I meant was that with a decimal exponent, the units could be
> >dollars,
> >and additions and subtractions of cents would be exact (assuming the
> >mantissa has enough bits), with no worries about rounding. Which is
> >the
> >basis
>All I meant was that with a decimal exponent, the units could be
>dollars,
>and additions and subtractions of cents would be exact (assuming the
>mantissa has enough bits), with no worries about rounding. Which is
>the
>basis for this whole discussion.
This is called fixed point. All that is
On Mon, Dec 17, 2018 at 10:04 AM Larry Brasfield
wrote:
> Gerry Snyder wrote:
> < I don't think anyone has pointed out that the "evil" is not floating
> point, it is the binary exponent.
>
> Disregarding the “evil” appellation, the fundamental fact is that, with
> modern floating point hardware
Apologies ... I should have included a link to Jean-Michel Muller's work
on "Elementary Functions" and on preserving monotonicity and always
getting correctly rounded results when implementing the elementary
functions in floating-point arithmetic.
On 12/18/18 6:01 AM, R Smith wrote:> On 2018/12/17 11:53 PM, Dennis
Clarke wrote:
>>
>> This thread is getting out of hand. Firstly there is no such binary
>> representation ( in this universe ) for a trivial decimal number such as
>> one tenth ( 0.10 ) and really folks should refer to the text
Although the problem is well known by the readers, may be someone would like
remember the basics (somethin written by me some years ago -in spanish-).
http://www.zator.com/Cpp/E2_2_4a.htm
If you want "play" whiths the numbers in IEE754 this page bay be the fun
(unfortuately, the original is not
On Mon, Dec 17, 2018 at 2:50 PM Thomas Kurz wrote:
> Ok, as there seem to be some experts about floating-point numbers here,
> there is one aspect that I never understood:
>
> floats are stored as a fractional part, which is binary encoded, and an
> integer-type exponent. The first leads to the
On 12/18/18 6:21 AM, R Smith wrote:
>
> I'm not even going to touch on silly/stupid programming and
> calculations that round along the intermediate steps, those have been
> mentioned already, they are evil and it isn't the fault of the storage
> medium.
Actually, periodically rounding IS a valid
On 2018/12/18 1:21 AM, James K. Lowden wrote:
First, the problem is not storage it's calculation.
Second, the thread was started because a floating point calculation
in SQLite, exactly as it is run today, led to the following value:
211496.252
which is typical of such problems.
On 2018/12/17 11:53 PM, Dennis Clarke wrote:
This thread is getting out of hand. Firstly there is no such binary
representation ( in this universe ) for a trivial decimal number such as
one tenth ( 0.10 ) and really folks should refer to the text book
recently published ( 2nd Edition actually )
>This thread is getting out of hand. Firstly there is no such binary
>representation ( in this universe ) for a trivial decimal number such
>as one tenth ( 0.10 ) and really folks should refer to the text book
>recently published ( 2nd Edition actually ) where all this is covered
>:
> Handbook
On Mon, 17 Dec 2018 17:35:54 +
Simon Slavin wrote:
> On 17 Dec 2018, at 5:16pm, James K. Lowden
> wrote:
>
> > IEEE
> > double-precision floating point is accurate to within 15 decimal
> > digits.
>
> First, the problem is not storage it's calculation.
>
> Second, the thread was started
> On Dec 17, 2018, at 1:50 PM, Thomas Kurz wrote:
>
> Can someone explain to me why it has been defined this way? Having 1 bit
> sign, 11 bit exponent, and 52 bit mantissa, I would have stored the (in the
> meantime well known) number 211496.26 as 21149626E-2, i.e. I would have
> stored a
On 17 Dec 2018, at 21:50, Thomas Kurz wrote:
> Can someone explain to me why it has been defined this way? Having 1 bit sign,
> 11 bit exponent, and 52 bit mantissa, I would have stored the (in the meantime
> well known) number 211496.26 as 21149626E-2, i.e. I would have stored a 52 bit
>
On 12/17/18 3:19 PM, Darren Duncan wrote:
On 2018-12-17 9:16 AM, James K. Lowden wrote:
On Sat, 15 Dec 2018 01:24:18 -0800
Darren Duncan wrote:
If yours is a financial application then you should be using exact
numeric types only
Color me skeptical. That very much depends on the
out anticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
>Sent: Monday, 17 December, 2018 10:36
>To: SQLite mailing list
>Subject: Re: [sqlite] Question about floating point
>
On 2018-12-17 9:16 AM, James K. Lowden wrote:
On Sat, 15 Dec 2018 01:24:18 -0800
Darren Duncan wrote:
If yours is a financial application then you should be using exact
numeric types only
Color me skeptical. That very much depends on the application. IEEE
double-precision floating point is
On Monday, 17 December, 2018 12:27, Jay Kreibich wrote:
>> On Dec 17, 2018, at 1:12 PM, Keith Medcalf wrote:
>> The "nearest" representation of 211496.26 is
>> 211496.260931323. The two representable IEEE-754 double
>> precision floating point numbers bounding 211496.26 are:
>>
> On Dec 17, 2018, at 1:12 PM, Keith Medcalf wrote:
>
>
> The "nearest" representation of 211496.26 is 211496.260931323. The
> two representable IEEE-754 double precision floating point numbers bounding
> 211496.26 are:
>
> 211496.260931323
> 211496.25802094
>
>
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
>Sent: Monday, 17 December, 2018 10:36
>To: SQLite mailing list
>Subject: Re: [sqlite] Question about floating poi
On 17 Dec 2018, at 5:16pm, James K. Lowden wrote:
> IEEE
> double-precision floating point is accurate to within 15 decimal
> digits.
First, the problem is not storage it's calculation.
Second, the thread was started because a floating point calculation in SQLite,
exactly as it is run today,
On Sat, 15 Dec 2018 01:24:18 -0800
Darren Duncan wrote:
> If yours is a financial application then you should be using exact
> numeric types only
Color me skeptical. That very much depends on the application. IEEE
double-precision floating point is accurate to within 15 decimal
digits. The
On Sat, 15 Dec 2018 10:35:01 -0700
"Keith Medcalf" wrote:
> And the propensity to apply intermediate rounding still exists.
Yes. The only significant errors I've ever seen using floating point
were not due to the computer, but to the programmer.
--jkl
Tim Streater wrote:
[Responding to “There is a lot to like about BCD.”]
> And do any processors/computers have hardware for that these days?
The modern X86 descendent processors from AMD and Intel implement AA{A,D,M,S}
instructions, which do the BCD adjustments associated with addition,
Gerry Snyder wrote:
< I don't think anyone has pointed out that the "evil" is not floating point,
it is the binary exponent.
Disregarding the “evil” appellation, the fundamental fact is that, with modern
floating point hardware (implementing the IEEE-754 standard), only that subset
of rational
On Mon, Dec 17, 2018 at 2:43 AM Tim Streater wrote:
> On 17 Dec 2018, at 04:32, D Burgess wrote:
>
> >> Banks still use, as they have for a very long time, Binary Coded
> >> Decimal, or some equivalent that does not suffer from a loss of
> >> accuracy, so all this foofaraw to do with floating
On 17 Dec 2018, at 04:32, D Burgess wrote:
>> Banks still use, as they have for a very long time, Binary Coded
>> Decimal, or some equivalent that does not suffer from a loss of
>> accuracy, so all this foofaraw to do with floating point representation
>> of various amounts of currency does not
On Sun, Dec 16, 2018 at 9:26 PM Thomas Kurz wrote:
> > Good way to overflow your integers.
> > With floating point, that's not a problem.
>
> With int64, it shouldn't be a problem either.
>
>
Well.. are you absolutely sure about that?
Considering these Zimbabwe Dollars amounts mentioned
On 2018-12-16 6:54 AM, Wout Mertens wrote:
I'd also like to point out a problem with integer money: inflation. For USD
it's been OK so far, but imagine having to handle the Zimbabwean Dollar,
which ended up having 100 trillion dollar notes. Good way to overflow your
integers.
With floating
> Banks still use, as they have for a very long time, Binary Coded
> Decimal, or some equivalent that does not suffer from a loss of
> accuracy, so all this foofaraw to do with floating point representation
> of various amounts of currency does not apply to the real world.
>
> Cheers,
>
On 2018-12-15 2:15 AM, Frank Millman wrote:
On 2018-12-14 11:24 AM, Darren Duncan wrote:
If yours is a financial application then you should be using exact numeric types
only, such as integers that represent multiples of whatever quantum you are
using, such as cents; fractional numbers are a
On 2018-12-17 02:41, Simon Slavin wrote:
On 16 Dec 2018, at 2:54pm, Wout Mertens wrote:
imagine having to handle the Zimbabwean Dollar, which ended up having
100 trillion dollar notes. Good way to overflow your integers.
Indeed. But when the crisis started in the early 2000s, the currency
Ah, the luxuries of not programming in JavaScript ;)
Anyway, using int64 would not have been sufficient to represent, say, tax
numbers for the country, especially if you worked with cents.
Whereas 53 bits of precision gets you a very long way and can even handle
deflation
The
Wout.
On Sun,
> Good way to overflow your integers.
> With floating point, that's not a problem.
With int64, it shouldn't be a problem either.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
ginal Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Wout Mertens
>Sent: Sunday, 16 December, 2018 07:55
>To: SQLite mailing list
>Subject: Re: [sqlite] Question about floating point
>
>On Sat, Dec 15, 2018 at 7:13 PM Keith Medcalf
On 16 Dec 2018, at 2:54pm, Wout Mertens wrote:
> imagine having to handle the Zimbabwean Dollar, which ended up having 100
> trillion dollar notes. Good way to overflow your integers.
Indeed. But when the crisis started in the early 2000s, the currency was
devalued by 1000. Then ten zeros
On Sat, Dec 15, 2018 at 7:13 PM Keith Medcalf wrote:
>
> >And yet ... here we are. The post which started this thread summed
> >currency amounts and reached a total of 211496.252 .
>
> >Yes, you can say 'that would have been rounded before it was
> >printed'. But then you're into the
On Saturday, 15 December, 2018 10:54, Simon Slavin wrote:
>On 15 Dec 2018, at 5:35pm, Keith Medcalf wrote:
>> Fast forward 25 years and you would these days be hard pressed to
>find a computer that DOES NOT use proper IEEE-754 floating point and
>that DOES NOT default to a minimum of double
On 15 Dec 2018, at 5:35pm, Keith Medcalf wrote:
> Fast forward 25 years and you would these days be hard pressed to find a
> computer that DOES NOT use proper IEEE-754 floating point and that DOES NOT
> default to a minimum of double precision representation and that DOES NOT use
> extended
On Friday, 14 December, 2018 23:49, Frank Millman wrote:
> I know that floating point is not precise and not suitable for
> financial uses.
This is debatable. In the "old days" of what was called "fast floating point"
it was certainly true since the epsilon of a "fast floating point" number
On 15 Dec 2018, at 10:15am, Frank Millman wrote:
> Simon Slavin says ‘Currency amounts should be stored as integers’. Does this
> apply to sqlite3 specifically, or is that your recommendation for all
> databases?
For anything that goes near a computer. I used to work with international
On 15 Dec 2018, at 10:15, Frank Millman wrote:
Simon Slavin says ‘Currency amounts should be stored as integers’.
Does this apply to sqlite3 specifically, or is that your
recommendation for all databases?
It doesn't matter whether a database is involved.
Using integers for currency amounts
On 2018-12-14 11:24 AM, Darren Duncan wrote:
>
> If yours is a financial application then you should be using exact numeric
> types
only, such as integers that represent multiples of whatever quantum you are
using, such as cents; fractional numbers are a display or user input format
only,
On 15 Dec 2018, at 9:24am, Darren Duncan wrote:
> If yours is a financial application then you should be using exact numeric
> types only, such as integers that represent multiples of whatever quantum you
> are using, such as cents; fractional numbers are a display or user input
> format
If yours is a financial application then you should be using exact numeric types
only, such as integers that represent multiples of whatever quantum you are
using, such as cents; fractional numbers are a display or user input format
only, and in those cases they are character strings. -- Darren
On Dec 15, 2018, at 08.58, Jay Kreibich wrote:
>
> > On Dec 15, 2018, at 12:49 AM, Frank Millman wrote:
> >
> > I know that floating point is not precise and not suitable for financial
> > uses. Even so, I am curious about the following -
> >
[...]
> >
> > With the same version of sqlite3
> On Dec 15, 2018, at 12:49 AM, Frank Millman wrote:
>
> Hi all
>
> I know that floating point is not precise and not suitable for financial
> uses. Even so, I am curious about the following -
>
> SQLite version 3.26.0 2018-12-01 12:34:55
> Enter ".help" for usage hints.
> Connected to a
56 matches
Mail list logo
