I'm trying to find what the limit is for dividing in terms of accuracy.
Basically I have one program that inserts values to a table and determine sort order using one standard trick that has a REAL column
named "SortOrder" which gets the value Highest_previous_value+1 if an insert happens with s
On Wed, Sep 24, 2014 at 10:49 AM, RSmith wrote:
> I'm trying to find what the limit is for dividing in terms of accuracy.
>
> Basically I have one program that inserts values to a table and determine
> sort order using one standard trick that has a REAL column named
> "SortOrder" which gets the v
Hello,
Why don't you try the same approach with 64 bit integers? You could
insert consecutive items at 0x10 intervals, in this way you would
be allowed about 4G items to me inserted in any order you like. You could
also change the interval to change the maximum consecutive items inserte
Interesting trick.
I remember having seen something similar for Trees ...
Found it ...
http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/StephenHuntley/Huntley_Tcl2011.pdf
Well, he uses bignums.
Maybe this could be degenerated into a linear list, which is what you
are lo
RSmith wrote:
> how can I accurately establish how many total-then-divide-by-2's a set
> of co-values in 64-bit FP guise can withstand before the difference is
> too small to make sense to the sorter in SQLite?
Internally, SQLite uses 64-bit IEEE floating-point numbers, which is the
same as "doubl
RSmith wrote:
> I have one program that inserts values to a table and determine sort
> order using one standard trick that has a REAL column named
> "SortOrder" [...]
> reassign SortOrders simply in Integer steps: 1, 2, 3 etc.
>
> ID | SortOrder | Data
> 1 | 1 | 'First Row'
> 2 | 4
Is the approach of 'just try it and if it goes badly fix it' doable?
mid = (lo + hi) / 2;
if ((mid <= lo) || (mid >= hi)) {
Fix it
}
John Hascall
IT Services
Iowa State Univ.
> On Sep 24, 2014, at 11:49 AM, RSmith wrote:
>
> I'm trying to find what the limit is for dividing in terms of a
Thanks all for the responses.
Thanks Scott for the calcs, I had somehow imagined using a set of values might yield more iterations, but of course that is just
wishful thinking, the bits are the bits.
The idea from Alessandro is great if I could control or guess where the next inserts will be,
Which language are you using? Andres ideas could give some nice solutions
using blob, even without a specific arbitrary precision library. eg:
Splitting data with an encoding like
(In-order id) (Out-of-order id)
In-order insert are encoded with an encoding that guarantees lexicografical
ordering (
RSmith wrote:
> Clemens I'm liking the link list but did not go with it due to an expensive
> insert function
Yes, you have to update two references (with prev/next), but how is that
worse than the update of all SortOrder values?
> how would I get a normal SQL query ORDER BY clause to use that?
On 2014/09/24 22:24, Clemens Ladisch wrote:
RSmith wrote:
Clemens I'm liking the link list but did not go with it due to an expensive
insert function
Yes, you have to update two references (with prev/next), but how is that
worse than the update of all SortOrder values?
Well the insert runs
Thanks Alessandro, this will work, it's just... ugly... and for other reasons I'd prefer the sort order to be numeric. If however it
doesn't work out, this might just be the best solution, ugly or not. :)
Thanks!
Ryan
On 2014/09/24 21:33, Alessandro Marzocchi wrote:
Which language are you using
No problem! Let us know which solution you picked!
Alessandro
2014-09-24 22:50 GMT+02:00 RSmith :
> Thanks Alessandro, this will work, it's just... ugly... and for other
> reasons I'd prefer the sort order to be numeric. If however it doesn't work
> out, this might just be the best so
RSmith wrote:
> On 2014/09/24 22:24, Clemens Ladisch wrote:
>> RSmith wrote:
>>> I'm liking the link list but did not go with it due to an expensive insert
>>> function
>>
>> Yes, you have to update two references (with prev/next), but how is that
>> worse than the update of all SortOrder values?
On Wed, 24 Sep 2014 20:51:38 +0200
RSmith wrote:
> I was thinking in stead of maybe having a prev and next column, to
> just have a next column which points to an ID.
...
> ID | Next | Data
> 1 | 4 | 'First Row'
> 2 | 3 | 'Eventual Fourth Row'
> 3 | 1 | 'Last Row'
> 4 | 5 |
52
>-Original Message-
>From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
>boun...@sqlite.org] On Behalf Of RSmith
>Sent: Wednesday, 24 September, 2014 10:49
>To: sqlite-users@sqlite.org
>Subject: [sqlite] Division accuracy
>
>I'm trying to find w
functions to manipulate and
compare the values though.
-Ursprüngliche Nachricht-
Von: Scott Robison [mailto:sc...@casaderobison.com]
Gesendet: Mittwoch, 24. September 2014 18:58
An: rsm...@rsweb.co.za; General Discussion of SQLite Database
Betreff: Re: [sqlite] Division accuracy
On Wed, Sep 24
I've read through the rest of the thread on this so far. I like the linked
list idea, as updating three rows seems to be the better way of doing
things, but the question does remain 'what drives the sort reasoning?',
however, if you don't want to get that deep into CTEs and stuff for the
linked li
James K. Lowden wrote:
> RSmith wrote:
>> ID | Next | Data
>> 1 | 4 | 'First Row'
>> 2 | 3 | 'Eventual Fourth Row'
>> 3 | 1 | 'Last Row'
>> 4 | 5 | 'New Second Row'
>> 5 | 2 | 'New Third Row'
>
> The first question I'd have is: Where are the ordering criteria, and
> why
On Thu, 25 Sep 2014 10:36:31 +0200
Clemens Ladisch wrote:
> > The first question I'd have is: Where are the ordering criteria,
> > and why aren't they in the database? Someone is imposing an order,
> > but the basis for it is not included in the database design.
>
[amusing list omitted
On 2014/09/25 15:43, James K. Lowden wrote:
On Thu, 25 Sep 2014 10:36:31 +0200
Clemens Ladisch wrote:
Yes, and yes, absolutely. In that case the order is established by the
user, and can be captured by the application as integers, and stored in
the database. The problem is trivial because t
RSmith wrote:
> the time of finishing does not determine position alone, there are
> bonuses and penalties which doesn't stack up to integer values, but is
> measurable [...] Without going into too much detail about how bonuses
> and penalties are calculated
How can anybody help you without these
On Thu, 25 Sep 2014 18:40:23 +0200
RSmith wrote:
> It's much harder to make a mathematical positioning result than
> simply working out if the current is better or worse than any
> existing position.
So you say. But someone is doing *something* to determine who comes
before whom. Even synchron
On 2014/09/25 19:32, Clemens Ladisch wrote:
RSmith wrote:
the time of finishing does not determine position alone, there are
bonuses and penalties which doesn't stack up to integer values, but is
measurable [...] Without going into too much detail about how bonuses
and penalties are calculated
24 matches
Mail list logo