Re: Always false float comparisons
On 5/18/2016 10:10 AM, Timon Gehr wrote:
double kahan(double[] arr){
double sum = 0.0;
double c = 0.0;
foreach(x;arr){
double y=x-c;
double y = roundToDouble(x - c);
double t=sum+y;
double t = roundToDouble(sum + y);
c = (t-sum)-y;
sum=t;
}
return sum;
}
Those are the only two points in the program that depend on rounding. If you're
implementing Kahan, you'd know that, so there shouldn't be anything difficult
about it.
There's no reason to make the rest of the program suffer inaccuracies.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 07:09:30 UTC, Walter Bright wrote:
On 5/18/2016 10:10 AM, Timon Gehr wrote:
double kahan(double[] arr){
double sum = 0.0;
double c = 0.0;
foreach(x;arr){
double y=x-c;
double y = roundToDouble(x - c);
double t=sum+y;
double t = roundToDouble(sum + y);
c = (t-sum)-y;
sum=t;
}
return sum;
}
Those are the only two points in the program that depend on
rounding. If you're implementing Kahan, you'd know that, so
there shouldn't be anything difficult about it.
There's no reason to make the rest of the program suffer
inaccuracies.
People are trying to get across that, if they wanted to maximize
accuracy, they would request the most precise type explicitly. D
has 'real' for that. This thread has shown unequivocally that the
semantics you are insisting on is bound to cause endless
confusion and complaints.
Re: Always false float comparisons
On Wednesday, 18 May 2016 at 22:16:44 UTC, jmh530 wrote: On Wednesday, 18 May 2016 at 21:49:34 UTC, Joseph Rushton Wakeling wrote: On Wednesday, 18 May 2016 at 20:29:27 UTC, Walter Bright wrote: I do not understand the tolerance for bad results in scientific, engineering, medical, or finance applications. I don't think anyone has suggested tolerance for bad results in any of those applications. I don't think its about tolerance for bad results, so much as the ability to make the trade-off between speed and precision when you need to. It isn't only about speed. It is about correctness as well. Compilers should not change the outcome (including precision and rounding) unless the programmer has explicitly requested it, and if you do the effects should be well documented so that the effect is clear to the programmer. This is a well known and universally accepted principle in compiler design. Take for instance the documentation page for a professional level compiler targeting embedded programming: http://processors.wiki.ti.com/index.php/Floating_Point_Optimization It gives the programmer explicit control over what kind of deviations the compiler can create. If you look at Intel's compiler you'll see that they even turn off fused-multiply-add in strict mode because it skips a single rounding between the multiply and the add. https://software.intel.com/sites/default/files/article/326703/fp-control-2012-08.pdf Some languages allow constant folding of literals in _expressions_ to use infinite precision, but once you have bound it to a variable it should use the same precision, and you always have to use the same rounding mode. This means that if you should check the rounding mode before using precomputed values. If you cannot emulate the computation then you can simply run the computations prior to entering main and put the "constant computations" in global variables. That said, compilers may have some problematic settings enabled by default in order to look good in benchmarks/test suites. In order to be IEEE compliant you cannot even optimize "0.0 - x" to "-x", you also cannot optimize "x - 0.0" to "x". Such issues make compiler vendors provide many different floating point options as command line flags.
Re: Interest in Paris area D meetups?
On Thursday, 19 May 2016 at 06:50:58 UTC, chmike wrote: On Wednesday, 18 May 2016 at 15:05:21 UTC, Guillaume Chatelet wrote: I got inspired by Steven's thread :) Anyone in Paris interested in D meetups? Feel free to add yourself to the map: https://www.google.com/maps/d/edit?mid=1euIpoA6stFHlmIk1m9qbVHwP_64 Hello, great initiative. I would be interested in a french meetup, but in Marseille (south of France). How do I add myself on the map ? I'm using an iPad and could find the method. You need to click on the pin (under the search bar) and then click on the map. Just add your name (I also added my github username in parenthesis). Let's see how many people in France are interested.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 06:04:15 UTC, Joakim wrote: In this case, not increasing precision gets the more accurate result, but other examples could be constructed that _heavily_ favor increasing precision. In fact, almost any real-world, non-toy calculation would favor it. Please stop saying this. It is very wrong. Algorithms that need higher accuracy need error correction mechanisms, not unpredictable precision and rounding. Unpredictable precision and rounding makes adding error correction difficult so it does not improve accuracy, it harms accuracy when you need it.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 08:28:22 UTC, Ola Fosheim Grøstad wrote: On Thursday, 19 May 2016 at 06:04:15 UTC, Joakim wrote: In this case, not increasing precision gets the more accurate result, but other examples could be constructed that _heavily_ favor increasing precision. In fact, almost any real-world, non-toy calculation would favor it. Please stop saying this. It is very wrong. I will keep saying it because it is _not_ wrong. Algorithms that need higher accuracy need error correction mechanisms, not unpredictable precision and rounding. Unpredictable precision and rounding makes adding error correction difficult so it does not improve accuracy, it harms accuracy when you need it. And that is what _you_ need to stop saying: there's _nothing unpredictable_ about what D does. You may find it unintuitive, but that's your problem. The notion that "error correction" can fix the inevitable degradation of accuracy with each floating-point calculation is just laughable.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 08:37:55 UTC, Joakim wrote: On Thursday, 19 May 2016 at 08:28:22 UTC, Ola Fosheim Grøstad wrote: On Thursday, 19 May 2016 at 06:04:15 UTC, Joakim wrote: In this case, not increasing precision gets the more accurate result, but other examples could be constructed that _heavily_ favor increasing precision. In fact, almost any real-world, non-toy calculation would favor it. Please stop saying this. It is very wrong. I will keep saying it because it is _not_ wrong. Can you then please read this paper in it's entirety before continuing saying it. Because changing precision breaks properties of the semantics of IEEE floating point. What Every Computer Scientist Should Know About Floating-Point Arithmetic https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#3377 «Conventional wisdom maintains that extended-based systems must produce results that are at least as accurate, if not more accurate than those delivered on single/double systems, since the former always provide at least as much precision and often more than the latter. Trivial examples such as the C program above as well as more subtle programs based on the examples discussed below show that this wisdom is naive at best: some apparently portable programs, which are indeed portable across single/double systems, deliver incorrect results on extended-based systems precisely because the compiler and hardware conspire to occasionally provide more precision than the program expects.» And that is what _you_ need to stop saying: there's _nothing unpredictable_ about what D does. You may find it unintuitive, but that's your problem. No. It is not my problem as I would never use a system with this kind of semantics for anything numerical. It is a problem for D. Not for me. The notion that "error correction" can fix the inevitable degradation of accuracy with each floating-point calculation is just laughable. Well, it is not laughable to computer scientists that accuracy depends on knowledge about precision and rounding... And I am a computer scientists, in case you have forgotten...
Re: Always false float comparisons
On Thursday, 19 May 2016 at 11:00:31 UTC, Ola Fosheim Grøstad wrote: On Thursday, 19 May 2016 at 08:37:55 UTC, Joakim wrote: On Thursday, 19 May 2016 at 08:28:22 UTC, Ola Fosheim Grøstad wrote: On Thursday, 19 May 2016 at 06:04:15 UTC, Joakim wrote: In this case, not increasing precision gets the more accurate result, but other examples could be constructed that _heavily_ favor increasing precision. In fact, almost any real-world, non-toy calculation would favor it. Please stop saying this. It is very wrong. I will keep saying it because it is _not_ wrong. Can you then please read this paper in it's entirety before continuing saying it. Because changing precision breaks properties of the semantics of IEEE floating point. What Every Computer Scientist Should Know About Floating-Point Arithmetic https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#3377 «Conventional wisdom maintains that extended-based systems must produce results that are at least as accurate, if not more accurate than those delivered on single/double systems, since the former always provide at least as much precision and often more than the latter. Trivial examples such as the C program above as well as more subtle programs based on the examples discussed below show that this wisdom is naive at best: some apparently portable programs, which are indeed portable across single/double systems, deliver incorrect results on extended-based systems precisely because the compiler and hardware conspire to occasionally provide more precision than the program expects.» The example he refers to is laughable because it also checks for equality. The notion that "error correction" can fix the inevitable degradation of accuracy with each floating-point calculation is just laughable. Well, it is not laughable to computer scientists that accuracy depends on knowledge about precision and rounding... And I am a computer scientists, in case you have forgotten... Computer scientists are no good if they don't know any science.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 11:33:38 UTC, Joakim wrote: The example he refers to is laughable because it also checks for equality. With good reason, because it's intended to illustrate the point that two calculations that _look_ identical in code, that intuitively should produce identical results, actually don't, because of under-the-hood precision differences.
Re: DMD producing huge binaries
On 5/17/16 6:04 PM, ZombineDev wrote: On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu wrote: On 05/17/2016 05:44 PM, Georgi D wrote: Hi, While working on a D project which heavily uses the lazy algorithms for ranges I noticed a sudden huge increase in the compilation time and the produced binary size. [snip] Thanks. That's definitely deserving of a bug report. -- Andrei I'm guessing that is highly related to this one: https://issues.dlang.org/show_bug.cgi?id=15831 Yep. chain uses voldemort type, map does not. Georgi: try copying chain implementation into your local file, but instead of having a static internal struct, move it to a module-level struct (you probably have to repeat the template parameters, but not the constraints). See if it produces a similar slimming effect. -Steve
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 05:06:44 UTC, Vladimir Panteleev wrote: Here you can see the final string value of the program argument in your program. The correct invocation is: mytest "my dir\\" What you suggest is non-standard in Windows, and would require distributing the application with some form of comment saying you have to use double backslashes, which is unprofessional. Software should serve the user and not the other way round. Notice I am not debating the escape character, but the inconsistency of buildNormalizedPath, which IMHO should have worked and fixed the trailing backslash. In the future, consider posting to the learn group. I did not post there because I thought this was not necessarily a newbie question. My apologies.
Re: D mentioned and criticized
On Wednesday, 18 May 2016 at 21:45:16 UTC, Abdulhaq wrote: On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat wrote: On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat wrote: Nim is much more interesting as a D alternative, in the sense that it is a. I give up, kept pressing ENTER while typing a message. Please finish, I have to know what follows "a" :-) Nim is much more interesting as a D alternative, in the sense that it is a more radical departure from C++. Be it in syntax, meta-programming, and experimental features. It certainly said no to variable-sized integers, while Loci stays with them.
Benjamin Thaut's talk: D's Import and Export Business
Hi, after looking Benjamins talk I took some time to think about it. Benjamin made some effort towards a sophisticated DLL suppport for D. What I understand: He won't push his changes until "export" will become an attribute. But without his changes there is no need to change the semantic of "export". It seems like a deadlock. I tried to find a solution to this problem. For the moment I ignore the export issue and have a look at linux. I understand in linux everything is exported by default. If it is decided, that this default behavior is changed in the long term, there needs to be a way to switch batch to the old behavior. Therefore a compiler switch "exportAll" will be necessary. So why do not start with this compiler switch, which will also export all symbols on windows. If the changes of Benjamin are adapted to this switch we can already get the sophisticated dll support and can later decide on the semantic change of export. Does this make sense? Kind regards André
Re: DMD producing huge binaries
On 05/19/2016 08:38 AM, Steven Schveighoffer wrote: Yep. chain uses voldemort type, map does not. We definitely need to fix Voldemort types. Walter and I bounced a few ideas during DConf. 1. Do the cleartext/compress/hash troika everywhere (currently we do it on Windows). That should help in several places. 2. For Voldemort types, simply generate a GUID-style random string of e.g. 64 bytes. Currently the name of the type is composed out of its full scope, with some exponentially-increasing repetition of substrings. That would compress well, but it's just a lot of work to produce and then compress the name. A random string is cheap to produce and adequate for Voldemort types (you don't care for their name anyway... Voldemort... get it?). I very much advocate slapping a 64-long random string for all Voldermort returns and calling it a day. I bet Liran's code will get a lot quicker to build and smaller to boot. Andrei
Re: Benjamin Thaut's talk: D's Import and Export Business
On Thursday, 19 May 2016 at 14:00:54 UTC, Andre Pany wrote: Hi, after looking Benjamins talk I took some time to think about it. Benjamin made some effort towards a sophisticated DLL suppport for D. What I understand: He won't push his changes until "export" will become an attribute. But without his changes there is no need to change the semantic of "export". It seems like a deadlock. I tried to find a solution to this problem. For the moment I ignore the export issue and have a look at linux. I understand in linux everything is exported by default. If it is decided, that this default behavior is changed in the long term, there needs to be a way to switch batch to the old behavior. Therefore a compiler switch "exportAll" will be necessary. So why do not start with this compiler switch, which will also export all symbols on windows. If the changes of Benjamin are adapted to this switch we can already get the sophisticated dll support and can later decide on the semantic change of export. Does this make sense? Kind regards André What's the URL to watch the videos? Thanks.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 12:00:33 UTC, Joseph Rushton Wakeling wrote: On Thursday, 19 May 2016 at 11:33:38 UTC, Joakim wrote: The example he refers to is laughable because it also checks for equality. With good reason, because it's intended to illustrate the point that two calculations that _look_ identical in code, that intuitively should produce identical results, actually don't, because of under-the-hood precision differences. And that's my point too, that floating point will always subvert your expectations, particularly such simplistic notions of equality, which is why you should always use approxEqual or it's analogues.
Re: DMD producing huge binaries
On 5/19/16 9:45 AM, Andrei Alexandrescu wrote:
On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:
Yep. chain uses voldemort type, map does not.
We definitely need to fix Voldemort types. Walter and I bounced a few
ideas during DConf.
1. Do the cleartext/compress/hash troika everywhere (currently we do it
on Windows). That should help in several places.
2. For Voldemort types, simply generate a GUID-style random string of
e.g. 64 bytes. Currently the name of the type is composed out of its
full scope, with some exponentially-increasing repetition of substrings.
That would compress well, but it's just a lot of work to produce and
then compress the name. A random string is cheap to produce and adequate
for Voldemort types (you don't care for their name anyway...
Voldemort... get it?).
I very much advocate slapping a 64-long random string for all Voldermort
returns and calling it a day. I bet Liran's code will get a lot quicker
to build and smaller to boot.
This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?
Example:
auto foo(T)(T t) if (someConstraints)
{
static struct Result
{
T t;
}
return Result(t);
}
Changes to:
private struct foo_Result(T) if (someConstraints)
{
T t;
}
auto foo(T)(T t) if (someConstraints)
{
alias Result = foo_Result!T // inserted by compiler
return Result(t);
}
Or even better:
template(T) foo if (someConstraints)
{
struct Result
{
T t;
}
auto foo(T t)
{
return Result(t);
}
}
What this does is lower the number of times the template parameters (and
function arguments) appears in the type name to 1. This gets rid of the
exponential nature of the symbol name.
This doesn't work for voldemorts with closures, but maybe it can somehow
be reconstructed so the context is included in the generated struct.
-Steve
Re: DMD producing huge binaries
On 05/19/2016 10:43 AM, Steven Schveighoffer wrote: This may be crazy, but I solved this problem by simply moving the struct outside the function. What about a lowering that does this for you? That's also a possibility, but likely a more complicated one. -- Andrei
Re: Possible bug in std.path?
On 5/19/16 9:49 AM, Hugo wrote: On Thursday, 19 May 2016 at 05:06:44 UTC, Vladimir Panteleev wrote: Here you can see the final string value of the program argument in your program. The correct invocation is: mytest "my dir\\" What you suggest is non-standard in Windows, and would require distributing the application with some form of comment saying you have to use double backslashes, which is unprofessional. Software should serve the user and not the other way round. Then complain to Microsoft :) This is Microsoft's command shell sending that parameter to your program. Notice I am not debating the escape character, but the inconsistency of buildNormalizedPath, which IMHO should have worked and fixed the trailing backslash. buildNormalizedPath is being send the string `my dir"`, what is it supposed to do with that? -Steve
Re: D mentioned and criticized
On Thursday, 19 May 2016 at 13:53:46 UTC, Guillaume Piolat wrote: On Wednesday, 18 May 2016 at 21:45:16 UTC, Abdulhaq wrote: On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat wrote: On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat wrote: Nim is much more interesting as a D alternative, in the sense that it is a. I give up, kept pressing ENTER while typing a message. Please finish, I have to know what follows "a" :-) Nim is much more interesting as a D alternative, in the sense that it is a more radical departure from C++. Be it in syntax, meta-programming, and experimental features. It certainly said no to variable-sized integers, while Loci stays with them. Thanks :-) - interesting.
Re: DMD producing huge binaries
On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote: On 05/19/2016 10:43 AM, Steven Schveighoffer wrote: This may be crazy, but I solved this problem by simply moving the struct outside the function. What about a lowering that does this for you? That's also a possibility, but likely a more complicated one. -- Andrei We don't actually need to lower it, just mangle it as if it was lowered.
Re: DMD producing huge binaries
On 5/19/16 10:56 AM, Daniel Murphy wrote: On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote: On 05/19/2016 10:43 AM, Steven Schveighoffer wrote: This may be crazy, but I solved this problem by simply moving the struct outside the function. What about a lowering that does this for you? That's also a possibility, but likely a more complicated one. -- Andrei We don't actually need to lower it, just mangle it as if it was lowered. Noice! -- Andrei
Re: Benjamin Thaut's talk: D's Import and Export Business
On 05/19/2016 07:15 AM, flamencofantasy wrote: What's the URL to watch the videos? Thanks. Until the HD versions appear later (presumably on YouTube), all current videos are here: https://www.sociomantic.com/blog/2016/05/follow-dconf-2016-in-real-time/#.Vz3WR5R4foe You can find a particular day and talk in the scrollable list there. Ali
Re: Benjamin Thaut's talk: D's Import and Export Business
On Thursday, 19 May 2016 at 15:08:32 UTC, Ali Çehreli wrote: On 05/19/2016 07:15 AM, flamencofantasy wrote: What's the URL to watch the videos? Thanks. Until the HD versions appear later (presumably on YouTube), all current videos are here: https://www.sociomantic.com/blog/2016/05/follow-dconf-2016-in-real-time/#.Vz3WR5R4foe You can find a particular day and talk in the scrollable list there. Ali Thank you.
Re: D mentioned and criticized
On Thursday, 19 May 2016 at 13:53:46 UTC, Guillaume Piolat wrote: On Wednesday, 18 May 2016 at 21:45:16 UTC, Abdulhaq wrote: On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat wrote: On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat wrote: Nim is much more interesting as a D alternative, in the sense that it is a. I give up, kept pressing ENTER while typing a message. Please finish, I have to know what follows "a" :-) Nim is much more interesting as a D alternative, in the sense that it is a more radical departure from C++. Be it in syntax, meta-programming, and experimental features. It certainly said no to variable-sized integers, while Loci stays with them. It certainly is interesting. The fact that it compiles to C, C++ or Objective-C is also pretty handy. What turns me off is obligatory indentation à la Python :(, and I don't know how the fact that it compiles to C affects the language as a whole.
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer wrote: Then complain to Microsoft :) This is Microsoft's command shell sending that parameter to your program. This is how CommandLineToArgvW behaves, which is called by druntime to parse the command line. For example, xcopy parses the command line correctly, e.g. this works as expected: xcopy file "..\"
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Thursday, 19 May 2016 at 00:09:42 UTC, Alex Parrill wrote: Apparently GitHub didn't add my own repo to my list of watch repos, meaning no notifications for them... I'll look over the pull request. Let's not split this project. Depends on how far you want to catch up. Lets discuss this in the d-vulkan issues.
Re: DMD producing huge binaries
On 5/19/16 10:43 AM, Steven Schveighoffer wrote:
Or even better:
template(T) foo if (someConstraints)
{
struct Result
{
T t;
}
auto foo(T t)
{
return Result(t);
}
}
This solution works awesomely, actually. It even produces smaller code
than moving the struct completely outside.
I'm going to use this mechanism in iopipe to get my voldemorts back :)
-Steve
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:
Am Wed, 18 May 2016 18:57:48 +
schrieb ParticlePeter :
On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
> On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König
> wrote:
>
>> I think I will use glfw3 later. I don't know if the
>> original problem of using multiple configurations (xcb,
>> xlib, glfw3, ...) is possible with only dub's internal
>> logic. I tried putting this in my "vulkantest" packages'
>> dub.json
>>
>> "subConfigurations":
>> {
>>"erupted": "with-derelict-loader",
>>"erupted": "normal"
>> }
>>
>> just for testing, and dub told me
>>
>> Could not resolve configuration for package vulkantest
>>
>> So I thinnk multiple subconfigurations are not supported.
>
> The way to handle this is to make multiple configurations of
> vulkantest, one for each of the configurations of erupted
> you want to support. Then, when you build vulkantest, you
> specify the configuration you want to build on the command
> line (unless you're building the default).
This is a good point, the custom project platform
configuration would then be forwarded to erupted. Only
drawback would be that "with-derelict-loader" config is not
available in combination with a platform config, but in the
later case you would want to grab vkGetInstanceProcAddr anyway
in platform specific means.
Manuel, I could just skim over xcb-d. As far as I can see it
has the module xcb.xcb. Is this module sufficient to be
imported in erupted.types.d? In this case I would not have to
touch the erupt.py generator but instead just fix the
erupted.dub file. As you can test it, how about a pull request?
@ Peter: Yes, importing xcb.xcb is all you need, no patches
necessary. But I could patch erupteD's dub.json for an xcb
configuration, and maybe put in the readme how to use a
configuration, but probably not until sunday.
@Mike: Having multiple subconfigurations (xcb, xlib, glfw3,
...) to pick for the user is the solution Peter was going for,
as I understood him. The problem is when a user wants to
support both xcb and xlib, or any mix of them. But this is
probably just a pathetic use case not relevant in practice, I
just stumbled over the question if that is possible when I
wanted to add proper xcb, xlib, etc. support to erupteD.
As far as I understand Mike it is still possible. Suppose you
build an engine based on (d-)vulkan/erupted, lets call it
Turtle-Engine, you would also specify sub-configurations for xcb,
xlib, win, ... and you could support any of (d-)vulkans/erupted
sub-configs in your corresponding configs. When some dude (no
sexual prejudice meant) wants to write a Turtle-App, which is
based on your Turtle-Engine he decides how many of your configs
representing platforms he would like to support. Now you see, as
the language architect pointed out, its turtles all the way down.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer wrote: On 5/17/16 6:04 PM, ZombineDev wrote: On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu wrote: On 05/17/2016 05:44 PM, Georgi D wrote: Hi, While working on a D project which heavily uses the lazy algorithms for ranges I noticed a sudden huge increase in the compilation time and the produced binary size. [snip] Thanks. That's definitely deserving of a bug report. -- Andrei I'm guessing that is highly related to this one: https://issues.dlang.org/show_bug.cgi?id=15831 Yep. chain uses voldemort type, map does not. Georgi: try copying chain implementation into your local file, but instead of having a static internal struct, move it to a module-level struct (you probably have to repeat the template parameters, but not the constraints). See if it produces a similar slimming effect. -Steve Yes, Making a local copy of chain and moving the structure outside of the method solved the problem and reduced the code size. The stripped size even reduced from the version that did not experience the huge increase. Stripped: 7.4Mb -> 5.5MB Should we actually change the implementation in phobos to be like this? In the company I work in we are very sensitive to the code size so anything that can be made for this in phobos will help with adoption. I am still curious though why the code size increased so dramatically with such a small change. Both versions return a result from chain and actually the one that does not experience the increase is more complex (includes the one that does). In my actual code I have multiple calls to chain on top of the result of this and the code size does not increase dramatically. I am also concerned by the fact that ldc on mac just could not compile the source which produced the big binary (entering an infinite loop). Thanks
Re: Possible bug in std.path?
On 5/19/16 11:25 AM, Kagamin wrote: On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer wrote: Then complain to Microsoft :) This is Microsoft's command shell sending that parameter to your program. This is how CommandLineToArgvW behaves, which is called by druntime to parse the command line. For example, xcopy parses the command line correctly, e.g. this works as expected: xcopy file "..\" Thanks for correcting, this is a difference from posix that I forgot about. The reason for this (as spelled out in the comments) is to get around the poor handling of utf8 by Windows. I think if you write a C program in Windows, your argv/argc will contain .." You'd have to do the same acrobatics D does to get the original, so I don't think this is a problem that we need to solve. Use those low-level functions if you wish. -Steve
Re: DMD producing huge binaries
On 5/19/16 11:56 AM, Georgi D wrote: On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer wrote: On 5/17/16 6:04 PM, ZombineDev wrote: I'm guessing that is highly related to this one: https://issues.dlang.org/show_bug.cgi?id=15831 Yep. chain uses voldemort type, map does not. Georgi: try copying chain implementation into your local file, but instead of having a static internal struct, move it to a module-level struct (you probably have to repeat the template parameters, but not the constraints). See if it produces a similar slimming effect. Yes, Making a local copy of chain and moving the structure outside of the method solved the problem and reduced the code size. Thanks, that confirms the bug reports are for the same issue. The stripped size even reduced from the version that did not experience the huge increase. Stripped: 7.4Mb -> 5.5MB Should we actually change the implementation in phobos to be like this? I'd much prefer we fix the compiler to handle voldemort types in a more sane way rather than try and fix the code to deal with compiler deficiencies. However, if this isn't something that's easily done (or done within a decent time frame), we may look at that solution. In the company I work in we are very sensitive to the code size so anything that can be made for this in phobos will help with adoption. I am still curious though why the code size increased so dramatically with such a small change. Both versions return a result from chain and actually the one that does not experience the increase is more complex (includes the one that does). Each call to a voldemort wrapping function (one that wraps one type into another "voldemort" type, or internal struct) increases the symbol size at a rate of 3^n. Non-voldemort types do not suffer from this, because the symbol size increases at just n. In my actual code I have multiple calls to chain on top of the result of this and the code size does not increase dramatically. I am also concerned by the fact that ldc on mac just could not compile the source which produced the big binary (entering an infinite loop). I would expect the possibility that the issue is with the linker. In my toy experiments, the compiler works just fine and produces an object file. It's the linker having issues with parsing those humungous symbols. -Steve
Re: Always false float comparisons
On Thursday, 19 May 2016 at 11:33:38 UTC, Joakim wrote: Computer scientists are no good if they don't know any science. Even the computer scientists that does not know any science are infinitely better than those who refuse to read papers and debate on a rational level. Blind D zealotry at its finest.
Re: Possible bug in std.path?
On 5/19/16 12:02 PM, Steven Schveighoffer wrote: On 5/19/16 11:25 AM, Kagamin wrote: On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer wrote: Then complain to Microsoft :) This is Microsoft's command shell sending that parameter to your program. This is how CommandLineToArgvW behaves, which is called by druntime to parse the command line. For example, xcopy parses the command line correctly, e.g. this works as expected: xcopy file "..\" Thanks for correcting, this is a difference from posix that I forgot about. The reason for this (as spelled out in the comments) is to get around the poor handling of utf8 by Windows. I think if you write a C program in Windows, your argv/argc will contain .." You'd have to do the same acrobatics D does to get the original, so I don't think this is a problem that we need to solve. Use those low-level functions if you wish. For reference to OP, here is the code that accesses original command line, which you can model for your desired behavior: https://github.com/dlang/druntime/blob/master/src/rt/dmain2.d#L356 -Steve
Re: DMD producing huge binaries
On 05/19/2016 11:56 AM, Georgi D wrote: Making a local copy of chain and moving the structure outside of the method solved the problem and reduced the code size. The stripped size even reduced from the version that did not experience the huge increase. Stripped: 7.4Mb -> 5.5MB Thanks very much for helping with these measurements! -- Andrei
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 16:02:27 UTC, Steven Schveighoffer wrote: The reason for this (as spelled out in the comments) is to get around the poor handling of utf8 by Windows. One receives unicode arguments by declaring wmain function. AFAIK, mingw and msvc do it fine, not sure about dmc.
Re: Always false float comparisons
On 19.05.2016 08:04, Joakim wrote:
On Wednesday, 18 May 2016 at 17:10:25 UTC, Timon Gehr wrote:
It's not just slightly worse, it can cut the number of useful bits in
half or more! It is not unusual, I have actually run into those
problems in the past, and it can break an algorithm that is in Phobos
today!
I wouldn't call that broken. Looking at the hex output by replacing %f
with %A in writefln, it appears the only differences in all those
results is the last byte in the significand.
Argh...
// ...
void main(){
//double[] data=[1e16,1,-9e15];
import std.range;
double[] data=1e16~repeat(1.0,1).array~(-9e15);
import std.stdio;
writefln("%f",sum(data)); // baseline
writefln("%f",kahan(data)); // kahan
writefln("%f",kahanBroken(data)); // broken kahan
}
dmd -run kahanDemo.d
1000.00
1001.00
1000.00
dmd -m32 -O -run kahanDemo.d
1000.00
1000.00
1000.00
Better?
Obviously there is more structure in the data that I invent manually
than in a real test case where it would go wrong. The problems carry
over though.
As Don's talk pointed out,
all floating-point calculations will see loss of precision starting there.
...
This is implicitly assuming a development model where the programmer
first writes down the computation as it would be correct in the real
number system and then naively replaces every operation by the rounding
equivalent and hopes for the best.
It is a useful rule if that is what you're doing. One might be doing
something else. Consider the following paper for an example where the
last bit in the significant actually carries useful information for many
of the values used in the program.
http://www.jaist.ac.jp/~s1410018/papers/qd.pdf
In this case, not increasing precision gets the more accurate result,
but other examples could be constructed that _heavily_ favor increasing
precision.
Sure. In such cases, you should use higher precision. What is the
problem? This is already supported (the compiler is not allowed to use
lower precision than requested).
In fact, almost any real-world, non-toy calculation would
favor it.
In any case, nobody should depend on the precision out that far being
accurate or "reliable."
IEEE floating point has well-defined behaviour and there is absolutely
nothing wrong with code that delivers more accurate results just because
it is actually aware of the actual semantics of the operations being
carried out.
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 15:25:02 UTC, Kagamin wrote: On Thursday, 19 May 2016 at 14:53:21 UTC, Steven Schveighoffer wrote: Then complain to Microsoft :) This is Microsoft's command shell sending that parameter to your program. This is how CommandLineToArgvW behaves, which is called by druntime to parse the command line. For example, xcopy parses the command line correctly, e.g. this works as expected: xcopy file "..\" As far as I know, CommandLineToArgvW is *the* correct way to parse command-line arguments on Windows. If you do not use it, then your program will not work correctly when invoked by other programs which assume you use it, and this includes most programs which use libraries that accept program arguments as an array (which is the correct abstraction for program arguments anyway). The fact that some standard Windows utilities do not obey this convention is more likely a historical artifact from DOS days.
Re: Always false float comparisons
On 18.05.2016 19:10, Timon Gehr wrote: implementation-defined behaviour Maybe that wasn't the right term (it's worse than that; I think the documentation of the implementation is not even required to tell you precisely what it does).
Re: Always false float comparisons
On 19.05.2016 09:09, Walter Bright wrote:
On 5/18/2016 10:10 AM, Timon Gehr wrote:
double kahan(double[] arr){
double sum = 0.0;
double c = 0.0;
foreach(x;arr){
double y=x-c;
double y = roundToDouble(x - c);
Those two lines producing different results is unexpected, because you
are explicitly saying that y is a double, and the first line also does
implicit rounding (probably -- on all compilers and targets that will be
relevant in the near future -- to double). It's obviously bad language
design on multiple levels.
double t=sum+y;
double t = roundToDouble(sum + y);
c = (t-sum)-y;
sum=t;
}
return sum;
}
Those are the only two points in the program that depend on rounding.
If you say so. I would like to see an example that demonstrates that the
first roundToDouble is required.
Also, in case that the compiler chooses to internally use higher
precision for all local variables in that program, the 'roundToDouble's
you have inserted will reduce precision in comparison to the case where
they are not inserted, reducing magical precision enhancement that would
otherwise happen. (I.e., assuming that some of the ideas are valid and
it is in fact desirable to have variable precision enhancement depending
on target, if I find a precision bug I can fix by adding roundToDouble,
this introduces a potential regression on other targets. And as none of
it was guaranteed to work in the first place, the resulting mess is all
my fault.)
If you're implementing Kahan,
And if you are not? (I find the standard assumption that counterexamples
to wrong statements are one-off special cases tiresome. This is not
usually the case, even if you cannot construct other examples right away.)
you'd know that,
I would, but what often happens in practice is that people don't. For
example because they wouldn't expect roundToDouble to be required
anywhere in code that only uses doubles. They are right.
so there shouldn't be anything difficult about it.
...
https://issues.dlang.org/show_bug.cgi?id=13474
Creating useful programs in D shouldn't require knowing (or thinking
about) an excess amount of D-specific implicit arcane details of the
language semantics. Being easy to pick up and use is a major selling
point for D.
I'm not convinced there is nothing difficult about it. It's certainly a
generator of incidental complexity. Also, error prone is not the same as
difficult. Almost everybody makes some mistakes occasionally.
There's no reason to make the rest of the program suffer inaccuracies.
Indeed there isn't. I'm not suggesting to allow using a precision lower
than the one specified.
If you are talking about programs that "benefit" from automatic
extension of precision: do you think their authors are aware that e.g.
their 32 bit release builds with gdc/ldc are producing wrong results?
Re: Possible bug in std.path?
On 5/18/2016 8:49 PM, Hugo wrote: mytest "my dir\" I should get "OK", but instead I get: Error: 'my test"' is not a valid directory path. Windows command line processing has special handling for " and \. The \ is used to escape the next character, which here is a ". You can see the resulting argument is [my test"]. Note the quote. If the trailing backslash is removed it works as intended, but IMHO buildNormalizedPath should have worked. buildNormalizedPath is passed [my test"]. It cannot possibly do as you suggest. In any case, notice the double quote in the output. To me this suggests the backslash is acting not as a path terminator but as an escape sequence. This is happening because of how standard Windows programs deal with " and \ on the command line.
Re: DMD producing huge binaries
On 5/19/2016 8:39 AM, Steven Schveighoffer wrote:
template(T) foo if (someConstraints)
{
struct Result
{
T t;
}
auto foo(T t)
{
return Result(t);
}
}
This solution works awesomely, actually. It even produces smaller code than
moving the struct completely outside.
I'm going to use this mechanism in iopipe to get my voldemorts back :)
Consider using a 'static struct'. A non-static struct will include a hidden
member that points to the stack frame of foo(), i.e. "produces smaller code".
Re: DMD producing huge binaries
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote: I very much advocate slapping a 64-long random string for all Voldermort returns and calling it a day. I bet Liran's code will get a lot quicker to build and smaller to boot. Let's see how far we get with compression first. https://github.com/dlang/dmd/pull/5793 Using 64 character random strings will make symbolic debugging unpleasant.
Re: Possible bug in std.path?
On 5/19/2016 3:41 PM, Adam D. Ruppe wrote: So indeed, the OP stumbled upon a weird case of Windows command line, but it is really just this one weird case. It's not at all weird. It's just garden variety double quoted string behavior. Linux has its own quoting scheme on the command line, too.
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 22:13:36 UTC, Walter Bright wrote:
Windows command line processing has special handling for " and
\. The \ is used to escape the next character, which here is a
". You can see the resulting argument is [my test"]. Note the
quote.
Not exactly... it treats \" as a special case, not \ in general.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx
Quote:
CommandLineToArgvW has a special interpretation of backslash
characters when they are followed by a quotation mark character
("), as follows:
2n backslashes followed by a quotation mark produce n
backslashes followed by a quotation mark.
(2n) + 1 backslashes followed by a quotation mark again
produce n backslashes followed by a quotation mark.
n backslashes not followed by a quotation mark simply produce
n backslashes.
So indeed, the OP stumbled upon a weird case of Windows command
line, but it is really just this one weird case.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote: Using 64 character random strings will make symbolic debugging unpleasant. Using 6.4 megabyte strings already makes symbolic debugging unpleasant. The one thing that worries me about random strings is that it needs to be the same across all builds, or you'll get random linking errors when doing package-at-a-time or whatever (dmd already has some problems like this!). But building a gigantic string then compressing or hashing it still sucks... what we need is a O(1) solution that is still unique and repeatable.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 22:17:37 UTC, Walter Bright wrote: Consider using a 'static struct'. A non-static struct will include a hidden member that points to the stack frame of foo(), i.e. "produces smaller code". Queue me going to the language reference to look up static structs and reading "A struct can be prevented from being nested by using the static attribute, but then of course it will not be able to access variables from its enclosing scope." Not a fan of that description...
Re: DMD producing huge binaries
On 5/19/2016 4:36 PM, jmh530 wrote: Queue me going to the language reference to look up static structs and reading "A struct can be prevented from being nested by using the static attribute, but then of course it will not be able to access variables from its enclosing scope." Not a fan of that description... You can always submit a PR for a better one.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 22:46:02 UTC, Adam D. Ruppe wrote: On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote: Using 64 character random strings will make symbolic debugging unpleasant. Using 6.4 megabyte strings already makes symbolic debugging unpleasant. The one thing that worries me about random strings is that it needs to be the same across all builds, or you'll get random linking errors when doing package-at-a-time or whatever (dmd already has some problems like this!). But building a gigantic string then compressing or hashing it still sucks... what we need is a O(1) solution that is still unique and repeatable. Clearly the reason for building such a gigantic string was some sort of repetition. Detect the repetition on-the-fly to avoid processing all of it. This way the generated name is already compressed.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 23:56:46 UTC, poliklosio wrote: (...) Clearly the reason for building such a gigantic string was some sort of repetition. Detect the repetition on-the-fly to avoid processing all of it. This way the generated name is already compressed. It seems like dynamic programming can be useful.
Re: Always false float comparisons
On 5/18/2016 4:30 AM, Ethan Watson wrote: I appreciate that it sounds like I'm starting to stretch to hold to my point, but I imagine we'd also be able to control such things with the compiler - or at least know what flags it uses so that we can ensure consistent behaviour between compilation and runtime. All compilers I know of use "round to nearest" for constant folding, and that is not adjustable.
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 22:44:06 UTC, Walter Bright wrote: On 5/19/2016 3:41 PM, Adam D. Ruppe wrote: So indeed, the OP stumbled upon a weird case of Windows command line, but it is really just this one weird case. It's not at all weird. It's just garden variety double quoted string behavior. Linux has its own quoting scheme on the command line, too. I must confess I was a bit misled then by this portion of the unittest: assert (buildNormalizedPath(`c:\foo\.\bar/..\\baz\`) == `c:\foo\baz`); Since I saw somewhere D could use different quoting styles, I assumed the function would deal with the trailing backslash.
Re: Possible bug in std.path?
On 5/19/2016 6:35 PM, Hugo wrote: I assumed the function would deal with the trailing backslash. And it can. It just never received a trailing backslash because that was removed by the Windows argument processing.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 22:46:02 UTC, Adam D. Ruppe wrote: On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote: Using 64 character random strings will make symbolic debugging unpleasant. Using 6.4 megabyte strings already makes symbolic debugging unpleasant. The one thing that worries me about random strings is that it needs to be the same across all builds, or you'll get random linking errors when doing package-at-a-time or whatever (dmd already has some problems like this!). But building a gigantic string then compressing or hashing it still sucks... what we need is a O(1) solution that is still unique and repeatable. Good point. Using a SHA1 derived from the string instead of a GUID is imho better. It has the advantage of repeatability, is even shorter and not very expensive to generate.
Re: DMD producing huge binaries
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote: On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote: I very much advocate slapping a 64-long random string for all Voldermort returns and calling it a day. I bet Liran's code will get a lot quicker to build and smaller to boot. Let's see how far we get with compression first. https://github.com/dlang/dmd/pull/5793 Using 64 character random strings will make symbolic debugging unpleasant. You could simply add a "trivial" version of the struct + enclosing function name (ie once, without repetitions) before or after the random character string. This way you would know which struct its referring to, its unique, and you still avoid generating a 5 Exabyte large symbol name just to compress/hash/whatever it.
Re: Always false float comparisons
On 5/19/2016 1:26 PM, Timon Gehr wrote: Those two lines producing different results is unexpected, because you are explicitly saying that y is a double, and the first line also does implicit rounding (probably -- on all compilers and targets that will be relevant in the near future -- to double). > [...] It's obviously bad language design on multiple levels. Floating point semantics simply are not that simple, on any compiler, language or hardware. I recommend reading what the C/C++ Standards say about it, and look at the plethora of compiler switches for VC++/g++/clang++. The people who design these things are not fools, and there are good reasons for the way things are. Sorry, I don't agree. If you say so. I would like to see an example that demonstrates that the first roundToDouble is required. That's beside the point. If there are spots in the program that require rounding, what is wrong with having to specify it? Why compromise speed & accuracy in the rest of the code that does not require it? (And yes, rounding in certain spots can and does compromise both speed and accuracy.) And if you are not? (I find the standard assumption that counterexamples to wrong statements are one-off special cases tiresome. You might, but I've implemented a number of FP algorithms, and none of them required rounding to a lower precision. I've also seen many that failed due to premature rounding. Creating useful programs in D shouldn't require knowing (or thinking about) an excess amount of D-specific implicit arcane details of the language semantics. Being easy to pick up and use is a major selling point for D. As pointed out innumerable times here, the same issues are in C and C++ (with even more variability!). When designing an algorithm that you know requires rounding in a certain place, you are already significantly beyond implementing a naive algorithm, and it would be time to start paying attention to how FP actually works. I'm curious if you know of any language that meets your requirements. (Java 1.0 did, but Sun was forced to abandon that.)
Re: Always false float comparisons
On 5/19/2016 12:49 AM, Max Samukha wrote: People are trying to get across that, if they wanted to maximize accuracy, they would request the most precise type explicitly. D has 'real' for that. This thread has shown unequivocally that the semantics you are insisting on is bound to cause endless confusion and complaints. C++ programs do the same thing, and have for decades, and such behavior is allowed by the C++ Standard. People have been confused by and complained about floating point behavior at least since I started programming 40 years ago. I have not invented anything new here.
