Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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. >

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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 what t

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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?

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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?

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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,

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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 |

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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

Re: [sqlite] Division accuracy

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 >

[sqlite] Division accuracy

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