<div dir="auto">Also let me say that databases *may* optimize this or allow use of native types, with the risk of truncating or expecting a larger type than the programmer expects. Scientific avoids this at the price of using the textual representations the target expects.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 11, 2022, 15:45 Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let me try this again.<br>
<br>
Database backends generally use the scientific package to represent<br>
numbers, because databases do not represent numbers as Haskell Int / C<br>
(int) or even Haskell Integers (unless you mean something like<br>
Data.Fixed). A database number typically has a number of decimal<br>
digits and a precision again specified as decimal digits. (ex.<br>
NUMERIC(9, 2)) It is not floating point.<br>
<br>
The scientific package, to fit such applications (including that of<br>
JSON), stores numbers as ASCII digits because they are so represented<br>
(as decimal digits and decimal precision), not as machine numbers.<br>
<br>
Accordingly, these numbers are stored and transmitted as decimal<br>
digits, not as the sort of binary numbers you might expect.<br>
<br>
On Thu, Aug 11, 2022 at 3:36 PM Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de" target="_blank" rel="noreferrer">olf@aatal-apotheke.de</a>> wrote:<br>
><br>
> > My observation about the "scientific" package is also relevant here:<br>
> > most DBMSes have a different notion of "number" than most programming<br>
> > languages, so unless there is specifically a binary number field type<br>
> > it is probably necessary to send it as a string of some variety. The<br>
> > "scientific" package abstracts over this for Haskell.<br>
><br>
> You mean that formatting a Scientific number as String is more<br>
> efficient than formatting an Integer/Double in its usual<br>
> representation? How about parsing? In most parsing libraries I've seen<br>
> [1,2,3] the following code transforms a string of digits to an integer.<br>
><br>
> import Data.Char (ord)<br>
> import Data.Foldable (foldl')<br>
><br>
> -- The parser ensures only digit Chars<br>
> -- are passed to this function.<br>
> fromDigit :: Num a => Char -> a<br>
> fromDigit = let<br>
>     z = ord '0'<br>
>     in \digit -> fromIntegral (ord digit - z)<br>
><br>
> appendDigit :: Num a => a -> Char -> a<br>
> appendDigit x d = 10 * x + fromDigit d<br>
><br>
> digitsToNum :: Num a => [Char] -> a<br>
> digitsToNum = foldl' appendDigit 0<br>
><br>
> If in addition to 'show' the function prependDigit (and its foldr<br>
> cousin for digits behind the floating point) were particularly<br>
> efficient for Scientific [*], that would indeed make a strong case for<br>
> using Scientific in parsing and (SQL-)database applications.<br>
><br>
> Olaf<br>
><br>
> [1] <a href="https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.Token.html#local-6989586621679060535" rel="noreferrer noreferrer" target="_blank">https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.Token.html#local-6989586621679060535</a><br>
> [2] <a href="https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_" rel="noreferrer noreferrer" target="_blank">https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_</a><br>
> [3] <a href="https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal" rel="noreferrer noreferrer" target="_blank">https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal</a><br>
> [*] This seems not to be the case currently: The Num instance is implemented as<br>
><br>
>  Scientific c1 e1 * Scientific c2 e2 =<br>
>         Scientific (c1 * c2) (e1 + e2)<br>
><br>
> Would it be a bad idea to add special cases for numbers of the form<br>
> Scientific 1 e? It penalizes all multiplications with a pattern match.<br>
><br>
<br>
<br>
-- <br>
brandon s allbery kf8nh<br>
<a href="mailto:allbery.b@gmail.com" target="_blank" rel="noreferrer">allbery.b@gmail.com</a><br>
</blockquote></div>