Re: Bug or feature? iota has different semantics for integer and float arguments
On Saturday, 7 January 2023 at 02:31:14 UTC, Ali Çehreli wrote: On 1/6/23 17:50, Arredondo wrote: > Would anyone volunteer to file a bug report? Me! Me! :) https://issues.dlang.org/show_bug.cgi?id=23604 Ali Thanks a lot :D Arredondo.
Re: Bug or feature? iota has different semantics for integer and float arguments
On Saturday, 7 January 2023 at 00:52:20 UTC, Ali Çehreli wrote: Although that difference is a bug, iota does have a special floating point implementation to prevent the accumulation of floating point errors. Thank you for this clarification Ali. I appreciate the fact that there is a specialized implementation for float types in an attempt to mitigate error accumulation. After posting my previous message I became convinced that the behavior I was seeing was indeed a bug. The specialized fp implementation simply does not conform to the semantics specified in the documentation: "If begin < end && step < 0 or begin > end && step > 0 or begin == end, then an empty range is returned." The culprit is this assert in the `in` block of the fp implementation: ``` assert((end - begin) / step >= 0, "iota: incorrect startup parameters"); ``` This effectively prevents iota from ever returning an empty range. Git blame points to a commit from March 2015. It's unbelievable to me this hasn't been fixed in almost 8 years. Would anyone volunteer to file a bug report? I attempted to do it myself but I would need to create an account in the Issue Tracking System, and apparently it doesn't accept gmail addresses anymore? (facepalm). Arredondo.
Bug or feature? iota has different semantics for integer and float arguments
Consider: ``` import std.range.iota; auto r = iota(5, 0); ``` `r` is an empty range, as it should be. But if you call: ``` auto r = iota(5.0, 0); ``` then you get an exception (incorrect startup parameters). This was unexpected, and a pain to debug. What is the rationale behind iota having different semantics depending on whether the arguments are floats or not? Arredondo.
Re: Integer programming in D?
On Monday, 19 July 2021 at 14:37:01 UTC, jmh530 wrote: glpk can handle mixed integer programming problems. Since it is a C library, it would be pretty easy to call from D but I don't see a binding or anything available. I would try to call it with dpp and if that doesn't work then something else like dstep. Thanks. I'll take a look.
Integer programming in D?
Is there an integer linear programming/discrete optimization library for D? an equivalent to the JuMP library for Julia for instance. Doesn't have to be too big, I really only need to solve a few smallish binary linear systems, but taking a quick look at code.dlang I did not immediately find anything. Cheers! Arredondo.
Re: How to sort a multidimensional ndslice?
On Tuesday, 18 August 2020 at 04:07:56 UTC, 9il wrote: To reorder the columns data according to precomputed index: auto index = a.byDim!1.map!sum.slice; Hello Ilya, thanks for the answer! Unfortunately I can't use it because I don't have (and can't define) a sorting index for my columns. I only have a predicate `larger(c1, c2)` that compares two columns to decide which one is "larger". Cheers! Armando.
How to sort a multidimensional ndslice?
I want to sort a two-dimensional ndslice by its columns according
to some predefined predicate.
What I mean is _not_ sorting the contents of each column
individually, but instead to reorder the entire columns of the
matrix so that they are sorted according to some "greater than"
function.
Here's a MWE (the `larger` function is just an example):
```
import std.stdio;
import mir.ndslice.slice;
import mir.ndslice.sorting;
void main() {
auto a = [[1, -1, 3, 2],
[0, -2, 3, 1]].sliced;
writeln(a);
a.byDim!1.sort!((u, v) => larger(u, v));
writeln(a);
}
auto larger(C)(C u, C v) {
import mir.math.sum : sum;
return sum(u) > sum(v);
}
```
I would have expected this to print:
[[1, -1, 3, 2], [0, -2, 3, 1]]
[[3, 2, 1, -1], [3, 1, 0, -2]]
but instead it prints
[[1, -1, 3, 2], [0, -2, 3, 1]]
[[1, -1, 3, 2], [0, -2, 3, 1]]
i.e, nothing happens!
Any suggestions?
Arredondo.
in vs inout
The recent change log for v2.092.0 Beta says that with the new implementation for the `in` storage class: `in` should be the storage class of choice for purely input function parameters. I had been using inout for some time now for "purely input function parameters". Is there a case to be made in favor of const? why would be scope const preferred over scope inout? Cheers! Arredondo.
Re: Get variable symbol name that was passed to a paramater?
So, 6 years later, what is the idiomatic way of doing this? Has
there been any progress on this matter?
As far as I can tell from this thread, all proposed solutions are
imperfect in some way, which is a shame for a language with
"Second to none reflection".
Arredondo.
On Saturday, 9 November 2013 at 09:12:21 UTC, Rob T wrote:
I have a template function called "inspect" that takes two
variables as arguments,
void inspect(T)( string symbol, T value )
{
writeln(symbol, " = ", value);
}
int y = 100;
inspect( y.stringof, y );
writes to console
y = 100
I am wondering if there's a way to pass only the variable and
have the inspect function determine the variable's symbol name
as passed rather than have to pass both the name and value
separately?
void inspect(T)( T value )
{
writeln( ? , " = ", value);
}
I've tried a template with alias parameter
void inspect(alias value)()
{
writeln( value.stringof , " = ", value);
}
It works except when passing a variable contained inside a
struct or class due to a missing "this" during evaluation, I'm
also worried about template bloat.
I figure mixins may help, but not if it's same or less
convenient to use as the double entry method.
Any suggestions, or is it just impossible or not worth trying?
--rt
Re: Unexpected behaviour in associative array
On Sunday, 21 April 2019 at 00:13:15 UTC, 9il wrote: In the latest release you can do yourSlice.lightConst.field lightConst converts from const slice to slice of const. I will add const and immutable field to the next major release. That is very good to know. BWT, I think ndslice is an amazing contribution, and you are doing a great job. I do find it hard to navigate sometimes though, with the rather thin documentation that it has. More docs would definitely be at the top of my wish list :) Kind regards, Arredondo
Re: Unexpected behaviour in associative array
On Saturday, 20 April 2019 at 14:24:34 UTC, 9il wrote: On Friday, 19 April 2019 at 12:37:10 UTC, Arredondo wrote: Slice!(Contiguous, [2], byte*) payload; BTW, any reason not to use the new version of ndslice? For new API it would be: Slice!(byte*, 2, Contiguous) or just Slice!(byte*, 2) I think this new ndslice API is newer than my code. I might consider upgrading though, maybe in the new version Slice.field() is const, so I can use my preferred implementation of toHash()?
Re: Unexpected behaviour in associative array
On Friday, 19 April 2019 at 12:48:32 UTC, Adam D. Ruppe wrote: It might just be that toHash is secretly dependent on various attributes in the signature. You nailed it. This was it. It was not trivial to add the missing @safe and const attributes, but it worked. Thanks!
Re: Unexpected behaviour in associative array
On Friday, 19 April 2019 at 12:43:06 UTC, Adam D. Ruppe wrote: On Friday, 19 April 2019 at 12:03:33 UTC, Arredondo wrote: key in aa Keep in mind that D's `in` operator returns a *pointer* to the element, or null if it isn't there. If you aren't treating the return value as a pointer, you could hit trouble. I understand that. The issue is that it should't return null if theres a matching element in the aa!
Re: Unexpected behaviour in associative array
On Friday, 19 April 2019 at 11:32:17 UTC, Andre Pany wrote:
Could you please post the coding, otherwise it is quite hard to
help you.
Here's a reasonably-sized code fragment that demonstrates the
issue. I hope the comments along the way are descriptive enough
Thanks,
Arredondo
--
// this is a thin wrapper around a 2D byte matrix
// that uses an ndslice internally
struct State {
import std.digest.murmurhash;
import mir.ndslice;
this(byte rows, byte cols) inout @safe pure nothrow {
payload = slice!byte([rows, cols], 0);
}
size_t toHash() pure nothrow {
byte[] data = payload.field();
immutable digest = digest!(MurmurHash3!(128, 64))(data);
immutable hash = *cast(size_t*) [0];
return hash;
}
bool opEquals(ref inout State q) inout @safe pure nothrow {
return payload == q;
}
Slice!(Contiguous, [2], byte*) payload;
alias payload this;
}
void main(string[] args) {
import std.stdio;
// create a key
auto key1 = State(2, 2);
key1[0, 0] = cast(byte) 1;
// insert it in an assoc. array
int[State] map;
map[key1] = 101;
// create the exact same key
auto key2 = State(2, 2);
key2[0, 0] = cast(byte) 1;
// it is an identical key as far as the aa is concerned
assert(key1.opEquals(key2));
assert(key2.opEquals(key1));
assert(key1.toHash == key2.toHash);
// yet it is not in the map
writeln(key1 in map); // prints some memory address
writeln(key2 in map); // prints null <-- unexpected behaviour
}
Re: Unexpected behaviour in associative array
On Friday, 19 April 2019 at 11:55:41 UTC, Andre Pany wrote: https://dub.pm/commandline.html#dustmite Thanks, but it appears that this tool is used to isolate the cause of build errors, and I'm not having build errors, just unexpected behavior at runtime. Something I have observed while continuing the tinkering is that sometimes the call key in aa segfaults (Program exited with code -11) when key is not in the aa. Very strange indeed.
Re: Unexpected behaviour in associative array
On Friday, 19 April 2019 at 11:32:17 UTC, Andre Pany wrote: Could you please post the coding, otherwise it is quite hard to help you. Kind regards Andre Yes, I'm working on isolating the problem. It's a bit laborious because the custom Struct is actually a wrapper around an ndslice matrix, and I still don't know if the issue is reproducible without this dependency.
Unexpected behaviour in associative array
Hi all, I'm using a custom Struct as the key type in an associative array. I have defined the toHash() and opEquals(...) functions, and the problem I'm having is that the test mykey in aa always fails (returns null) even though there are keys in the aa that return identical toHash() values than mykey and return true for opEquals. This is beyond frustrating, because at this point I'm pretty much out of ideas. Have you had this problem before? Any tips or suggestions would be much appreciated. Arredondo.
Stateful modules and extern(C)
I want to call some of my D code from Python. I'm annotating the
pertinent functions with extern(C) export, as in
module foo;
extern(C) export int initialize() {
return 42;
}
I compile with:
dmd -fPIC -shared ./foo.d
From the Python end, I can load the library using ctypes and the
call works fine. The problem is, as soon as I have some state in
my D module, as in:
module foo;
int call_count;
extern(C) export int initialize() {
++call_count;
return 42;
}
the call to initialize from python gives:
AttributeError: ./foo.so: undefined symbol: initialize
Can you share some tips/examples of non-trivial/stateful D
modules that are successfully export(C)ed and maybe consumed with
ctypes? Are there any specific attributes that I need to annotate
my module globals with?
Thank you!
Arredondo.
Re: Unexpected behaviour of foreach statement
On Friday, 2 March 2018 at 10:32:08 UTC, Jonathan M Davis wrote:
foreach does not support indices for ranges, only arrays. When
you have
foreach(e; range)
it gets lowered to
foreach(auto __range = range; !__range.empty;
__range.popFront())
{
auto e = __range.front;
}
There are no indices involved there, and if a range isn't a
random-access range, it doesn't support any kind of indices
anyway. The compiler would have to add a variable to count the
elements, and it doesn't support that.
I understand. I guess I was expecting the compiler to
automatically do something along the lines of what enumerate
does. Although, a nicer error message would have saved the day
just as well.
Arredondo
Re: Unexpected behaviour of foreach statement
On Friday, 2 March 2018 at 10:34:31 UTC, bauss wrote:
You can also call "array" from "std.array".
auto range = iota(5).array;
foreach (i, el; range) {
writeln(i, ": ", el);
}
Thank you. That's how I had it in my original code, I was just
trying to avoid gratuitous memory allocation.
Arredondo
Re: Unexpected behaviour of foreach statement
On Friday, 2 March 2018 at 10:27:27 UTC, Nicholas Wilson wrote: try https://dlang.org/phobos/std_range.html#enumerate This worked. Thank you!
Unexpected behaviour of foreach statement
Hi,
The following works as expected:
auto range = [1, 2, 3, 4, 5];
foreach (i, el; range) {
writeln(i, ": ", el);
}
but this slight modification doesn't:
auto range = iota(5);
foreach (i, el; range) {
writeln(i, ": ", el);
}
DMD 2.078.3 says:
Error: cannot infer argument types, expected 1 argument, not 2
The error message is not helpful either, because indicating the
types, as in:
foreach (int i, int el; range) { ... }
throws the same error.
What's going on here?
Arredondo
Re: Help using lubeck on Windows
On Monday, 26 February 2018 at 17:40:05 UTC, jmh530 wrote: On Monday, 26 February 2018 at 17:12:51 UTC, Arredondo wrote: Okay, so I just finished configuring WSL. The way I want to use my app is having it read from stdin, do some calculations, and write to stdout, in an infinite cycle. I wanted to feed this to some higher level algorithms in Wolfram Mathematica, that's why I needed Windows binaries. But it turns out that I can feed the shell.exe program itself to Mathemtaica, and from there call my compiled-in-ubuntu app and do the same thing. So it looks like I could get away with using WSL after all. I am new to linux, so I could use some help, and you have clearly done this before. So far I've managed to install dmd and OpenBlas. I guess I should pass some commands to dmd so it knows where to look for the static blas and lapack libraries. Any suggestions? Thank you, Arredondo. I was using Ubuntu with WSL. For installing, I think I had done sudo apt update sudo apt upgrade sudo apt-get install libblas-dev liblapack-dev I think on Linux you can just put blas and lapack in the libs in your dub.json. I always just try to do some simple example first, usually just calling dmd/ldc directly. So long as I can translate it to a dub configuration that is equivalent, then I will switch over. You might look at some of the dub.jsons that are used in Lubeck and other mir projects for reference. This worked. Thank you jmh530! I feel like at this moment, lubeck should be clearly marked "not Windows ready", as not everybody will have the inclination/patience to deal with incompatible object file formats or the Windows subsystem for Linux. I wonder if compiling OpenBlas from source using DMC would solve this. I also wonder if the resulting binaries would be as fast. Arredondo
Re: Help using lubeck on Windows
On Monday, 26 February 2018 at 05:15:48 UTC, jmh530 wrote: On Sunday, 25 February 2018 at 14:25:04 UTC, Arredondo wrote: On Friday, 23 February 2018 at 16:56:13 UTC, jmh530 wrote: I had given up and used WSL at this point rather than compile it myself with CMAKE. Less of a headache. I don’t understand. Wouldn’t WSL produce Linux binaries? I need my project compiled as a Windows .exe, other parts of my development environment depend on that. Usually what I need is to do some calculation and print the results in the console or write them to a file, so it's fine for me. If you need an exe, then I guess WSL wouldn't be for you. Okay, so I just finished configuring WSL. The way I want to use my app is having it read from stdin, do some calculations, and write to stdout, in an infinite cycle. I wanted to feed this to some higher level algorithms in Wolfram Mathematica, that's why I needed Windows binaries. But it turns out that I can feed the shell.exe program itself to Mathemtaica, and from there call my compiled-in-ubuntu app and do the same thing. So it looks like I could get away with using WSL after all. I am new to linux, so I could use some help, and you have clearly done this before. So far I've managed to install dmd and OpenBlas. I guess I should pass some commands to dmd so it knows where to look for the static blas and lapack libraries. Any suggestions? Thank you, Arredondo.
Re: Help using lubeck on Windows
On Friday, 23 February 2018 at 16:56:13 UTC, jmh530 wrote: I had given up and used WSL at this point rather than compile it myself with CMAKE. Less of a headache. I don’t understand. Wouldn’t WSL produce Linux binaries? I need my project compiled as a Windows .exe, other parts of my development environment depend on that.
Re: Help using lubeck on Windows
On Friday, 23 February 2018 at 18:29:09 UTC, Ilya Yaroshenko wrote: openblas.net contains precompiled openblas library for Windows. It may not be optimised well for exactly your CPU but it is fast enought to start. Put the library files into your prodject and add openblas library to your project dub configuration. A .dll files are dinamic, you need also a .lib /.a to link with. OpenBLAS contains both cblas and lapack api by default. We defenetely need to add an example for Windows Best Ilya It is not working my friend. I've been at this for nearly two full days now. All the .lib/.a files I have tried for BLAS and LAPACK just fail to link, including those from openblas.net. rdmd insists on: Error 42: Symbol Undefined _cblas_dgemm Error 42: Symbol Undefined _cblas_dger Error: linker exited with status 2 Am I missing something? Thank you.
Help using lubeck on Windows
Help using lubeck on Windows I'd like to experiment with linear algebra in D, and it looks like lubeck is the way to do it right now. However, I'm having a hard time dealing with the CBLAS and LAPACK dependencies. I downloaded the OpenBLAS binaries for Windows (libopenblas.dll), but I am cluless as to what to do with them. I can't find an example of how to link them/what commands to pass to dmd. Any help deeply appreciated.
Re: How to proceed with learning to code Windows desktop applications?
On Tuesday, 30 January 2018 at 18:52:18 UTC, I Lindström wrote: On Tuesday, 30 January 2018 at 12:30:36 UTC, rjframe wrote: VS release builds compile to native now by default; for easy Windows programming, you really can't beat C# and drawing the GUI (Windows Forms, not necessarily the new stuff). If the OP wants to learn what's needed for more complex GUI tasks (like for most non-simple applications), learning to build a GUI from source is kind of necessary though. I've been looking into C# and VS2017 today along with VisualD. Reading through all this it looks like the simplest path is to learn C# and VS and go from there. I've found a pile of courses on LinkedIn that seem to build up to what I need. What makes me sad is that I have to drop D for at least the time being. As other have said, WPF and C# is the way to go for Windows GUI programming, but you don't necessarily need to drop D. You could write your interface code in VS and have it call your D library via pinvoke (Platform Invoke). To make this work you must mark your public D functions with extern(C). Read the documentation on extern(C) and PInvoke. Honestly, I don't know why more people don't do this. It really seems to be like the best of both worlds, as C# + WPF is king for Windows GUI and D is king for library development. The only drawback I can think of is you have to expose your awesome D library via a dumped down C interface.
