Re: ODBC Library?
On Monday, 10 November 2014 at 20:37:51 UTC, Charles wrote: For anyone in the future: I needed odbc32.lib, so I created the following odbc32.def and used implib. Thanks me. My computer I was using recently died, and ran into this problem again when getting everything set up. Is there any way to just fix this issue altogether?
Re: Failed 'dub run' with 'Failed to invoke the compiler dmd'
On Saturday, 31 October 2015 at 05:33:08 UTC, Timoses wrote: On Saturday, 31 October 2015 at 04:00:18 UTC, Timoses wrote: Linking... ld: library not found for -levent clang: error: linker command failed with exit code 1 (use -v to see invocation) --- errorlevel 1 dmd failed with exit code 1. Seems to be fixed by editing dmd.conf (added -L-L/usr/local/lib) [Environment] DFLAGS=-I/Library/D/dmd/src/phobos -I/Library/D/dmd/src/druntime/import -L-L/Library/D/dmd/lib -L-L/usr/local/lib Have a question though: Why is it -L-L/usr/local/lib and not -L/usr/local/lib ? DMD uses different linkers depending on the platform. For the compiler, -L means 'pass this command to the linker.' In this case, that just also happens to be -L, which is understood by ld (the system linker) as the flag to set the library path. If you were using the Microsoft linker on Windows, it would be -L/LIBPATH:dir. If you were manually linking with libevent on Mac or Linux, you would pass -L-levent, and so on.
Re: Failed 'dub run' with 'Failed to invoke the compiler dmd'
On Saturday, 31 October 2015 at 06:13:27 UTC, Mike Parker wrote: DMD uses different linkers depending on the platform. For the compiler, -L means 'pass this command to the linker.' In this case, that just also happens to be -L, which is understood by ld (the system linker) as the flag to set the library path. If you were using the Microsoft linker on Windows, it would be -L/LIBPATH:dir. If you were manually linking with libevent on Mac or Linux, you would pass -L-levent, and so on. Cool! Thanks a lot!
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 15:42:00 UTC, tcak wrote: On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote: On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. Any other thoughts? For finance stuff - missing a floating point decimal data type. Things like 1.1 + 2.2 = 3.3003 I always thought that this type of arithmetic operations can be solved with BigInt, but never tried it. Since the issue is related to IEEE standard, a simulated (not supported by hardware directly) data type might be required. Bigint îs enough only for addition or subtraction as long as you keep a commonly agreed constant scale. Once you need multiplication, division or rounding, managing a dynamic scale can be very messy. IEEE standard is also divided between two standard formats: DPD preferred by IBM and BID preferred by Intel. Currently a DPD partial implementation is available on code.dlang.org; Unfortunately it's not updated since 4 months. The author proposed this for phobos integration without success. My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library.
Re: good reasons not to use D?
On Sat, 2015-10-31 at 15:41 +, tcak via Digitalmars-d-learn wrote: > On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote: > > On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: > > > I'm writing a talk for codemesh on the use of D in finance. > > > > > > Any other thoughts? > > > > For finance stuff - missing a floating point decimal data type. > > Things like 1.1 + 2.2 = 3.3003 > > I always thought that this type of arithmetic operations can be > solved with BigInt, but never tried it. Since the issue is > related to IEEE standard, a simulated (not supported by hardware > directly) data type might be required. In that std.bigint.BigInt provides the accuracy, yes it does suffice. But it is slow. As far as I am aware only IBM Big Iron (aka mainframes, aka z-Series) has hardware decimal floating point these days. (Even though 1970s and 1980s microprocessors had the feature.) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote: My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library. I agree
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote: My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library. "must be builtin in any modern language" – which modern languages actually have decimals as a built-in type, and what is your rationale against having them as a solid library implementation? It seems like it would only be interesting for a very fringe sector of users (finance, and only the part of it that actually deals with accounting). — David
Re: good reasons not to use D?
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. Any other thoughts? For finance stuff - missing a floating point decimal data type. Things like 1.1 + 2.2 = 3.3003
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote: On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. Any other thoughts? For finance stuff - missing a floating point decimal data type. Things like 1.1 + 2.2 = 3.3003 I always thought that this type of arithmetic operations can be solved with BigInt, but never tried it. Since the issue is related to IEEE standard, a simulated (not supported by hardware directly) data type might be required.
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 23:07:46 UTC, rumbu wrote: On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger wrote: On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote: My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library. "must be builtin in any modern language" – which modern languages actually have decimals as a built-in type, and what is your rationale against having them as a solid library implementation? It seems like it would only be interesting for a very fringe sector of users (finance, and only the part of it that actually deals with accounting). — David GNU C - 3 built-in decimal data types - https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html This is a vendor-specific extension and likely exposed by GDC already.
Re: good reasons not to use D?
On 10/31/2015 09:06 AM, Russel Winder via Digitalmars-d-learn wrote: > As far as I am aware only IBM Big Iron (aka mainframes, aka z-Series) has > hardware decimal floating point these days. (Even though 1970s and 1980s > microprocessors had the feature.) Although still years away from production, the Mill CPU will have decimal floating point: http://millcomputing.com/wiki/Instruction_Set Ali
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote: On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. Any other thoughts? For finance stuff - missing a floating point decimal data type. Things like 1.1 + 2.2 = 3.3003 Isn't D used by a rather large banking company internally? I believe I remember this being mentioned somewhere.
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger wrote: On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote: My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library. "must be builtin in any modern language" – which modern languages actually have decimals as a built-in type, and what is your rationale against having them as a solid library implementation? It seems like it would only be interesting for a very fringe sector of users (finance, and only the part of it that actually deals with accounting). — David C# - built-in decimal data type 128 bit (96 bit significand + 32 bit sign and scale) - https://msdn.microsoft.com/en-us/library/364x0z75.aspx GNU C - 3 built-in decimal data types - https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html Besides that, according to the last IEEE-2008 standard, any language must implement decimal floating point support at the same level of binary float support. Once al language has float, double and real, must also define decimal counterparts - decimal32, decimal64 and decimal128. Concerning the advantages of a built-in data type, it happens to work right now to a decimal BID floating point implementation, here is a list of problems I encountered during development: - literals - right now the only way to define literals is a templated string, using float literals will result in precision loss, since binary floating point cannot be represented exactly. - correct comparison operators - operator overloading doesn't allow unordered comparisons similar to binary data types. Comparing any NaN, must always return false, implementing opEquals is not enough is this case, since a != b is equivalent to !(a == b) - implicit casting cannot be defined - a decimal32 must be implicitly convertible to decimal64 and a decimal64 must be implicitly convertible to decimal128. - using a global DecimalContext (according to IEEE standard) - similar to std.math.FloatingPointControl, will make all your functions impure. Throwing exceptions according also to IEEE standard will make any calculation garbage collected. The compiler can override this behaviour as it's doing in the binary floating point case, they are also using a global context and throw exceptions. - BigInt is unsuitable as backend for decimal128 data type since it allocates on overflow, therefore all your operations will be garbage collected. Also BigInt is using uint arrays as backend, there is no performance optimisation for 64 bit arithmetic, that's why is slow. Adding a scale to the BigInt is not enough, once you need to multiply values with high-precision percents, you must keep all your numbers scaled to many, many digits resulting in very poor performance. - Efficient 128 bit arithmetic is missing since ucent is not implemented and the decimal128 data type is heavily built on it. Writing your own 128 bit data type will have the same disadvantages as exposed above. As a fun fact, through trial and error, I discovered that a FPU division is faster than the Newton–Raphson applied to wide integral data types. Probably, a fine tuned assembler implementation is faster than that. Since there are operations calculated using unlimited precision like fma(), there is also need for efficient >128 bit arithmetic. - Impurity and garbage collection being involved, the CTFE is not always available. - Heavily templating your code to cover all three decimal data types, will result in unintelligible compiler errors like "Out of memory" and will render features like code completion useless. Using mixins will break out syntax highlighting, code completion and documentation; to cope with that you will finally copy-paste code all over the place. - you cannot interfere with compiler optimisations, eg comparing a decimal value to 0 in certain cases can be done with a simple bit test, instead of a fully featured function, even inlined. Yes, I'm working in the "very fringe sector of users" - financial apps. So banks, insurance companies, investment funds and accounting firms are a very fringe sector. In most cases they are using Java for development, a very fringe language. Good to know that.
