Re: Printing shortest decimal form of floating point number with Mir
On 1/3/2021 8:37 PM, 9il wrote: I didn't believe it when I got a similar answer about IEEE floating-point numbers: D doesn't pertinent to be IEEE 754 compatible language and the extended precision bug is declared to be a language feature. The "extended precision bug" is how all x87 code works, C to C++ to Java. The reason is simple - to remove the problem requires all intermediate results to be written to memory and read back in, which is a terrible performance problem. Early Java implementations did this write/read, and were forced to change it. The advent of the XMM registers resolved this issue, and all the x86 D compilers now use XMM for 32 and 64 bit floating point math, when compiled for a CPU that has XMM registers. Extended precision only happens when the `real` 80 bit type is used, and that is IEEE conformant. If you are aware of an FP bug in the XMM code generation, please file an issue on bugzilla, and I'll be happy to take care of it. The SIMD buglist is now down to one issue (32 byte stack alignment) which is something else. The conversion to and from strings is a different problem.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote: I suppose the answer would be that D doesn't pretend to support all C++ template features and the bug is not a bug because we live with this somehow for years. But it is a bug even if there was no C++... An alias should work by simple substitution, if it does not, then it is no alias... I didn't believe it when I got a similar answer about IEEE floating-point numbers: D doesn't pertinent to be IEEE 754 compatible language and the extended precision bug is declared to be a language feature. I suppose we shouldn't expect D to pretend to be a robust language for large business projects. I think this is up to the compiler?
Re: Printing shortest decimal form of floating point number with Mir
On Sunday, 3 January 2021 at 22:50:16 UTC, Ola Fosheim Grøstad wrote: On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. This is just silly. You don't have to accept a specific solution... ...but... YOU DO HAVE TO ACKNOWLEDGE A TYPE SYSTEM BUG! If an indirection through an alias causes type unification to fail then that is a serious type system failure. No excuses please... "workarounds" are indeed just excuses, telling people "workarounds" they already know about is borderline offensive. I wouldn't call it mocking, but I certainly see why it can be perceived as such. I suppose the answer would be that D doesn't pretend to support all C++ template features and the bug is not a bug because we live with this somehow for years. I didn't believe it when I got a similar answer about IEEE floating-point numbers: D doesn't pertinent to be IEEE 754 compatible language and the extended precision bug is declared to be a language feature. I suppose we shouldn't expect D to pretend to be a robust language for large business projects.
Re: Printing shortest decimal form of floating point number with Mir
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: [snip] The way I saw it the whole argumentation for a language change went like this: 9il: This would be helpful for my lib Atila: Im not convinced this is good addition to the language Thats it. No more good arguments came later. If proposal has only this kind of argument then ofcourse it will be rejected. Even if the idea is good. You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. We all would have to be with it for 10 or more years. So to avoid situation that I described a proposal needs to have solid argumentation and cost/benefit ratio needs to be clear to make good decision. What happened was more that Atila said why not use template constraints and Ilya replied it makes things overly complicated and Atila responded about a workaround existing and he didn't see why to add. Obviously, if Atila or Walter is not in favor of something, it's usually better to know that sooner rather than later. However, it is a bit unfortunate that this never made its way farther through the DIP process. There was a first round review, but I think it was postponed before formal assessment. And for the end I want to point out that your proposal is not in the same category as ast macros. If you or some one else comes up with solid arguments then the outcome might be different. As for me. Im do not know ins and outs of templates to make a judgment if your proposal is good or not. No one showed how it would benefit the code I write. If you aren't writing templates, then it wouldn't affect you. However, it was deemed beneficial enough that a form of it was added to C++ as part of C++ 11 (was news to me as I rarely write C++). The paper on it is here [1], though it doesn't really get into the benefits of it. I'm sure there is a lot of C++ 11 and later code out there that uses the C++11 version of the idea. Nevertheless, there are some differences between the C++11 template aliases and these. C++11 adds the using syntax in addition to the typedef syntax. D already has the alias syntax, which is like using. The difference is that D's template alias syntax works when defining variables. It only doesn't work the same with type deduction in functions. In addition, one reason the DIP was postponed because it really had only addressed the short form template alias, not the long form. However, the C++ version only seems to support the equivalent of the short form. Regardless, the DIP likely could have been improved by mentioning its inclusion in C++ 11 (and perhaps focused a bit less on implementation). I wonder if the inability to do this would inhibit the ability of D code to interact with C++ code bases. For instance, what if you have a C++ function that takes a template alias and try to call it in D. Would you have to write out the target of the alias to get it to work? This kind of thing could be important. You wouldn't be able to use the same template aliases in D the way you use them in C++. If the DIP remained focused on C++ compatibility (if that is an actual issue), then it would only need to support the short form syntax (though that may raise questions as to why not support both). [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf
Re: Printing shortest decimal form of floating point number with Mir
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. This is just silly. You don't have to accept a specific solution... ...but... YOU DO HAVE TO ACKNOWLEDGE A TYPE SYSTEM BUG! If an indirection through an alias causes type unification to fail then that is a serious type system failure. No excuses please... "workarounds" are indeed just excuses, telling people "workarounds" they already know about is borderline offensive. I wouldn't call it mocking, but I certainly see why it can be perceived as such.
Re: Package for differential equation solvers
Great to see someone is bringing d to numeric algorithms. Back in the days https://www.boost.org/doc/libs/1_75_0/libs/numeric/odeint/doc/html/index.html was my favorite library since it is templated.
Re: Printing shortest decimal form of floating point number with Mir
On Sunday, 3 January 2021 at 06:35:23 UTC, 9il wrote: On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote: On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote: On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D. I apologise if what I wrote came across as mockery; it certainly wasn't intended that way. How would you have liked for me to have handled it better? I am not speaking for Ilya, but from skimming through the dialogue it struck me that you didn't respond from the perspective of managing the process, but from a pure engineer mindset of providing alternatives. It would've been better if you started by 1. understanding the issue 2. acknowledging that the type system has an obvious bug 3. looking at the issue from the perspective of the person bringing attention to the issue. I don't think anyone was looking for workarounds, but looking for 1. acknowledgment of the issue 2. acknowledgment of what the issue leads to in terms of inconvenience 3. a forward looking vision for future improvements +1 I don't want to be the guy that comes and just takes a missive dump in the middle of the room but I feel like I have to. The whole language change process is not a place to get tribe`s validation or get emotional support for your boo boos. Its like looking for a virgin partner in a brothel. Makes no sense. You should view it more like this https://images.theconversation.com/files/31778/original/zhrxbdsm-1379916057.jpg?ixlib=rb-1.1.0=45=format=926=clip The way I saw it the whole argumentation for a language change went like this: 9il: This would be helpful for my lib Atila: Im not convinced this is good addition to the language Thats it. No more good arguments came later. If proposal has only this kind of argument then ofcourse it will be rejected. Even if the idea is good. You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. We all would have to be with it for 10 or more years. So to avoid situation that I described a proposal needs to have solid argumentation and cost/benefit ratio needs to be clear to make good decision. And for the end I want to point out that your proposal is not in the same category as ast macros. If you or some one else comes up with solid arguments then the outcome might be different. As for me. Im do not know ins and outs of templates to make a judgment if your proposal is good or not. No one showed how it would benefit the code I write.
Re: I'm creating a game purely written in D with the arsd library
On 1/3/21 1:31 PM, Murilo wrote: On Sunday, 3 January 2021 at 02:42:46 UTC, James Blachly wrote: My final suggestion is that -- given this is a D programming enthusiasts' newsgroup, where we are interested in seeing D code, you might get great feedback on the code itself. Kind regards How did you have access to the source code? Did you use a decompiler? `strings Game |less`
Re: I'm creating a game purely written in D with the arsd library
On Sunday, 3 January 2021 at 02:42:46 UTC, James Blachly wrote: My final suggestion is that -- given this is a D programming enthusiasts' newsgroup, where we are interested in seeing D code, you might get great feedback on the code itself. Kind regards How did you have access to the source code? Did you use a decompiler?
