Re: Printing shortest decimal form of floating point number with Mir
On 1/5/2021 9:57 PM, Timon Gehr wrote: Anyway, I wouldn't necessarily say occasional accidental correctness is the only upside, you also get better performance and simpler code generation on the deprecated x87. I don't see any further upsides though, and for me, it's a terrible trade-off, because possibility of incorrectness and lack of portability are among the downsides. There are algorithms in Phobos that can break when certain operations are computed at a higher precision than specified. Higher does not mean better; not all adjectives specify locations on some good/bad axis. As far as I can tell, the only algorithms that are incorrect with extended precision intermediate values are ones specifically designed to tease out the roundoff to the reduced precision. I don't know of straightforward algorithms, which is what most people write, being worse off because of more precision. For example, if you're summing values in an array, the straightforward approach of simply summing them will not become incorrect with extended precision. In fact, it is likely to be more correct. > I want to execute the code that I wrote, not what you think I should have > instead written, because sometimes you will be wrong. With programming languages, it does not matter what you think you wrote. What matters is how the language semantics are defined to work. In writing professional numerical code, one must carefully understand it, knowing that it does *not* work like 7th grade algebra. Different languages can and do behave differently, too.
Re: Printing shortest decimal form of floating point number with Mir
On 06.01.21 03:27, Walter Bright wrote: On 1/5/2021 5:30 AM, Guillaume Piolat wrote: It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform. That same argument could be use to always use float instead of double. I hope you see it's fallacious ... Evidence that supports some proposition may well fail to support a completely different proposition. An analogy for your exchange: G: Birds can fly because they have wings. W: That same argument could be used to show mice can fly. I hope you see it's fallacious Anyway, I wouldn't necessarily say occasional accidental correctness is the only upside, you also get better performance and simpler code generation on the deprecated x87. I don't see any further upsides though, and for me, it's a terrible trade-off, because possibility of incorrectness and lack of portability are among the downsides. I want to execute the code that I wrote, not what you think I should have instead written, because sometimes you will be wrong. There are algorithms in Phobos that can break when certain operations are computed at a higher precision than specified. Higher does not mean better; not all adjectives specify locations on some good/bad axis.
Re: Printing shortest decimal form of floating point number with Mir
On 1/5/2021 2:42 AM, 9il wrote: On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote: On 1/4/2021 11:22 PM, 9il wrote: I can't reproduce the same DMD output as you. I did it on Windows 32 bit. I tried it on Linux 32, which does indeed show the behavior you mentioned. At the moment I don't know why the different behaviors. https://issues.dlang.org/show_bug.cgi?id=21526 It just uses SSE, which I think a good way to go, haha. As I mentioned upthread, it will use SSE when SSE is baseline on the CPU target, and it will always round to precision. Does this mean that DMD Linux 32-bit executables should compile with SSE codes? The baseline Linux target does not have SSE. I ask because DMD compiles Linux 32-bit executables with x87 codes when -O is passed and with SSE if no -O is passed. That is very weird. Example, please?
Re: Printing shortest decimal form of floating point number with Mir
On 1/5/2021 5:30 AM, Guillaume Piolat wrote: It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform. That same argument could be use to always use float instead of double. I hope you see it's fallacious What about this plan? - use SSE all the time in DMD That was done for OSX because their baseline CPU had SSE. - drop real :) No.
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 21:46:34 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2021 at 21:43:09 UTC, welkam wrote:
Replace alias Bar(T) = Foo!T; with alias Bar = Foo;
struct Foo(T) {}
alias Bar = Foo;
void f(T)(Bar!T x) {}
void main() {
auto foo = Bar!int();
f(foo);
}
The example was a reduced case. One can trivially construct
examples where that won't work.
It is very useful to create a simple alias from a complex type
for export from a type library, then it breaks when people use
that type library to write templated functions.
People do this all the time in C++.
I reread the whole thread. You want something like this except
without mixins and to actually work.
struct Foo(T) {}
mixin template Bar(T) {
Foo!T
}
void f(T)(Foo!T x) {}
void main() {
f(mixin Bar!(int)());
}
In languages you can pass things by value, by reference or by
name. Alias works by the name passing mechanic. You can not use
alias or capture by name here because you cant get a name of
something that doesn't exist yet.
What you want is parametric generation of definition and
insertion in place. Now that's something Walter can understand.
Re: I'm creating a game purely written in D with the arsd library
On Tuesday, 5 January 2021 at 21:42:49 UTC, Murilo wrote: On Saturday, 2 January 2021 at 22:49:19 UTC, Guillaume Piolat wrote: On Saturday, 2 January 2021 at 04:12:29 UTC, Murilo wrote: Here is the link https://drive.google.com/file/d/1Il1xLN8b5rzghYLXTQqq2apv5YMKv7rx/view?usp=sharing I can't pass the first screen with a static photo and music. Help? I've just uploaded the version 2.0 which is way better. Check it out. Hello, Thanks. I've encountered the following problems: - explored all places but did not solve anything - I don't see all the text that people are saying in the textbox - on LOAD, couldn't retrieve my saved game, it crashed Looks strange and interesting otherwise.
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 21:46:34 UTC, Ola Fosheim Grøstad
wrote:
It is very useful to create a simple alias from a complex type
for export from a type library, then it breaks when people use
that type library to write templated functions.
People do this all the time in C++.
Example:
// library code
struct _config(T){}
struct _matrix(T,C){}
alias matrix(T) = _matrix!(T,_config!T);
// application code
void f(T)(matrix!T m){}
void main()
{
f(matrix!float());
f(matrix!double());
}
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 21:43:09 UTC, welkam wrote:
Replace alias Bar(T) = Foo!T; with alias Bar = Foo;
struct Foo(T) {}
alias Bar = Foo;
void f(T)(Bar!T x) {}
void main() {
auto foo = Bar!int();
f(foo);
}
The example was a reduced case. One can trivially construct
examples where that won't work.
It is very useful to create a simple alias from a complex type
for export from a type library, then it breaks when people use
that type library to write templated functions.
People do this all the time in C++.
Re: Printing shortest decimal form of floating point number with Mir
On Wednesday, 23 December 2020 at 22:13:09 UTC, Ola Fosheim
Grøstad wrote:
The big picture that the DIP suggested was that when stuff like
this fails to compile:
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
auto foo = Bar!int();
f(foo);
}
Then most programmers would just conclude that the compiler is
broken beyond repair and move on to another language.
Replace alias Bar(T) = Foo!T; with alias Bar = Foo;
struct Foo(T) {}
alias Bar = Foo;
void f(T)(Bar!T x) {}
void main() {
auto foo = Bar!int();
f(foo);
}
Re: I'm creating a game purely written in D with the arsd library
On Saturday, 2 January 2021 at 22:49:19 UTC, Guillaume Piolat wrote: On Saturday, 2 January 2021 at 04:12:29 UTC, Murilo wrote: Here is the link https://drive.google.com/file/d/1Il1xLN8b5rzghYLXTQqq2apv5YMKv7rx/view?usp=sharing I can't pass the first screen with a static photo and music. Help? I've just uploaded the version 2.0 which is way better. Check it out.
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 21:03:40 UTC, welkam wrote:
This code compiles
struct bar(T) {}
void f(T)(bar!T x) {}
void main()
{
alias fooInt = bar!int;
alias foo = bar;
assert(is(fooInt == bar!int));
assert(is(foo!int == bar!int));
assert(is(fooInt == foo!int));
}
This code has no relation to what we discuss in this thread…
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 15:10:29 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2021 at 15:04:34 UTC, welkam wrote:
Also how "i'm like you" is an insult?
I don't think I should reply to this…
Then dont replay to this sentence. My post had more than one
sentence.
Also the thing where I showed that what you said for days is not
possible and is a bug is actually possible if you followed D's
syntax and semantics. I guess it had nothing to do with your loss
of motivation to discuss this topic further.
This code compiles
struct bar(T) {}
void f(T)(bar!T x) {}
void main()
{
alias fooInt = bar!int;
alias foo = bar;
assert(is(fooInt == bar!int));
assert(is(foo!int == bar!int));
assert(is(fooInt == foo!int));
}
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 18:48:06 UTC, ag0aep6g wrote: On Tuesday, 5 January 2021 at 18:06:32 UTC, Ola Fosheim Grøstad wrote: My main concern is that we need to attract more people with a strong comp.sci. background because as a language grow it becomes more tricky to improve and the most difficult topics are the ones that remain unresolved (like we see with @live, shared and GC). I don't have that background myself, so I don't think I can provide any insight here. Well, what I mean is that it is not so bad if D is perceived as an "enthusiast language", then you don't expect a flawless implementation. If the language spec outline something that is "beautiful" (also in a theoretical sense) and show where the implementation needs some love then people can contribute in areas they are interested in. If the spec is so-so, then it will be a revolving door... It probably would be a good idea to focus on one subsystem at a time. Refactor, document, make a list of priority improvements for that subsystem, and then improve/reimplement, document, then move on to the next subsystem. If memory management is in the center now, then that is great, but then maybe the next cycle could take another look at the type system as a whole. I'm afraid I don't have anything profound to contribute here either. I have no idea how to manage a group of volunteers (including Walter). Most people will shy away from the difficult, tedious or boring bits, so by keeping focus on one subsystem at a time, one could hope that the difficult/tedious/boring bits receive more attention... (Nothing specific for D, just human behaviour.)
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 18:06:32 UTC, Ola Fosheim Grøstad wrote: My main concern is that we need to attract more people with a strong comp.sci. background because as a language grow it becomes more tricky to improve and the most difficult topics are the ones that remain unresolved (like we see with @live, shared and GC). I don't have that background myself, so I don't think I can provide any insight here. [...] It probably would be a good idea to focus on one subsystem at a time. Refactor, document, make a list of priority improvements for that subsystem, and then improve/reimplement, document, then move on to the next subsystem. If memory management is in the center now, then that is great, but then maybe the next cycle could take another look at the type system as a whole. I'm afraid I don't have anything profound to contribute here either. I have no idea how to manage a group of volunteers (including Walter).
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 17:13:01 UTC, ag0aep6g wrote: Sure. I've said in my first post in this thread that "issue 1807 is well worth fixing/implementing". Ok, if we have a majority for this, then all is good. A program has a bug when it doesn't behave as intended by its author. I think that's a pretty permissive definition of bug. So, DMD has a bug when it doesn't behave as Walter intended when he wrote or accepted the code. Ok, I can't argue if that is the definition. My main concern is that we need to attract more people with a strong comp.sci. background because as a language grow it becomes more tricky to improve and the most difficult topics are the ones that remain unresolved (like we see with @live, shared and GC). I agree that there are more important topics than streamlining parametric types. Like shared and memory management. But it is still important to have an idea of which areas are worth picking up, if someone comes along with an interest in writing solvers, then this could be something he/she could tinker with. should work. Walter has not come forward to say that he made a mistake in the implementation. Ok, but that is not important. What is important is that if someone comes along with an interest in this area, then we can encourage them to work on it. Done. Incremental improvements lead to a system that works pretty well a lot of the time. That's Walter's signature, isn't it? That happens in many compiler development cycles. Of course, D has also added a lot of features... perhaps at the expense of bringing what is to perfection. I don't disagree. But we have to work with what we got. The implementation exists. The spec doesn't. It probably would be a good idea to focus on one subsystem at a time. Refactor, document, make a list of priority improvements for that subsystem, and then improve/reimplement, document, then move on to the next subsystem. If memory management is in the center now, then that is great, but then maybe the next cycle could take another look at the type system as a whole.
Re: Printing shortest decimal form of floating point number with Mir
On 05.01.21 11:44, Ola Fosheim Grøstad wrote:
So, does that mean that you agree that having better unification would
be a worthwhile item to have on a wish list for 2021? So, if somebody
want to do a full implementation that performs well, then it would be an
interesting option?
Sure. I've said in my first post in this thread that "issue 1807 is well
worth fixing/implementing".
Quite frankly, it is much better to just say "oh, this is a deficiency
in the implementation" than to say that the language spec is fubar...
It's not either or. The spec on IFTI is lacking. That's true whether we
we call issue 1807 a bug or an enhancement.
I don't think it's a productive use of our time, but if you'd like to
argue semantics, here's why I don't consider issue 1807 a "bug":
(PS: This turned out longer than planned. Please feel free to ignore.)
A program has a bug when it doesn't behave as intended by its author. I
think that's a pretty permissive definition of bug. So, DMD has a bug
when it doesn't behave as Walter intended when he wrote or accepted the
code.
I see no evidence that IFTI's type deduction was ever intended to behave
as requested in issue 1807. The spec doesn't say it should work. Walter
has not come forward to say that he made a mistake in the implementation.
I do see evidence that the existing deduction works as intended: Walter
has called issue 1807 a "good idea for an enhancement request"[2], i.e.
not a bug.
Maybe most importantly, the existing behavior just feels like the kind
of thing Walter does. Start with trivial deduction, allowing this:
void f(T)(T p) {}
int x;
f(x);
Then also allow derived types (e.g. pointers), because all the needed
info is readily available in the type (DMD can get `int` from the type
`int*`):
void f(T)(T* p) {}
int* x;
f(x);
Then realize that types created from templates also keep the needed info
around for name mangling (DMD can get `S` and `int` from the type
`S!int`). Use that to allow:
struct S(T) {}
void f(S!T p) {}
S!int x;
f(x);
Done. Incremental improvements lead to a system that works pretty well a
lot of the time. That's Walter's signature, isn't it?
Also, the whole idea of writing the language spec to match the
implementation is not a good approach.
I don't disagree. But we have to work with what we got. The
implementation exists. The spec doesn't.
Documenting the existing system has merit, even when you or someone else
eventually finds the time and motivation to design a better one.
[1] https://dlang.org/spec/template.html#function-templates
[2] https://issues.dlang.org/show_bug.cgi?id=1807#c1
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 15:04:34 UTC, welkam wrote: Also how "i'm like you" is an insult? I don't think I should reply to this…
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 22:55:28 UTC, Ola Fosheim Grøstad
wrote:
It is a name, e.g.:
alias BarInt = Bar!int;
"BarInt", "Bar!int" and "Foo!int" are all names, or labels, if
you wish. And they all refer to the same object: the nominal
type. Which you can test easily by using "is(BarInt==Foo!int)".
Bar!int is not a name. It's declaration. Bar is the name.
https://github.com/dlang/dmd/blob/master/src/dmd/dtemplate.d#L5754
Labels are myLabel: and are used with goto, break, continue.
Objects are class instances.
On Monday, 4 January 2021 at 23:08:31 UTC, Ola Fosheim Grøstad
wrote:
If the terminology is difficult, <...>
The main problem here is that you use words/definitions
interchangeably that refer to similar concepts but are different.
As if they are the same. They are not! I got the concept from the
first post and I believe most here got it too. What we have
trouble here is getting it from abstract realm to reality. And
reality demands it to be specific.
and type "struct _ {}" <...> should be
interchangeable with no semantic impact.
What you want is to reference template thingy by name and assign
it to thing so when you use the thing it should be
interchangeable with template thingy and should be semantically
equivalent. So what is a thing? From your posts its either/or:
1. identifier
2. declaration.
And from your posts the template thingy is either/or:
1. template instantiation
2. template definition
Since you cant get specific we will talk about all 4
possibilities. For a template declaration of myStruct lets see
how we can go about creating an alias to it.
struct myStruct(T) {}
For assigning template instantiation to a identifier(1,1) its
simple.
alias myS11 = myStruct!int;
For assigning template definition to a identifier(1,2) you write
like this
alias myS12 = myStruct;
For assigning template instantiation to a declaration(2,1) well
you cant. The language does not permit that.
For assigning template definition to a declaration(2,2). You cant
do that too.
And in practice it looks like this
[code]
struct myStruct(T) {}
void f(T)(myStruct!T x) {}
void main()
{
alias myS11 = myStruct!int;
alias myS12 = myStruct;
myStruct!int x;
f(x);
myS11 x11;
f(x11);
myS12!int x12;
f(x12);
}
[/code]
Now there are also function templates but I will leave it as
homework assignment. So the million dollar question is. What do
you want to do with alias assignment to declaration that you cant
do by assignment to identifier?
Drop ad hominem. Argue the case.
Ad hominem is when you use insult INSTEAD of argument. A detail
that most people miss. Also how "i'm like you" is an insult?
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 13:30:50 UTC, Guillaume Piolat wrote: On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote: The only D compiler that uses excess precision is DMD and only if -O flag is passed. The same example compiled with GDC uses write-read codes. LDC uses SSE codes. DMD still supports baseline 32 bit Windows that does not have XMM registers. It would be nice if no excess precision was ever used. Fun fact: in AIFF files the samplingrate is stored as a 80 bit IEEE Standard 754 floating point. ;)
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote: The only D compiler that uses excess precision is DMD and only if -O flag is passed. The same example compiled with GDC uses write-read codes. LDC uses SSE codes. DMD still supports baseline 32 bit Windows that does not have XMM registers. It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform. Accidental correctness of say, C integer promotion, doesn't break on another system - it's OK ; it's a different ilk. What about this plan? - use SSE all the time in DMD - drop real :)
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote: On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: [snip] [snip[ Regardless, the DIP likely could have been improved by mentioning its inclusion in C++ 11 (and perhaps focused a bit less on implementation). Yes.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 17:48:50 UTC, ag0aep6g wrote: I think you're hitting the nail on the head here regarding the confusion. Such a rewrite makes intuitive sense, and it would be nice, but it doesn't happen. So, does that mean that you agree that having better unification would be a worthwhile item to have on a wish list for 2021? So, if somebody want to do a full implementation that performs well, then it would be an interesting option? Quite frankly, it is much better to just say "oh, this is a deficiency in the implementation" than to say that the language spec is fubar... Also, the whole idea of writing the language spec to match the implementation is not a good approach. I think D could become competitive if the existing feature set is streamlined and polished.
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote: On 1/4/2021 11:22 PM, 9il wrote: I can't reproduce the same DMD output as you. I did it on Windows 32 bit. I tried it on Linux 32, which does indeed show the behavior you mentioned. At the moment I don't know why the different behaviors. https://issues.dlang.org/show_bug.cgi?id=21526 It just uses SSE, which I think a good way to go, haha. As I mentioned upthread, it will use SSE when SSE is baseline on the CPU target, and it will always round to precision. Does this mean that DMD Linux 32-bit executables should compile with SSE codes? I ask because DMD compiles Linux 32-bit executables with x87 codes when -O is passed and with SSE if no -O is passed. That is very weird.
Re: Printing shortest decimal form of floating point number with Mir
On 1/4/2021 11:22 PM, 9il wrote: I can't reproduce the same DMD output as you. I did it on Windows 32 bit. I tried it on Linux 32, which does indeed show the behavior you mentioned. At the moment I don't know why the different behaviors. https://issues.dlang.org/show_bug.cgi?id=21526 It just uses SSE, which I think a good way to go, haha. As I mentioned upthread, it will use SSE when SSE is baseline on the CPU target, and it will always round to precision. The only D compiler that uses excess precision is DMD and only if -O flag is passed. The same example compiled with GDC uses write-read codes. LDC uses SSE codes. DMD still supports baseline 32 bit Windows that does not have XMM registers. As for C, it allows an intuitive built-in way to work with exact precision when an assignment works like a directive to use exact precision for the expression result, unlike D. It doesn't cover all cases but an intuitive and very easy way to do things the right way. It's a rarity of cases that require the rounding, and DMD does have the functions in druntime to do it for those cases. It's what people doing numerics have asked for. It means the write/read penalty is only there when it is actually required. In any case, this is an issue for the past. The future is XMM code, and DMD does the round-to-precision in all XMM code generation. If you find a case where it isn't, please file a bugzilla and let me know so I can fix it.
