Re: Giving up
Good catch! On Saturday, 6 August 2022 at 17:27:30 UTC, Rumbu wrote: [...] long double x = 0x1p-16383; dmd -c test2.c test2.c(3): Error: number `0x1p-16383` is not representable It is. But not in the double type and `0x1p-16383` is a double not a long double. [...] Also the value needs a L suffix in clang to not be interpreted a classic double. GCC is no exception and needs the `L` suffix, too. [1] [1] https://en.cppreference.com/w/cpp/language/floating_literal
Re: Giving up
On Saturday, 6 August 2022 at 06:03:59 UTC, Vladimir Panteleev wrote: On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote: [...] The last version where this compiled successfully was D 0.116, released on March 7, 2005. Perhaps you may have had a bug in your test suite which caused these lines to not be compiled. The file named intel.d was introduced with ``` commit b5b1458585b65b9072f907de4c3f09b1b4790e26 (tag: v0.9.1) Author: razvan.stefanescu Date: Wed Jan 31 23:09:19 2018 +0200 a lot of changes ``` it seems that nobody, including me, ever executed `dub test`. Archiving and CI would be nice for packages registered with code.dlang.org.
Re: Giving up
Hi Rumbu,
I appreciate your work.
On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:
[...]
The last issues are generated by unpublished changes in the
parser:
Examples:
```
float z = 85886696878585969769557975866955695.E0; //integer
The latest compiler here on my local machine is 2.073.2 of 2017
(?):
```
$ dmd --version
DMD64 D Compiler v2.073.2
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright
$ cat e0.d
unittest {
float z = 85886696878585969769557975866955695.E0; //integer
overflow, I don't see any int
real x = 0x1p-16383; //number `0x1p-16383` is not
representable. It is, trust me.
}
$ dmd e0
e0.d(2): Error: integer overflow
e0.d(3): Error: number '0x1p-16383' is not representable
```
Re: Beta 2.100.0
On Friday, 22 April 2022 at 14:33:19 UTC, Brian Callahan wrote: Just added a changelog entry for my zlib update to phobos... (Sorry for not doing it before! Even after Iain mentioned it...) ~Brian Has the zlib-source been altered or why is it included as source? I mean I just upgraded my OS's zlib shared object and thought I'm done.
Re: D GUI Framework (responsive grid teaser)
On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote: [...] Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 I optimized the whole thing a bit, so now a complete screen with layouting, hittesting, drawing takes about 28ms, that's 8x faster than before. Drawing is still around 10ms, layouting around 16ms, spatial index handling 2ms. Awesome. Compared to the video you posted some days ago there is also almost no visible aliasing. Do you plan to create a web browser based on your framework?
Re: Another take on decimal data types
On Sunday, 14 January 2018 at 12:35:43 UTC, rumbu wrote: On Sunday, 14 January 2018 at 11:44:39 UTC, kdevel wrote: On Sunday, 14 January 2018 at 07:20:26 UTC, rumbu wrote: On Saturday, 13 January 2018 at 22:51:18 UTC, kdevel wrote: [...] Can you please tell me on your system what are the values for real.sizeof and real.mant_dig? They are 12 and 64 (-m32) and 16 and 64 (-m64). This is curious. Because the only documented real type with a 64-bit mantissa is the 80-bit Intel Extended Precision format with a unique sizeof of 10 (and not 12 or 16). sizeof returns the in-memory size (at least in C and C++) which is subject to alignment constraints. 32-bit mode typically requires 4-byte aligned access (96 bit = 12 byte) while 64-bit requires 8-byte alignment (128 bit = 16 bytes) for optimal performance. Cf. e.g. p. 28 of "SYSTEM V APPLICATION BINARY INTERFACE Intel386" (long double) http://www.sco.com/developers/devspecs/abi386-4.pdf and p. 12 of "System V Application Binary Interface AMD64 Architecture Processor Supplement" https://www.uclibc.org/docs/psABI-x86_64.pdf Actually, real80 is the only type I'm supporting in the library, any other real type is converted to double. This will explain some loss of precision. Agreed. Do you have more information about the real type on you system, because on mine (Windows), real.sizeof is always 10, irrespective of -m32 or -m64. Mantissa will be easy to extract being 64-bit, but I don't know the exact layout of your real type to extract the exponent. Assumed that your machine has a X86_64 cpu real = long double is the 80-bit extended precision format. I suppose you are running windows and it may be that the Window ABI stores these reals 16-bit (2-byte) aligned. In this case there will be no padding. But I have not found info on this topic.
Re: Another take on decimal data types
On Sunday, 14 January 2018 at 07:20:26 UTC, rumbu wrote: On Saturday, 13 January 2018 at 22:51:18 UTC, kdevel wrote: [...] Can you please tell me on your system what are the values for real.sizeof and real.mant_dig? They are 12 and 64 (-m32) and 16 and 64 (-m64). [...] [...] Forgot to propagate the sign in case of decimal to binary conversion. Corrected. ACK. [...] It compiles now. ACK.
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 22:05:02 UTC, rumbu wrote:
Now it prints:
1.00+0.84147098480789650669
+0.8414709848078965066525023216302990 +2.653e-18
My values differ slightly
1.00 0.841470984807896506664591
0.8414709848078965066525023.653e-18
But I would check this later.
Your unity test also seems now to compute correctly. My maximum
|δ| for decimal128 is now 1e-34
Same here.
Do you have something against including parts of your test
published here as unittests? Thanks.
No, of course not, please take whatever you need! I have another
testcase which prints awkward results:
sinus_31.d
```
import std.stdio;
import std.math;
import decimal;
void main ()
{
real r;
for (r = 1; r < 6; r += .1L) {
decimal128 d = r;
auto dsin = sin (d);
auto rsin = sin (r);
real delta = cast(real) dsin;
delta -= rsin;
writefln ("%9.2f %30.24f %30.24f %12.4g", r, rsin, dsin,
delta);
}
}
```
Please note the large deltas in case of negative operands. I
suspect the conversion to real is wrong for these numbers:
1.00 0.841470984807896506664591
0.841470984807896506652502 -5.421e-20
1.10 0.891207360061435339970703
0.8912073600614353787342713.871e-17
1.20 0.932039085967226349689098
0.932039085967226332095783 -1.756e-17
1.30 0.963558185417192964729825
0.9635581854171929758025501.106e-17
1.40 0.985449729988460180693261
0.985449729988460165022497 -1.567e-17
1.50 0.997494986604054430972058
0.997494986604054430941723 -5.421e-20
1.60 0.999573603041505164359688
0.99957360304150516184 -2.548e-18
1.70 0.991664810452468615338453
0.9916648104524686216595146.343e-18
1.80 0.973847630878195186514452
0.973847630878195177217087 -9.324e-18
1.90 0.946300087687414488452770
0.9463000876874145185556393.014e-17
2.00 0.909297426825681695322298
0.9092974268256816953960205.421e-20
2.10 0.863209366648873770600393
0.863209366648873727768840 -4.283e-17
2.20 0.808496403819590184279108
0.808496403819590083670346 -1.006e-16
2.30 0.745705212176720177432929
0.7457052121767202999801941.226e-16
2.40 0.675463180551150926659871
0.6754631805511509980929627.145e-17
2.50 0.598472144103956494242628
0.598472144103956494051855 -2.168e-19
2.60 0.515501371821464235509908
0.515501371821464164135960 -7.139e-17
2.70 0.427379880233829934906920
0.427379880233829779959717 -1.549e-16
2.80 0.334988150155904919986691
0.3349881501559050929127641.729e-16
2.90 0.239249329213982328722001
0.2392493292139824233381579.458e-17
3.00 0.141120008059867222739193
0.141120008059867222100745-6.37e-19
3.10 0.041580662433290579926783
0.041580662433290496266481 -8.366e-17
3.20-0.058374143427579908318645
-0.058374143427580079845624 0.1167
3.30-0.157745694143248381115198
-0.157745694143248199327897 0.3155
3.40-0.255541102026831318288136
-0.255541102026831224503680 0.5111
3.50-0.350783227689619847116916
-0.350783227689619848120369 0.7016
3.60-0.442520443294852383234834
-0.4425204432948524578009170.885
3.70-0.529836140908493212172466
-0.529836140908493358235883 1.06
3.80-0.611857890942719074699619
-0.6118578909427189294045591.224
3.90-0.687766159183973817053612
-0.6877661591839737462235901.376
4.00-0.756802495307928250372134
-0.7568024953079282513726391.514
4.10-0.818277111064410503490831
-0.8182771110644102973284161.637
4.20-0.871575772413588059281658
-0.8715757724135881438531781.743
4.30-0.916165936749454983402223
-0.9161659367494549086814651.832
4.40-0.951602073889515953533484
-0.9516020738895160594505671.903
4.50-0.977530117665097055001684
-0.9775301176650970553891351.955
4.60-0.993691003633464455912887
-0.9936910036334644149781271.987
4.70-0.23257564100884174467
-0.232575641008862484432
4.80-0.996164608835840671935500
-0.9961646088358406886689001.992
4.90-0.982452612624332512691275
-0.9824526126243324484891471.965
5.00-0.958924274663138469525139
-0.9589242746631384688931541.918
5.10-0.925814682327732297803524
-0.9258146823277324360419561.852
5.20-0.883454655720153265790421
-0.8834546557201531864308001.767
5.30-0.832267442223901164892897
-0.8322674422239012705588071.665
5.40-0.772764487555987363974919
-0.7727644875559871452935061.546
5.50-0.705540325
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 19:28:40 UTC, rumbu wrote:
On Saturday, 13 January 2018 at 18:37:10 UTC, kdevel wrote:
I get large numerical dicrepancies and an exception:
That's because you are mixing floating point and decimal.
Just to take one example: double 1.1 cannot be represented
exactly as floating point and it's in fact
1.1002384185791015625.
Sure. double has 53 mantissa bits but float only 24. But that is
not my point.
I am *not* talking about the 1e-18 but about these lines:
1.10 0.891207360061435339970703
0.8781666700439167 -1e-02
1.20 0.932039085967226349689098
0.93273599822296001e-04
1.30 0.963558185417192964729825
0.9647744178037840
1e-03
and
5.70-0.550685542597637763537807
-25.1655002545915000 -
At 5.7 the value is obviously out of range.
sin is calculated using a Taylor series: sin(x) = x - x^3/3! +
x^5/5! - x^7/7! ... and so on. Raising to power all that junk
after 1.1 will lead finally to error. If you really want to
find out sin(1.1) using decimal, try sin(decimal128("1.1")) or
sin(decimal128(1)/10);
Chapter 9.2 of IEEE-754-2008 says the domain of sin(x) is (-inf,
inf). So if the argument x is outside the radius of convergence
of the Taylor series x must be reduced modulo 2pi such that it
fits.
For exact values like sin(1.0), I let you decide which one is
more exact:
Wolfram Alpha: 0.8414709848078965066525023216302989
real: 0.84147098480789650666459100
double:0.8414709848078965048700
float: 0.8414709568023681640600
decimal128:0.8414709848078965066329679978908351
decimal64: 0.841470984807896500
decimal32: 0.841471
Anyway, I wouldn't call a difference at the 18th digit a "large
discrepancy" when we are talking about irrational numbers.
See above.
Regarding the exception, I cannot reproduce it, but I'll look
into it.
Nice.
Thank you for your exhaustive testing :)
There's more to come (sorry for the greek symbols, could not
resist to check this utf-8 feature):
unity.d
```
import std.stdio;
import std.typecons;
import std.range;
import std.math;
import decimal;
immutable size_t N = 100;
void unity (T) ()
{
writeln ("\n=== ", T.stringof, " ===\n");
immutable one = T (1);
immutable two = T (2);
immutable π = atan (one) * 4;
writefln!"π = <%30.24f>" (π);
foreach (i; iota(N + 1)) {
auto φ = two * π * i / N;
auto sinφ = sin (φ);
auto cosφ = cos (φ);
auto unity = sinφ * sinφ + cosφ * cosφ;
auto δ = one - unity;
writeln ("φ = <", φ, ">, δ = <", δ, ">");
}
}
void main ()
{
// unity!float;
// unity!double;
// unity!real;
// unity!decimal32;
unity!decimal64;
unity!decimal128;
}
```
Selected lines from the output produced here (Linux, DMD64 D
Compiler v2.077.1):
=== Decimal!64 ===
π = <3.1415926535897930>
φ = <0>, δ = <0>
φ = <0.0628319>, δ = <0>
φ = <0.125664>, δ = <1e-16> possibly okay
:
φ = <0.942478>, δ = <2.41721e-06>too large
:
φ = <2.45044>, δ = <-6.57811e-07>ditto
φ = <2.51327>, δ = <-3.83012e-10>ditto
φ = <2.57611>, δ = <0.479476>ditto
:
:
:
=== Decimal!128 ===
π = <3.141592653589793238612055>
φ = <0>, δ = <0>
φ = <1e-02>, δ = <-1.73780e-22>
:
Something went wrong with printing φ. And also this program
crashes:
core.exception.RangeError@decimal/package.d(6652): Range violation
??:? _d_arrayboundsp [0x80bc65f]
??:? void decimal.sinkFloat!(char,
decimal.integrals.unsigned!(128).unsigned).sinkFloat(ref
const(std.format.FormatSpec!(char).FormatSpec), void
delegate(const(char)[]),
const(decimal.integrals.unsigned!(128).unsigned), const(int),
const(bool), const(decimal.RoundingMode), const(bool)) [0x80b2976]
??:? void decimal.sinkGeneral!(char,
decimal.integrals.unsigned!(128).unsigned).sinkGeneral(ref
const(std.format.FormatSpec!(char).FormatSpec), void
delegate(const(char)[]),
const(decimal.integrals.unsigned!(128).unsigned), const(int),
const(bool), const(decimal.RoundingMode)) [0x80b33a4]
??:? void decimal.sinkDecimal!(char,
decimal.Decimal!(128).Decimal).sinkDecimal(ref
const(std.format.FormatSpec!(char).FormatSpec), void
delegate(const(char)[]), ref
const(decimal.Decimal!(128).Decimal),
const(decimal.RoundingMode)) [0x80b241a]
??:? const void
decimal.Decimal!(128).Decimal.toString!(char).toString(scope void
delegate(const(char)[]), std.format.FormatSpec!(char).FormatSpec)
[0x80b22bb]
??:? void
std.format.formatObject!(std.stdio.File.LockingTextWriter,
decimal.Decimal!(128).Decimal, char).formatObject(ref
std.stdio.File.LockingTextWriter, ref
decimal.Decimal!(128).Decimal, ref
const(std.format.FormatSpec!(char).FormatSpec)) [0x80b73cf]
??:? void
std.format.formatValue!(std.stdio.File.LockingTextWriter,
decimal.Decimal!(128).Decimal, char).formatValue(ref
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 17:46:15 UTC, rumbu wrote:
The following code works:
real r;
for (r = 1; r < 6; r += .1L) {
decimal128 d = r;
auto dsin = sin (d);
auto rsin = sin (r);
auto delta = dsin - rsin; //delta is decimal128
writefln ("%9.2f %30.24f %30.24f %12.4g", r, rsin,
dsin, delta);
}
rsinus.d
```
import std.stdio;
import std.math;
import decimal;
void main ()
{
real r;
for (r = 1; r < 6; r += .1L) {
decimal128 d = r;
auto dsin = sin (d);
auto rsin = sin (r);
auto delta = dsin - rsin;
writefln ("%9.2f %30.24f %30.24f %12.4g", r, rsin, dsin,
delta);
}
}
```
I get large numerical dicrepancies and an exception:
1.00 0.841470984807896506664591
0.8414709848078965066329683.633e-18
1.10 0.891207360061435339970703
0.8781666700439167 -1e-02
1.20 0.932039085967226349689098
0.93273599822296001e-04
1.30 0.963558185417192964729825
0.96477441780378401e-03
1.40 0.985449729988460180693261
0.9854497299884601650222082.352e-17
1.50 0.997494986604054430972058
0.997494986604054430940101 -1.206e-17
1.60 0.999573603041505164359688
0.91730939 -1e-02
1.70 0.991664810452468615338453
0.9916648104524686216596665.316e-17
1.80 0.973847630878195186514452
0.9738476308781951772178013.222e-17
1.90 0.946300087687414488452770
0.9463000876874145185587115.006e-17
2.00 0.909297426825681695322298
0.909297426825681695408286 -1.229e-17
2.10 0.863209366648873770600393
0.863209366648873727768592 -9.243e-17
2.20 0.808496403819590184279108
0.808496403819590083669388 -1.180e-16
2.30 0.745705212176720177432929
0.7457052121767202999767181.573e-16
2.40 0.675463180551150926659871
0.6754631805511509980810254.488e-17
2.50 0.598472144103956494242628
0.598472144103956494052117 -5.365e-17
2.60 0.515501371821464235509908
0.515501371821464164136844 -1.059e-16
2.70 0.427379880233829934906920
0.427379880233829779962563 -1.640e-16
2.80 0.334988150155904919986691
0.3349881501559050929126991.534e-16
2.90 0.239249329213982328722001
0.2392493292139824233379498.154e-17
3.00 0.141120008059867222739193
0.1411200080598672221001099.000e-18
3.10 0.041580662433290579926783
0.041580662433290496264607 -8.502e-17
3.20-0.058374143427579908318645
-0.058374143427580079845578 -1.746e-16
3.30-0.157745694143248381115198
-0.1577456941432481993277621.774e-16
3.40-0.255541102026831318288136
-0.2555411020268312245032961.098e-16
3.50-0.350783227689619847116916
-0.350783227689619848119312 -1.252e-17
3.60-0.442520443294852383234834
-0.442520443294852457798085 -5.310e-17
3.70-0.529836140908493212172466
-0.529836140908493358228498 -1.787e-16
3.80-0.611857890942719074699619
-0.6118578909427189293857889.811e-17
3.90-0.687766159183973817053612
-0.6877661591839737462241222.078e-17
4.00-0.756802495307928250372134
-0.756802495307928251373997 -5.067e-17
4.10-0.818277111064410503490831
-0.8182771110644102973318001.797e-16
4.20-0.871575772413588059281658
-0.871575772413588143861425 -6.686e-17
4.30-0.916165936749454983402223
-0.9161659367494549087011531.013e-16
4.40-0.951602073889515953533484
-0.951602073889516059449964 -1.634e-16
4.50-0.977530117665097055001684
-0.977530117665097055387688 -4.889e-17
4.60-0.993691003633464455912887
-0.993691003633464414974720 -8.475e-18
4.70-0.23257564100884174467
-0.23257564100886240565 -5.624e-17
4.80-0.996164608835840671935500
-0.996164608835840688651004 -8.651e-18
4.90-0.982452612624332512691275
-0.9824526126243324484897332.651e-17
5.00-0.958924274663138469525139
-0.958924274663138468894495 -1.739e-17
5.10-0.925814682327732297803524
-0.925814682327732436044974 -9.704e-17
5.20-0.883454655720153265790421
-0.8834546557201531864374885.926e-17
5.30-0.832267442223901164892897
-0.832267442223901270573400 -1.281e-16
5.40-0.772764487555987363974919
-0.7727644875559871453248932.202e-16
5.50-0.705540325570391908089566
-0.7055403255703919062308031.647e-17
5.60-0.631266637872321313522395
-0.631266637872321596869491 -3.079e-16
5.70-0.550685542597637763537807
-25.1655002545915000 -
core.exception.RangeError@decimal/package.d(6652): Range violation
??:? _d_arrayboundsp [0x46ccea]
decimal/package.d:6652
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 14:43:53 UTC, rumbu wrote:
I received a suggestion to reorganize the file structure
because of some bug in dub
(https://issues.dlang.org/show_bug.cgi?id=11847). The dub.json
remained out of sync.
I changed it, but I am not 100% sure that it's working. I am
not experienced with dub, If someone wants to maintain
dub.json, I will be more than happy to accept any pull request.
I can compile/run the nosine.d now. But implicit conversion
between decimalX and float/double/real does not seem to work. I
came across this in
sinus.d
```
import std.stdio;
import std.math;
import decimal;
void main ()
{
real r;
for (r = 1; r < 6; r += .1L) {
decimal128 d = r;
auto dsin = sin (d);
auto rsin = sin (r);
real delta = dsin - rsin;
writefln ("%9.2f %30.24f %12.4g", r, rsin, dsin, delta);
}
}
```
$ dmd sinus.d decimal.git/libdecimal.a
sinus.d(12): Error: cannot implicitly convert expression
dsin.opBinary(rsin) of type Decimal!128 to real
I tried to change the subtraction to
```
real delta = dsin;
delta -= rsin;
```
getting
sinus_e1.d(12): Error: cannot implicitly convert expression dsin
of type Decimal!128 to real
Changes this into
```
real delta = dsin.to!real;
delta -= rsin;
```
sinus_e2.d(12): Error: template decimal.to cannot deduce function
from argument types !(real)(Decimal!128), candidates are:
decimal/package.d(5814):decimal.to(T, D)(auto ref const D
x, const RoundingMode mode) if (isIntegral!T && isDecimal!D)
decimal/package.d(5832):decimal.to(F, D)(auto ref const D
x, const RoundingMode mode) if (isFloatingPoint!F && isDecimal!D)
to no avail. Also
```
real delta = cast(real) dsin;
```
did not succeed:
decimal/package.d(933): Error: undefined identifier mode, did you
mean template modf(D)(auto ref const D x, ref D y) if
(isDecimal!D)?
sinus_e3.d(12): Error: template instance
decimal.Decimal!128.Decimal.opCast!real error instantiating
Also
```
real delta = dsin.to!(real, RoundingMode.tiesToEven);
```
ain't work:
sinus_e4.d(12): Error: template decimal.to cannot deduce function
from argument types !(real, cast(RoundingMode)0)(Decimal!128),
candidates are:
decimal/package.d(5814):decimal.to(T, D)(auto ref const D
x, const RoundingMode mode) if (isIntegral!T && isDecimal!D)
decimal/package.d(5832):decimal.to(F, D)(auto ref const D
x, const RoundingMode mode) if (isFloatingPoint!F && isDecimal!D)
How can I convert a decimalX to float/double/real?
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 14:43:53 UTC, rumbu wrote:
On Saturday, 13 January 2018 at 13:56:20 UTC, kdevel wrote:
Now my code does no longer compiles against the decimal
package. This is my directory structure:
I received a suggestion to reorganize the file structure
because of some bug in dub
(https://issues.dlang.org/show_bug.cgi?id=11847). The dub.json
remained out of sync.
I changed it, but I am not 100% sure that it's working. I am
not experienced with dub, If someone wants to maintain
dub.json, I will be more than happy to accept any pull request.
I only invoked dub in order to generate libdecimal.a
Personally I hate dub because it's polluting my %APPDATA%
folder and each time I connect my laptop to the company domain
network, I must wait to sync zillions of files.
I have now the following directory structure:
dlang-decimal/
decimal -> decimal.git/src/decimal/
decimal.git/ [git cloned
decimal.git]
libdecimal.a
src/
decimal/
floats.d
floats.di
integrals.d
integrals.di
package.d
package.di
ranges.d
ranges.di
sinks.d
sinks.di
nosine.d
I have generated the .di files with dmd -H *.d within the
src/decimal directory. Now dmd in unwilling to compile:
$ dmd nosine.d decimal.git/libdecimal.a
decimal/integrals.di(537): Error: xadd cannot be interpreted at
compile time, because it has no available source code
decimal/integrals.di(567):called from here: xadd(result,
z)
decimal/integrals.di(121):called from here: fma(this,
10u, cast(uint)(cast(int)c - 48), ovf)
decimal/integrals.di(978):called from here: unsigned(0LU,
0LU).this("1")
[the four lines repeat untill 77 lines are printed]
How come?
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 13:49:59 UTC, kdevel wrote:
diff --git a/dub.json b/dub.json
index c48899f..d8882c1 100644
--- a/dub.json
+++ b/dub.json
@@ -10,16 +10,16 @@
"configurations": [
{
"name": "library",
-"excludedSourceFiles": [ "src/benchmark.d",
"src/test.d" ]
+"excludedSourceFiles": [
"src/benchmark/benchmark.d", "src/test/test.d" ]
},
Now my code does no longer compiles against the decimal package.
This is my directory structure:
dlang-decimal/
decimal -> decimal.git/src
decimal.git[created by git clone
decimal.git]
nosine.d
$ dmd nosine decimal.git/libdecimal.a
nosine.d(3): Error: module decimal is in file 'decimal.d' which
cannot be read
import path[0] = /.../dmd2/linux/bin64/../../src/phobos
import path[1] = /.../dmd2/linux/bin64/../../src/druntime/import
make: *** [nosine] Fehler 1
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 13:44:20 UTC, kdevel wrote:
$ dub
Performing "debug" build using dmd for x86_64.
decimal ~master: building configuration "library"...
src/test/test.d(4,5): Error: only one main allowed. Previously
found main at src/benchmark/benchmark.d(143,5)
dmd failed with exit code 1.
diff --git a/dub.json b/dub.json
index c48899f..d8882c1 100644
--- a/dub.json
+++ b/dub.json
@@ -10,16 +10,16 @@
"configurations": [
{
"name": "library",
-"excludedSourceFiles": [ "src/benchmark.d",
"src/test.d" ]
+"excludedSourceFiles": [
"src/benchmark/benchmark.d", "src/test/test.d" ]
},
{
"name": "unittest",
-"excludedSourceFiles": [ "src/benchmark.d",
"src/test.d" ]
+"excludedSourceFiles": [
"src/benchmark/benchmark.d", "src/test/test.d" ]
},
{
"name": "benchmark",
"targetType": "executable",
-"excludedSourceFiles": [ "src/test.d" ]
+"excludedSourceFiles": [ "src/test/test.d" ]
}
]
}
Re: Another take on decimal data types
On Saturday, 13 January 2018 at 01:30:12 UTC, rumbu wrote: On Friday, 12 January 2018 at 13:09:42 UTC, kdevel wrote: $ dmd nosine.d decimal.git/libdecimal.a decimal/package.d(10505): Error: undefined identifier decimalCapAngle Sorry, broke some code when I made the split. Now it's working. $ dub Performing "debug" build using dmd for x86_64. decimal ~master: building configuration "library"... src/test/test.d(4,5): Error: only one main allowed. Previously found main at src/benchmark/benchmark.d(143,5) dmd failed with exit code 1.
Re: Another take on decimal data types
On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:
- all std.math functions implemented (even logarithms and
trigonometry);
nosine.d
```
import std.stdio;
// import std.math;
import decimal;
void nosine (T) ()
{
T d = T(1.1);
writeln (sin(d));
}
void main ()
{
nosine!decimal32;
nosine!decimal64;
nosine!decimal128;
}
```
$ dmd nosine.d decimal.git/libdecimal.a
decimal/package.d(10505): Error: undefined identifier
decimalCapAngle
decimal/package.d(5364): Error: template instance
decimal.decimalSin!(Decimal!32) error instantiating
nosine.d(8):instantiated from here: sin!(Decimal!32)
nosine.d(13):instantiated from here: nosine!(Decimal!32)
decimal/package.d(10505): Error: undefined identifier
decimalCapAngle
decimal/package.d(5364): Error: template instance
decimal.decimalSin!(Decimal!64) error instantiating
nosine.d(8):instantiated from here: sin!(Decimal!64)
nosine.d(14):instantiated from here: nosine!(Decimal!64)
decimal/package.d(10505): Error: undefined identifier
decimalCapAngle
decimal/package.d(5364): Error: template instance
decimal.decimalSin!(Decimal!128) error instantiating
nosine.d(8):instantiated from here: sin!(Decimal!128)
nosine.d(15):instantiated from here: nosine!(Decimal!128)
Re: Another take on decimal data types
On Friday, 12 January 2018 at 05:18:15 UTC, rumbu wrote: On Thursday, 11 January 2018 at 23:57:29 UTC, kdevel wrote: What about the failed comparison: You are right in fact, there is also a failed comparison. Now corrected. Works. Thanks for the changes!
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 22:36:40 UTC, rumbu wrote:
1000
100
10
1
0.1
0.01
0.001
0.0001
1e-05
Regarding printf, I cannot help, this is a C function, has
nothing to do with D formatting.
Sure. What about the failed comparison:
gt.d
```
import std.stdio;
import decimal;
void loopme(T) ()
{
"---".writeln;
T e = 10;
while (e > 1e-6) {
e /= 10;
writeln (e, ' ', e > 1e-6);
}
}
void main ()
{
loopme!decimal32;
loopme!decimal64;
loopme!decimal128;
}
```
This gives here:
---
1 true
0.1 false
---
1 true
0.1 false
---
1 true
0.1 true
0.010 true
0.0010 true
0.00010 true
1.0e-05 true
1.0e-06 true
1.0e-07 false
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 20:44:13 UTC, kdevel wrote:
On Thursday, 11 January 2018 at 20:35:03 UTC, kdevel wrote:
<--- loop output missing
loop.d
```
import std.stdio;
import decimal;
void loopme(T) ()
{
"---".writeln;
T e = T(1000);
while (e > T(1e-6)) {
e.writeln;
e /= 10;
}
}
void main ()
{
loopme!float;
loopme!decimal32;
}
```
This prints
---
1000
100
10
1
0.1
0.01
0.001
0.0001
1e-05
---
1000
100
10
1
0.1
0.010<--
0.0010 <--
0.00010 <--
1.0e-05 <--
Why are there trailing zeroes?
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 20:40:01 UTC, Dmitry Olshansky
wrote:
printf ("%.2f\n", d);
C’s printf by definition can’t be customized.
Sure.
http://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html
What did you expect?
To be honest: A compile time error. Modern C compilers can check
such format strings. Example: GCC 6:
mis.c
```
#include
int main ()
{
double d = 0;
printf ("%p\n", d);
return 0;
}
```
$ gcc -Wall mis.c
mis.c: In function 'main':
mis.c:6:14: warning: format '%p' expects argument of type 'void
*', but argument 2 has type 'double' [-Wformat=]
printf ("%p\n", d);
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 20:35:03 UTC, kdevel wrote:
printf ("%.2f\n", d);
This must read
writefln ("%.2f", d);
Would have expected a compile time/run time error.
This prints:
0.735
0.00 <--- expected: 0.74
Good. writefln prints the expected value.
0.735
0.73
<--- loop output missing
This is still missing. If I change the while-loop threshold to
1e-9 the values are printed.
Re: Another take on decimal data types
Great project!
On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:
- all format specifiers implemented (%f, %e, %g, %a);
Really?
[...]
What's next:
- more tests;
Here you are:
```
import std.stdio;
import decimal;
void main ()
{
decimal32 d = "0.7";
d *= decimal32("1.05");
d.writeln;
printf ("%.2f\n", d);
float f = 0.7f;
f *= 1.05f;
f.writeln;
printf ("%.2f\n", f);
decimal32 e = 1_000_000_000;
while (e > 1e-7) {
e.writeln;
e /= 10;
}
}
```
This prints:
0.735
0.00 <--- expected: 0.74
0.735
0.73
<--- loop output missing
(DMD64 D Compiler v2.077.1)
