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)