Mir-Ion 2.3.0
[got](https://github.com/libmir/mir-ion/blob/master/source/mir/ser/cbor.d) CBOR serialzation. It is the fastest Mir serialization target.
I have no plans for CBOR deserialization. It can be implemented
using the MsgPack deserialization target as a draft.
Hi Walter and Dlang Community,
Mir libraries or their parts can be moved to Phobos/Druntime
under BSL-1.0. I won't be able to help with mir migration except
for general review and coordination with copyright holders. I use
D for work but am no longer an active open-source contributor.
-
On Tuesday, 20 December 2022 at 19:46:36 UTC, John Colvin wrote:
On Tuesday, 20 December 2022 at 00:40:07 UTC, H. S. Teoh wrote:
On Mon, Dec 19, 2022 at 04:16:57PM -0800, Walter Bright via
Digitalmars-d-announce wrote:
On 12/19/2022 4:35 AM, Adam D Ruppe wrote:
> On Monday, 19 December 2022 at
On Friday, 25 February 2022 at 06:03:34 UTC, Nonobvious wrote:
From [Go Your Own Way (Part Two: The
Heap)](https://dlang.org/blog/2017/09/25/go-your-own-way-part-two-the-heap/):
[...]
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#.stdcUninitSlice
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote:
As usual please report any bugs at
https://issues.dlang.org
The compiler has some mangling or attributes deduction bug when
compiling or linking tagged self-referencing algebraic.
The GitHub job:
On Sunday, 30 January 2022 at 10:58:33 UTC, 9il wrote:
[mir.algebraic](http://mir-core.libmir.org/mir_algebraic.html)
I like `suit` a lot. It helps to define very clean visitors.
```d
import std.traits: isDynamicArray, Unqual;
import std.meta: templateNot;
alias V = Variant!(long, int,
[mir.algebraic](http://mir-core.libmir.org/mir_algebraic.html)
additions:
- `some`, `none`, and `suit` second level algebraic visitor
handlers
- `@reflectErr` UDA
- `Err` auto expanded wrapper when `@reflectErr` can't be used
- Required utility API
```d
import mir.algebraic;
import
On Saturday, 27 November 2021 at 12:16:39 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 27 November 2021 at 11:35:21 UTC, Salih Dincer
wrote:
I also found similar errors but couldn't solve them. I think
it has to do with mir.slice.kind. Exactly Kind Topology...
I won't use parallel for it as a
On Friday, 20 August 2021 at 16:55:57 UTC, David Gileadi wrote:
On 8/20/21 9:54 AM, Dennis wrote:
On Friday, 20 August 2021 at 16:44:53 UTC, 9il wrote:
Builtin complex numbers have been replaced with mir.complex
in the following packages:
Out of curiosity, how did std.complex fall short?
On Friday, 20 August 2021 at 16:54:07 UTC, Dennis wrote:
On Friday, 20 August 2021 at 16:44:53 UTC, 9il wrote:
Builtin complex numbers have been replaced with mir.complex in
the following packages:
Out of curiosity, how did std.complex fall short?
There are few reasons. The main one is that
mir.complex [1] has been added to mir-core v1.1.80
Builtin complex numbers have been replaced with mir.complex in
the following packages:
- cblas,
- lapack
- mir-blas
- mir-lapack
- lubeck
[1] http://mir-core.libmir.org/mir_complex.html
MRs are welcome.
Kind regards,
Ilya
On Sunday, 16 May 2021 at 10:28:24 UTC, Tobias Pankrath wrote:
On Sunday, 16 May 2021 at 09:50:21 UTC, 9il wrote:
mir-ion and Asdf JSON libraries have been added to the
Kostya/benchmarks.
https://github.com/kostya/benchmarks#json
If we exclude parsers with inaccurate number parsing then the
mir-ion and Asdf JSON libraries have been added to the
Kostya/benchmarks.
https://github.com/kostya/benchmarks#json
If we exclude parsers with inaccurate number parsing then the top
will be
1. C++, simdjson
2. Rust, Serde
3. Dlang, Mir Amazon's Ion DOM
4. Dlang, Mir Asdf DOM
5. C++
Hi all,
As you may know, [Mir](https://github.com/libmir) provides two
JSON libraries: [asdf](http://asdf.libmir.org/) and WIP
[mir-ion](http://mir-ion.libmir.org/). The last one is based on
Amazon's Ion dual format.
Both libraries provide a direct de/serialization API that doesn't
need to
On Tuesday, 23 February 2021 at 03:48:15 UTC, Max Haughton wrote:
On Monday, 22 February 2021 at 07:14:26 UTC, 9il wrote:
On Sunday, 21 February 2021 at 16:18:05 UTC, Kyle Ingraham
wrote:
I am trying to convert sRGB pixel values to XYZ with mir
using the following guide:
On Sunday, 21 February 2021 at 16:18:05 UTC, Kyle Ingraham wrote:
I am trying to convert sRGB pixel values to XYZ with mir using
the following guide:
http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
[...]
mir-glas is deprecated experimental project. It is worth use
mir-blas
On Friday, 29 January 2021 at 15:35:49 UTC, drug wrote:
Between is there a plan to implement some sort of static slice
where the lengths of the dimensions are known in compile time?
Compiler help is very useful.
No. BLAS/LAPACK API's can't use compile-time information. User
matrix loops can
On Tuesday, 26 January 2021 at 14:43:08 UTC, drug wrote:
It is not easy to understand what mir library one should use to
work with matrices. mir-glas turns out unsupported now and I
try to use mir-blas. I need to reimplement my Kalman filter
version to use more high dimension matrix than 4x4
On Wednesday, 6 January 2021 at 02:30:30 UTC, Walter Bright wrote:
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
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
On Tuesday, 5 January 2021 at 03:20:16 UTC, Walter Bright wrote:
On 1/4/2021 4:11 AM, 9il wrote:
[...]
The reason those switches are provided is because the
write/read is a performance hog.
D provides a couple functions in druntime which guarantee
rounding intermediate values to
On Monday, 4 January 2021 at 05:58:09 UTC, Walter Bright wrote:
On 1/3/2021 8:37 PM, 9il wrote:
I didn't believe it when I got a similar answer about IEEE
floating-point numbers: D doesn't pertinent to be IEEE 754
compatible language and the extended precision bug is declared
to be a language
On Sunday, 3 January 2021 at 22:50:16 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
You should put yourself in the boots of Atila. If you accept a
change that later turns out to be bad idea you cant just take
it out.
This is just silly. You don't
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
Yes, it wasn't explicit. He didn't write bad words, he did a bad
decision. Bad for D.
On Thursday, 24 December 2020 at 11:05:16 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
[...]
Non-concept version is more verbose, but yeah, works fine in
C++17:
namespace detail {
template class F, class U>
static constexpr void
On Wednesday, 23 December 2020 at 18:23:25 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
Have you read the DMD PR thread (not the DIP itself)?
It was a mockery executed by Atila accompanied by silent
Walter's and Andrei's ignoring.
I am not sure
On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
I don't use tensors much, how does it help zipping?
Safe optimizations. Mir uses unsafe ugly workarounds somehow in
some places and doesn't improve some
On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
https://issues.dlang.org/show_bug.cgi?id=16486
https://issues.dlang.org/show_bug.cgi?id=16465
https://issues.dlang.org/show_bug.cgi?id=10884
and the oldest one
On Wednesday, 23 December 2020 at 16:51:33 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 16:20:37 UTC, Timon Gehr
wrote:
On 23.12.20 16:37, Ola Fosheim Grøstad wrote:
On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote:
You, Andrey, and Atila don't care about language
On Wednesday, 23 December 2020 at 15:37:45 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote:
You, Andrey, and Atila don't care about language features that
have been requested for Mir or even more: rejecting DIP draft
+ DMD partial implementation for no
On Wednesday, 23 December 2020 at 16:20:37 UTC, Timon Gehr wrote:
On 23.12.20 16:37, Ola Fosheim Grøstad wrote:
On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote:
You, Andrey, and Atila don't care about language features
that have been requested for Mir or even more: rejecting DIP
On Tuesday, 22 December 2020 at 19:45:43 UTC, Paul Backus wrote:
On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote:
On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:
On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote:
"Struct non-static methods marked with the return
On Tuesday, 22 December 2020 at 21:53:20 UTC, Walter Bright wrote:
If you don't want the formatting code to be part of Phobos, I
respect your choice.
Why did you think I may want it?
Phobos is almost not used in my work.
You, Andrey, and Atila don't care about language features that
have
On Tuesday, 22 December 2020 at 17:07:16 UTC, ag0aep6g wrote:
On Tuesday, 22 December 2020 at 16:54:56 UTC, 9il wrote:
On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:
[...]
[...]
If I am correct Dlang doesn't provide an instrument to
validate it, isn't it?
What alternative
On Tuesday, 22 December 2020 at 16:43:30 UTC, ag0aep6g wrote:
On Tuesday, 22 December 2020 at 16:32:20 UTC, 9il wrote:
"Struct non-static methods marked with the return attribute
ensure the returned reference will not outlive the struct
instance."
The issue isn't that the reference outlives
On Tuesday, 22 December 2020 at 14:27:02 UTC, ag0aep6g wrote:
On 22.12.20 04:56, 9il wrote:
6. Algebraic type subsets are supported by `get`,
`trustedGet`, `_is`, and `this` primitives. You can operate
with algebraic subset as with the type of the original
typeset. [1]
"trustedGet" - That
On Tuesday, 22 December 2020 at 09:18:25 UTC, Walter Bright wrote:
On 12/21/2020 8:33 PM, 9il wrote:
These functions in Phobos would make a great advertisement
for Mir.
How this possible?
A lot more people will have Phobos than Phobos+Mir. If they are
perusing the source code and see Mir
On Tuesday, 22 December 2020 at 04:33:55 UTC, 9il wrote:
On Tuesday, 22 December 2020 at 02:02:24 UTC, Walter Bright
wrote:
On 12/20/2020 9:42 PM, 9il wrote:
On Sunday, 20 December 2020 at 22:21:56 UTC, Walter Bright
wrote:
Can the improved parsing be added to D? (It would need to be
Boost
On Tuesday, 22 December 2020 at 02:02:24 UTC, Walter Bright wrote:
On 12/20/2020 9:42 PM, 9il wrote:
On Sunday, 20 December 2020 at 22:21:56 UTC, Walter Bright
wrote:
Can the improved parsing be added to D? (It would need to be
Boost licensed.)
If I am correct there is open PR that set DMD to
On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov
[ZombineDev] wrote:
How does your work compare to sumtype? Would mir.algebraic
offer any benefits, which would make it worth switching over?
replied at
https://forum.dlang.org/post/zlphfxktclgdookqt...@forum.dlang.org
If we can work
On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath
wrote:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
Truly algebraic Variant and Nullable with an order-independent
list of types.
Thanks for sharing it!
Could you give a (very short) explanation on why sumtype could
not
On Sunday, 20 December 2020 at 22:21:56 UTC, Walter Bright wrote:
On 12/13/2020 10:47 PM, 9il wrote:
Note that D's compiler floating-point literals parsing and
Phobos floating-point literals parsing are not precise
[5,6,7,8]. It is recommended to use Mir's to!double/float/real
to convert
On Monday, 14 December 2020 at 06:47:32 UTC, 9il wrote:
Hi all,
Generic version of Ryu algorithm [1] was ported to D, well
optimized, and adopted to mir packages.
[...]
Default formatting has been reworked to be more human-friendly:
1.23e1 -> 1.23
On Thursday, 17 December 2020 at 15:38:52 UTC, jmh530 wrote:
On Thursday, 17 December 2020 at 15:12:12 UTC, 9il wrote:
On Wednesday, 16 December 2020 at 16:14:08 UTC, jmh530 wrote:
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:
[...]
What about making it into a sub-package, as
On Wednesday, 16 December 2020 at 18:14:54 UTC, Oleg B wrote:
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:
On Wednesday, 16 December 2020 at 14:54:26 UTC, Oleg B wrote:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
[...]
Great library! Have you any plan to separate
On Wednesday, 16 December 2020 at 16:14:08 UTC, jmh530 wrote:
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote:
[snip]
Thanks! Maybe, but mir-core is quite small itself and
mir.algebraic is the only part that would be extended or
updated in the near future. Other parts are quite
On Wednesday, 16 December 2020 at 14:54:26 UTC, Oleg B wrote:
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:
Truly algebraic Variant and Nullable with an order-independent
list of types.
Nullable is defined as
```
alias Nullable(T...) = Variant!(typeof(null), T);
```
Variant and
Hi all,
Generic version of Ryu algorithm [1] was ported to D, well
optimized, and adopted to mir packages.
It allows printing the shortest (scientific) decimal form of a
floating-point number that if it is converted back would produce
the same floating-point number.
The update requires
On Wednesday, 9 December 2020 at 14:34:18 UTC, Andre Pany wrote:
Hi,
I want to port some Python coding and try have as much similiar
coding as
possible.
I thought I can have a mir variant which stores either class A
or B
and I can call at runtime a method like this:
```
/+ dub.sdl:
Hi all,
Compiler Explorer [1] is an interactive compiler. The left-hand
pane shows the editable code. The right, the assembly output of
having compiled the code with a given compiler and settings.
HowTo
1. open the site [1]
2. press 'Libraries' bottom on the right window and pick required
On Monday, 7 December 2020 at 12:28:39 UTC, data pulverizer wrote:
On Monday, 7 December 2020 at 02:14:41 UTC, 9il wrote:
I don't know. Tensors aren't so complex. The complex part is a
design that allows Mir to construct and iterate various kinds
of lazy tensors of any complexity and have
On Sunday, 6 December 2020 at 17:30:13 UTC, data pulverizer wrote:
On Saturday, 5 December 2020 at 07:44:33 UTC, 9il wrote:
sweep_ndslice uses (2*N - 1) arrays to index U, this allows
LDC to unroll the loop.
For example, for 2D case, withNeighboursSum [2] will store the
pointer to the
On Friday, 4 December 2020 at 20:26:17 UTC, data pulverizer wrote:
On Friday, 4 December 2020 at 14:48:32 UTC, jmh530 wrote:
It looks like all the `sweep_XXX` functions are only defined
for contiguous slices, as that would be the default if define
a Slice!(T, N).
How the functions access
On Friday, 4 December 2020 at 03:48:15 UTC, Walter Bright wrote:
On 12/3/2020 8:27 AM, 9il wrote:
Since the first announcement [0] the original benchmark [1]
has been boosted [2] with Mir-like implementations.
This is really great! Can you write an article about it? Such
would be really
On Friday, 4 December 2020 at 02:35:49 UTC, data pulverizer wrote:
On Thursday, 3 December 2020 at 21:28:04 UTC, jmh530 wrote:
Am I correct in assuming that the data in the NDSlice is also a
single array?
sweep_ndslice uses (2*N - 1) arrays to index U, this allows LDC
to unroll the loop.
On Thursday, 3 December 2020 at 17:08:58 UTC, jmh530 wrote:
On Thursday, 3 December 2020 at 16:27:59 UTC, 9il wrote:
Looks good, but a few typos:
Thanks!
On Thursday, 3 December 2020 at 16:50:39 UTC, Andre Pany wrote:
On Thursday, 3 December 2020 at 16:27:59 UTC, 9il wrote:
Hi all,
Since the first announcement [0] the original benchmark [1]
has been boosted [2] with Mir-like implementations.
D+Mir:
1. is more abstract than NumPy
2.
Hi all,
Since the first announcement [0] the original benchmark [1] has
been boosted [2] with Mir-like implementations.
D+Mir:
1. is more abstract than NumPy
2. requires less code for multidimensional algorithms
3. doesn't require indexing
4. uses recursion across dimensions
5. a few
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt
wrote:
Dear all,
to compare MIR and Numpy in the HPC context, we implemented a
multigrid solver in Python using Numpy and in D using Mir and
perforemd some benchmarks with them.
You can find our code and results here:
On Wednesday, 18 November 2020 at 13:14:37 UTC, jmh530 wrote:
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt
wrote:
It also looks like you are compiling on ldc with -mcpu=native
--boundscheck=off. Why not -O as well?
-O is added by DUB
Truly algebraic Variant and Nullable with an order-independent
list of types.
Nullable is defined as
```
alias Nullable(T...) = Variant!(typeof(null), T);
```
Variant and Nullable with zero types are allowed.
`void` type is supported.
Visitors are allowed to return different types.
Cyclic
On Monday, 26 October 2020 at 14:31:00 UTC, Vino wrote:
Hi All,
Is it possible to create a multi dimensional associative
array using mir.ndslice,
if yes,
(1): request you to point me to some example / docs
(2): below is an example multi dimensional associative array
using the core
On Sunday, 25 October 2020 at 06:05:27 UTC, Vino wrote:
Hi All,
Currently we are testing various json module such as
"std.json, std_data_json, vibe.data.json and asdf", the below
code works perfectely while use "std_data_json or
vibe.data.json" but not working as expected when we use
On Sunday, 11 October 2020 at 17:10:19 UTC, jmh530 wrote:
On Sunday, 11 October 2020 at 10:14:04 UTC, tastyminerals wrote:
On Thursday, 8 October 2020 at 16:40:01 UTC, 9il wrote:
It is a pleasure to announce the Dlang Statistical Package by
John Michael Hall.
[...]
Awesome! Are there any
It is a pleasure to announce the Dlang Statistical Package by
John Michael Hall.
API
http://mir-stat.libmir.org/
GitHub
http://github.com/libmir/mir-stat
DUB
https://code.dlang.org/packages/mir-stat
The initial release provides descriptive statistics and
algorithms for transforming data
On Tuesday, 29 September 2020 at 04:52:11 UTC, Shaleen Chhabra
wrote:
I wish to use load / save for sparse compressed matrices using
mir.
import mir.sparse;
auto sp = sparse!double(5, 8);
auto crs = sp.compress;
How can I save/load sparse compressed arrays in `npz` format?
On Monday, 14 September 2020 at 09:50:16 UTC, Christoph wrote:
Hi Ilya,
On Sunday, 13 September 2020 at 19:29:31 UTC, 9il wrote:
[...]
I have tested it with dmd and ldc and called them just with
$ dub build --compiler=ldc(dmd)
with no more configurations in the dub.json file.
[...]
On
On Sunday, 13 September 2020 at 14:48:30 UTC, Christoph wrote:
Hi all,
I am trying to implement a sweep method for a 2D Red-black
Gauss-Seidel Solver with the help of mir and its slices.
The fastest Version I discovered so far looks like this:
```
void sweep(T, size_t Dim : 2, Color color)(in
On Wednesday, 2 September 2020 at 07:01:48 UTC, Shaleen Chhabra
wrote:
Hi,
The libmir libraries can be found here:
https://github.com/libmir
I wish to use mir-algorithm and numir so that i can directly
use .npy format from python and perform the required analysis.
I checked out latest
On Tuesday, 18 August 2020 at 13:07:56 UTC, Arredondo wrote:
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
The following code just sorts each row:
--
/+dub.sdl:
dependency "mir-algorithm" version="~>3.9.24"
+/
import mir.ndslice;
import mir.ndslice.sorting;
import mir.algorithm.iteration: each;
void main() {
// fuse, not sliced if you use an array of arrays for argument
auto a = [[1,
On Wednesday, 15 July 2020 at 11:37:23 UTC, jmh530 wrote:
On Wednesday, 15 July 2020 at 11:26:19 UTC, 9il wrote:
[snip]
@fmamath private double sd(T)(Slice!(T*, 1) flatMatrix)
@fastmath violates all summation algorithms except `"fast"`.
The same bug is in the original author's post.
I
On Wednesday, 15 July 2020 at 11:23:00 UTC, jmh530 wrote:
On Wednesday, 15 July 2020 at 05:57:56 UTC, tastyminerals wrote:
[snip]
Here is a (WIP) project as of now.
Line 160 in
https://github.com/tastyminerals/mir_benchmarks_2/blob/master/source/basic_ops.d
std of [60, 60] matrix 0.0389492
On Wednesday, 15 July 2020 at 07:34:59 UTC, tastyminerals wrote:
On Wednesday, 15 July 2020 at 06:57:21 UTC, 9il wrote:
On Wednesday, 15 July 2020 at 06:55:51 UTC, 9il wrote:
On Wednesday, 15 July 2020 at 06:00:46 UTC, tastyminerals
wrote:
On Wednesday, 15 July 2020 at 02:08:48 UTC, 9il
On Wednesday, 15 July 2020 at 06:00:46 UTC, tastyminerals wrote:
On Wednesday, 15 July 2020 at 02:08:48 UTC, 9il wrote:
On Tuesday, 14 July 2020 at 19:04:45 UTC, tastyminerals wrote:
@fastmath private double sd0(T)(Slice!(T*, 1) flatMatrix)
@fastmath shouldn't be really used with summation
On Wednesday, 15 July 2020 at 06:55:51 UTC, 9il wrote:
On Wednesday, 15 July 2020 at 06:00:46 UTC, tastyminerals wrote:
On Wednesday, 15 July 2020 at 02:08:48 UTC, 9il wrote:
On Tuesday, 14 July 2020 at 19:04:45 UTC, tastyminerals wrote:
@fastmath private double sd0(T)(Slice!(T*, 1)
On Tuesday, 14 July 2020 at 21:58:49 UTC, Cecil Ward wrote:
Does anyone know if this has already been published by someone
else?
https://github.com/libmir/mir-core/blob/master/source/mir/utility.d#L29
We test LDC and DMC. CI needs an update to be actually tested
with GDC.
On Tuesday, 14 July 2020 at 20:56:06 UTC, DanielG wrote:
I have some D-wrapped C libraries I'm considering publishing to
DUB, mainly for my own use but also for anybody else who might
benefit. I've never done this before so I have some questions:
- Should there be any obvious relationship
On Wednesday, 15 July 2020 at 02:08:48 UTC, 9il wrote:
On Tuesday, 14 July 2020 at 19:04:45 UTC, tastyminerals wrote:
@fastmath private double sd0(T)(Slice!(T*, 1) flatMatrix)
@fastmath shouldn't be really used with summation algorithms
except the `"fast"` version of them. Otherwise, they
On Tuesday, 14 July 2020 at 19:04:45 UTC, tastyminerals wrote:
@fastmath private double sd0(T)(Slice!(T*, 1) flatMatrix)
@fastmath shouldn't be really used with summation algorithms
except the `"fast"` version of them. Otherwise, they may or may
not behave like "fast".
For now, Mir doesn't really support GDC. But we want to. Is there
are a clear way to get a specific version of GDC. Is there a
table of GDC compilers with correspnding DMD FE versions?
dlang.org refers to a deprecated page, it is weird.
On Tuesday, 7 July 2020 at 23:56:45 UTC, kinke wrote:
On Tuesday, 7 July 2020 at 23:52:05 UTC, 9il wrote:
On Tuesday, 7 July 2020 at 16:38:39 UTC, kinke wrote:
So wouldn't the trivial 'fix' be using `strtod` for double
literals and `strtof` for floats? [For LDC, we wouldn't rely
on the host C
On Tuesday, 7 July 2020 at 16:38:39 UTC, kinke wrote:
On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote:
On 6/21/2020 8:24 AM, 9il wrote:
[...]
Great work! Would you like to add it to dmd?
AFAIU, the 'problem' is that *all* floating-point literals are
parsed as real_t values,
On Tuesday, 7 July 2020 at 12:52:35 UTC, Adam D. Ruppe wrote:
On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
Businesses will not want to commit to a balkanized project.
It's been ages since I worked on a software project for a
business that didn't have many random third (and
On Tuesday, 7 July 2020 at 12:04:43 UTC, Steven Schveighoffer
wrote:
On 7/7/20 7:13 AM, 9il wrote:
[...]
Guys, this is all open source, all licensed identically. There
are ways to solve this. Practically speaking, just because DMD
depends on Mir, doesn't mean that Mir has control over how
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
On Tuesday, 7 July 2020 at 10:58:25 UTC, 9il wrote:
From a business point of view, having slightly more correct
string to float conversion holds very little value. I'll
stick with sscanf thanks...
For a high tech real markets
On Tuesday, 7 July 2020 at 12:35:57 UTC, jmh530 wrote:
On Tuesday, 7 July 2020 at 12:33:40 UTC, jmh530 wrote:
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat
wrote:
[...]
Is that not an example of how Steve thinks it should work?
Both are Boost licensed. mir-core has no external
On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote:
On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
There is no risk for DMD and DFL to depend on a Mir's Boost
licensed library. If something happens with Mir or Mir change
the
On Tuesday, 7 July 2020 at 09:28:26 UTC, Guillaume Piolat wrote:
On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
That's right, it's not about the licensing. It's that the DLF
should control the code it distributes.
Businesses will not want to commit to a balkanized project.
On Sunday, 5 July 2020 at 10:39:49 UTC, Walter Bright wrote:
On 7/5/2020 3:35 AM, Walter Bright wrote:
All of DMD, Druntime, and Phobos use Boost, except for Curl
and the zip library (which we probably shouldn't have added).
Also, there are no dependencies on Curl and zip.
We don't
On Sunday, 5 July 2020 at 08:15:53 UTC, Walter Bright wrote:
It doesn't work quite like that. The D Language Foundation
controls it. Andrei, Atila, and myself control it only as far
as we DLF empowers us to, which can change. Official parts of
the DMD distribution have to be controlled by
On Sunday, 5 July 2020 at 08:15:53 UTC, Walter Bright wrote:
On 7/5/2020 12:24 AM, 9il wrote:
On Sunday, 5 July 2020 at 06:23:35 UTC, Walter Bright wrote:
On 7/4/2020 8:09 PM, 9il wrote:
Does the float parsing code require bignum?
Yes. The decimal float parsing requires big integer arithmetic
On Sunday, 5 July 2020 at 06:23:35 UTC, Walter Bright wrote:
On 7/4/2020 8:09 PM, 9il wrote:
On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote:
On 6/21/2020 8:24 AM, 9il wrote:
So excited to finally announce we can correctly parse
floating-point numbers according to IEEE round
On Saturday, 4 July 2020 at 20:35:48 UTC, Walter Bright wrote:
On 6/21/2020 8:24 AM, 9il wrote:
So excited to finally announce we can correctly parse
floating-point numbers according to IEEE round half-to-even
(bankers) rule like in C/C++, Rust, and others.
Great work! Would you like to add
On Thursday, 25 June 2020 at 11:55:14 UTC, Mike Parker wrote:
Simen Kjærås outlines an approach to supporting head-mutable
types in D without the need for compiler or language changes.
The blog:
https://dlang.org/blog/2020/06/25/a-pattern-for-head-mutable-structures/
Reddit:
Should it always be 53? or it can be 64, when?
Thank you
On Monday, 22 June 2020 at 12:04:13 UTC, 9il wrote:
On Monday, 22 June 2020 at 10:53:02 UTC, Dukc wrote:
On Sunday, 21 June 2020 at 15:24:14 UTC, 9il wrote:
Can mir_parse handle other bases than decimal?
No, only the decimal basis is supported for now. Support for
hexadecimal FP/integer
On Monday, 22 June 2020 at 10:53:02 UTC, Dukc wrote:
On Sunday, 21 June 2020 at 15:24:14 UTC, 9il wrote:
Can mir_parse handle other bases than decimal?
No, only the decimal basis is supported for now. Support for
hexadecimal FP/integer parsing can be added though.
The basic stuff for
Hey everyone,
So excited to finally announce we can correctly parse
floating-point numbers according to IEEE round half-to-even
(bankers) rule like in C/C++, Rust, and others.
@nogc, optionally nothrow API is provided as part of Mir
Algorithm v3.9.0 [0].
The documentation is available [1].
1 - 100 of 317 matches
Mail list logo
