Documentation Source Text

Check-in [2f7a35660e]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Merge the branch-3.31 changes into trunk.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 2f7a35660e78ffb21be6d9ced896755bbdd70b5635280ba8bcc0fbb9c5193c48
User & Date: drh 2020-05-16 00:12:23
Context
2020-05-18
14:36
Fix a minor typo in the rtree documentation. check-in: da19a96616 user: drh tags: trunk
2020-05-16
00:12
Merge the branch-3.31 changes into trunk. check-in: 2f7a35660e user: drh tags: trunk
00:10
Remove the FAQ about the round() function. check-in: b064af7596 user: drh tags: branch-3.31
2020-05-15
17:41
Update the round() question in the FAQ. check-in: 2beb2b13f2 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/faq.in.

359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
...
643
644
645
646
647
648
649

650
651
652
653
654


655
656
657
658
659
660
  <p>The [sqlite3_prepare_v2()] interface creates a
  [prepared statement] that will automatically recompile itself if
  the schema changes.  The easiest way to deal with
  [SQLITE_SCHEMA] errors is to always use [sqlite3_prepare_v2()]
  instead of [sqlite3_prepare()].
}

faq {
  Why does ROUND(9.95,1)  return 9.9 instead of 10.0?
  Shouldn't 9.95 round up?
} {
  <p>SQLite uses binary arithmetic and in binary, there is no
  way to write 9.95 in a finite number of bits.  The closest to
  you can get to 9.95 in a 64-bit IEEE float (which is what
  SQLite uses) is 9.949999999999999289457264239899814128875732421875.
  So when you type "9.95", SQLite really understands the number to be
  the much longer value shown above.  And that value rounds down.</p>

  <p>This kind of problem comes up all the time when dealing with
  floating point binary numbers.  The general rule to remember is
  that most fractional numbers that have a finite representation in decimal
  (a.k.a "base-10")
  do not have a finite representation in binary (a.k.a "base-2").
  And so they are
  approximated using the closest binary number available.  That
  approximation is usually very close, but it will be slightly off
  and in some cases can cause your results to be a little different
  from what you might expect.</p>

  <p>In SQLite version 3.29.0 ([dateof:3.29.0]), the rounding behavior
  was modified to more often give the results expected by people
  accustomed to thinking in decimal instead of binary.
}

faq {
  I get some compiler warnings when I compile SQLite.
  Isn't this a problem?  Doesn't it indicate poor code quality?
} {
  <p>Quality assurance in SQLite is done using 
  [test coverage | full-coverage testing],
................................................................................
# End of questions and answers.
#############

hd_puts {<h2>Frequently Asked Questions</h2>}

hd_puts {<ol class=nounderline>}
for {set i 1} {$i<$cnt} {incr i} {

  hd_puts "<li><a href=\"#q$i\">[lindex $faq($i) 0]</a></li>"
}
hd_puts {</ol>}

for {set i 1} {$i<$cnt} {incr i} {


  hd_fragment q$i
  hd_puts "<p><b>($i) [lindex $faq($i) 0]</b></p>\n"
  hd_resolve "<blockquote>[lindex $faq($i) 1]</blockquote></li>\n"
}
hd_puts {</ol>}
</tcl>







|
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<







 







>
|




>
>


|



359
360
361
362
363
364
365
366

























367
368
369
370
371
372
373
...
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
  <p>The [sqlite3_prepare_v2()] interface creates a
  [prepared statement] that will automatically recompile itself if
  the schema changes.  The easiest way to deal with
  [SQLITE_SCHEMA] errors is to always use [sqlite3_prepare_v2()]
  instead of [sqlite3_prepare()].
}

faq {} {}


























faq {
  I get some compiler warnings when I compile SQLite.
  Isn't this a problem?  Doesn't it indicate poor code quality?
} {
  <p>Quality assurance in SQLite is done using 
  [test coverage | full-coverage testing],
................................................................................
# End of questions and answers.
#############

hd_puts {<h2>Frequently Asked Questions</h2>}

hd_puts {<ol class=nounderline>}
for {set i 1} {$i<$cnt} {incr i} {
  if {[lindex $faq($i) 1]==""} continue;
  hd_puts "<li value='$i'><a href=\"#q$i\">[lindex $faq($i) 0]</a></li>"
}
hd_puts {</ol>}

for {set i 1} {$i<$cnt} {incr i} {
  set body [lindex $faq($i) 1]
  if {[string length $body]==0} continue;
  hd_fragment q$i
  hd_puts "<p><b>($i) [lindex $faq($i) 0]</b></p>\n"
  hd_resolve "<blockquote>$body</blockquote></li>\n"
}
hd_puts {</ol>}
</tcl>